Нейронки в агентском режиме

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

Немного воды: последние год-два мне постоянно попадается информация о нейросетях для программирования в разном виде с одним посылом — нейросети вытесняют разработчиков. Одна часть знакомых разработчиков (в основном джуны и часть мидлов) придерживается примерно такого же мнения, что нейросети делают то же самое гораздо быстрее и эффективнее. Вторая же часть (мидлы+ и сеньоры-помидоры) скептически смотрит на подобное «вытеснение». Менеджерский состав из числа моих знакомых, с которыми я сотрудничаю или просто общаюсь по старой памяти, тоже предрекал и предрекает сейчас замену разработчиков на ИИ: «Скажешь ИИ, что нужно, а он быстренько сделает и подправит при желании». Вроде бы схема выглядит неплохо. Люди не из среды разработки вообще начали говорить что-то вроде: «Наконец-то программистов раскулачили, и они не будут так радоваться жизни за баснословные деньги, которые им платят. Теперь всё сделает ИИ». Такие знакомые у меня есть и, наверно, у вас тоже.

Примерно в конце весны этого (2026) года мне начали попадаться проекты от заказчиков, желающих попробовать разработку с нейросетями, причём имелось в виду не частичное использование в отдельных модулях или задачах (это делает, наверное, большинство разработчиков, и я тоже), а полное внедрение ИИ во все процессы — от составления ТЗ до релиза и разворачивания на прод-сервере. Поначалу я упирался: слишком уж много рисков и неопределённости. Но потом решил: «Ладно, берусь», так как заказчик согласен на тесты с рисками, да и отказываться от нового способа разработки было бы неразумно с моей стороны. Время идёт, и нужно идти с ним в ногу. А если уж не понравится, то всегда можно кодить как раньше.

ПЛЮСЫ

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

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

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

3. Лендинги. Это просто «песня». Практически все топовые нейросети на данный момент умеют их создавать на приемлемом для большинства заказчиков уровне. Не могу сказать, что они полностью закроют потребность в подобных продуктах, так как иногда требуется что-то особенное, и нейросеть не может уловить настрой въедливого заказчика, но большая часть заказов-лендингов точно отвалится со временем. И это тоже хорошо — меньше возни с подобными заказами.

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

5. Экономия времени на набор кода. Если сильно упростить процесс программирования (для людей не из разработки), то он делится на два этапа: 1 — продумывание кода и 2 — набор этого кода на клавиатуре. Нейросети в моём случае сократили время написания стандартных (это важно) элементов раз в 5–10 (да, прирост скорости в этой области невероятен). То есть CRUD’ы, часть API, DTO, сущности, валидаторы (нужно проверять, опасно!), часть репозиториев и всего такого пишется на ура. Проще говоря, второй пункт (набор кода) упростился значительно, но со «сложным кодом» всё равно приходится возиться самому, так как чтобы объяснить, как должен выглядеть этот «сложный код» нейросети, нужно написать в несколько раз больше текста для неё, да ещё и с сомнительным результатом. Насчёт первого пункта (продумывания) ситуация спорная: если вы не разработчик, то варианта у вас нет — что нейросеть сгенерирует, то и будет. А для программистов это на дальней дистанции выходит боком. Почему? Напишу в блоке минусов кодинга с нейросетями.

6. Визуализация «хотелок» от менеджеров и даже заказчиков. С нейросетями появилась возможность не только выслушать заказчика/менеджера/доменного эксперта, но и посмотреть сгенерированную ими программу — это суперопция. Некоторым заказчикам (у меня уже такой есть) не лень посидеть перед Клодом и повбивать запросы в командную строку. Этим нужно пользоваться. Конечно, использовать сгенерированную кашу навряд ли выйдет, а вот посмотреть визуально на идею заказчика получится. Это может значительно ускорить понимание сложного и спорного функционала. Подобная схема получения части ТЗ (несколько сгенерированных страниц ЛК) мне очень понравилась. Навряд ли это станет массовым явлением, так как на это нужно немалое количество времени со стороны заказчика и какие-никакие умения, но пока интерес к теме ИИ-кодинга у всех подряд есть — используем!

МИНУСЫ

Теперь поговорим о плохом. Эта сторона монеты присутствует, причём многим людям она кажется неочевидной даже из среды разработчиков. У меня получились вот такие пункты:

1. Данные проекта утекают на серверы нейросети. Если вы занимаетесь серьёзной продуктовой разработкой, то перспектива утечки исходников вам навряд ли понравится, а уж людям из отдела безопасности — тем более. Выход — локальное решение, хотя даже оно не всегда помогает, так как может найтись нерадивый сотрудник с желанием прогнать доступную ему часть проекта через Клод, ДипСик или что-то подобное. Использование нейросети в агентском режиме нужно обязательно оговаривать с заказчиком. Чем крупнее и серьёзнее заказ, тем больше вероятность отказа в использовании ИИ.

