Практический подход к разработке с ИИ-агентами: спецификация, документация, этапы, тесты и управление несколькими моделями.
Собрано в Sveska из открытых обсуждений сообщества. Авторы сообщений не указываются.
Обновлено
Для предсказуемой разработки с ИИ-агентами сначала фиксируют требования, архитектуру и критерии приёмки, а затем ведут работу небольшими этапами. Ключевое условие для сложных и долгих проектов — сохранять документацию, решения и контекст.
Для такого процесса рекомендуют подход Spec Driven Development (SDD): сначала спецификация, критерии приёмки и тесты, затем реализация по этому плану. В качестве варианта SDD-фреймворка упоминается openspec.
На сложном продукте проблемой может стать не написание кода, а сохранение целостности проекта. Если не фиксировать документацию и цепочку принятых решений, проект начинает расползаться, а время уходит на восстановление контекста.
Полезно организовать хранение артефактов:
Для существующей кодовой базы стоит заранее подготовить компактный context-манифест. В нём описывают архитектуру проекта, жёсткие ограничения и табу. Это помогает агенту быстрее ориентироваться, экономит токены и уменьшает число неточных изменений и последующих переделок.
Важно: даже если человек не просматривает код постоянно, ему нужно понимать архитектурные решения проекта.
Для более предсказуемого расхода лимитов Codex на длительных проектах рекомендуют заранее определить правила тестирования. Для UI можно использовать недорогие smoke-тесты в браузере Terra или Luna по преднастроенному сценарию.
Модель и уровень reasoning стоит выбирать вручную, учитывая:
Внешние skills можно адаптировать под правила и архитектуру конкретного проекта.
Один из подходов — работать в VS Code с Claude Code и при необходимости запускать через CLI других агентов и модели в фоне под конкретные задачи. Например, одной модели можно поручить ревью, другой — отдельную coding-задачу. Это позволяет экономить лимиты основной модели.
Для командной работы с агентами вместо дополнительных интерфейсных обвязок можно использовать самописный agent team skill и нативные Projects в GitHub. По описанному опыту это даёт наблюдаемость и управляемые процессы без дополнительной прокладки.
Тюнингованные skills и сложная инфраструктура настройки могут быть невыгодны для разового пилота. Такой подход имеет смысл прежде всего для нескольких долгоживущих проектов, которые постоянно развиваются.
Статья собрана по сообщениям за сентябрь—октябрь 2026 года.