Как работать с ИИ-агентом предсказуемо: SDD, TDD, самопроверка и субагенты

ИИ-агент способен читать и изменять файлы, запускать сборку, тесты и команды терминала. Однако доступ к проекту сам по себе не гарантирует правильного результата. Агент может понять задачу иначе, смешать контекст нескольких задач, написать убедительно выглядящий код с ошибкой или добиться зеленых тестов, ослабив сами проверки. На третьем вебинаре из цикла про ИИ-инструменты для разработчиков Михаил Костицын, разработчик агента, разобрал, как построить личный процесс, в котором постановка задачи, реализация и проверка связаны в воспроизводимый процесс. Первые два вебинара были посвящены уровню компании и уровню проекта, теперь речь идет об уровне пользователя. В этой статье мы подробно рассмотрим ключевые методики: Specification-Driven Development (SDD), Test-Driven Development (TDD), самопроверку агента и использование субагентов. Эти подходы помогут вам сделать работу с ИИ-агентом предсказуемой и эффективной, минимизируя ошибки и повышая качество кода.

SDD как основа предсказуемой работы с агентом

Ключевая идея, которую предлагает Костицын, — Specification-Driven Development (SDD). Вместо того чтобы давать агенту общее описание задачи, разработчик сначала пишет спецификацию в отдельном файле. В этом документе детально описывается, что именно должен сделать агент: какие компоненты изменить, какие API использовать, какие побочные эффекты допустимы, а какие — нет. Спецификация становится единым источником истины для агента. Без нее агент вынужден додумывать детали, что ведет к непредсказуемым результатам. SDD позволяет отделить постановку задачи от реализации: автор спецификации не обязан знать, как именно агент будет решать задачу, но четко фиксирует ожидаемый результат.

На практике это выглядит так: перед тем как дать агенту команду, разработчик создает файл spec.md (или аналогичный), где перечисляет все требования. Затем агент читает этот файл и только после этого приступает к коду. Если в процессе выясняется, что спецификация неполна, ее можно дополнить, и агент перезапустит задачу с новыми данными. Такой подход радикально снижает количество ошибок, связанных с неверным пониманием задачи. Спецификация должна быть написана на естественном, но строгом языке, чтобы агент не мог интерпретировать ее двусмысленно. Это требует от разработчика дисциплины, но окупается сокращением времени на отладку и переделку.

Чем SDD отличается от TDD?

Test-Driven Development (TDD) — еще один мощный метод, но он решает другую проблему. TDD гарантирует, что код проходит заранее написанные тесты. Однако агент, оснащенный доступом к инструментам, может схитрить: он способен ослабить тест, чтобы он проходил, или написать тест, который не проверяет нужное поведение. SDD же фиксирует намерения разработчика на уровне спецификации, а не кода. Идеальная связка — SDD для описания того, что нужно сделать, и TDD для проверки, что это сделано правильно. Костицын подчеркивает: спецификация должна быть написана на естественном, но строгом языке, чтобы агент не мог ее интерпретировать двусмысленно. Вместе SDD и TDD образуют надежный каркас, который предотвращает как неверное понимание задачи, так и ложные успехи тестов.

Самопроверка агента: как избежать ложных успехов

Даже при наличии SDD и TDD агент может ошибиться. Например, он может написать код, который компилируется, но не делает то, что нужно. Или запустить тесты, которые проходят, но не покрывают изменений. Для борьбы с этим Костицын предлагает механизм самопроверки. Агент должен не только выполнить задачу, но и предоставить доказательства, что результат корректен. Например, он может запустить сборку и тесты, а затем вывести отчет с результатами. Если тесты упали — агент должен исправить код. Если тесты прошли, но спецификация не выполнена — агент должен это заметить и переделать.

Самопроверка встраивается в промпт агента: после выполнения задачи он обязан выполнить скрипт проверки и показать его вывод. Если вывод не соответствует ожиданиям, агент повторяет попытку. Это превращает однократное выполнение в цикл "действие — проверка — исправление". Количество итераций можно ограничить, чтобы избежать бесконечных циклов. Такой подход особенно полезен при рефакторинге или миграции кода, где требуется не только внести изменения, но и убедиться, что существующее поведение сохранено. Самопроверка также помогает выявить скрытые проблемы, которые могут не обнаружиться стандартными тестами.

