Зона 1 — Деливери (черновик разведки, сжато)

Собрано 02.09.2026 по рамке Рамка разведки. Зона считается самой проработанной, поэтому здесь не полный улов, а карта устоявшегося и граница, за которой процесс кончается.

Уже в базе, повторно не приношу: плейбук Anthropic «The AI-Native SDLC» (Louis Claxton, 21.08.2026) разобран в плейбук Anthropic — петля intent.md → spec.md → plan.md → PR → инцидент, ярусы автономии по сигмам, откат как самый отрепетированный путь, «скилл — совет, хук — закон».

Найденные подходы

Понятийная рамка ко всей группе SDD. Биргитта Бёкелер (Thoughtworks), https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html , 15.10.2025 — разбор Kiro, spec-kit и Tessl, показывающий, что «SDD» это три разные вещи, и давший рынку словарь из трёх уровней: spec-first (спека написана до кода и после выката не поддерживается), spec-anchored (спека живёт рядом с кодом и синхронизируется), spec-as-source (человек правит только спеку, код — производная, как HCL → инфраструктура). Уровень определяет роль человека: на spec-first он приёмщик кода, на spec-as-source код не читает вовсе. Отдельной методологией не считаю — ролей и артефактов не задаёт, классифицирует чужие. Модель-агностично полностью. Открытые вопросы автора вынесены в раздел «Граница».

1. GitHub Spec Kit — SDD, доведённый до исполняемого конвейера

• Кто держит: GitHub (Microsoft), первый автор — Ден Делимарский. Открытый код, MIT.
• Источник: анонс https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/ — 02.09.2025; документация https://github.github.com/spec-kit/; репозиторий https://github.com/github/spec-kit (v1.0.0 — 21.08.2026, v1.0.3 — 01.09.2026)
• Артефакты: цепочка markdown-файлов, каждый — вход следующего шага. Команды: /speckit.constitution (конституция проекта — принципы качества, тестирования, UX, производительности, действующие на все дальнейшие решения), /speckit.specify (что и зачем), /speckit.clarify (добор недосказанного до планирования), /speckit.plan (стек и архитектура), /speckit.tasks (список задач), /speckit.analyze (сверка артефактов между собой на противоречия и покрытие), /speckit.checklist (чек-лист полноты требований), /speckit.implement.
• Роли (человек / агент): человек утверждает конституцию и спеку, отвечает на вопросы шага clarify и принимает результат; агент пишет план, задачи и код. Точка «человек сказал да» — переход specify → plan. Отдельных ролей ревьюера и релиз-менеджера конвейер не вводит: это его слабое место.
• Отдано агенту: генерация плана и задач из спеки, кросс-артефактная сверка (analyze находит расхождения между спекой, планом и задачами — то, что раньше делал аналитик), реализация.
• Зрелость: промышленная практика в смысле распространения, пилоты в смысле доказанного эффекта — подтверждено 130K+ звёзд и 270+ контрибьюторов на 21.08.2026, версией 1.0 и 157 расширениями сообщества; при этом ни одного независимого замера пользы с числами в открытых источниках не нашлось.
• Модель-агностичность: заявленная и проверяемая — 30+ поддерживаемых агентов (Copilot, Claude Code, Gemini CLI, Codex, Cursor), переключение одной командой; процесс — это markdown и slash-команды, ничего платформенного в несущей конструкции.
• Чем подтверждено: вендорский материал (GitHub), но с открытым кодом и внешним разбором Бёкелер, которая относит spec-kit скорее к spec-first, чем к заявленному spec-anchored: ветвление устроено так, что спека после мёржа не живёт.

2. AI-DLC (AWS) — методология, переписывающая церемонии, а не файлы

