Сейчас почти все представляют AI-разработку одинаково. Агент пишет код. Разработчик открывает diff, делает code review и разрешает релиз. То есть мы заменили программиста на AI, но сам процесс практически не изменился.
Но меня не покидает одна мысль. Есть известный принцип утки: если что-то плавает как утка, крякает как утка и выглядит как утка — скорее всего, это утка.
Почему бы не применить этот принцип к разработке? Если после изменений система проходит все тесты, выполняет продуктовые сценарии, не ломает существующее поведение, укладывается в требования по производительности и безопасности, то зачем вообще читать код? Мы ведь никогда не проверяли код ради кода. Мы всегда пытались понять только одно — правильно ли работает система. Раньше это было невозможно без code review. Код писал человек, и только другой человек мог оценить его качество.
Но теперь код все чаще пишет AI.
И возникает странная ситуация: агент способен написать или переписать тысячу строк за несколько минут, а человек будет читать их значительно дольше. Получается, что скорость генерации уже давно обогнала скорость проверки.
Код перестает быть главным артефактом
Мне кажется, что главным артефактом разработки постепенно становится уже не код, а система проверок. Именно тесты начинают описывать ожидаемое поведение системы. Не только unit-тесты, но и интеграционные, E2E, контрактные, нагрузочные проверки, проверки безопасности и мониторинг после релиза. Если система ведет себя так, как должна, то, возможно, нам уже не так важно, как именно она реализована.
Когда-то разработчики писали на ассемблере и внимательно следили за каждой инструкцией процессора. Затем появились языки высокого уровня, и сегодня большинство из нас даже не задумывается, какой машинный код сгенерировал компилятор. Конечно, хорошему инженеру по-прежнему полезно понимать, что происходит «под капотом», и при необходимости уметь разобраться в сгенерированном коде. Но в повседневной работе мы доверяем компилятору, потому что проверяем не последовательность инструкций, а то, что программа работает правильно. Возможно, AI — это просто следующий уровень этой же эволюции. Код, написанный агентом, постепенно становится таким же промежуточным представлением, каким когда-то стал ассемблер: нас все меньше интересует, как он написан, и все больше — что в итоге делает система.
Личное наблюдение
Я неожиданно поймал себя на том, что именно так последние месяцы работаю над AURAIDO — AI-платформой для создания брендированных аудиоканалов для бизнеса. Большую часть кода уже пишут агенты. А я почти перестал думать о реализации отдельных фич. Вместо этого большую часть времени я трачу на проектирование архитектуры, описание требований для агентов, построение автоматических проверок и определение тех мест, где решение обязательно должен принимать человек.
В итоге я формулирую задачи, разбиваю их на части, определяю ограничения, а затем проверяю не код, а результат работы агентов. По сути, я все реже выступаю как исполнитель и все чаще — как человек, который проектирует работу команды, состоящей из AI.
Возможно, именно туда и движется наша профессия
Если AI берет на себя написание кода, то роль разработчика неизбежно меняется. Мы становимся в большей мере Product Owner'ами — потому что именно качество требований определяет качество результата. Мы становимся архитекторами — потому что именно архитектура позволяет агентам безопасно изменять систему. Мы становимся инженерами по качеству — потому что именно мы строим систему автоматического тестирования, которая определяет, можно ли выпускать изменения. И мы становимся инженерами по безопасности — потому что именно человек должен определить границы, где автоматике пока нельзя доверять полностью.
Принцип Утки
Возможно, у AI-разработки должен появиться свой Принцип Утки.
Если система проходит все проверки, выполняет продуктовые сценарии, не нарушает ограничения по безопасности и производительности, то для большинства изменений этого должно быть достаточно.
Если она ведет себя как правильная система — значит, для пользователя она и есть правильная система.
Проверять нужно не код.
Проверять нужно поведение.
Комментарии (38)
Abstraction
14.07.2026 09:31Мы ведь никогда не проверяли код ради кода. Мы всегда пытались понять только одно — правильно ли работает система. Раньше это было невозможно без code review.
int add(int x, int y);Поймите, правильно ли работает эта функция без code review. При условии что её реализацию сгенерировала система с мандатом писать любой бред пока он проходит проверки.
100% тестовое покрытие? ~30% ошибок заключаются в отсутствующих логических путях, ~40% - в неверных результатах на уникальной комбинации логических путей (статистика от Р. Гласса).
Stepik Автор
14.07.2026 09:31Не совсем понял мысль. В современных реалиях вы просите вашего агента написать фугкцию сложения, задаете ограничения - работаем только с целыми числами и проверяете, что числа складываются правльно. Можно, конечно, идти по пути ревью, если вы это пишете для космического корабля, но если это, к примеру, калькулятор калорий, можно использовать этот принцип утки и доверится что там навайбкодит агент. Моя мысль такая.
Abstraction
14.07.2026 09:31и проверяете, что числа складываются правльно
Как? Если программа прошла N тестов, то с какой вероятностью она пройдёт ещё M в проде? Если у вас нет никаких дополнительных убеждений, если программа есть идеальный чёрный ящик, то ответ известен: [(N+1)/(N+2)]^M ("правило Лапласа"). Что примерно равно -exp(M/N). Чтобы быть уверенным в надёжности программы таким образом, вычислительные ресурсы тестирования должны превышать вычислительные ресурсы использования.
И это, заметьте, в не-адверсариальных сценариях, когда пользователь просто гоняет приложение примерно в ожидаемых вами условиях, а не ломает его целенаправленно.
not-allowed-here
14.07.2026 09:31т.е. вопрос полноты покрытия валидацией - что мешает уменьшить Зоны покрываемые каждой отдельной валидацией? т.е. писать код так чтобы его можно было валидировать на вашем уровне ресурсов, а потм и з этих кодовых блооков уже собирать приложение, за однои проблему с тем что ИИ теряет контекс решим - тут правда вопрос достаточности - есть конечно крайние случаи когда всё равно всё упадет как бы ты не валидировал, но насколько они часты? если их скажем 2% то вопрос насколько велики эти два процента? и насколько часто они выпадают? а то окажется что валидируем мы ради одного случая из сотен миллионов и ситуации которая складывается с такой же вероятностью... может имеет смысл посмотреть на Внешние уровни защиты которые будут защищать данные от прохода "мусора" из-за редких ошибок?
Siemargl
14.07.2026 09:31int add(int x, int y);Поймите, правильно ли работает эта функция без code review.
add(INT_MAX , 42)
Abstraction
14.07.2026 09:31т.е. вопрос полноты покрытия валидацией - что мешает уменьшить Зоны покрываемые каждой отдельной валидацией?
То что мы обсуждаем попытку не заглядывать в код.
Хорошо валидированные Зоны у нас есть - это операторы и стандартные функции языка.
Проблема в том, что из них хочется собрать уникальную, сложную конфигурацию и быть уверенным что она работает правильно.
Есть попытка отождествить "правильно" с "то что проходит написанные мной тесты". Но в полном пространстве сложных конфигураций есть много объектов. Пусть программа - это цепочка из N блоков, каждый из которых может быть выбран K способами. Тогда я начинаю с пространства размером K^N. Пусть каждый тест имеет T вариантов исхода, из которых только один правильный. Тогда набор тестов, который проходится только правильной программой, имеет в среднем N*log_T(K) независимых тестов (а независимые в совокупности тесты практически недостижимы).
Следствие-раз: раньше нам надо было N*log(K) бит информации чтобы написать программу, теперь нам надо N*log_T(K)*log(T) бит информации чтобы определить правильные результаты тестов - в информационном смысле, наша задача не упростилась ни на йоту.
Следствие-два: раньше нам надо было искать ошибки в коде, теперь нам надо искать ошибки в тестах кода. Проблема в том что ошибки кода, обычно, достаточно локальны - они дают конфигурацию, которая коротко описывается конструкцией "ведёт себя как надо, за исключением: ...". А ошибки тестов дают некоторое подмножество пространства конфигураций, которое может вообще не иметь компактного выражения на доступном нам языке (потому что всех подмножеств конфигураций 2^(K^N), их слишком много чтобы у всех них были короткие описания).
PVoLan
14.07.2026 09:31В целом, можно представить себе кучу тестов вида
assertEquals(add(2,2), 4)assertEquals(add(3,4), 7)и т.д. Набрав достаточное количество таких тестов, вы можете с достаточной уверенностью предполагать, что сгенеренная функция действительно делает сложение, не глядя в код самой функции
Вопросы/проблемы вот какие:
Для ряда задач легче разобраться как работает сложение регистров в ассемблере и написать "математически верный" код руками, чем составить мильен тестов (которые еще и запускать надо всякий раз)
Для другого ряда задач не требуется 100%-я точность результатов, достаточно 80-90-95% ("а перед остальными 10% мы извинимся и даже вернем деньги" - вполне себе рабочая бизнес-модель во многих случаях, особенно если у бизнеса низкий горизонт планирования)
Stepik Автор
14.07.2026 09:31Я согласен и об этом и пишу. AI, на мой взгляд, уже пришел в нашу профессию и вопрос, как мы его проверяем - нужен ли ревью его кода в большинстве случаев?
PVoLan
14.07.2026 09:31Как мне кажется, ответ зависит от от факторов, которые я указал выше
Стоимость. Написать нормально руками через код-ревью и "по науке" может быть дешевле, чем составлять промпты и "очерчивать границы" агентам через тестирование и проч
Надежность. И код, написанный вручную, и код, сгенеренный через ИИ, будет содержать ошибки. Вопрос - какой процент ошибок допустим на вашем проекте? 10%? 1%? 0,0001%? Высокие показатели качества сложно достичь на одних только тестах, не понимая как работает система внутри.
Abstraction
14.07.2026 09:31В целом, можно представить себе кучу тестов вида
Откуда в тестах взялись эталонные значения и почему вы им доверяете? Если вы их сгенерировали сами и руками, то суммарно разработка этой функции обошлась вам абсурдно дорого. Если вы их сгенерировали автоматически некоторым доверенным процессом, который было написать не сложнее чем проверяемую функцию, то зачем вам вообще функция, используйте этот процесс.
("а перед остальными 10% мы извинимся и даже вернем деньги" - вполне себе рабочая бизнес-модель во многих случаях, особенно если у бизнеса низкий горизонт планирования)
Вернуть деньги хрен бы с ним, клиенты с претензией "ваша программа не считает что нам надо" обычно не слезут пока не получат результат расчёта. И это ещё хорошо если ошибка выглядит как "программа упала", а не "программа втихую выдала неверные результаты".
Затем, если в программе 50 мест где можно ошибиться (это довольно простая программа), то для уровня ошибок в 20%, в каждом отдельном месте вероятность ошибки должна быть 0.45%.
YuryZakharov
14.07.2026 09:31~30% ошибок заключаются в отсутствующих логических путях, ~40% - в неверных результатах на уникальной комбинации логических путей
Если Вы знаете, что логические пути отсутствуют, то знаете, какие именно, а значит, можете проверить.
Всё, что формализуется, можно формально же и проверить. Условно говоря, скрмптом, а не моделью.
Ваш пример с функцией не имеет смысла без контекста. Будут требования, можно будет сказать, работает она или нет. И сказать это сможет не только reviewer, но и формальный скрипт.
funca
14.07.2026 09:31Всё, что формализуется, можно формально же и проверить. Условно говоря, скрмптом, а не моделью.
P = NP - проверяйте.
Abstraction
14.07.2026 09:31Если Вы знаете, что логические пути отсутствуют, то знаете, какие именно, а значит, можете проверить.
???
Не знаю. Вот я написал программу, которая обрабатывает некоторые входные данные.
Вопрос: не забыл ли я какой-то конкретный случай?
Ответ: а хрен его знает. Что мне пришло в голову - я проверил. Как проверить, пришло ли мне в голову всё что нужно проверить?Будут требования, можно будет сказать, работает она или нет.
Требования к
add(): должна работать правильно во всех нынешних и будущих, ещё не написанных вызовах. При компиляции любым потенциально используемым компилятором.Нет, можно сказать "дайте мне документацию на двенадцати листах, и любая претензия к поведению
add(), которая не указывает, какой пункт документации нарушен - не моя проблема". Но это задача перекладывания ответственности, а не задача разработки ПО: проблема всё равно будет чья-то.
Alex_RF
14.07.2026 09:31Необходимо не забывать, что одной из задачь code-review является то, что код должен быть понятен всем членам команды. Для чего это нужно? Что бы любой член команды мог корректно внести изменения, когда это понадобится (оговорки на зоны ответсвенности принимаются). С другой стороны, при подходе описаном в статье, команда не нужна. Тогда вопрос - зачем вообще код ревьювить? Оставить надо одного заказчика. Купить ему токенов (взять коммисию с них конечно), а програмистов всех уволить.
VtripleG
14.07.2026 09:31Слепому не покажешь, глухому не расскажешь. Люди, ушедшие с головой в омут ИИ истерии, уже не смогут представить себе, что в мире кроме генерации есть подходы, которые часто и много где просто лучше и эффективнее. Число строк кода != качество получившегося кода, но именно это принято замалчивать
not-allowed-here
14.07.2026 09:31а надо ли? вопрос в том что не правильнее ли каждый раз генерировать новый артефакт? ну вот при достаточном уровне дробления вполне можно прийти к тому что ИИ генерит кучу конструктивных блоков к схеме доступной для понимания человеком и уже тогда получается так что схема приложения понятна и внести изменения надо не в код, а в логику работы блока через правку запроса, валидирующие массивы и тесты, а что там за код в блоке несколько без разницы....
copyhold
14.07.2026 09:31от кодревью нас спасёт только BDD.
Я согласен с автором насчет того, что программист в конечном итоге перестанет владеть кодом.
В то же время чтобы быть уверенным в правильной работе системы нужно задавать поведенческие тесты. Они, эти тесты должны выглядеть понятными для разработчика ( или продакт оунера ). Что на данный момент к сожалению не так.
Нужна тестовая система которая позволит описыват поведение в более или менее человеческим языком.
Я мечтаю о том, чтобы тесты задавались текстом. На основе этого текста генерировался код теста ( одноразово ). А потом уже система проверялась этим тестом.
KivApple
14.07.2026 09:311) Кому-то ревьюить код всё равно придётся. Если не человеку, то другому ИИ агенту. А потом ревьюить фиксы и так далее в цикле, пока агент ревьюер не перестанет находить серьёзные ошибки.
2) Сколько не работаю с ИИ, не перестаю обращать внимание на то, что у ИИ есть сложности с отделением важного от неважного. Он регулярно ставит в один ряд серьёзности реальный баг "мы забыли сохранить результаты работы программы" и "мы забыли обработать ситуацию, если поставщик API кардинально именит схему данных всех ответов API и это произойдёт одновременно с падением ОС и исчерпанием дискового пространства" (то что в принципе нельзя обработать и просто принимается, а любая попытка обработать, как правило, делает программу хуже). И как минимум иногда нужен человеческий ревью "баг реальный или звучит как перестраховка от того от чего невозможно перестраховаться".
3) Важный вопрос - планируется ли человеку работать с этим кодом. Если предполагается работа ИИ рука об руку с человеком, то человеческий ревью обязателен, чтобы код не стал слишком инопланетным (даже если в нём и не будет крупных ошибок) и поддерживать alignment с тем, с чем конкретная команда способна работать. Если это проект, который предполагается целиком и полностью доверить ИИ, тогда ревью человеком менее важен.
4) Не надо становиться жертвой культа продуктивности "всё автоматизировать и ускорить до предела".
fox0x0
14.07.2026 09:31Некоторые компании уже используют N8N для процесса ревью кода и автоматических доработок. Но тут как ружье Чехова на мой взгляд без SAST и DAST для компаний средней руки
panzerfaust
14.07.2026 09:31А что, если AI-код вообще не нужно ревьюить?
Ну так не ревьювьте, кто вас заставляет? Организуйте уже легендарную компанию-единорога из одного человека и агентов. А то три года уже одни разговоры.
Вопрос уровня "а почему не напечатать деньги, чтобы в мире не было бедных". Значит, есть на то причины.
funca
14.07.2026 09:31
Если это выглядит как утка, крякает как утка, но требует батарейки - вероятно, вы выбрали неправильную абстракцию Сейчас ИИ для разработки больше напоминает педального коня, нежели поумневшую лошадь.
Мы становимся в большей мере Product Owner'ами, архитекторами, инженерами по качеству, инженерами по безопасности.
Работа ролей, которые всю дорогу воспринимались как вспомогательные, вдруг обрела особый смысл и важность благодаря ИИ? ИИдиократия какая-то получается.
Zippy
14.07.2026 09:31агент способен написать или переписать тысячу строк за несколько минут, а человек будет читать их значительно дольше.
типа как в народной мудрости - один дурак может задать столько вопросов что и сто мудрецов не ответят
FlyingDutchman2
14.07.2026 09:31Допустим, что мы дали AI задание написать программу сортировки с использованием алгоритма quicksort. Код написан и проходит все тесты (данные сортируются). Но как проверить без code review, что реализован именно алгоритм qucksort, а не какой-то другой?
xSVPx
Кардиостимулятор похожий на кардиостимулятор себе поставите ?
Stepik Автор
Я в статье упомянул, что вещи, связанные с безопасностью все еще важны. Если воспользоваться вашей аналогией, то очки, которые работают, как очки, я бы себе взял.
Stepik Автор
Можно еще такой мыслительный эксперимент примерить на себя. Вы бы купили машину с двигателем, который работает как двигатель? Точнее можете допустить такую ситуацию на рынке авто, что существует компания, инженеры которой сами не делают двигатель, а лигь проверяют, что он работает, как двигатель, не взрывается, не течет и вообще по работе не отличается от двигателя, спроектированного вручную?
xSVPx
Нет, я не купил бы.
Яб в нее не сел, даже если бы ее купил кто-то еще и была такая возможность.
Я слишком часто видел некоторое дерьмо, при том, что все тесты были зеленые.
Если вам всё равно есть ли ошибки, может проще этот код вообще не писать ? Зачем он нужен ?
Stepik Автор
Не, мысль не в том, что мне все равно на ошибки, а в том, как их теперь ловить - через ревью инженера или через тестирование поведения.
Stepik Автор
все тесты были зеленые
но это же был отревьювенный код, верно?
edogs
А принципиально он ничем и не отличается. Как "вручную" спроектировали двигатель?
Как вообще работает "наука"?
Придумывается теория, проводится куча экспериментов, теория признается работающей, при этом она может не во всех экспериментах работать (ньютоновская физика та же).
Замените слово "теория" на двигатель и ... и вот, приехали. Никто понятия не имеет как что работает, но все полагаются на выводы сделанные из кучи тестов. Можно с умным видом говорить про е=мц-квадрат и вот это всё, но опять же, это не более чем что-то подтвержденное ограниченном количеством тестов и объединенное в более общую формулу.
Всё равно как прийти в казино, наткнуться на шарик выпадающий на красное 1000 раз подряд и сделать теорию о том, что выпадают только красное, провести эксперимент еще 10к раз и снова получить красное и принять как факт, что выпадает только красное. Возможна такая ситуация? По терверу возможна. S - наука:)
Stepik Автор
Так может нам теперь и не нужно делать ревью ИИ кода в большинстве случаев и более внимательно относится к архитектуре и тестирванию? Я об этом в статье
dan_sw
Так может нам теперь и вообще не нужно думать, критически мыслить, анализировать, выстраивать различные математические модели в голове и в принципе рассуждать? Зачем, ведь ИИ делает это всё гораздо быстрее, обладая всеми возможными информационными ресурсами людей... Смысл тогда вообще что-либо делать? ИИ придумает идею, придумает её архитектуру, придумает к ней тесты, придумает как её сделать и сделает, ИИ выпустит продукт, наберёт команду из других ИИ, создаст скрипт и будет делегировать работу суб-агентам, ИИ будет торговать акциями на бирже, ИИ будет указывать людям что им делать (он ведь знает это лучше, чем сами люди) и как вообще жить.
ИИ...ИИ..ИИ..ИИ..ИИ..ИИ.. и только ИИ. Ничего кроме ИИ. Одно ИИ. Везде ИИ.... Даже там где его нет (о ужас) скоро будет только ИИ. Один сплошной ИИ...
Думаю, рано или поздно, человечество в принципе целиком и полностью будет поглощено одной единственной темой (учитывая мировые тенденции - 100% гарантия) - искусственный интеллект (ИИ). И ничего кроме не останется... даже думать самому будет запрещено.
В целом, Ваша статья не несёт ничего нового... И так понятно что везде будет ИИ и что не нужно уже ничего делать. Забыли добавить, разве что, что и проектировать, и тесты писать, и идеи придумывать тоже не надо. Можно ведь оценивать результат по деньгам - вот сделал ИИ проект, принёс прибыль и значит всё хорошо. А если нет - значит плохо... Вот и всё. А то мелочитесь... архитектуру и тестирование нам, людям, оставить. Зачем, когда ИИ всё это уже делает? Особенно передовые модели. Всё теперь сводится чисто к экономической составляющей. Чем больше разнообразного мусора (который обязательно будут хавать), тем лучше. Главное чтобы генерацию этого мусора самому возглавлять, иначе будущая экономика тебя съест :)
Stepik Автор
Моя статье про наше (разработчиков) новое место в этом мире
funca
Погонщики лошадей переквалифицировались в шоферов, но принципиально это ни чего не изменило. Нынешние разработчики станут погонщиками для ИИ.
edogs
А самолетом разработанным кем попало без нормального ревью кода полетите?
https://habr.com/ru/articles/458224
В любом текущем проекте больше 90% кода который создатель проекта не проверял, подключаемые библиотеки, копипаста с предыдущих проектов, код от вчерашних джунов.
5 минут гугления и Вы найдете кучу проблем (в т.ч. с безопасностью) порожденных надеждой на либы, пакеты и вот это всё.
TDD так вообще этот принцип (работает и значит ок) спустило официально на уровень разработки (давайте сделаем чтобы тесты проходило и ладно), а заказчик продукта никогда и не разбирался в коде который ему дают - у него исходно этот принцип был.
ИИ кв этом смысле качественно ничего не меняет, просто вскрывает вещи, которые и так были очевидными.