AI Native SDLC

Узкое место переезжает, а не исчезает

Когда генерация кода ускоряется, ограничением становятся формулировка намерения, проверка, выпуск и управление изменениями. Поэтому простое добавление агента в этап Build только увеличивает очередь на review. Процесс становится AI-native не от доли сгенерированного кода, а от того, что каждая стадия оставляет следующей проверяемый вход.

Артефактная цепочка

Минимальная форма цикла:

intent.md → spec.md → plan.md → diff + tests → review findings → incident → новый intent.md

Переход заканчивается принятым и версионированным артефактом в его канонической системе, а не сообщением в чате. Следующий агент читает устойчивый контракт и durable linkage между стадиями. В Git-first процессе цепочка коммитов становится аудитом движения от намерения к последствию; при внешнем источнике эту роль выполняет связка record ID ↔ commit/PR (Evidence Spine).

Одна строка таблицы скрывает развилку: чем именно человек принимает работу на переходе diff + tests — ограниченным по размеру диффом, работающим инкрементом, который он проходит руками, или вовсе артефактами выше по течению (Agent Code Review).

Перед intent.md не хватает стадии: исследование

Цепочка выше начинается с намерения — «какую проблему решаем». В незнакомой или большой кодовой базе между намерением и планом есть отдельная работа, которую легко принять за часть планирования: понять, как устроено то, что уже есть — какие файлы относятся к задаче, как течёт информация, где на самом деле лежит причина. Это не спецификация: спецификация описывает, что должно получиться, исследование — что уже так.

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

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

Стадия наследует свойства остальных: результат — версионируемый артефакт, который читают и бракуют. В разобранном случае первое исследование выбросили целиком, потому что оно пришло к выводу, что дефекта нет; второе запустили с более узкой постановкой. Выброшенное исследование стоит дешевле выброшенной реализации ровно во столько раз, во сколько отличается их множитель (Agent Code Review).

plan.md проверяется простым тестом: сможет ли другой исполнитель реализовать его, не видя исходный разговор. Если во время реализации план изменился, изменение синхронизируется с артефактом — иначе план превращается в ложное свидетельство.

Критерий выхода из spec.md: полнота, измеренная не автором

У перехода intent → spec в таблице стоит гейт «продукт и архитектура», и это описание владельца, а не проверки. Спецификация объявляется готовой, когда её автор перестаёт находить в ней дыры, — а он и не должен их находить, иначе бы он их закрыл.

Разобранный путь одной команды показывает, что именно это и было узким местом. Наивная раздача задач агентам дала субъективное ускорение при объективном замедлении; разработка через тесты дала покрытие сценариев ниже трети и ускорения не дала; спецификация вперёд кода подняла разбор граничных случаев выше половины — и ускорения всё ещё не дала. Заработало только с двумя измеримыми критериями качества самой спецификации:

1. Спецификация ревьюится на языке, которым ревьюеры владеют: все сущности с ограничениями и состояниями, все контракты, вся архитектура — то есть в форме, про которую разработчик умеет сказать «здесь неверно», а не «выглядит разумно».
2. Полнота измеряется числом, и не автором. Из спецификации порождаются тест-кейсы в форме сценариев, и независимая сторона возвращает оценку покрытия сценариев, перечень дыр и перечень противоречий. Непригодность к тестированию, пропуски и двусмысленность проявляются именно здесь: неполная спецификация даёт неполные или взаимно противоречивые кейсы.

И главное — гейт блокирующий: код не порождается, пока кейсы не приняты. Без этой части первые две превращаются в рекомендацию.

Переносимая суть, отделённая от конкретных цифр: у стадии спецификации появляется критерий выхода, который нельзя удовлетворить, уговорив себя. Судит не автор — это тот же принцип независимости, что у оценщика в паре с генератором (Generator Evaluator, Source Independence).

У гейта есть вход, и его описала вторая команда независимо: прежде чем порождать тест-кейсы, сами требования разбирает отдельный агент по кодифицированному чек-листу достаточности. В их случае двенадцать критичных замечаний превратили документ в двадцать восемь атомарных требований — и это не косметика, а предусловие: пока требование остаётся абзацем, «реализовано частично» будет его нормальным состоянием, и никакая последующая проверка полноты не различит состояний (Generated Test Quality).

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

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

