Почему с ИИ мы всё ещё пишем плохой софт

На стриме я услышал вопрос: «Насколько важно качество кода в эпоху ИИ?» Дальше ещё спросили, не потеряла ли вся эта борьба за качество смысл.

Спикер с этим категорически не согласился. Он рассказывал, как агент присылает зелёные пул‑реквесты, проходит все проверки, а в коде всё равно остаётся фигня. Например, разнобой в именах классов. И надо придумывать, чем ещё ограничить болванчика, чтобы он сам замечал такие проблемы и понимал, что пора делать рефакторинг.

Я это слушал и словил когнитивный диссонанс. У меня с агентами таких проблем нет. Я как раз прошу ИИ искать баги, разбирать сомнительные решения, улучшать тесты и делать рефакторинг. Получается достаточно хорошо. Почему у нас настолько разный опыт?

Похожие претензии я часто вижу на Хабре и других платформах. К вайбкодингу относятся довольно резко. Иногда достаточно написать, что пользовался агентом, чтобы дальше обсуждали твою профессиональную непригодность.

Плохой софт мы успешно писали и без ИИ. Временные решения годами оставались в проде, а код в некоторых проектах боялись лишний раз трогать. Ещё и повторяли: «Работает — не трогай». Я с таким подходом в корне не согласен. Теперь есть болванчик, который может помочь со всем этим разобраться. Почему же при таких возможностях мы продолжаем получать плохой софт?

Мне захотелось разобраться, что вообще происходит и кто виноват. Правда, как говорится в старом анекдоте, в расследовании главное не выйти на самого себя.

Болванчик ведь умеет искать ошибки

Болванчик может помочь с багом, который воспроизводится по большим праздникам. С ним можно разобрать, каких случаев не хватает в тестах, и дополнить старые проверки.

В Meta сделали TestGen‑LLM, который дополняет уже написанные тесты. Новые тесты собирали и запускали, затем проверяли, добавилось ли покрытие. Предложения, прошедшие автоматический отбор, смотрели инженеры. По данным авторов, они приняли в прод 73% таких рекомендаций.

При рефакторинге можно сначала обсудить, почему в одной функции собралось столько разной логики и как её разделить. А однотипные правки в куче файлов отдать правильно настроенному агенту.

В опросе Stack Overflow за 2026 год около 58% ответивших на вопрос о применении ИИ использовали его для тестов, а 64% — для отладки и рефакторинга. Для генерации кода в знакомой области получилось около 69%.

Заработало, можно брать следующую задачу

Вот добавляешь фичу с болванчиком. Он написал код, ты посмотрел, попробовал обычный сценарий. Работает.

Можно задержаться и посмотреть, что будет, если запрос отправят дважды. Или если соседний сервис не ответит. Агент поможет разобраться и с этим. Заодно посмотреть на сам код: понятно ли, что он делает, и насколько легко будет его менять.

Но есть соблазн закрыть задачу. Новую кнопку уже можно показать пользователю и сообщить, что всё готово. Пользу от рефакторинга заметим, когда снова полезем в этот код. Проверишь редкий сценарий, убедишься, что всё нормально, а на демо покажешь ту же самую кнопку.

Если после каждого такого результата сразу брать следующую фичу, от агента и будем получать в основном следующие фичи. Проверку и рефакторинг опять оставим на тот прекрасный день, когда разгребём остальное. А вот в прекрасном проект_name будущего багов не будет и код будет идеальным.

Бизнесу к пятнице нужна фича

Руководитель может искренне переживать за качество. Когда пользователи жалуются, поддержка не справляется, а разработчики исправляют последний релиз вместо следующего, качество сразу становится очень важным. Хотелось бы, чтобы это было заметно и при составлении планов, а то будет как в той фразе с забытыми оврагами.

С новой фичей понятно, что покажем заказчику в пятницу. С рефакторингом старого модуля разговор сложнее. Ты объясняешь, что потом следующие фичи будет легче добавлять. В ответ могут спросить, почему нельзя сначала доделать текущую. Старый модуль ведь пока работает.

На рефакторинг время нужно сейчас. А сколько он сэкономит на будущих задачах, ещё попробуй оцени, когда этих задач пока даже нет в плане. Новую фичу заказчик уже ждёт.

Заказчик платит за то, чтобы решить свою задачу. Если ему нужна новая возможность, ответ «у нас фичефриз, сначала разберёмся с техдолгом» его может не устроить. Он может уйти к конкуренту, у которого эта возможность уже есть, пока мы приводим код в порядок.