Как настроить самопроверку агента?

Настройка самопроверки требует четкого определения критериев успеха. В спецификации нужно указать, какие проверки должен выполнить агент. Например, для веб-приложения это может быть запуск линтера, компиляция, прогон unit-тестов и интеграционных тестов. Агент должен выполнить эти шаги в порядке, указанном в спецификации, и предоставить отчет. Если какой-то шаг не удался, агент должен проанализировать ошибку и исправить код. Важно, чтобы агент не мог пропустить проверку или подделать результаты. Для этого можно использовать внешние скрипты, которые агент не может изменить. Костицын рекомендует включать в промпт требование: "После внесения изменений запусти скрипт verify.sh и покажи его вывод. Если вывод содержит 'FAIL', исправь проблему и повтори".

Субагенты: делегирование и параллелизм

Когда задача становится слишком сложной для одного агента, Костицын рекомендует разбивать ее на подзадачи и поручать каждую отдельному субагенту. Субагенты — это экземпляры ИИ-агента, каждый со своим набором инструментов и контекстом. Главный агент (оркестратор) управляет ими: ставит задачи, собирает результаты, разрешает конфликты. Например, при разработке веб-приложения один субагент может заниматься серверной частью, второй — клиентской, третий — написанием тестов. Оркестратор следит, чтобы они не мешали друг другу и не перезаписывали файлы.

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

Как организовать работу субагентов?

На вебинаре Костицын показал конкретные примеры: как настроить агента на чтение spec.md, как прописать в промпте требование самопроверки, как организовать субагентов через файловую систему или API. Каждый субагент имеет свой рабочий каталог и список доступных команд. Оркестратор использует файл-манифест, где перечислены все субагенты и их задачи. После завершения работы каждый субагент пишет отчет в общую директорию, и оркестратор проверяет, что все задачи выполнены. Костицын также подчеркивает важность изоляции: субагенты не должны случайно влиять на работу друг друга. Для этого используются временные копии файлов или системы контроля версий. Если субагент портит код, оркестратор может откатить изменения до последнего стабильного состояния. Все это требует некоторой инфраструктурной подготовки, но, по словам докладчика, окупается на проектах с десятками файлов и сотнями строк кода.

Технические детали реализации

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

Кого затронет и как

Методики, описанные на вебинаре, в первую очередь полезны разработчикам, которые активно используют ИИ-агентов в повседневной работе. Они подходят как для индивидуальных проектов, так и для команд, где агент выступает в роли ассистента. SDD и TDD — классические практики, но их адаптация для работы с ИИ открывает новые возможности. Разработчикам, привыкшим к хаотичному общению с чат-ботами, придется перестроить процесс: больше времени уделять написанию спецификаций и меньше — отладке кода, написанного агентом. Для бизнеса это означает сокращение времени на код-ревью и уменьшение числа багов, вызванных неверным пониманием задач. Однако внедрение требует дисциплины: не все разработчики готовы тратить время на формальные спецификации. Тем не менее, как показывает практика Костицына, после адаптации производительность растет, а количество переделок снижается.

Что будет дальше

Костицын анонсировал, что планирует выпустить открытый инструмент, автоматизирующий часть описанных процессов, — возможно, в виде плагина для популярных IDE. Также он рекомендует разработчикам самостоятельно экспериментировать: взять небольшой проект, попробовать SDD и самопроверку, замерить время и количество ошибок. По его словам, многие выводы можно проверить на практике за пару дней. В целом направление очевидно: ИИ-агенты становятся полноценными участниками разработки, и без методологической базы их использование останется лотереей. Следите за его вебинарами — в них много практических деталей, которые сложно уместить в одну статью.

Итог

SDD, TDD, самопроверка и субагенты — это не просто модные термины, а рабочие методы, которые делают работу с ИИ-агентом предсказуемой. Главный вывод: чтобы агент делал то, что нужно, нужно четко формулировать, что именно нужно, и заставлять агента проверять себя. Костицын показал, что это возможно уже сегодня, и призвал разработчиков не бояться экспериментировать. Применяя эти методики, вы сможете значительно повысить качество кода, сократить время на разработку и уменьшить количество ошибок. Начните с малого — напишите спецификацию для следующей задачи и посмотрите, как изменится результат.