С AI в клиентской разработке стало выгодно делать то, что раньше технически было несложно, но экономически бессмысленно. Какой‑нибудь специфический фильтр, дополнительный экран в админке, сценарий обработки данных… Раньше смотришь на задачу и понимаешь, что руками это несколько часов работы. Клиенту функция не настолько нужна, сколько она стоит в хорошей реализации, поэтому либо от неё отказываемся, либо ищем готовый плагин, который умеет нужное и подгружает ещё семьдесят свистелок.

Сейчас значительную часть такой работы можно сделать намного дешевле. AI снимает вагон рутинной работы, и маленькие кастомные решения перестали быть чем‑то вроде «ну нет, это полдня печатать код и ещё день на отладку». Там, где раньше приходилось подгонять задачу под готовый инструмент, теперь чаще можно подогнать инструмент под задачу.

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

У меня в итоге получилось разделение работы между обычным чатом и агентом.

Есть, например, CRM на Laravel, которую я хорошо знаю. Если надо изменить знакомую часть проекта, я часто вообще не даю агенту задачу целиком. Я и так знаю, где лежит нужный код. Беру несколько файлов, отправляю их в чат, описываю изменение и получаю готовый кусок. Потом возвращаю файлы в проект, а агент уже проверяет интеграцию, при необходимости поправляет мелочи и делает commit.

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

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

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

Кроме того, агент со временем начинает неплохо подхватывать привычные способы решения задач в проекте. Это удобно до тех пор, пока он не запомнил что‑нибудь неудачное. Тогда возникает ситуация: уже выяснили, что так делать не надо, уже записали это в правилах, а на похожей задаче агент всё равно периодически возвращается к старому способу.

Самые неприятные расходы начинаются не на сложных задачах, а на неожиданных препятствиях. Пока всё идёт нормально, агент может кучу работы сделать быстро и дёшево. Потом на пустяковом шаге один раз не отвечает SSH, зависает Node или dev‑server не успевает подняться, и начинается расследование!!! Причем порой совершенно шизофреническое. За то время, пока агент проверяет несколько гипотез, сервер уже давно снова отвечает.

Особенно весело, если у него при этом есть доступ к большим логам. В двух гигабайтах логов обязательно найдётся что‑нибудь страшное. Старый timeout, ошибка от предыдущего деплоя, warning от давно удалённого модуля, неудачный запрос недельной давности. Если агент уже решил искать причину проблемы, материала у него будет достаточно. Иногда после этого приходится отдельно возвращать его к исходному вопросу и объяснять, что ошибка, которую он нашёл, к сегодняшней ситуации отношения не имеет.

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

У меня сейчас нет универсальной схемы «всё вот это через чат» или «всё вот это через агента». Для знакомого куска проекта я чаще сама выбираю контекст и отдаю локальную работу чату. Если требуется исследование, подключаю агента. Если код уже готов, агент удобно занимается интеграцией, проверками и коммитами. Иногда задача по ходу переезжает из одного режима в другой.

В результате по факту AI‑экономия в разработке выглядит не как «закину промпт в агент и получу работающую систему», а как оплата постоянного пригляда за очень деятельным джуном с СДВГ.