2. Потеря контроля над проектом — часть 1: вайб-кодинг. Один из небольших проектов я создал чистым вайб-кодингом, то есть без прописывания требований архитектуры, стиля и т. д. Ревью кода тоже не делал. Результат получил ожидаемый — проект практически невозможно дорабатывать, как проекты, сделанные реальными разработчиками. Проект, написанный нейросетью от нуля и до финала (хотя бы MVP), похож на одеяло, сотканное из множества разных кусков по размеру и происхождению: разные стили, разные подходы, постоянное дублирование функционала и даже имитация нужного решения. На короткой дистанции получается работающий прототип. Если функционала немного, то указанные выше проблемы чистого вайб-кодинга не помешают вам протестировать идею, но для большого количества функционала такой подход слабо подходит, так как отсутствие чётко прописанной архитектуры и всего того, что даёт команде, например, тимлид (ревьювер кода), не даст спокойно дорабатывать проект — функционал будет постоянно сбоить и ломаться с новыми изменениями. А чтобы запустить подобный проект в реальное коммерческое плавание, нужно обладать или хорошими юристами, или отсутствием знаний о внутренних проблемах чистого вайб-кодинга.

3. Потеря контроля над проектом — часть 2: своеволие ИИ. Вариант с руководством ИИ будет использовать (как мне кажется) подавляющее большинство разработчиков, так как он на порядок эффективнее. Что под этим понимается? Чёткое прописывание задач проекта (практическое ТЗ с атомарными задачами), архитектуры приложения (1 — стратегические шаблоны, например, монолит, микросервисы, CQRS, луковая и т. д.; 2 — тактические шаблоны, например, где и как использовать структурные, порождающие и поведенческие), архитектуры окружения (стек, например, PHP/NGINX-PHP-FPM/Redis/PostgreSQL/RabbitMQ), способов наращивания функционала, предпочитаемых решений для конкретных задач и т. д. Для всех, кроме одного проекта (который был мной реализован для теста чистого вайб-кодинга), я использовал именно такой подход. И даже при полном описании всех требований нейросети (пробовал топ-5 нейросетей) периодически отступают от полученных инструкций в том или ином виде, иногда сильно. Нередко приходится несколько раз перезапрашивать у ИИ решение, соответствующее архитектуре приложения. Например, нейросеть неожиданно начинает складывать функционал в контроллеры или сущности, хотя ранее она без проблем помещала его в сервисный слой. Если игнорировать подобные нарушения установленной архитектуры, то проект постепенно потеряет управляемость разработчиком со всеми вытекающими последствиями. Иногда, сужу по себе, бывает попросту лень проверять пулл-реквесты от нейросети.

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

4. Дыры в безопасности. Они появляются постоянно, по крайней мере в моей сфере (веб-разработка). Код, написанный нейросетью, частенько содержит уязвимости даже при наличии начальных требований писать «безопасный код». Поэтому необходимо относиться к этому аспекту внимательно. Например, если в вашей задаче есть установка для нейросети: «фильтруй все входящие данные и экранируй исходящие» (классика), — это не значит, что так и будет в решении нейросети, поэтому держим ухо востро. Также я заметил особенность нейросетей: они не боятся выкладывать содержимое внутренних логов в тексты исключений, которые выбрасываются при ошибках. Например, при возникновении ошибки ИИ без проблем может выложить полный стек в текст и отправить пользователю в браузер. Такое поведение может привести к печальным последствиям.

Отдельно хочу выделить логические ошибки в безопасности. Например, в разрабатываемой CRM есть форма приглашения пользователя, состоящая из почты (куда высылается ссылка с токеном) и селекта со списком своих проектов (под названиями проектов ИИ поместил их ID). Функционал работает, и с виду всё хорошо, но если подменить на клиентской стороне ID проекта на чужой и отправить запрос, то можно пригласить участника не в свой проект. Подобные фортели я замечал неоднократно. Разработчикам с опытом, конечно, эти проблемы видны сразу, а вот пользователям нейросетей без опыта разработки такая ситуация не просто не покажется проблемой — они её даже не заметят.

5. Неадекватное поведение нейросети. Такое тоже случается. В чём это выражается? По-разному. У меня всплывало вот что:

• нейросеть пыталась решать задачу настолько странным образом, что как будто бы переходила к другой задаче, а токены тем временем утекали рекой с баланса;
• нейросеть устанавливала на локальное окружение сторонние программы, и так как у неё есть на это права в системе, наворотила она довольно много;
• нейросеть портила данные в БД — такое, к несчастью, тоже случается, хотя в моём случае это не было критичным из-за изолированного окружения;
• нейросеть нарушала жёстко прописанные правила работы с репозиторием, создавала и меняла коммиты.

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

Ещё один момент, наверное, тоже стоит отнести к необычному поведению. Чем дольше нейросеть решает какую-либо задачу, тем хуже она в ней разбирается и тем менее эффективным будет решение. Такое странное наблюдение у меня появилось. Почему странное? Потому что у людей эта схема выглядит ровно наоборот: чем дольше мы чем-то занимаемся, тем лучше это у нас получается.

6. Неудачные решения. Насколько я знаю, нейросети обучаются на огромных объёмах кода, а качество этого кода разное: попадается и хорошо написанный, и так себе. На основе какого кода нейросеть сгенерирует ответ под вашу задачу — большой вопрос, это почти лотерея. Такая проблема есть, и уловить её можно, как мне кажется, только при наличии практического опыта в конкретной сфере. Вот что попадалось мне:

• создание дублирующего кода. Например, в системе были отлаженные валидаторы текстовых данных, но нейросеть начала постепенно добавлять свои дублирующие функции вместо них;
• написание кода «на будущее». Таким подходом часто балуются начинающие разработчики, и нейросеть, похоже, переняла эту способность. Система постепенно начинает обрастать неиспользуемым кодом, который «когда-нибудь точно пригодится»;
• недоделанные задачи. Например, нейросеть может понаделать множество точек сбора логов-предупреждений (не критических ошибок), но забыть разрешить в основной конфигурации приложения сохранять эти самые предупреждения;
• устаревшие решения. Например, нейросеть может воспользоваться utf8, а не utf8mb4;
• косноязычность. Код от ИИ обычно отличается от кода человека, хоть ИИ и учится на реальных проектах. Код нейросети работает, выглядит неплохо, но что-то в нём явно не так, когда читаешь. Трудно объяснить, но даже когда джуны присылают пулл-реквесты с плохим кодом на проверку, он читается проще, чем код, сгенерированный нейросетью. Этот пункт субъективен, возможно, мне тут просто кажется;
• достаточные, но не лучшие решения. Попробую раскрыть на примере загрузки изображений в проект. Нейросеть по моему запросу написала модуль сохранения файлов через форму. Изображения принимаются на бэкенде, проверяются, получают новые случайные наименования и складываются в директорию /uploads. С виду опять всё хорошо, но это только на первый взгляд. Нейросеть знала, что проект будет хранить большое количество файлов на локальной машине, и всё равно поместила все файлы в /uploads, а можно было сделать директорию /uploads с подуровнями по дате, пользователю, наименованию файла и т. д. То есть был выбран рабочий вариант, но далеко не лучший в данной ситуации. Повторюсь: нейросеть знала, что в проекте будет большое количество файлов, и контекстное окно не было забито другими задачами — просто был выбран не лучший вариант решения задачи.

ВЫВОДЫ

Как я написал в начале заметки, нейросети — это инструмент, который точно не является волшебной палочкой для воплощения желаний. Он, бесспорно, усилит ваши способности, но не заменит вас как специалиста. Разработчик будет быстрее и эффективнее писать код, врачи — быстрее и точнее выставлять диагнозы, юристы учтут большее количество пробелов в договорах и т. д. Но полная замена навряд ли произойдёт (хотя, может, выйдет ещё пара версий Клода, которые объяснят мне мою неправоту :)). На данный момент нейросети — это усилители для специалистов и умные помощники для неспециалистов, что тоже очень ценно.

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

Разработчики могут ошибаться при принятии кода в репозиторий от нейросети: где-то что-то не усмотреть или попросту полениться проверить. Это одна из проблем кодинга с нейросетями, которую я прочувствовал на себе. То есть даже при наличии знаний и опыта они не всегда спасают. А вот как человек без опыта разработки может понять, плох или хорош присланный ИИ код? Какая архитектура подходит конкретно под ваш проект? Даже если спросить у нейросети, какую архитектуру выбрать конкретно под вашу идею (монолит обычный или модульный, микросервисы, событийную, гексогональную, CQRS и т. д.), то как можно без опыта использования всех этих архитектур понять, решает ли нейросеть задачи в рамках выбранной архитектуры или нет? Разработчик поймёт это сразу, а не разработчик — когда корабль уже будет приближаться ко дну. В этом вся соль.

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

Одно ясно точно: ИИ — это будущее сферы разработки, который избавит нас от рутинных задач и, отчасти, подрежет вакансии «наборщиков кода на клавиатуре», что тоже хорошо.

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