Есть один популярный аргумент против AI в разработке: «Написание кода — это лишь малая часть SDLC. Есть ещё интервью с заказчиком, формулирование требований, архитектурное проектирование, тестирование, мониторинг. ИИ — это просто очень быстрый кодер, а не думающий участник команды».
Этот аргумент справедлив. Для первого этапа освоения инструмента.
На первом этапе человек видит, что AI пишет код — и делает вывод: «ИИ = кодер». Потом замечает, что кодинг — не вся разработка. Делает следующий вывод: «значит, AI не заменит разработку целиком». Логика правильная, но вывод устаревает раньше, чем его успевают произнести вслух.
На следующем витке выясняется, что нейросети прекрасно умеют делать именно то, о чём говорит этот аргумент.
Сбор требований: clarify gate в Jira
Заказчик создаёт задачу: «сделайте интеграцию с ERP». Команда уходит в недели уточнений в мессенджерах, которые не попадают в систему учёта, не версионируются и теряются при смене исполнителя.
Решение, которое уже работает в продакшне: AI-агент ведёт структурированный clarify-диалог с заказчиком прямо в Jira. Он задаёт вопросы по осям — Scope, акторы, данные, NFR, зависимости, acceptance criteria. Тикет не переходит в разработку, пока в нём не зафиксированы цель, scope и проверяемые AC.
С project context (bible проекта + история похожих задач + корпусный поиск) агент задаёт вопросы под контекст проекта, а не шаблонные: «В архитектуре каталог — Elasticsearch и B2B-витрина в PostgreSQL. Отчёт по полному индексу или только по витрине?»
В итоге — зрелый тикет с проверяемыми AC: то, что уходит в разработку без последующего «а мы имели в виду совсем другое».
Reference trace: github.com/dobryakov/jira-clarify-bot — FastAPI, Docker, контракт вебхуков, механика ElicitationEngine.
Проектирование и согласование спеки
Интеграция двух систем разных компаний: классически это недели встреч, переписка, ручное ведение OpenAPI-контракта.
Эксперимент: два AI-агента — по одному со стороны каждой организации — провели переговоры самостоятельно. Продукт разговора: chat-history.txt (транскрипт) и openspec.yaml (согласованный OpenAPI). Git-история показывает пошаговое формирование контракта — видна «совместная работа», а не один монолитный вывод.
Архитектурный принцип, который агенты воспроизвели сами: граница организации пересекается только контрактом (POST /orders), а не внутренними данными. Ownership пересчёта суммы явно закреплён в описании endpoint'а — без этого два сервиса могут оба считать total, расходиться и не знать, кто прав.
Reference trace: github.com/dobryakov/bots-discuss-spec
Spec-Driven Development: specify → clarify → plan → tasks
Анти-паттерн: один большой промпт → агент сразу пишет код. Через час структура непонятна, откат дорогой. На ретро: «ИИ не тянет архитектуру» — хотя причина не в AI, а в том, что не было зафиксированного «что строим».
Spec-Driven Development переворачивает порядок. Конституция репозитория (.specify/) — шаблоны и память проекта, заполненные до первой фичи. Потом цепочка: specify → clarify → plan → tasks → implement. Спека — источник истины, код — производная.
Агент не выдумывает структуру каждый раз: он наследует шаблоны из памяти проекта и работает в рамках устойчивых решений по стеку и соглашениям. Параллельные фичи получают одинаковый scope, понятный в PR и в голове.
Reference trace: github.com/dobryakov/ytrader-bybit — полный цикл .specify/ + specs/.
Тестирование: eval как release-критерий
AI-фича, которая работает на демо, ломается в проде. Причина — «demo grade eval»: тестирование на тех же входах, что питч. Длинный хвост реального трафика никогда не прогонялся.
Три слоя eval как release-gate:
Layer 1 — Regression. Фиксированный набор кейсов с известным ожидаемым выводом: edge-кейсы из реальных инцидентов (не из демо), adversarial-входы на каждый тип вывода. Любой новый фейл блокирует релиз.
Layer 2 — Distribution check. 20–50 свежих реальных входов через новую версию. Проверка не на «идеал», а на diff против снапшота прошлого релиза: распределение длины, изменение retrieved-чанков, сдвиг confidence к краям — модель либо уверена во всём, либо ни в чём — признак хрупкости.
Layer 3 — Human spot-check. Обязателен перед первым прод-деплоем нового вида вывода. Доменный человек читает 10–20 реальных выводов с конкретными вопросами: нет ли данных, к которым модель не должна иметь доступ; счёл бы эксперт это корректным; нет ли adversarial-эксплуатации.
Один ответственный подписывает sign-off. Если его нельзя назвать — это уже диагноз.
Reference trace: github.com/dobryakov/eval-harness
Мониторинг и воспроизводимые мультиагентные workflow
Чат-агент решает задачу заново каждый раз. Для разовой задачи это нормально, для автоматизации в проде — нет: воспроизводимости нет как класса, а дебажить «агент что-то сделал не так» без артефактов невозможно.
Решение: агент производит персистентные версионируемые артефакты, а не эфемерные ответы. Dual-file pattern: .workflow.json (экспорт рабочего графа) + .meta.md (YAML-метаданные с guidance для агента и workflow_id). Разделение не случайное: агент читает .meta.md и видит, что workflow уже существует — не пересоздаёт, а обновляет тот же инстанс. Повторяющаяся задача — переиспользует проверенный workflow, не регенерирует.
LLM как consumer событийного потока (Kafka, webhooks, monitoring) — разбирает логи, подсвечивает аномалии, пишет RCA. Мультиагентная связка: один агент ловит ошибки, второй исправляет, третий ревьюит и верифицирует, четвёртый гоняет безопасность.
Reference trace: github.com/dobryakov/ai-n8n-workflow-builder
Ограничения каждой практики
Во всех пяти практиках — явный human-in-the-loop checkpoint.
В clarify gate — approve от заказчика или PO. В eval harness — sign-off конкретного ответственного. В cross-org negotiation — формальная верификация контракта за пределами автономии агента.
Контекст решает всё. Clarify gate без project bible задаёт generic вопросы. Cross-org negotiation без явного trust model — это proof-of-concept, не боевой продукт. Eval harness без кейсов из реальных инцидентов превращается в тот же demo-grade.
Мультиагентные связки — это проектируемая архитектура с явным ownership. «Один ИИ ловит ошибки, второй исправляет» работает ровно настолько, насколько чётко определены границы каждого агента и критерии передачи.
Итог
Паттерн одинаковый во всех пяти практиках: AI снимает рутину подготовки — clarify-диалог, переговоры по контракту, spec-генерацию, формирование eval-набора, сборку workflow — а конкретный человек принимает решение в конкретной точке.
Каждый из перечисленных шагов SDLC уже покрыт работающими практиками с публичными артефактами. Аргумент «ИИ — просто кодер» был точным. До второго этапа.