• Кто держит: AWS, автор — Raja SP, Principal Solutions Architect. Открытый набор правил: https://github.com/awslabs/aidlc-workflows
• Источник: https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/ — 31.07.2025
• Артефакты: требования, истории, единицы работы, дизайн, код, тесты, IaC — всё хранится в репозитории проекта. Собственных имён файлов методология не фиксирует; фиксирует имена такта: спринт → bolt (часы-дни вместо недель), эпик → unit of work, ритуалы → Mob Elaboration и Mob Construction.
• Роли (человек / агент): три фазы — Inception (намерение → требования), Construction (архитектура, модель, код), Operations (инфраструктура и выкатка). В каждой агент формирует план и задаёт уточняющие вопросы, команда целиком валидирует вживую. Ключевой сдвиг: асинхронное ревью одиночки заменяется синхронной проверкой всей командой предложения агента.
• Отдано агенту: черновики требований, декомпозиция, архитектурные предложения, код, тесты, IaC.
• Зрелость: идея, местами пилоты — подтверждено отсутствием в анонсе каких-либо кейсов и цифр; есть white paper и открытый репозиторий правил, есть отраслевая адаптация для финсектора в блоге AWS, но независимых внедрений с числами не нашлось.
• Модель-агностичность: процесс — да (фазы и ритуалы ни к чему не привязаны); реализация тянет за собой Amazon Q Developer и Kiro. Пограничный случай: несущая конструкция агностична, обвязка вендорская.
• Чем подтверждено: вендорский материал, характер — декларация методологии. Смежно: Kiro как её инструментальное воплощение — https://kiro.dev/docs/specs/ , три файла requirements.md (user stories и критерии приёмки в нотации EARS), design.md, tasks.md плюс steering-файлы product.md / tech.md / structure.md, задающие стандарты команды.

3. RPI — Research → Plan → Implement

• Кто держит: Борис Тане (Boris Tane), Engineering Lead в Cloudflare; сходящаяся линия у Block и HumanLayer (там же практика Frequent Intentional Compaction).
• Источник: https://boristane.com/blog/how-i-use-claude-code/ — 10.02.2026
• Артефакты: research.md (глубокое чтение кодовой базы) и plan.md (подход, фрагменты кода, пути файлов, гранулярный todo-лист). Оба переживают сжатие контекста — в этом их смысл.
• Роли (человек / агент): человек правит plan.md инлайн-аннотациями прямо в markdown и повторяет цикл 1–6 раз, каждый с явной оговоркой «пока не реализовывать»; агент читает, планирует, исполняет и отмечает выполненное в том же файле. Автор сознательно отказывается от встроенного plan mode в пользу редактируемого файла: файл — общее состояние человека и агента, чат — нет.
• Отдано агенту: исследование кодовой базы, написание плана, вся реализация после утверждения.
• Зрелость: пилоты — подтверждено тем, что это систематизация девяти месяцев личной практики одного инженера, сошедшаяся с независимыми линиями Block и HumanLayer; чисел по командам нет.
• Модель-агностичность: практика агностична (два markdown-файла и правило «не писать код без утверждённого плана»), изложение целиком на Claude Code.
• Чем подтверждено: личная практика инженера, подробно расписанная; характер — практика, не кейс с метриками.

4. Superpowers — методология, механически навязанная агенту

• Кто держит: Джесси Винсент (Jesse Vincent, obra), открытый плагин для Claude Code: https://github.com/obra/superpowers
• Источник: первая публикация https://blog.fsck.com/2025/10/09/superpowers/ — 09.10.2025; ключевой разбор ролей — https://blog.fsck.com/2025/12/18/superpowers-4/ — 18.12.2025; версия 5 — https://blog.fsck.com/2026/03/09/superpowers-5/ — 09.03.2026
• Артефакты: набор SKILL.md — по файлу на инженерную практику (TDD, отладка, брейншторм, написание плана, код-ревью, верификация перед сдачей); план-документ; отдельный git worktree на задачу.
• Роли (человек / агент): конвейер из семи стадий — брейншторм (агент допрашивает человека до того, как что-то писать) → worktree → план → исполнение подзадачами, на каждую свежий субагент → TDD внутри → ревью → закрытие ветки. С версии 4 ревью разделено на двух разных агентов: сначала spec-review (сделано ли то, что в плане), и только после его одобрения — code-review (качество кода); обе стадии оформлены как циклы. Человек утверждает замысел и план, дальше вмешивается по исключению.
• Отдано агенту: всё исполнение, включая проверку самого себя чужими глазами — субагент-ревьюер стартует с чистым контекстом и потому не защищает код, который только что написал.
• Зрелость: пилоты с широким распространением — подтверждено ~40K звёзд у плагина и регулярным потоком релизов (v4.3.0 — 12.02.2026, v5.0.6 — 25.03.2026); автор сам пишет, что данных о применении другими у него нет.
• Модель-агностичность: несущая конструкция (skills, субагенты, worktree-изоляция) завязана на механику Claude Code — плагины, Agent Skills, лимиты на описания скиллов. Идея переносима, реализация — нет.
• Чем подтверждено: практика одного автора, публично воспроизводимая; отдельно ценно, что автор применяет TDD к самим скиллам — прогоняет будущих агентов через сценарии с давлением сроков, проверяя, станут ли они срезать углы.

