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

Эта глава связывает самостоятельность ИИ с маршрутом разработки и выпуском по риску. Определения A0–A3 и обязательные условия для каждого уровня приведены в разделе «Уровни A0–A3».

Жизненный цикл разработки программного обеспечения с ИИ (AI SDLC) нужен не для того, чтобы генерировать больше кода. Его задача — быстрее превращать согласованное намерение в небольшое проверенное изменение и сохранять контроль до и после выпуска.

Формальные спецификации, автоматические проверки и контрольные точки создают основу производственной разработки. Сам процесс не делает риск низким: нужны права, наблюдение, откат и оценка цены ошибки. [G1-D1-p13], The New SDLC With Vibe Coding_Day_1.pdf, с. 13.

1. Согласуйте намерение #

Короткая спецификация изменения отвечает на вопросы:

• какую проблему решаем;
• кто получит результат;
• что входит и не входит в работу;
• какие ограничения уже действуют;
• как проверить результат;
• что может сломаться;
• как откатить.

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

Спецификация в репозитории задаёт общее намерение, но не отменяет более точные ограничения кода, тестов и записей решений. [G1-D5-p8], Day_5_v3.pdf, с. 8.

2. Соберите постоянный и оперативный контекст #

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

Система получает только нужные части. Секреты и производственные данные не копируются в контекст по умолчанию. Каждый источник имеет происхождение и разрешённую область.

3. Спланируйте небольшое изменение #

Небольшое изменение легче понять, проверить, рецензировать и откатить. План перечисляет:

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

Ускорение генерации может перенести часть ограничения в постановку, архитектуру и проверку. Это зависит от задачи и команды и не отменяет сложность реализации. [G1-D1-p19]

4. Создайте изолированную рабочую среду #

Код, подготовленный системой или внешней зависимостью, запускается в краткоживущей изолированной среде.

Минимальные ограничения:

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

Список разрешённых доменов не является достаточной защитой. Разрешённый ресурс может вернуть вредоносный материал или принять лишние данные. [G1-D4-p15], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 15.

Имена новых пакетов проверяют по происхождению и закрепляют по версии. Галлюцинация имени зависимости создаёт риск цепочки поставок. [G1-D4-p14], тот же материал, с. 14.

5. Реализуйте с явными зависимостями #

Среда фиксирует:

• модель и её режим;
• версию инструкции;
• навыки и вспомогательные материалы;
• доступные инструменты;
• внешние серверы;
• пределы прав и расходов;
• историю существенных действий.

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

6. Выполните обычные тесты и независимые проверки #

Обычные тесты проверяют детерминированные свойства. Набор оценочных проверок исследует вероятностное поведение. Оба вида нужны вместе. [G1-D5-p30], Day_5_v3.pdf, с. 30.

Проверки включают:

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

Успешная сборка и тесты являются нижней границей, но не полным доказательством. [G1-D4-p30], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 30.

Если система исправляет серьёзный дефект, она не должна незаметно ослабить воспроизводящий тест. Изменение такого теста получает отдельное обоснование и рецензию. Для обычной разработки тест можно менять, когда изменилось согласованное поведение. [G1-D4-p23]

7. Проверьте результат и ход действий #

Рецензент проверяет:

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

Для интерфейса проверяется отрисованный результат, управление с клавиатуры и поведение на нужных экранах. Исходный код не показывает все визуальные и интерактивные дефекты. [G1-D4-p36]

8. Подготовьте описание запроса на слияние #

ИИ может подготовить черновик. Автор изменения подтверждает его точность.

Обязательные поля:

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

ИИ может подготовить сводку, точки возможной поломки и оценку риска. Автор изменения отвечает за их точность. [G1-D5-p19], Day_5_v3.pdf, с. 19.

9. Выберите условия выпуска по риску #

Условное автоматическое слияние допустимо для заранее определённого низкого риска. Прохождение тестов само по себе не разрешает любой выпуск. [G1-D5-p20]

10. Наблюдайте после выпуска #

Команда заранее знает:

• какие показатели должны измениться;
• какие ошибки считать существенными;
• кто получает сигнал;
• когда выпуск останавливается;
• как откатить;
• сколько длится усиленное наблюдение.

