Команды разработчиков могут укрепить доверие к коду, сгенерированному агентами искусственного интеллекта, с помощью четырехэтапного фреймворка цикла разработки, ориентированного на агентов (Agent Centric Development Cycle, AC/DC): «направление», «генерация», «проверка» и «исправление» (guide, generate, verify and solve), пишет на портале The New Stack Маниш Капур, старший директор по техническому маркетингу продуктов компании Sonar.

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

Один из полезных способов осмысления этой системы — это фреймворк AC/DC. В основе AC/DC лежат четыре этапа, которые определяют, как на самом деле работает агентная разработка в масштабе: «направление», «генерация», «проверка», «исправление». Из этих этапов наибольшее внимание рынка привлекает этап генерации кода агентами ИИ. Но на практике успех или провал фреймворка зависит от силы окружающих его слоев. При слабом руководстве агенты начинают с неверных предположений. При слабой проверке ошибки незаметно накапливаются. При слабом решении проблем команды получают в наследство растущую очередь проблем, для решения которых нет масштабируемого способа.

Почему проверка выходит на первый план

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

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

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

Направление: задавайте агентам границы, а не просто промпты

Первое требование в агентном рабочем процессе — это задание направления. Не общих промптов, а структурированного контекста.

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

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

В этом смысле этап «направление» — это не просто подготовка. Это первый уровень контроля.

Проверка: уровень, превращающий скорость в доверие

Проверка — это этап, на котором агентная разработка становится либо управляемой, либо хрупкой.

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

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

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

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

Качество кода все больше влияет на экономику разработки с использованием ИИ. В контролируемом исследовании, проведенном компанией Sonar с использованием согласованных пар репозиториев с одинаковыми внешним поведением, архитектурой, зависимостями и тестовым покрытием, агенты, работающие с кодовыми базами более высокого качества, в среднем использовали примерно на 7% меньше входных токенов, на 8% меньше выходных токенов и на 11% меньше усилий по рассуждениям. Они также перечитывали файлы на 34% реже, что является полезным сигналом того, что более понятный код снижает неопределенность и позволяет агентам более уверенно вносить изменения. Другими словами, качество кода больше не является просто вопросом поддерживаемости. Оно начинает выглядеть как переменная эффективности инфраструктуры ИИ.

Исправление: замкнуть цикл вместо увеличения бэклога

Уровень проверки полезен только в том случае, если он приводит к действиям.

Вот почему этап «исправление» так важен в модели AC/DC. Когда выявляются проблемы, процессу необходим систематический способ их устранения, повторной проверки исправлений и извлечения уроков из результатов. В противном случае проверка становится механизмом отчетности, а не оперативным механизмом. Это особенно важно в средах, где ИИ увеличивает общий объем проверяемого кода. Без механизма исправления любая система обнаружения в конечном итоге превращается в генератор бэклога.

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

Реальный сдвиг

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

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

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

В эпоху программных агентов реальное преимущество будет заключаться не только в генерации кода. Оно будет заключаться в создании дисциплины для этого процесса.