5. BMAD-METHOD — многоагентный аджайл с явными ролями

• Кто держит: BMad Code, открытый фреймворк под MIT: https://github.com/bmad-code-org/BMAD-METHOD
• Источник: репозиторий выше; внешний разбор https://www.port.io/blog/bmad-method-explained
• Артефакты: project brief → PRD → документ архитектуры → story-файлы с полным вшитым контекстом → код. Каждый артефакт — вход следующего агента, зависимости между ролями заданы явно.
• Роли (человек / агент): роли переносятся с человеческой команды на агентов один к одному: Analyst пишет бриф, PM — PRD, Architect — архитектуру, Scrum Master режет архитектуру на story-файлы, Developer исполняет, Test Architect держит гейты качества. Человек — заказчик и приёмщик на переходах между фазами планирования; внутри «BMad Loop» цикл идёт без ручной подачи команд.
• Отдано агенту: весь цикл от брифа до коммита, включая ревью и прогон гейтов.
• Зрелость: пилоты — подтверждено популярностью репозитория и потоком независимых разборов; воспроизводимых внедрений с числами не нашлось. Главный риск методологии заметен на глаз: она копирует человеческие церемонии, вместо того чтобы спросить, нужны ли они, когда исполнитель — агент.
• Модель-агностичность: заявлена и по конструкции правдоподобна (роли — markdown-инструкции), но привязка к конкретным IDE и агентам всё же есть.
• Чем подтверждено: открытый код и вторичные разборы; характер — описанный процесс, не измеренный результат.

6. Разделение обязанностей как проверяемое требование — OWASP AISVS, Приложение C

• Кто держит: OWASP, сообщество; AISVS 1.0 выпущен 24.06.2026 (14 глав, 514 проверяемых требований).
• Источник: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md
• Артефакты: не документы, а машинно-проверяемые требования к системе контроля версий, CI и реестру артефактов. Ключевые: AC.8.1 — «автономные агенты не могут одобрить, смёржить, подписать или задеплоить артефакты, которые сами породили, и это ограничение обеспечивается системой контроля версий, системой CI и реестром артефактов»; AC.8.4 — разделение обязанностей держится по стадиям, каждая (генерация, ревью, одобрение, деплой) выполняется отдельным субъектом; AC.4.1 — ревьюер не может быть тем же лицом, что заказало генерацию, и сам агент за человека-ревьюера не считается; AC.9.1 и AC.10.1 — подписанное происхождение артефакта (in-toto / SLSA, записи AI BOM) и обязательные поля: модель и её версия, идентичность агента, контекст генерации, хеш промпта, участие человека, идентификатор сессии; AC.12.5 — правки файлов пайплайна на каждом PR уходят по усиленному маршруту ревью с участием безопасника.
• Роли (человек / агент): ровно об этом весь текст. Человек — единственный, кто одобряет; агент — недоверенная автоматизация с отдельной машинной идентичностью.
• Зрелость: промышленная практика в статусе стандарта — подтверждено релизом 1.0 и тем, что требования сформулированы как проверяемые пункты аудита, а не как советы. Отдельно ценна оговорка самого стандарта: политики недостаточно, ограничение должно быть вшито в инструменты.
• Модель-агностичность: полная, вендора нет по определению — это OWASP.
• Чем подтверждено: отраслевой стандарт с открытой историей правок; характер — нормативное требование, а не кейс.