Техническая успешность выпуска не заменяет проверку результата для пользователя. Если время сократилось, но выросла доля исправлений, эффект нужно считать целиком.

11. Превратите инцидент в улучшение #

Сначала воспроизведите наблюдаемый сбой. Затем сохраните его как постоянную проверку, если это уместно.

Цепочка:

инцидент → воспроизведение → причина → исправление → проверка → обновление правила или контекста → наблюдение

Начинайте исправление с воспроизведения и сохраняйте подходящий случай как регрессионную проверку. [G1-D5-p14], Day_5_v3.pdf, с. 14.

Не каждый инцидент становится тестом. Иногда причина находится в правах, данных, поставщике или организационном решении. Тогда меняется соответствующий артефакт, а проверка подтверждает новый механизм.

Когда нужен MCP #

Протокол контекста модели (Model Context Protocol, MCP) стандартизует подключение контекста и инструментов. Проверенная на дату среза стабильная редакция — 2025-11-25. [MCP-2025-11-25]

Используйте MCP, если:

• несколько клиентов должны обращаться к одному инструменту;
• нужен устойчивый интерфейс обнаружения возможностей;
• команда готова отдельно управлять авторизацией, схемами и эксплуатацией.

Не вводите MCP для одного простого внутреннего вызова, если прямой интерфейс дешевле и понятнее.

Формула N × M → N + M описывает сокращение числа интерфейсов, но не убирает адаптацию схем, авторизацию, семантику и эксплуатацию. [G1-D2-p13], Agent Tools & Interoperability_Day_2.pdf, с. 13.

Стабильное расширение централизованного управления доступом было объявлено 18 июня 2026 года. Оно решает часть авторизации и не заменяет проверку сервера, данных, действий и журналов. [MCP-2026-managed-auth]

Когда нужен A2A #

Протокол взаимодействия агентов (Agent-to-Agent, A2A) предназначен для связи автономных удалённых участников. Проверенный выпуск на дату среза — 1.0.0 от 12 марта 2026 года. Запись о 1.0.1 не подтвердилась. [A2A-1-0-0]

Используйте A2A, если участники:

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

Не используйте A2A только потому, что в схеме нарисовано два агента. Внутренней функции или инструменту часто хватает обычного вызова. A2A предназначен для распределённых специализированных участников. [G1-D2-p22]

Юридическая и управленческая ответственность не передаётся удалённому агенту вместе с задачей. [G1-D2-p23]

Когда нужен A2UI #

Протокол интерфейса от агента к пользователю (Agent-to-User Interface, A2UI) передаёт декларативное описание интерфейса, которое клиент отображает из доверенного каталога компонентов.

На дату среза текущая производственная версия — 0.9.1. Семейство 0.9 представлено 17 апреля 2026 года. Версия 1.0 остаётся кандидатом и не называется стабильной. [A2UI-0-9] [A2UI-0-9-1-current]

Используйте A2UI, если результат лучше понять и уточнить через интерактивное представление. Для короткого ответа достаточно текста. Для передачи данных может хватить структурированного формата. Для постоянного детерминированного экрана лучше обычный код.

Декларативный каталог уменьшает поверхность атаки по сравнению с произвольным кодом, но не отменяет проверку схемы, данных, событий и прав действий. [G1-D2-p33]

Сгенерированную структуру нужно проверить по схеме до отображения и исполнения. [G1-D2-p40]

A2UI может передаваться через A2A, но не зависит от него архитектурно. Тезис об обязательной связи отвергнут. [G1-D2-p29]

Дерево выбора протокола #

1. Нужен только текстовый ответ? Верните текст.
2. Нужны структурированные данные? Используйте обычную схему данных.
3. Модель должна вызывать локальный инструмент? Начните с прямого ограниченного интерфейса.
4. Несколько клиентов подключаются к общим инструментам? Рассмотрите MCP.
5. Взаимодействуют независимые удалённые участники с длительными задачами? Рассмотрите A2A.
6. Пользователю нужен динамический интерфейс из доверенного каталога? Рассмотрите A2UI.
7. Для каждого «да» отдельно проверьте доверие, права, наблюдение, стоимость и резерв.

Протокол — вариант интерфейса. Он не заменяет операционную модель.

Рабочая карточка главы #