Создание ПО с помощью агентов искусственного интеллекта — это не индивидуальный вид спорта, особенно когда проекты затрагивают несколько репозиториев, сервисов и требуют знаний в области инженерии подсказок, пишет на портале The New Stack Анкит Джайн, соучредитель и генеральный директор портала Aviator.

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

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

Правда в том, что оба этих подхода можно встретить в одной и той же компании.

Проблемы с внедрением ИИ на предприятиях

Существует несколько проблем с текущим подходом к внедрению ИИ на предприятиях:

  1. Отсутствие контекста: работа с большими, беспорядочными кодовыми базами предприятий далека от вайб-кодинга. Независимо от того, насколько хороши модели или насколько хорошо мы проектируем следующий кодирующий агент, мы не можем добиться прогресса, не предоставив правильный и полный контекст агентам больших языковых моделей (LLM).
  2. Кривая обучения: для эффективного использования кодирующих агентов требуется как минимум определенное обучение, которое сегодня не предоставляется большинством организаций. Это приводит к различиям в использовании и успешности этих инструментов. Некоторые разработчики, которые опробовали и протестировали различные подходы, теперь имеют свои удобные справочники о том, как получить максимальную отдачу от этих инструментов, в то время как другие все еще пробуют свои силы с ограниченным успехом.
  3. Коллективные знания: предприятия не строятся за один день. Люди приходят и уходят, регулярно унося с собой много коллективных знаний. Когда мы думаем о контексте, мы всегда думаем о документах и спецификациях того, что и как. Многие корпоративные знания вращаются вокруг «почему». Эволюция организации включает в себя тысячи микрорешений, принимаемых каждый день, которые формируют деревья решений, отраженные в коде. Понимание того, почему продукт построен таким образом, так же важно, как и понимание того, как он построен. Иногда эта информация может даже не быть отражена в спецификациях продукта.

Удаленные агентные среды

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

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

В конечном итоге, инженеры, которые знают, как хорошо работать с агентами на основе IDE, получат от этого пользу, но удаленные агенты сами по себе не решают реальную проблему предприятия: отсутствие сотрудничества между разработчиками и ИИ.

Разработка на основе спецификаций

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

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

Перестаньте выбрасывать подсказки

Надо также понимать высокую важность проверки кода. Помимо поиска ошибок, проверка кода помогает обмениваться знаниями. Так корпоративные знания передаются от одного человека другому. Я также большой поклонник периодического парного программирования как альтернативы, которая помогает быстро согласовать идеи. Однако, если мы посмотрим на наши шаблоны кодирования ИИ, мы делаем все наоборот:

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

Многопользовательские удаленные агентные среды

Здесь и приходит на помощь концепция руководств по эксплуатации (ранбук, runbook). Ранбуки для агентного ИИ — это способ сохранить контекст, совместно работать над подсказками, делиться рабочими процессами выполнения и вести журналы аудита и поддерживать предварительно настроенные удаленные агентные среды.

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

Ранбуки позволяют командам переключаться из однопользовательского режима в многопользовательский, чтобы:

  • совместно работать над подсказками;
  • делиться рабочими процессами выполнения;
  • вести журналы аудита.

Эти ранбуки устраняют разрыв между спецификациями продукта и кодом, поскольку вы можете:

  • взять чужой ранбук и развивать его;
  • применять контекст из одного пути кода или репозитория к другому;
  • создавать свои собственные спецификации и получать отзывы от команды;
  • сотрудничать со всеми заинтересованными сторонами в рамках одной сессии с агентами кодирования.

Контроль версий

Многоразовые ранбуки фиксируют знания команды в области ИИ-подсказок и шаблонов выполнения, которые постоянно развиваются. Если это живые, динамичные документы, важно поддерживать их версионирование. Это дает несколько преимуществ:

  • понимание того, как развивались спецификации;
  • отслеживание любых изменений кода в точной версии ранбука;
  • возможность для других пользователей создавать свои версии ранбуков и вносить в них изменения;
  • откат изменений, когда ИИ дает сбой (а это обязательно произойдет).

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