Сегодня многие смотрят на AI-агентов как на «разработчиков в коробке»: дал задачу — получил готовое решение. На практике всё работает не совсем так.

Да, современные LLM и агентные инструменты умеют быстро производить много кода. Но есть проблема: количество сгенерированного кода ещё не означает качество инженерного решения. Модель может уверенно пойти в неверную сторону, выбрать чрезмерно сложную архитектуру, начать строить лишнюю инфраструктуру или решать задачу окольным путём. Именно поэтому работа с AI-агентом во многом напоминает code review. 

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

Почему? Потому что основная ценность при работе с агентом — не в том, чтобы исправлять каждую строчку после него, а в том, чтобы регулярно задавать вопрос:

«Он вообще решает задачу правильным способом?»

Это намного важнее, чем спорить о названии функции, порядке условий или выборе между .reduce() и .map().filter().

Где AI-агенты ошибаются чаще всего

AI-инструменты часто делают одно и то же: они выбирают слишком тяжёлое решение там, где достаточно простого:

• агент пытается реверс-инжинирить фронтенд и вытаскивать данные обходным способом, хотя эти данные уже доступны напрямую в более удобном виде;

• агент хочет строить полноценную инфраструктуру фоновых задач, очередей и polling-механизмов там, где достаточно обычного неблокирующего запроса с клиента;

• агент охотно наращивает сложность, если его не остановить вовремя.

Это очень похоже на ситуацию с неопытным, но энергичным разработчиком: он может вложить много усилий в реализацию первой пришедшей в голову идеи, не задаваясь вопросом, является ли она вообще хорошей. Работа AI-агента похожа на работу с мотивированными junior-разработчиками — только без гарантии, что со временем у них появится зрелое инженерное суждение. 

Почему «vibe coding» упирается в потолок

Отсюда вытекает и критика чистого «vibe coding». Если человек не умеет заметить, что модель ушла не туда, он довольно быстро оказывается в ловушке:

• тратится время;

• тратятся токены;

• растёт сложность кодовой базы;

• ухудшается способность агента дальше в ней ориентироваться.

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

Решение становится всё менее управляемым, и в какой-то момент агент уже не помогает, а только ускоряет накопление хаоса.

Плохой code review и плохая работа с AI — это одно и то же

Одна из самых частых ошибок в code review — смотреть только на тот код, который уже написан, и почти не думать о коде, который вообще можно было не писать.

Есть ревьюеры, которые:

• внимательно проходят diff построчно;

• находят мелкие шероховатости;

• предлагают переименования;

• спорят о стиле; но почти не задают вопрос:

«А это вообще должно быть реализовано именно здесь и именно так?»

С AI-агентами такой подход особенно вреден. Если вы сосредоточены только на косметике, вы упускаете более важное:

агент может уверенно строить архитектурный тупик

Лучший review — структурный

Он учитывает контекст за пределами текущего diff’а:

• можно ли переиспользовать уже существующую систему;

• можно ли взять данные из более правильного источника;

• можно ли упростить решение;

• можно ли вообще обойтись без новой подсистемы.

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

Какие типы ревьюеров хуже работают с AI:

Придирчивый построчный ревьюер

Такой человек:

• бесконечно правит мелочи;

• просит заменить один вызов другим;

• спорит о форме записи;

• но может пропустить фундаментальную ошибку в подходе.

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

Ревьюер-«штамп»

Такой человек слишком доверяет результату:

• «ну вроде сгенерировалось»;

• «тесты зелёные»;

• «выглядит правдоподобно».

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

Что значит «хорошо уметь пользоваться AI»

Хорошая модель взаимодействия сегодня — не «полностью автономный AI-сотрудник», а скорее centaur chess для разработки: сильный инженер + компьютерный помощник. И в этой связке человек ценен не скоростью печати и не способностью написать цикл. Его ценность — в инженерном суждении:

Распознать плохую архитектуру
Остановить усложнение
Выбрать более простой путь
Держать систему в здравом состоянии

Практический вывод

Если вы хотите лучше использовать Claude Code, Codex, Copilot и подобные инструменты, прокачивайте не только prompt engineering, но и навыки хорошего code review:

• оценку архитектуры;

• чувство соразмерности решения;

• умение переиспользовать существующие механизмы;

• умение замечать, где задача решается слишком сложно;

• привычку спрашивать:

«А нельзя ли проще?»

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