Roadmapa adopcji: od jednej zmiany do zamkniętej pętli

Roadmapa prowadzi jedno repozytorium od doraźnych promptów do kontrolowanego AI-native SDLC w pięciu falach opartych na dowodach. Każda fala dodaje tylko kontrole potrzebne następnej: przekazania artefaktów, feedback sesji, bramki review, izolowaną pracę równoległą i wreszcie sygnały produkcyjne tworzące kolejną intencję.

Nie automatyzuj od razu wszystkich etapów. Słaba pętla ręczna staje się wtedy szybszą słabą pętlą. Zacznij od reprezentatywnej zmiany, zachowuj artefakty i metryki, a dalej przechodź dopiero, gdy dowody wyjścia są widoczne w Git, CI, PR lub incydencie.

Przed pierwszą falą

Wybierz repozytorium, które ma:

maintainera akceptującego intent.md, spec.md i plan.md;
lokalne komendy typecheck, lint, test i build;
ochronę gałęzi i wskazanego approvera produkcji;
brak konieczności udostępniania agentowi poświadczeń produkcyjnych;
dość powtarzalnej pracy, by porównać co najmniej pięć podobnych zmian.

Zapisz baseline: lead time, first-pass CI success, liczbę cykli review, escaped defects i change-failure rate. Celem nie jest maksymalna aktywność agentów, lecz szybsza ukończona praca bez pogorszenia jakości ani kontroli.

Pięć fal

Fala	Dodaj	Bramka człowieka	Dowód wyjścia
0. Baseline	Jedno repo, jeden typ zmiany, obecne metryki	Maintainer wybiera zakres i tier ryzyka	Pięć porównywalnych historycznych zmian
1. Najpierw artefakty	`intent.md` → `spec.md` → `plan.md`; Plan mode; pętla sesji	Product owner akceptuje intent/spec; inżynier plan	Trzy zmiany zachowują łańcuch i uruchamiają checki przed review
2. Najpierw review	Rankingowane review agentowe, chronione testy, branch protection, approval produkcji	Code owner wykonuje merge; release owner zatwierdza produkcję	Review działa na każdym pilotowym PR i nie omija checków
3. Bezpieczna równoległość	Jeden worktree na zadanie, ograniczone poświadczenia, skille, hooki	Inżynier przydziela zakres i scala wyniki	Dwa zadania kończą się bez kolizji plików, portów, stanu lub chmury
4. Ograniczona automatyzacja	Checki nieinteraktywne, skany cykliczne, wynik maszynowy, evale harnessu	Właściciel akceptuje automatyzację i zmiany polityk	Zadania failują zamknięcie, emitują dowody i nie mutują produkcji
5. Zamknięta pętla	Deterministyczny sygnał produkcyjny tworzy triage i kolejny `intent.md`	Service owner wybiera ważność i ścieżkę; bramki pozostają	Syntetyczny alert trafia do triage z dowodami i bez mutacji produkcji

Uruchom falę 1 na prawdziwej zmianie

Zapisz problem i oczekiwany wynik w intent.md bez szczegółów implementacji.
Z zaakceptowanej intencji utwórz spec.md. Zastosuj polityki bezpieczeństwa, UX, danych i zgodności już podczas pisania.
Wejdź w Plan mode narzędzia, zbadaj repo i zapisz zaakceptowany plan.md.
Zrealizuj jeden ograniczony milestone w izolowanym checkoutcie.
Uruchom prawdziwe checki repo przed zgłoszeniem ukończenia. Zachowaj wyniki komend i dowody wizualne przy PR.
Porównaj wynik z baseline i zapisz rework, czas review oraz escaped defects.

Ten sam prompt sterujący działa w Claude Code, Cursorze i Codex:

Read the accepted intent.md and spec.md plus the repository instructions.
In read-only planning mode, propose one implementation milestone with exact files,
risks, test-first proof, rollback, and commands to run. Stop for approval.
After approval, implement only that milestone in an isolated checkout.
Do not weaken tests or cross the production gate. Report literal command results.

Zdecyduj o przejściu dalej

Przechodź dalej dopiero, gdy obecna fala jest nudna i powtarzalna:

oczekiwany artefakt powstaje bez przypomnienia;
wskazana osoba dokładnie wie, co akceptuje;
błąd zatrzymuje przepływ zamiast zostać ostrzeżeniem;
dowód jest dołączony tam, gdzie pracuje kolejny reviewer;
opóźniona metryka jakości pozostaje stabilna lub się poprawia.

Problemy adopcyjne

Pilot obejmuje tylko trywialne zadania. Wybierz powtarzalną, produkcyjnie ważną pracę z prawdziwymi testami i reviewerem. Literówki nie ćwiczą cyklu.

Artefakty stają się biurokracją. Każdy plik musi czytać następny etap i każdy powinien być połączony z PR. Usuń pola, których nie używa żadna decyzja ani agent.

Przepustowość rośnie razem z awariami. Nie zwiększaj współbieżności. Najpierw popraw specyfikację, feedback, evale i sygnał review.

Narzędzie staje się procesem. Zachowaj przenośne artefakty i bramki. Zespół musi móc zmienić Claude Code, Cursor lub Codex bez przebudowy kontroli.

Kontynuuj rollout

Łańcuch artefaktów Utwórz przenośne przekazania używane w falach 1–5.

Governance i autonomia Przypisz tier ryzyka, tożsamości, uprawnienia i ludzkie bramki.

Metryki Mierz szybkość i jakość razem w każdej fali.

Mapa narzędzi Wdróż tę samą roadmapę w Claude Code, Cursorze lub Codex.