Авторы исследования о работе с техдолгом сравнили, как её оценивают менеджеры и разработчики. Менеджеры считали, что поддерживают эту работу чаще, чем это ощущали разработчики. Мелкие исправления поощряли, а крупные переделки часто откладывали: не хватало понятного объяснения пользы и подходящего способа всё переделать. Времени на это у разработчиков в итоге не было.

Это исследование вышло ещё до массового использования агентов. Теперь заняться старым модулем вместе с ИИ проще. Но если в плане к пятнице стоит новая фича, то и болванчика займут ею.

ИИ можно сравнить с суперкаром. Профи быстрее доедет до финиша, а новичок разложится на первом повороте. Причём до этого поворота он ещё и доберётся гораздо быстрее, чем рассчитывал.

Под новичком я тут понимаю и тех, кто принимает решения. Можно годами руководить разработкой и принять первую работающую версию от агента за готовый продукт.

Сделай как у нас принято

В старом проекте одно и то же решение скопировано в несколько мест. Приносишь агента: «Посмотри, как у нас сделано, и добавь ещё». Он может повторить и ошибку, которая была в образце. А потом показываем результат со словами «Вот что написал ваш ИИ».

В эксперименте о разбитых окнах и техдолге 29 разработчиков расширяли системы с разным количеством старых проблем. В более запущенном коде участники чаще добавляли новые: дублировали функциональность, выбирали непонятные имена.

В ноябрьском препринте 2026 года проверяли, повторяют ли агенты уязвимости, которые уже есть в проекте. Им показывали безопасные и уязвимые варианты существующего кода. Во втором случае похожие уязвимости чаще появлялись и в новых изменениях. Просьба следовать существующему стилю усиливала эффект.

С тем же агентом можно было бы разобрать старое решение и исправить ошибку во всех его копиях. Но такая задача у нас даже не стояла: мы просили ещё одну фичу, и мы её получили.

Миллион строк продать проще

Сравните два выдуманных заголовка:

Я с ИИ‑агентами переписал миллион строк с одного языка на другой за 10 дней.

И второй:

ИИ помог мне порефакторить кодовую базу.

Первый я бы открыл хотя бы из любопытства. Зачем переписывали, как успели, что сломали, на кого это потом оставили. Миллион строк уже в заголовке, а подробностей пока никаких.

Со вторым надо ещё разобраться. Может, переменные переименовали. А может, убрали такую проблему, из‑за которой каждую новую фичу приходилось делать неделю. Пока не расскажешь, что изменилось, не очень понятно, зачем читать.

И тут я, пока об этом думал, сам же вспомнил возражение. Про баги ведь тоже можно написать так:

ИИ нашёл уязвимость, которая скрывалась в коде сто десять лет.

Вот такое я бы тоже почитал. А если через эту уязвимость ещё и root на сервере получить можно, добавляем в начало заголовка «ШОК!». Про баги тоже можно рассказать громко, когда есть такая история.

Но такие баги не находятся каждый день, по крайней мере пока что. В обычной работе скорее разбираешься, почему страница падает при пустом списке, или чинишь фильтр, который не учитывал одно из условий. Пользователям эти исправления нужны, а заголовок «ИИ помог починить фильтр», мягко говоря, не цепляет.

При этом кто‑то может спокойно разбирать старые баги с болванчиком, приводить проект в порядок и ничего об этом не публиковать. Мы про него просто не узнаем. Потом посмотрим на громкие истории и решим, что все только генерируют очередные сервисы.

А если сам всё время читаешь про «переписал за выходные», тоже хочется попробовать. Видно, что можно показать и чем похвастаться. Про обычный рефакторинг ещё придумай, как рассказать. И чтобы дочитали дальше заголовка.

И где в этом расследовании я

В чужом PR можно быстро заметить проблему и объяснить, почему так делать нельзя. А если мне самому нужно будет выпустить то же изменение к пятнице? Насколько подробно я в него полезу и что сочту достаточной проверкой?

Бизнес в первую очередь платит нам за функциональность, которую ждёт заказчик. На проверку и рефакторинг времени часто не хватает. Мы и поручаем болванчику следующую фичу, а старые проблемы оставляем на потом.

Мне кажется, возможности ИИ для повышения качества мы используем слабее, чем его возможности для ускорения разработки. В расследовании мы всё‑таки вышли на самих себя, с чем я нас всех и поздравляю.

P. S. ШОК! В конце статьи обнаружена ссылка на мой канал с IT‑мемами. Для эксплуатации достаточно нажать «Подписаться». Спасибо, что дочитали.