Перейти к содержимому

Жизненный цикл разработки с агентами

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

Этот раздел о том, как перестроить весь жизненный цикл разработки (SDLC, software development lifecycle) вокруг агентов: от идеи, записанной любым сотрудником, до метрик сопровождения, которые сами порождают новые задачи. Раздел «Практика» учит работать с агентом над одной задачей; здесь речь о том, что происходит до и после неё.

Узкое место сместилось: код быстрый, процесс медленный

Заголовок раздела «Узкое место сместилось: код быстрый, процесс медленный»

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

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

Цикл состоит из шести этапов, и последний замыкается на первый:

flowchart TB
    P["Plan: намерение"] --> D["Design: спецификация"]
    D --> B["Build: план и код"]
    B --> T["Test: проверки"]
    T --> DEP["Deploy: ревью и выкатка"]
    DEP --> M["Maintain: метрики"]
    M --> P

Аномалия, найденная на этапе сопровождения, становится новым намерением и проходит цикл заново.

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

Цепочка артефактов: intent.md, spec.md, plan.md, пул-реквест

Заголовок раздела «Цепочка артефактов: intent.md, spec.md, plan.md, пул-реквест»

Этапы соединяются не передачами между людьми, а закоммиченными файлами. Намерение записано в intent.md: проблема и желаемый результат словами автора идеи. Из него агент собирает spec.md: требования и проектные решения. Из спецификации рождается план-файл plan.md, знакомый по разделу Контекст-инжиниринг, а из плана код и пул-реквест (pull request).

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

Внешний цикл и внутренний: как это соотносится с рабочим циклом

Заголовок раздела «Внешний цикл и внутренний: как это соотносится с рабочим циклом»

Страница Рабочий цикл с агентом описывает внутренний цикл: сформулировать, спланировать, выполнить, проверить, зафиксировать. Это ритм одной задачи, от постановки до коммита, и он целиком живёт внутри этапа Build.

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

Раз каждый переход оформлен коммитом, скорость и качество процесса считаются по меткам времени, без новой отчётности. Метрики делятся на два вида:

  • Опережающие (leading). Показывают скорость сейчас: время от разговора до закоммиченного intent.md, от намерения до спецификации, от плана до пул-реквеста.
  • Запаздывающие (lagging). Показывают качество спустя время: доля намерений, доживших до проектирования, объём переделок спецификации после начала сборки, инциденты после выкатки.

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

Автор учебника: Шахматов Алексей