AI-native cykl życia oprogramowania

AI-native cykl życia oprogramowania (SDLC) prowadzi planowanie, projektowanie, budowę, testy, wdrożenie i utrzymanie (plan, design, build, test, deploy, maintain) jako jedną pętlę, w której każdy etap commituje artefakt czytany przez następny: intent.md, spec.md, plan.md, diff z testami, zrecenzowany pull request i raport z incydentu. Agenci przygotowują pierwszą wersję na każdym etapie, a bramki należą do imiennie wskazanych osób.

Ta strona jest dla dewelopera, tech leada albo CTO, których agenci oddają działający diff w jedno popołudnie, podczas gdy ticket nadal powstawał tydzień, a pull request wciąż czeka dwa dni na recenzję. Budowa przestała być wąskim gardłem; kroki wykonywane w ludzkim tempie wokół niej — nie. Ta sekcja pokazuje, jak je przebudować.

Proces opiera się na The AI-native SDLC playbook (Anthropic, 21 sierpnia 2026). Artefakty to zwykłe pliki, więc Claude Code, Codex i Cursor pasują do tej samej pętli — zobacz mapę narzędzi.

Co commituje każdy etap cyklu i kto to zatwierdza

Każdy wiersz to jeden etap. Artefakt to to, co etap commituje; kolumna dowodów mówi, jak sprawdzić bramkę bez czytania przez człowieka każdej wygenerowanej linii.

Etap	Commitowany artefakt	Dowód sprawdzany na bramce	Człowiek odpowiedzialny za bramkę
Plan	`intent.md` słowami inicjatora	Problem, oczekiwany rezultat i ograniczenia są opisane; otwarte pytania wypisane	Product owner akceptuje intencję
Design	`spec.md` z kryteriami akceptacji	Każde kryterium da się przetestować; skille z politykami zastosowane i wymienione	Tech lead zatwierdza spec
Build	`plan.md`, potem diff i testy	Diff zgadza się z listą plików w planie; nowe testy nie przechodzą przed zmianą	Inżynier akceptuje plan
Test	Wynik testów i lintera dołączony do zmiany	Sesja uruchomiła komendę sprawdzającą projekt i wkleiła wynik	Automatycznie; inżynier czyta tylko błędy
Deploy	Pull request z uwagami agenta recenzującego	Uwagi rozwiązane, CI zielone, klasa ryzyka ustawiona	Wskazany recenzent merguje; właściciel release’u promuje
Maintain	Raport z incydentu i następny `intent.md`	Zadziałał deterministyczny alert; dowody zebrane w trybie tylko do odczytu	Dyżurny inżynier akceptuje nową intencję

Łańcuch commitów jest jednocześnie ścieżką audytu: kto o co prosił, co wyprodukował agent i kto to zatwierdził. Ludzka recenzja samego kodu zostaje dla zmian regulowanych i krytycznych; które to są, określa strona czytanie dowodów zamiast kodu.

Uruchom pętlę na najbliższej zmianie

Playbook dzieli każdy etap na praktyki (ang. plays), z których każda opisuje jedną czynność, i można je wdrażać niezależnie od siebie. Pięć z nich nie ma żadnych warunków wstępnych: intent.md, plik instrukcji (CLAUDE.md albo AGENTS.md, albo reguły (rules) w Cursorze), skille, pętla feedbacku w sesji i hooki jako bramki akceptacji. Zacznij od nich na jednej prawdziwej zmianie.

Wybierz jedną zmianę, która już jest w backlogu i jest na tyle mała, żeby zmergować ją w tym tygodniu.
Zamień ticket w intent.md pierwszym promptem poniżej, a potem poproś osobę, która zgłosiła zmianę, o jego akceptację.
Wejdź w tryb planowania, poproś o plan, który wymienia pliki, kolejność pracy i testy dowodzące zmiany, i zacommituj zaakceptowany plan jako plan.md.
Uruchom claude --permission-mode plan albo wpisz /plan w trwającej sesji.

Wpisz /plan w terminalowym UI Codeksa, żeby przełączyć się w Plan mode przed startem pracy.

