AI-агенты в повседневной разработке: как это выглядит на практике

Разговор об AI в разработке обычно колеблется между «скоро заменит программистов» и «генерирует мусор». Обе позиции мешают увидеть простую вещь: инструмент оказался очень полезным на одном классе задач и почти бесполезным на другом. Границу стоит знать точно.

Чем агент отличается от автодополнения

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

Разница практическая, а не терминологическая. Автодополнению вы говорите, что печатать. Агенту — что должно получиться. Это перекладывает нагрузку с набора текста на формулирование задачи и проверку результата, и к этому нужно привыкнуть.

Задачи, где выигрыш заметен сразу

• Разбор незнакомого кода. Быстро понять, что делает чужой модуль, где входные точки, что произойдёт при изменении. На проектах в поддержке это экономит больше всего времени.
• Типовые модули и компоненты. Каркас по образцу существующего кода: структура, стиль, соглашения. Не творчество, но объём.
• Тесты. Особенно на граничные случаи, которые лень перечислять руками.
• Массовые однотипные правки. Переименование по всему проекту с учётом контекста, приведение к новому API, обновление вызовов.
• Обработка данных и вспомогательные скрипты. Разовые задачи, ради которых не хочется тратить полдня.
• Техническая документация. Описание того, что уже написано, — по коду, а не по памяти.
• Отладка. Гипотезы о причине ошибки по стектрейсу и логам. Часть гипотез мимо, но круг поиска сужается быстрее.

Задачи, где агент скорее мешает

• Архитектурные решения. Модель предложит популярный вариант, не зная ни бюджета, ни компетенций команды, ни планов на три года.
• Код с неявными требованиями. Всё, что «должно работать как в прошлом проекте» или «как договорились на встрече», ей неизвестно.
• Оптимизация без измерений. Она уверенно оптимизирует не то место.
• Задачи, где вы сами не понимаете требований. Быстро получить неверное решение — не улучшение.
• Тонкая специфика платформы. Нюансы поведения конкретной версии Bitrix или Drupal модель нередко додумывает.

Как выглядит рабочий цикл

Устойчивая схема получается примерно такой:

1. Сформулировать задачу конкретно. Не «добавь фильтр», а «добавь фильтр по статусу в список заказов, по образцу фильтра по дате в соседнем модуле».
2. Дать контекст. Файлы-образцы, соглашения проекта, ограничения. Без этого модель выберет свой стиль.
3. Получить изменение небольшого объёма. Правки на несколько файлов ревьюятся, правки на тридцать — нет.
4. Прочитать диффы построчно. Это основная работа, и её нельзя пропускать.
5. Запустить тесты и проверить руками. Особенно сценарии, которых не было в тестах.
6. Зафиксировать замечание в правилах проекта. Если пришлось поправить одно и то же дважды, это пропущенное правило.

Ревью машинного кода: на что смотреть

Ошибки AI отличаются от человеческих. Человек ошибается там, где устал или спешил; модель — там, где ей не хватило контекста, причём с одинаково уверенным видом.

Особого внимания требуют:

• Безопасность. Экранирование вывода, проверка прав, параметризация запросов, валидация входных данных.
• Граничные случаи. Пустые коллекции, отсутствующие значения, нулевые количества.
• Обработка ошибок. Проглоченные исключения — очень частый паттерн.
• Скрытые запросы в циклах. Особенно при работе с ORM.
• Несуществующие методы. Правдоподобно названный метод, которого нет в этой версии библиотеки.
• Лишние зависимости. Подключенная библиотека там, где хватило бы десяти строк.

Про ответственность

Формулировка простая: код, попавший в проект, — ваш, независимо от того, кто набрал текст. Инструмент не несёт ответственности ни за уязвимость, ни за потерянные данные, ни за неверный расчёт.

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

Что меняется в работе

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