Я уволил вайбкодера: AI писал код, а отвечать за него было некому

Вступление

Я как-то уволил вайбкодера.

Звучит, конечно, как начало очередного текста из серии «нейросети всё испортили, раньше было лучше, трава зеленее, тесты стабильнее, Jenkins падал по расписанию». Но нет. Это не статья против AI-инструментов. Я сам ими пользуюсь, считаю их полезными и уже плохо представляю себе разработку без ассистентов, автодополнения, быстрых черновиков, генерации тестовых данных и всех этих маленьких радостей, которые экономят время и нервы.

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

Человек хорошо продал себя на собеседовании. Уверенно рассказывал про инструменты, подходы, автоматизацию, современные практики, AI-ассистентов, ускорение разработки и прочие вещи, после которых в голове у менеджера где-то начинает тихо играть музыка из рекламного ролика: «сейчас мы наймём одного, а работать он будет за двоих».

На практике получилось немного иначе.

Не то чтобы человек совсем ничего не делал. Делал. Задачи двигались, пулл-реквесты появлялись, код приходил на ревью. Но почти в каждом ревью было очень много комментариев. Не в формате «давай тут пробел поправим» или «переименуем переменную, чтобы было красивее», а по существу: нейминг не туда, ответственность класса размыта, логика лежит не там, существующие паттерны проигнорированы, рядом уже есть готовый механизм, но почему-то вместо него написан новый костыль на ровном месте.

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

Но здесь было другое ощущение.

Каждая новая итерация выглядела не как осмысленное развитие предыдущей, а как новая генерация с чистого листа. Был один набор странностей, после комментариев он исчезал, но вместо него появлялся другой набор странностей. Иногда даже более творческий.

Примерно как если попросить AI-агента «поправь архитектуру», а он такой: «конечно», — и через минуту приносит вам ту же проблему, только теперь она называется ManagerFactoryServiceHelper и живёт в другом пакете.

Немного контекста: речь про автоматизацию тестирования

Сразу уточню: речь пойдёт про автоматизацию тестирования.

И здесь важно сделать небольшую паузу, потому что до сих пор встречается странное отношение к автотестам как к чему-то вторичному. Мол, ну это же не продуктовый код. Там же просто тесты. Проверил, что кнопка нажалась, что API вернул 200, что в JSON лежит нужное поле, и разошлись. На реальных проектах это так не работает.

Код автотестов — это такой же код. У него тоже есть архитектура, договорённости, паттерны, границы ответственности, технический долг, читаемость, расширяемость и стоимость поддержки. Иногда автотестовый фреймворк по сложности вполне может конкурировать с небольшим продуктовым сервисом: API-клиенты, фикстуры, генерация данных, моки, интеграции с CI/CD, отчёты, работа с окружениями, инфраструктурные настройки, ретраи, изоляция, стабилизация, параллельный запуск.

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

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

И вот здесь вайбкодинг без понимания начинает ломаться.

Сначала всё выглядело даже перспективно

Сотрудник с самого начала активно использовал AI-инструменты. Cursor, Claude Code, разные чаты, n8n с AI-интеграциями, какие-то свои связки, автоматизации, промпты, пайплайны. В общем, полный набор современного инженера, который не просто пишет код, а как будто выходит на проект в экзоскелете. На старте это даже производит хорошее впечатление.

Человек не сидит в блокноте, не копирует команды из старой статьи 2017 года, не спрашивает «а что такое автодополнение». Наоборот, он выглядит технологично. Кажется, что сейчас он быстро въедет в проект, обмажется контекстом, подключит своих AI-помощников и начнёт закрывать задачи с такой скоростью, что Jira попросит пощады.

Но довольно быстро стало заметно, что ускорения не происходит.

Человек въезжал в проект долго. Причём не просто долго изучал код — это нормально. Он долго въезжал в базовые процессы, терминологию, дежурства, разборы падений автотестов, интеграционные проблемы, взаимодействие с другими командами, ответы коллегам на вопросы. Иногда складывалось ощущение, что человек уже давно работает в компании, но до сих пор не понимает базовых слов, которыми все вокруг пользуются каждый день.