Между spec.md и plan.md не хватает ещё одной стадии: устройство программы

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

Формы, которые на этой стадии работают, названы конкретно, и все три — лёгкие:

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

Диаграммы последовательностей на этом уровне авторы пробовали и предпочли им псевдокод — оговорка их же: «своё место у диаграмм есть». Это предпочтение, а не результат замера.

Третья команда пришла к той же стадии независимо и с более узкой формой: у них это обязательный узел «модель данных» до генерации кода, и эффект описан как «настолько увеличило качество, это невероятно». Совпадение трёх независимых размещений одной стадии — довод сильнее любого из них по отдельности, при том что замера нет ни у кого.

Довод в пользу стадии — экономический, и он же объясняет, почему её пропуск незаметен: каждая из этих записей есть решение, которое иначе будет принято неявно во время ревью кода — в самый дорогой момент для перемены мнения. Стадия не добавляет решений, она переносит их туда, где они стоят дёшево (Agent Code Review).

Источник истины выбирается по виду артефакта

Не обязательно переносить весь процесс в Git. Для каждого вида артефакта нужен один источник истины: например, intent живёт в трекере, а plan и diff — в репозитории. Между системами хранится двусторонняя минимальная связь: ID записи ↔ commit SHA/PR. Копия без такой связи быстро расходится с оригиналом.

Чем мерить внедрение, и почему сэкономленные часы не годятся

У процесса, описанного выше, рано или поздно спрашивают, что он дал. Ответ по умолчанию — сэкономленное время на этапах — отброшен независимо двумя крупными командами, и причины у них разные, что делает схождение весомее самого факта.

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

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

Третье наблюдение показывает, зачем всё это нужно: в единственном парном замере одной из команд скорость выросла в три-четыре раза, а ценность — в 1,42, и там же опрос давал положительный результат при отрицательной измеренной продуктивности. То есть ошибиться здесь можно не только в величине, но и в знаке.

Отсюда практический вывод для выбора мерила: годится величина, которая считает доведённое до конца, а не сэкономленное по дороге, и не требует сравнения с контрфактическим прогоном, которого не будет. Обе замены этому удовлетворяют; сэкономленные часы не удовлетворяют ни одному из условий.

Оговорка о переносимости: величины и пороги здесь — чужие, и целевые значения ставятся по своему контуру. Переносится форма мерила, а не число.

Мягкий контур не заменяет жёсткий

Skills и файлы инструкций применяют политики в момент проектирования и сборки, но остаются советующим контуром. Критические инварианты принуждаются детерминированно: hook, permission, branch protection, CI, изоляция среды или ручной gate (Agent Harness).

Особый конфликт интересов возникает в цикле починки: агенту, который исправляет реализацию, нельзя позволять ослабить тест или evaluator, заставивший её упасть. Проверяемый артефакт замораживается на время цикла либо его изменение выносится в отдельный review (Generator Evaluator).

Эксплуатация замыкает разработку

Рабочая схема on-call начинается с детерминированного сигнала и только затем включает агента для сбора фактов и гипотез. Агент не должен сам создавать себе полномочия на исправление: read-only расследование, подготовка proposal/PR и выпуск — разные роли.

Инцидент не заканчивается постмортемом. Его след превращается в:

• новый intent.md, если требуется изменение продукта;
• регрессионный тест или eval-кейс;
• уточнение политики или инструмента только после доказанного повторяемого пробела (Skill Change Control).

Так Maintain становится входом следующего цикла, а не хвостом линейной схемы.

Что в playbook является примером, а не нормой

Рекомендации вроде 20–50 задач в eval-наборе, двух-трёх параллельных сессий и границ 1σ/2σ/3σ полезны как стартовые иллюстрации, но не переносятся без калибровки. Anthropic описывает собственный продукт и клиентскую практику; методики независимого сравнения и универсальных порогов публикация не даёт.

Связано с

• ADLC — жизненный цикл самой агентной системы, а не разработки с помощью агента
• Agent First Repository — почему договорённость должна стать доступным агенту артефактом
• Agent Harness — где мягкая инструкция превращается в исполнимый gate
• Evidence Spine — сквозная связь намерения, решения, действия и последствия
• Generator Evaluator — внешний критерий и защита evaluator от генератора
• Skill Change Control — почему инцидент сначала создаёт evidence и proposal