Przełącz agenta w Plan Mode, zanim opiszesz zmianę.
Podaj agentowi jedną komendę, która dowodzi poprawności zmiany — na przykład npm run typecheck && npm run lint && npm test — i wymagaj jej wyniku, zanim agent zgłosi koniec pracy.
Otwórz pull request z podlinkowanymi artefaktami, uruchom agenta recenzującego i merguj dopiero wtedy, gdy wskazana osoba zaakceptuje dowody.
Uruchom /code-review w sesji. Po głębszą recenzję sięgnij po claude ultrareview w powłoce.

Wpisz /review w terminalowym UI Codeksa albo uruchom codex exec review w CI.

Pozwól Bugbotowi zrecenzować pull request.

Read the ticket text I paste below. Do not propose a solution yet.
Write intent.md with these sections: Problem (in the requester's words),
Proposed outcome, Affected users and systems, Constraints, Open questions.
Quote the ticket wherever you can instead of paraphrasing it.
List every assumption you made under Open questions, and stop.
Ticket:

Audit this repository against a six-stage lifecycle: plan, design, build,
test, deploy, maintain. For each stage report: the artifact that exists
today (file path, or "none"), the command or CI job that checks it, and
who approves it according to CODEOWNERS, branch protection or the PR
template. Use only what you can find in the repository and git history.
End with the single stage that has no committed artifact or no automated
check, and propose the smallest change that adds one.

Deleguj, recenzuj, odpowiadaj — na każdym etapie

Na wszystkich sześciu etapach podziel pracę na trzy części:

Deleguj mechaniczną pierwszą wersję: szkic speca, boilerplate, wstępną recenzję, triage logów.
Recenzuj kompletność, bezpieczeństwo i dopasowanie do domeny.
Odpowiadaj za priorytety, architekturę, UX, merge i zgodę na produkcję.

Wynik pracy agenta, nawet jeśli brzmi pewnie, pozostaje szkicem, dopóki konkretna osoba nie zaakceptuje go na bramce. Gdzie powinna trafiać ta uwaga, opisuje strona Człowiek w pętli.

Co się psuje, gdy zespół wdraża AI-native cykl życia?

Artefakty powstają, ale nikt ich nie czyta. plan.md rozjeżdża się z diffem w ciągu tygodnia. Naprawa: aktualizuj plan.md w tym samym commicie co kod i każ agentowi recenzującemu porównać diff z planem.
Automatyzacja wchodzi przed bramkami. Agenci w CI przepychają zmiany przez pipeline bez hooków i bez agenta recenzującego. Naprawa: najpierw wdróż hooki i recenzję pull requestów; playbook wymienia je jako warunki wstępne automatyzacji pipeline’u.
Dwa źródła prawdy. Jira mówi jedno, spec.md drugie. Naprawa: dla każdego artefaktu wskaż jeden system jako źródło prawdy albo przynajmniej linkuj ID rekordu i SHA commita w obie strony (trzy warianty pokazuje łańcuch artefaktów).
Bramki stają się formalnością. Akceptacje przychodzą w kilka sekund. Naprawa: niech każda bramka sprawdza kolumnę dowodów z tabeli powyżej, a trend śledź metrykami SDLC.

Przewodniki po cyklu życia: artefakty, narzędzia, metryki i wdrożenie

Łańcuch artefaktów Pliki commitowane na każdym etapie i jedno źródło prawdy dla każdego z nich.

Mapa narzędzi Każda praktyka zmapowana na Claude Code, Codex i Cursor.

Metryki Wskaźniki wyprzedzające i opóźnione dla każdej praktyki, z gita, PR-ów, CI i incydentów.

Roadmapa wdrożenia Rozwiń pętlę w całym repozytorium, przejście po przejściu.

Governance i autonomia Poziomy ryzyka, tożsamości, uprawnienia i działania zakazane agentom.

Dokąd dalej w cyklu życia

Najpierw umieść cykl życia na drabinie autonomii na stronie jedna mapa, potem przeprowadź funkcję przez łańcuch artefaktów. Konfigurację poszczególnych narzędzi znajdziesz w sekcjach Claude Code, Codex i Cursor.