Как мы создавали AI-агента, с которым теперь сами разрабатываем продукты
Еще недавно поиск решения для относительно простой задачи мог надолго вывести разработчика из рабочего контекста. Нужно было найти подходящий метод для обработки коллекции, разобраться в документации, изучить ответы на Stack Overflow или отыскать нужное обсуждение на техническом форуме. Полезная информация часто находилась рядом с длинными спорами об архитектуре, качестве кода и профессиональном опыте автора.
Появление ИИ-чатов изменило этот процесс. Модель стала своеобразным продвинутым поисковиком: ей можно было задать уточняющий вопрос, показать фрагмент кода и попросить сравнить несколько вариантов реализации. Заодно чат помогал с рутинными задачами — например, подобрать название для метода, чтобы в проекте не появлялись конструкции вроде processDataFinalReallyFinal.
Следующим этапом стала генерация более крупных фрагментов и целых файлов. Разработчик уже не просто получал подсказку, а мог поручить модели реализовать заметную часть задачи. Однако у такого подхода быстро обозначились ограничения. Вместо небольшой функции модель могла выдать тысячи строк, которые требовали внимательного изучения. Сэкономленное на написании время переносилось на ревью, тестирование и исправление пропущенных проверок.
В результате скорость появления кода увеличивалась, но вместе с ней могла расти и стоимость сопровождения. Разработчику приходилось контролировать результат, проверять его качество и переносить данные между ИИ-чатом и средой разработки. Чат помогал с отдельными действиями, но не становился полноценным участником рабочего процесса.
От генерации к работе с проектом
Переход к агентному подходу должен был решить именно эту проблему. Современный ИИ-агент способен не только предложить код, но и взаимодействовать с проектом: работать с файлами, выполнять проверки и запускать сервисы в облачных окружениях. Это меняет формат взаимодействия. Разработчик формулирует задачу на более высоком уровне, а агент последовательно выполняет связанные с ней операции.
Собственного агента мы создавали постепенно, расширяя круг доступных ему задач. Каждая новая возможность была не самоцелью, а ответом на конкретное ограничение предыдущего процесса. Если генерация кода оставляла всю работу по проверке человеку, следующим шагом становилось выполнение тестов и других контролирующих процедур. Если результаты оставались в рамках локальной среды, появлялась необходимость автоматизировать развертывание сервисов в облаке.
Такой подход важен не только с технической, но и с организационной точки зрения. Агент перестает быть отдельным окном, куда нужно копировать контекст и затем возвращать полученный результат в IDE. Он включается в общий цикл разработки: получает доступ к материалам проекта, вносит изменения, запускает предусмотренные проверки и помогает довести задачу до рабочего состояния.
Что остается разработчику
Автоматизация написания кода, создания тестов и проверки изменений не отменяет роль человека. Напротив, она смещает фокус работы. Вместо постоянного выполнения однотипных операций разработчику приходится точнее формулировать требования, задавать ограничения, оценивать архитектурные решения и контролировать итоговый результат.
Опыт создания агента показывает, что главный эффект возникает не от самой генерации кода, а от объединения нескольких этапов в единую цепочку. Чем больше действий агент может выполнить самостоятельно, тем меньше разработчику приходится выступать посредником между чатом, редактором и инфраструктурой. При этом ответственность за цели проекта, качество решений и последствия изменений по-прежнему остается у команды.
