AI-native cykl życia oprogramowania

AI-native SDLC to jedna pętla wytwarzająca dowody, wspólna dla Claude Code, Cursora i Codeksa: plan, design, build, test, deploy oraz maintain. Każdy etap commituje artefakt dla następnego, a nazwani ludzie zachowują odpowiedzialność za produkt, architekturę, merge i produkcję. Zacznij od roadmapy wdrożenia, potem przejdź przez łańcuch artefaktów.

Tradycyjny SDLC powstał w erze, gdy pisanie kodu było wolnym i drogim krokiem. Product managerowie spisywali wymagania, architekci projektowali, inżynierowie implementowali, QA weryfikowało, zespoły release’owe wypuszczały, a operations obserwowały produkcję. Każde przekazanie wymuszało wyrównanie podczas tygodni implementacji.

Agentyczne kodowanie zawaliło ten środek. Dobrze wyspecyfikowana zmiana może przejść od planu do przechodzących testów w godzinach. Wąskie gardło przesunęło się na ludzkie kroki wokół builda: planowanie, review, test i deploy. Recenzja linia po linii nie nadąża, gdy agenci piszą większość diffa. Governance, które nadal przepuszcza wyjątki przez tygodniowe komitety, opodatkowuje każdy zysk, który agenci właśnie wypracowali.

AI-native SDLC zachowuje stare cele kontrolne i zmienia sposób ich egzekwowania. Proces jest pętlą. AI jest osadzone na każdym etapie. Każdy etap kończy się commitowaniem artefaktu, który następny etap może odczytać. Ludzie pozostają odpowiedzialni za osąd; ich uwaga przenosi się na bramki, a nie na każdą wygenerowaną linię.

Spotkasz też nazwy agentic SDLC lub AI SDLC. Etykiety się różnią; proces jest ten sam.

Co zmienia się na każdym etapie

Poniższa tabela pokazuje krańce spektrum. Większość zespołów siedzi gdzieś pomiędzy dwiema kolumnami.

Etap	Tradycyjny SDLC	AI-native SDLC
Plan	Wymagania zbierane przez komitet, spisywane ręcznie	Inicjator zapisuje intencję jako `intent.md` — czytelne dla człowieka i wykonywalne przez maszynę
Design	Spec pisany przez analityków, parsowany przez designerów	Wymagania i design zlewają się w jedną sesję, ograniczone wersjonowanymi skills
Build	Testy i kod pisane ręcznie; dokumentacja po fakcie	Testy i kod generuje agent; wiedza instytucjonalna żyje w `CLAUDE.md`, `.cursor/rules` lub `AGENTS.md`
Test	Bramki QA na granicach etapów	Ciągłe evale wplecione w implementację; sesja sprawdza własną pracę
Deploy	Ludzie recenzują każdą linię; governance w cyklach review	Warstwowa agentyczna recenzja; ludzka recenzja dla kodu regulowanego i krytycznego; hooki jako bramki akceptacji
Maintain	Ludzie obserwują produkcję pod kątem bugów	Agenci monitorują żywe deploymenty; naruszenie pasma kontrolnego zapisuje następny `intent.md`

Wątkiem przez prawą kolumnę jest commitowany artefakt. Na wczesnych etapach to plik markdown, który product owner i agent mogą oboje przeczytać. Od builda wzwyż artefaktem jest kod i jego rekordy. Łańcuch commitów to ścieżka audytu: kto o co prosił, co agent wyprodukował i kto to zatwierdził.

Deleguj, recenzuj, bierz odpowiedzialność

Na każdym etapie obowiązuje ten sam podział:

Deleguj — mechaniczne pierwsze przejście (boilerplate, draft speca, pierwsza recenzja, triage logów)
Recenzuj — kompletność, bezpieczeństwo, dopasowanie domenowe
Bierz odpowiedzialność — priorytety, architektura, UX, merge, akceptacja produkcji

Ludzie pozostają odpowiedzialni za każdą decyzję wymagającą osądu. Output agenta, który wygląda pewnie, nadal jest draftem, dopóki nazwany człowiek nie zaakceptuje go na bramce.

Jak łączą się etapy

Etap kończy się commitowaniem artefaktu. Ten commit uruchamia następny etap:

Zaakceptowany intent.md uruchamia przejście wymagań i designu.
Zatwierdzony spec.md uruchamia plan mode.
Zaakceptowany plan.md uruchamia implementację.
Zmergowany pull request uruchamia pipeline.
Naruszenie pasma kontrolnego na produkcji zapisuje następny intent.md.

Możesz zacząć od ręcznego promptowania każdego kroku. Stanem docelowym jest pętla, w której każdy zaakceptowany artefakt odpala następną bramkę. Ludzka uwaga koncentruje się na bramkach — recenzujesz to, co agent oznaczył, zamiast zaczynać każdy etap od zera.

Plays są modularne. Najpierw wdrażaj play bez prerequisite (intent.md, CLAUDE.md / rules / AGENTS.md, skills, pętla feedbacku, hooki). Dla każdego innego play najpierw wdrażaj plays, które go zasilają.

Strony w tej sekcji

Roadmapa wdrożenia Przejdź od baseline'u do zamkniętej pętli w pięciu niezależnie dostarczanych falach.

Łańcuch artefaktów intent.md → spec.md → plan.md → diff i testy → findings z PR → rekord incydentu. Nazwij jedno źródło prawdy.

Plan Zapisz intencję słowami inicjatora jako wersjonowany proto-spec.

Design Zamień zaakceptowaną intencję w spec.md, z polityką stosowaną w trakcie pisania speca.

Build Najpierw plan mode, potem implementacja. Wiedza instytucjonalna jako pliki. Guardraile jako kod.

Test Daj sesji pętlę feedbacku. Regression-testuj harness, który steruje agentem.

Deploy Warstwowa recenzja agenta, hooki jako bramki akceptacji i bramka produkcji, której agent nie może przejść.

Maintain Zamknij pętlę: trigger zapisuje następny intent.md. Zaplanowane skany i on-call.

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

Mapa narzędzi Każdy play zmapowany na prymitywy Claude Code, Cursor i Codex.

Metryki Wskaźniki wiodące i opóźnione per play, odczytywane z gita, PR-ów, CI i incydentów.

Ścieżki wdrożeniowe dla narzędzi

Po poznaniu kanonicznego cyklu użyj krótkich adapterów. Mapują te same artefakty i bramki na każde narzędzie bez powielania procesu.

Adapter Claude Code Plan mode, CLAUDE.md, skills, hooki, worktrees i headless CI

Adapter Cursora Tryby Plan i Agent, rules, skills, worktrees, Bugbot i Cloud Agents

Adapter Codeksa Plan mode, AGENTS.md, skills, hooki, worktrees aplikacji, exec i review

Powiązane

PRD to Plan to Todo — rozmowa, która produkuje wczesne artefakty
Human in the loop — gdzie siedzi ludzka uwaga, gdy agenci piszą większość diffa
Design pipeline — ścieżka UI od briefu do implementacji