7. spec-review — российская производственная практика с числами

• Кто держит: Александр Кальницкий, Mindbox.
• Источник: https://habr.com/ru/companies/mindbox/articles/1071152/ — 20.08.2026
• Артефакты: спецификация из восьми разделов (проблема, DoD, ядро, оболочка, workflows и далее), приёмочные тесты на Gherkin, мутационное тестирование с целью 80% убитых мутантов, интеграционные тесты на настоящей инфраструктуре, write-ahead log архитектурных решений.
• Роли (человек / агент): ход, ради которого стоит читать, — ревью переносится с кода на спеку. Команда утверждает архитектурные решения до генерации; классического код-ревью после агента нет вовсе, его заменяют приёмочные и мутационные тесты. Оператор агента обязан быть опытным разработчиком с навыком системного проектирования. Код структурирован в три слоя (функциональное ядро без I/O → оболочка с интерфейсами к БД, Kafka, HTTP → оркестрация), чтобы спека вообще могла быть точкой контроля.
• Отдано агенту: вся генерация кода и тестов по утверждённой спеке.
• Зрелость: пилоты, близко к промышленной практике внутри одной компании — подтверждено конкретикой: микросервис 11k строк кода и 18k строк тестов в проде без инцидентов; фича по часовым поясам 1,5k кода и 5k тестов под нагрузкой 30k RPS; интегрированным ботом пользуются 30 человек в день.
• Модель-агностичность: конструкция агностична — спека, слои, Gherkin, мутационные тесты не зависят от модели.
• Чем подтверждено: отчёт о собственной практике с числами. Характер — кейс. Независимой проверки нет, компания заинтересована в репутационном эффекте.

Русскоязычный контур — ещё две точки

• Сбер, AI-Disrupt PDLC — https://www.kommersant.ru/doc/8798345 , 07.07.2026. Обновлённое руководство по агентной разработке: приоритет среды исполнения над моделью (заявлено, что разброс эффективности от среды — до 22 п.п., между лучшей и худшей моделью — 1–3 п.п.), Specification-Driven Development как методология, двухконтурная схема (контур намерения — человек: исследование, постановка, валидация; контур исполнения — агенты: код, гипотезы, починка), прогноз перехода на «tiny teams» по 3–6 человек. Цифр внедрения в анонсе нет; это заявление о стратегии, а не отчёт о практике.
• Agentic SAMM — https://habr.com/ru/articles/1051650/ , 25.06.2026, Сергей Гордейчик. Каркас безопасной разработки для случая, когда разработчик не человек: три опоры (доверие к источнику по осям A–F и 1–6, «радиус поражения» как длительность окна автономности × масштаб доступных действий, делегирование через замысел, а не перечень запретов) и пять семейств мер — управление, проектирование, реализация, верификация, эксплуатация. Есть открытый сканер agent-audit. Пограничен между зонами 1 и 5.

Граница проработанности

Главный вывод разведки: деливери проработан ровно до момента, когда агент отдаёт диф. Всё, что дальше, описано либо как требование без процесса, либо не описано вовсе.

Что описано методологически — с ролями, артефактами и порядком:

1. Путь от намерения до дифа. Здесь не одна методология, а сходящееся семейство: SDD/Spec Kit, AI-DLC, RPI, Superpowers, BMAD, spec-review Mindbox. Все шесть, придя с разных сторон, пришли к одному: между «хочу» и «пишу код» вставляется утверждаемый человеком письменный артефакт, живущий в репозитории, а не в чате. Согласие такого числа независимых авторов — сильнейший признак зрелости во всей разведке.
2. Развилка «насколько спека переживает код». Таксономия Бёкелер дала рынку словарь, и теперь про любой инструмент можно спросить, spec-first он или spec-anchored, и получить осмысленный ответ. Это редкий случай, когда понятийная работа опередила инструменты.
3. Разделение обязанностей между агентами. Формулировка «агент, написавший код, не может его одобрить» существует на трёх уровнях сразу: как норма аудита (OWASP AISVS AC.8.1, AC.8.4, AC.4.1), как реализованная механика (Superpowers 4: spec-review и code-review — разные агенты, ревьюер стартует с чистым контекстом), как архитектурный принцип (плейбук Anthropic). Проработано.
4. Происхождение и след. AISVS перечисляет обязательные поля записи о генерации — модель, версия, идентичность агента, хеш промпта, участие человека, идентификатор сессии — и требует подписанных аттестаций происхождения. Это готовый к внедрению стандарт, а не эскиз.