И это важный момент. AI может помочь написать метод. Может объяснить кусок кода. Может предложить рефакторинг. Может сгенерировать клиент, модель, тест, фикстуру, пайплайн, да хоть README с эмодзи и красивыми бейджами. Но AI не может за вас прожить проектный контекст.

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

А если сам инженер этого тоже не понимает, получается интересная конструкция: AI уверенно генерирует решение в вакууме, а человек уверенно несёт его в кодовую базу. Очень современно. Очень быстро. Очень страшно.

Ревью как детектор реального понимания

Код-ревью в таких ситуациях работает лучше любого технического интервью.

На интервью человек может хорошо рассказывать. Может знать правильные слова. Может уверенно говорить про clean code, SOLID, паттерны, CI/CD, изоляцию тестов, стабильность, архитектуру и то, что «важно думать о поддержке». Иногда слушаешь и думаешь: ну всё, вот он, наш человек.

А потом открываешь пулл-реквест. И там начинается честный разговор. Не словами, а кодом.

Проблема была не в том, что код был синтаксически плохой. Наоборот, в этом и подвох. Современные AI-инструменты часто генерируют код, который внешне выглядит прилично. Он форматирован, типизирован, разложен по файлам, у него даже могут быть docstring-и, аккуратные названия и видимость архитектуры.

Но если присмотреться, оказывается, что он не попадает в проект.

• В проекте уже есть один способ создавать API-клиенты — появляется второй.
• В проекте уже есть общий механизм конфигурации — появляется локальный парсер env-переменных, потому что «так проще».
• В проекте уже есть фикстуры и фабрики данных — появляется отдельная генерация тестовых сущностей внутри конкретного теста.
• В проекте есть договорённость, где должна жить инфраструктурная логика, — она внезапно оказывается в тестовом классе.
• В проекте есть разделение ответственности — оно аккуратно размазывается тонким слоем по пяти новым файлам.

И вроде бы каждый отдельный кусок можно объяснить. Здесь удобно. Здесь быстро. Здесь «так предложил ассистент». Здесь «я подумал, что будет проще». Но вместе это превращается в архитектурный салат, в котором помидоры спорят с pytest-фикстурами, а огурцы почему-то наследуются от HTTP-клиента.

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

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

А при вайбкодинге без понимания часто происходит другое.

• Комментарий: «Не надо создавать отдельный клиент, у нас уже есть базовый механизм».
• Новая итерация: отдельный клиент удалён, зато теперь логика запроса лежит прямо в фикстуре.
• Комментарий: «Не надо смешивать подготовку данных и проверку результата».
• Новая итерация: подготовка данных вынесена, но теперь проверка результата происходит внутри helper-а, который ещё и сам ходит в API.
• Комментарий: «Здесь нарушена зона ответственности».
• Новая итерация: зона ответственности переехала. Нарушение осталось.

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

Момент, когда стало совсем понятно

Окончательно всё стало ясно не на маленьких задачах. Маленькие задачи вообще коварные. Там можно долго держаться на поверхности. Где-то подправить тест, где-то добавить проверку, где-то обновить схему, где-то написать небольшой helper. С AI такое действительно можно делать довольно бодро, особенно если вокруг уже есть понятные примеры.

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

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

И вот на такой задаче человек принёс решение, которое было формально «почти сделано», но по сути всё мимо.

• Нейминг не туда.
• Логика не там.
• Залезание в чужую зону ответственности.
• Игнорирование существующих практик.
• Новые костыли там, где уже были нормальные механизмы.
• Решения, которые выглядели так, будто человек не просто не прочитал соседний код, а принципиально сделал вид, что его не существует.

Самое неприятное — это не один конкретный баг. Баг можно поправить. Нейминг можно переименовать. Файл можно перенести. Метод можно переписать. Неприятно, когда за решением не видно модели мышления.

Когда ты смотришь на код и не понимаешь, из какой картины мира он появился. Почему именно так? Откуда этот слой абстракции? Зачем здесь этот helper? Почему эта ответственность оказалась здесь? Почему существующий механизм проигнорирован? Как человек вообще понял задачу?

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

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

AI не виноват. Он просто сделал то, о чём его попросили

