Сейчас многие организации переходят не просто к «агентской разработке», а к SDD (Spec‑Driven Development) и перестраивают SDLC вокруг него. У Anthropic вышла хорошая статья...

Сейчас многие организации переходят не просто к «агентской разработке», а к SDD (Spec‑Driven Development) и перестраивают SDLC вокруг него. У Anthropic вышла хорошая статья на тему реорганизации процессов вокруг агентов, поэтому данный текст разбит на две части:

SDD в организации — объяснение подходов, которые предлагает Anthropic, и того, как они ложатся в уже существующие процессы

SDD в solo‑проекте — как у меня получилось выстроить свой процесс SDD, используя две подписки (суммарно на 30$), чтобы разрабатывать пет‑проект и не улетать за лимиты.

Если ты знаком с SDD и текстом Anthropic, можешь пропустить первую половину и сразу перейти ко второй =)

Новый SDLC предлагает парадигму артефактов: intent.md → spec.md → plan.md → report.md → review.md, которые описаны человеческим языком. Жизнь фичи может посмотреть любой: от идеи до реализации — и понять, какие решения были приняты и на какие компромисы пришлось пойти.

Anthropic предлагают создать артефакт, в котором нужно отразить:

Intent (что хочется), Problem (что сейчас не так), Proposed outcome (чего хочется достичь), Affected (какие системы затрагиваются), Constraints (какие есть ограничения) и Open questions (на какие вопросы нужно ответить).

По сути, это тот же тикет в Jira/Tracker, который вы видели множество раз. Основная разница в том, что он должен придерживаться более строгого формата и должен делаться вместе с агентом.

Каждый, кто хотя бы немного работал в любой организации, знает, как сложно добиться от другого человека ответа на вопросы: «А чего ты хочешь? А зачем это?» Агент на этом этапе экономит время PO и dev‑команды на выяснение этого. Он общается с заказчиком фичи/аналитиком, и результатом их работы становится стандартизированный артефакт, который можно или передать дальше, или отправить на доработку с новыми вводными.Также агент обладает доступом к другим артефактам (например, прошлым решениям или коду), что позволяет ему изначально предложить идею, формат которой уже будет вписываться в продукт.

После того как идея была принята, её нужно задизайнить с учётом существующей архитектуры, нюансов безопасности и дизайна. На этом этапе цена ошибки минимальна (мы все ещё не начали писать код), поэтому PO должен гонять спеку столько раз, сколько нужно, пока результат не будет его полностью удовлетворять.