Что не описано даже здесь:

1. Пропускная способность пути «одобрено → в main». Узкое место переехало: команды с высокой долей ИИ мёржат почти вдвое больше PR, а метрики поставки не двигаются, потому что ревью, CI-парк и merge queue рассчитаны на скорость человеческого набора (Tian Pan, 02.07.2026, https://tianpan.co/blog/2026-07-02-the-merge-queue-is-the-new-bottleneck — там же: очередь с получасовым CI пропускает 48 PR в сутки, а очереди у предела растут не линейно, а взрывом). Про это есть инженерные приёмы — ярусные тесты, карантин для флаки-тестов, оптимистичная валидация, бюджет ретраев агенту, — но нет методологии: ни ролей, ни артефактов, ни того, кто в команде за это отвечает. Симметрично: у Uber около тысячи флаки-тестов на 600 тысяч, и агент, который перезапускает упавшее, из шума делает трафик.
2. Ревью в масштабе. Все шесть найденных подходов исходят из того, что находок ревью столько, сколько человек способен прочитать. Ни один не отвечает, что делать, когда агентных находок сотни: усталость ревьюера как процессный риск названа (плейбук Anthropic ограничивает придирки капом в REVIEW.md), но ни у кого нет ни порога эскалации, ни правила выборочной проверки, ни способа отличить формальное одобрение от настоящего. Сама Бёкелер задаёт зеркальный вопрос и оставляет его открытым: ревью markdown-спеки может оказаться дороже ревью кода, и тогда весь перенос контроля влево не окупается.
3. Эвалы конфигурации агента как регресс — есть у одного автора. Идея «CLAUDE.md, скиллы и хуки — это код, которому положен регресс-набор, гоняемый в CI на каждое изменение» описана как процесс только в плейбуке Anthropic. Всё остальное, что находится по запросу, — эвалы продуктовых агентов (Bedrock AgentCore, prompt-регрессии в GitHub Actions, голосовые агенты): там есть baseline, merge-блокирующий гейт, правило переоснования baseline в том же PR. Про регресс собственной конфигурации команды независимой методологии с ролями нет. Это одновременно самая дешёвая и самая незанятая ниша зоны.
4. Релиз, откат и безопасность выкатки при агентной скорости. Здесь пусто ярче всего. Есть отдельные утверждения — откат как самый отрепетированный путь пайплайна (Anthropic), прогрессивная выкатка канарейками, теневые деплои, добавление AWS в DevOps Agent проверки готовности к релизу, — но это приёмы инфраструктуры, а не процесс. Не описано: кто держит право на выкатку, когда автор изменения — агент; как выглядит дежурство, если за ночь смёржено вдвое больше; по какому признаку решают откатывать, если ни один человек не читал диф целиком; что считается постмортемом изменения, у которого нет человека-автора. Гипотеза «зона проработана далеко вперёд» верна для левой половины и неверна для правой.
5. Стоимость решения и когда всю эту машинерию не разворачивать. Бёкелер называет прямо: существующие workflow непропорциональны маленьким изменениям. Ни один из подходов не содержит правила «для правки в одну строку конвейер не запускается» — а без такого правила методология либо саботируется, либо съедает выигрыш.
6. Данные вместо деклараций. Единственный независимый отраслевой замер, который встретился, — DORA 2025 (около 5000 респондентов, 90% используют ИИ, медиана 2 часа в день): внедрение ИИ отрицательно связано со стабильностью поставки, нестабильность выросла, ИИ работает усилителем существующих сильных и слабых сторон организации (https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf). При этом ни одна из восьми найденных методологий не показывает, что её применение эту нестабильность снимает. Есть числа у Mindbox (11k+18k строк в проде без инцидентов, 30k RPS) — одна компания, самоотчёт.

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

Что искал и не нашёл

• «агент-релиз-менеджер», процесс выкатки при агентном авторстве. Запросы: continuous integration for AI agents merge queue progressive delivery rollback agent speed deployment safety 2026 practice. Нашлось: вендорские материалы про деплой самих ИИ-агентов (Harness, Red Hat, MLflow) и одна честная инженерная статья про merge queue. Методологии с ролями — нет. Ошибка поиска, которую отмечаю для остальных зон: запрос про «CI/CD и агентов» почти целиком забивается материалами про выкатку моделей, а не про выкатку кода, написанного агентом; это две разные темы, и вторая описана хуже.
• Эвалы конфигурации агента как регресс, независимо от Anthropic. Запросы: evals for agent configuration as regression tests CI "CLAUDE.md" OR "AGENTS.md" changes eval suite gate. Нашлись фреймворки и блоги вендоров про эвалы продуктовых агентов; ни одного текста, где регресс собственного харнеса команды описан как процесс с ответственным.
• Практика ревью, рассчитанная на сотни находок. Ни один из восьми подходов не даёт порога, выборки или правила эскалации. Тема названа как риск, но не закрыта.
• Независимая проверка эффекта SDD. Искал числа по внедрению spec-kit и AI-DLC. Не нашлось ничего, кроме звёзд на GitHub и самоотчётов; ближайшее к измерению — DORA, но он про ИИ вообще, не про SDD.
• Русскоязычные методологии деливери с ролями. Нашлись три точки (Mindbox, Сбер, Agentic SAMM), из них с числами — одна. Отраслевого стандарта или консорциума в русском контуре не нашлось; есть исследовательская волна AI4SDLC 2026 по СНГ, результатов на момент сбора не видел.

Общая оценка зоны

Зрелость зоны — неравномерная: левая половина промышленная практика, правая идея.

Дорога от намерения до дифа описана шестью независимыми командами, сошедшимися на одной конструкции — утверждаемый письменный артефакт в репозитории, а не переписка в чате. Разделение обязанностей между агентами доведено до нормы аудита, которую можно предъявить регулятору (AISVS 1.0). Понятийный аппарат есть и работает.

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

Для нашего контура полезнее всего два хода: перенос ревью со сгенерированного кода на спеку (Mindbox — единственная находка с производственными числами) и разделение ревью на два разных агента: сначала соответствие плану, потом качество (Superpowers 4). Оба не требуют ни прода, ни релиз-менеджера, ни регулятора — то есть применимы у нас в отличие от большей части плейбука Anthropic.

Источники

• https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html — Birgitta Böckeler, 15.10.2025
• https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/ — Den Delimarsky, GitHub, 02.09.2025 · https://github.github.com/spec-kit/ · https://github.com/github/spec-kit
• https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/ — Raja SP, AWS, 31.07.2025 · https://github.com/awslabs/aidlc-workflows · https://kiro.dev/docs/specs/
• https://boristane.com/blog/how-i-use-claude-code/ — Boris Tane, 10.02.2026
• https://blog.fsck.com/2025/12/18/superpowers-4/ — Jesse Vincent, 18.12.2025 · https://blog.fsck.com/2025/10/09/superpowers/ · https://github.com/obra/superpowers
• https://github.com/bmad-code-org/BMAD-METHOD · https://www.port.io/blog/bmad-method-explained
• https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md — OWASP AISVS 1.0, релиз 24.06.2026
• https://habr.com/ru/companies/mindbox/articles/1071152/ — Александр Кальницкий, Mindbox, 20.08.2026
• https://www.kommersant.ru/doc/8798345 — Сбер, AI-Disrupt PDLC, 07.07.2026
• https://habr.com/ru/articles/1051650/ — Сергей Гордейчик, Agentic SAMM, 25.06.2026
• https://tianpan.co/blog/2026-07-02-the-merge-queue-is-the-new-bottleneck — Tian Pan, 02.07.2026
• https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf — DORA, State of AI-assisted Software Development 2025
• https://nyosegawa.com/en/posts/coding-agent-workflow-2026/ — обзорный каталог воркфлоу, 14.03.2026 (использован как навигатор, находки проверены по первоисточникам)