Здесь легко скатиться в банальное «нейросети пишут плохой код». Но это не так. AI-инструменты могут писать хороший код. Они могут экономить время, помогать с рутиной, подсказывать подходы, находить ошибки, объяснять непонятные места, генерировать тестовые данные, набрасывать каркас решения. В руках сильного инженера это реально ускорение.

Но AI почти всегда работает с тем контекстом, который ему дали. А контекст — это не только открытые файлы в редакторе.

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

И самое главное: контекст — это умение оценить результат. Вот здесь и начинается главная проблема вайбкодинга.

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

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

Аналогия с домом, который построил агент

Для меня это похоже на строительство дома.

Можно сказать AI-агенту: «Построй мне хороший дом».

Он построит. Может даже красиво. С большими окнами, террасой, подсветкой, умным домом, рендерами в стиле «дорого-богато, но минимализм». На презентации всё будет выглядеть прекрасно. Можно будет ходить вокруг и думать: ну всё, теперь живём.

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

Проблема в AI? Не совсем.

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

С кодом то же самое. AI может сгенерировать решение. Но кто-то должен понять, выдержит ли оно реальную эксплуатацию.

• Кто-то должен заметить, что здесь нарушены границы ответственности.
• Кто-то должен понять, что этот helper через месяц станет помойкой.
• Кто-то должен увидеть, что эта фикстура теперь делает слишком много.
• Кто-то должен сказать: «Нет, мы так не пишем, потому что уже пробовали, и оно развалилось».

Если этого «кто-то» нет, AI становится не ассистентом, а генератором технического долга с приятным интерфейсом.

Вайбкодинг не проблема. Проблема — отсутствие ответственности

Я не считаю, что вайбкодинг сам по себе зло.

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

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

1. Это понять задачу.
2. Понять ограничения.
3. Понять существующую архитектуру.
4. Выбрать место для изменения.
5. Оценить последствия.
6. Сделать решение поддерживаемым.
7. Объяснить, почему оно именно такое.
8. И потом отвечать за него.

AI может помочь почти на каждом из этих этапов. Но он не должен подменять их собой. Если человек приносит код и не может объяснить, почему он устроен именно так, это не инженерное решение. Это артефакт генерации. Может быть, удачный. Может быть, даже рабочий. Но всё равно артефакт.

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

Что я теперь смотрю у людей, которые активно используют AI

После этой истории я не стал хуже относиться к AI-инструментам. Но я стал внимательнее относиться к людям, которые очень активно ими пользуются и строят вокруг этого свою профессиональную идентичность.

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

Но теперь мне важны другие вещи.

• Может ли человек объяснить своё решение без ссылки на «так предложил AI»?
• Понимает ли он, почему код лежит именно в этом месте?
• Видит ли он похожие паттерны в проекте?
• Умеет ли он читать существующий код перед тем, как писать новый?
• Может ли он после ревью исправить не только конкретный комментарий, но и принципиальную проблему?
• Способен ли он сказать: «Я попробовал такой подход, но он не подходит, потому что нарушает вот такую договорённость»?
• Понимает ли он, где AI можно доверить рутину, а где нужно думать самому?

Вот это важнее, чем список инструментов в резюме. Потому что Cursor, Claude Code, ChatGPT, Copilot, агенты, n8n и вся остальная прекрасная техника не делают человека инженером автоматически. Они просто усиливают то, что уже есть.

• Если у человека есть инженерное мышление, AI помогает двигаться быстрее.
• Если у человека его нет, AI тоже помогает двигаться быстрее. Просто не туда.

Почему увольнение было не про AI

Важно сказать отдельно: человек был уволен не за то, что пользовался AI. Это было бы странно. В 2026 году увольнять за использование AI-инструментов — примерно как в своё время ругаться на IDE, потому что «настоящие инженеры пишут в блокноте и компилируют силой характера».

Решение было не про инструменты. Оно было про результат, ответственность и способность работать в команде.

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

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

И здесь уже неважно, каким именно инструментом был написан код. Руками, ногами, голосом, Copilot-ом, агентом или силой утреннего вдохновения. Если результат стабильно плохой, инструмент не оправдание.

Заключение

AI — отличный инструмент, если за ним стоит человек, который понимает задачу, систему и последствия своих решений; без этого вайбкодинг превращается не в ускорение разработки, а в ускорение производства технического долга.