От прототипа к продакшену: Практический взгляд на AI-агентов в разработке ПО

От прототипа к продакшену: Практический взгляд на AI-агентов в разработке ПО

Колона некодера - t.me/necodernotes

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

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

Как мы создавали ПО раньше: Классический подход

До широкого распространения AI-агентов процесс разработки программного обеспечения был исключительно человекоцентричным. Он следовал устоявшемуся, последовательному пути с четким разделением ролей и обязанностей.

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

Каждый разработчик пишет необходимый код и, в идеале, покрывает его юнит-тестами. Этот код затем отправляется в среду разработки. Выделенная команда DevOps управляет всей инфраструктурой, обеспечивая бесперебойный конвейер от разработки до стейджинга и, наконец, до продакшена. Как только код оказывается на стейджинг-сервере, QA-инженер тщательно его тестирует. Только после получения зеленого света от QA код развертывается в продакшен.

Каждая человеческая роль в этой цепочке — продакт-менеджер, тимлид, разработчик, DevOps и QA — обычно работает в рамках стандартного 8-часового рабочего дня.


Классический процесс разработки


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

Как мы можем создавать ПО с AI-агентами: Новая парадигма

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

В этой новой модели продакт-менеджер по-прежнему создает бэклог. Однако вместо тимлида задачи из него забирает напрямую AI-агент. Этот агент работает 24/7.

Вот как работает цикл разработки под управлением AI:

  1. Валидация задачи: Перед началом работы AI-агент сначала анализирует задачу из бэклога на предмет ясности, полноты и логической непротиворечивости с существующим проектом. Если задача двусмысленна или неполна, она возвращается продакт-менеджеру с предложениями по улучшению.
  2. Разработка через тестирование (TDD): После валидации задачи агент инициирует цикл TDD. Сначала он генерирует тест, который должен быть пройден, чтобы задача считалась выполненной.
  3. Генерация кода с контекстом (RAG): Затем агент пишет код для прохождения этого теста. Важно отметить, что во время написания он использует механизм Retrieval-Augmented Generation (RAG) для доступа и понимания всей существующей кодовой базы и "Устава проекта" — документа, содержащего все нефункциональные требования, такие как стандарты безопасности, бенчмарки производительности и архитектурные принципы. Это гарантирует, что новый код всегда будет в контексте.
  4. Итеративное исправление: Если код не проходит тест, агент переписывает его, повторяя итерации до тех пор, пока тест не будет пройден. Чтобы предотвратить бесконечные циклы, предусмотрен предохранитель: после определенного количества неудачных попыток агент помечает задачу и оповещает человека — AI-оркестратора.
  5. Человеческий надзор: AI-оркестратор — это высококвалифицированный инженер, который настраивает агента, дает технические указания по сложным задачам (часто добавляя комментарии непосредственно в задачу в бэклоге) и расследует любые проблемы, отмеченные агентом.
  6. Финальное QA: Как только код успешно проходит свой тест, он развертывается в стейджинг-среду. Здесь человек, QA-инженер, выполняет окончательную проверку. Если обнаруживается ошибка, создается баг-репорт и добавляется в бэклог как высокоприоритетная задача для AI-агента. Если все в порядке, код отправляется в продакшен.


Процесс разработки с AI-агентом



Процесс разработки с AI-агентом

Заключение: Потенциал и открытые вопросы

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

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

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

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

Буду рад услышать ваши мысли и комментарии по поводу предложенного рабочего процесса.


Report Page