# Cztery poziomy agentowego wytwarzania oprogramowania > Dojrzałość agentowa to nie ilość AI, lecz zmiana, kto inicjuje pracę. Poziomy 0–4, model paths-to-outcomes i to, jak walidacja zamienia się w pętlę. URL: https://eiac.dev/blog/cztery-poziomy-agentowego-wytwarzania Filar: SDLC / Policy-as-Code Data: 2026-03-17 Tagi: platform-engineering, agents, adp, value-stream, ai --- W poprzedniej części ([Od IDP do ADP](/blog/od-idp-do-adp)) ustaliłem, że przewagą nie jest model, lecz deterministyczny szkielet platformy. Ale „agentowość" to nie przełącznik wł./wył. — i tu robi się ciekawie. To **kontinuum dojrzałości**, w którym zmienia się jedno: kto inicjuje pracę i jak głęboko platforma domyka pętlę bez człowieka. Rozłóżmy je na pięć poziomów (0–4), używając modelu „paths-to-outcomes".

Klucz

Poziomy różnią się nie liczbą użytego AI, lecz stopniem zaangażowania człowieka: is → in → on → orchestrator → poza pętlą. Im niżej możesz bezpiecznie zejść, tym wyższa przepustowość — ale „bezpiecznie" zależy od jakości platformy.

## Model: ścieżki w strumieniu wartości Niezależnie od narzędzi, strumień wartości „dostarcz funkcję" składa się z powtarzalnych ścieżek: | Ścieżka | Typowe wejście | Wyjście | |---|---|---| | Zdobądź kontekst | ticket, issue, zgłoszenie | kontekst do pracy | | Zmień (implement) | tworzenie kodu | kandydacka zmiana / commit | | Zweryfikuj (validate) | zmiana / PR | zweryfikowany artefakt lub błąd | | Promuj (promote) | zweryfikowany artefakt | zatwierdzony do wdrożenia | | Wdróż (deploy) | artefakt wydania | działający system | | Obserwuj (observe) | sygnały runtime | telemetria, widoczność | | Napraw (remediate) | alert | przywrócony stan | Ta struktura jest stabilna — i to czyni ją użyteczną: pozwala rozmawiać o platformie niezależnie od konkretnego CI czy chmury. Poziomy agentowe to opis tego, jak te ścieżki się zmieniają. ## Poziom 0: człowiek jest pętlą Punkt wyjścia: działający IDP, zero agentów. Człowiek pisze kod, a deterministyczna platforma wspiera wykonanie, wdrożenie i testy. Zysk rośnie liniowo, ograniczeniem jest przepustowość ludzi. To nie jest „poziom agentowy" — to fundament, który (jak pisaliśmy w [Od IDP do ADP](/blog/od-idp-do-adp)) jest tą samą pracą, co budowa ADP. ## Poziom 1: człowiek w pętli Agent wchodzi do edytora jako asystent. Zmieniają się dwie ścieżki: **zdobądź kontekst** (agentowe wyszukiwanie, wyjaśnianie komponentów) i **zmień** (generowanie kodu z promptu). Reszta systemu jest nietknięta — kod nadal idzie przez PR, CI dalej waliduje, człowiek akceptuje lub odrzuca każdą propozycję. To lokalne usprawnienie, nie zmiana strukturalna. Zysk jest realny, ale ograniczony — bo wąskim gardłem pozostaje przepustowość ludzkiego przeglądu. Wartość tego poziomu: osłania przed halucynacją (człowiek filtruje) i jest łatwy do wdrożenia. ## Poziom 2: człowiek na pętli Najbardziej fundamentalny przeskok. Agent przestaje być prywatnym narzędziem w edytorze, a staje się **uczestnikiem strumienia wartości**. Człowiek nadal „wysyła agenta" do pracy (to on jest wyzwalaczem i ponosi odpowiedzialność), ale wiele zadań biegnie równolegle w tle. Pojawia się **nowa ścieżka: „dispatch work to agents"** — warstwa, która zamienia ludzkie zlecenia w wykonywalne zadania agentowe z odpowiednim kontekstem, tożsamością i granicami. Typowe wejścia to nie „wymagania" w sensie SDLC, lecz zlecenia: „zbadaj ten alert z Sentry", „zrób pierwszą wersję z tego ticketu", „oskryptuj komponent z tego zrzutu ekranu". Jeden człowiek może uruchomić kilka agentów naraz, a potem zdecydować, co awansować. Drugą, najbardziej niedocenianą zmianą jest to, że **walidacja staje się pętlą**:

Walidacja jako pętla — przy niepowodzeniu sygnał wraca do agenta, który poprawia i ponawia.

Walidacja przestaje być bramką, przez którą przechodzi człowiek, a staje się przemysłowym sprzężeniem zwrotnym: agent powtarza próby, aż artefakt spełni wymagania platformy. To rodzi trzy konsekwencje, którym poświęcamy osobny artykuł ([Deterministyczny szkielet platformy agentowej](/blog/deterministyczny-szkielet-adp)): presję na pojemność CI, konieczność poszerzenia weryfikacji poza testy jednostkowe, oraz **policy-as-code jako nieodzowną, automatyczną bramkę** (np. [OPA](/katalog/open-policy-agent)/[Conftest](/katalog/conftest), [Checkov](/katalog/checkov), [Trivy](/katalog/trivy)). Promocja też się zmienia: człowiek nie czyta każdego diffa, lecz **weryfikuje zachowanie** (deploy preview, dowody z testów) i priorytetyzuje, co scalić. Na froncie często wystarczy podgląd w środowisku efemerycznym; backend wymaga twardszych, deterministycznych dowodów (scenariusze e2e, testy wydajności, polityki bezpieczeństwa). ## Poziom 3: człowiek jako orkiestrator Platforma zaczyna działać jako **ciągła warstwa wykonawcza w tle**. Praca nie wchodzi już tylko przez zlecenia człowieka — to platforma generuje ją z zaobserwowanych wzorców: nawracających anomalii, aktualizacji zależności, regresji wydajności, zaległości wykrytych analizą. Ścieżka „dispatch" rozrasta się w warstwę koordynacji całego ekosystemu agentów: harmonogramowanie, koordynacja wielu agentów na powiązanych obszarach, **wykrywanie konfliktów** gdy zmiany się nakładają. Ścieżka „obserwuj" staje się głównym źródłem sygnałów napędzających pracę. Przegląd człowieka staje się **wyjątkowy** — wkracza, gdy walidacja daje wynik niejednoznaczny lub zmiana jest wysokiego ryzyka. Pojawia się **promocja oparta na regule** — klasyfikacja ryzyka decyduje, co może iść automatycznie: ```yaml # polityka promocji oparta na ryzyku (pseudo-konfiguracja) promotion: auto: when: - change_class: ["dependency-patch", "config-tweak", "docs"] - validation: all-green - blast_radius: low human_review: when: - change_class: ["schema-migration", "iam", "public-api"] - blast_radius: ["medium", "high"] ``` Człowiek przestaje zatwierdzać pojedyncze zmiany — zaczyna **projektować reguły**, według których zmiany awansują. Ograniczenie przesuwa się z przepustowości przeglądu na dojrzałość architektury i ekonomię tokenów. Co istotne: bardzo niewiele organizacji jest dziś w pełni na poziomie 3 — częściej dla części frontendowej. ## Poziom 4: pełna autonomia (zarys) Logiczny kraniec trajektorii. Agenci **nie czekają już na zlecenia** — inicjują pracę w reakcji na sygnały środowiska (telemetria, zachowanie klientów, anomalie kosztów, alerty bezpieczeństwa), w granicach zdefiniowanych przez platformę. Ścieżka „napraw" staje się **samonaprawcza**: klasyfikacja incydentu dopasowuje znany wzorzec/playbook, a auto-remediacja wykonuje naprawę lub rollback bez człowieka; ludzie zajmują się tylko nowymi lub wysokoryzykownymi przypadkami, a każda naprawa poszerza bibliotekę wzorców. To, co Poziom 4 odblokowuje, jest jakościowo nowe: ciągły refactoring na dużą skalę, proaktywna remediacja CVE i dryfu zgodności, adaptacja do popytu, a przede wszystkim **samodoskonaląca się walidacja** — system analizuje własne wzorce porażek i aktualizuje kontekst/testy/reguły, by ta sama klasa błędu nie docierała ponownie do walidacji. Trzeba uczciwie powiedzieć: udokumentowanych wdrożeń Poziomu 4 jest dziś bardzo mało. Większość zespołów jest między 1 a 2, niektóre dotykają 3. Poziom 4 to mniej „praktyka branżowa", a bardziej kierunek — i zestaw ograniczeń architektonicznych, które trzeba spełnić, by autonomia była bezpieczna. ## Jak zmieniają się ścieżki, poziom po poziomie | Ścieżka | L1 | L2 | L3 | L4 | |---|---|---|---|---| | Zdobądź kontekst | wspomagana | dla agentów | ciągła | autonomiczna | | Zmień | wspomagana | wykonywana przez agenta | bez inicjacji człowieka | z sygnałów środowiska | | Zweryfikuj | bramka | **pętla** | wysoki wolumen | krytyczna warstwa kontroli | | Promuj | ręczna | weryfikacja zachowania | reguła (low-risk) | automatyczna | | Obserwuj | jak L0 | źródło zleceń | główne źródło sygnału | warstwa sensoryczna | | Napraw | ręczna | kierowana przez człowieka | częściowo auto | samonaprawcza | | Dispatch | — | **nowa** | koordynacja ekosystemu | inicjacja ze środowiska | ## Co to znaczy w praktyce Awans o poziom to nie „włącz więcej AI", lecz **inwestycja w konkretną zdolność platformy**: z L1 na L2 — kontekst dla agentów, tożsamość nie-ludzka, walidacja jako pętla, polityki jako kod; z L2 na L3 — harmonogramowanie, wykrywanie konfliktów, klasyfikacja ryzyka i auto-promocja; z L3 na L4 — samonaprawa i samodoskonalenie walidacji. Każdy z tych elementów to deterministyczny mechanizm — i właśnie one, nie modele, decydują, jak daleko możesz bezpiecznie zejść z człowiekiem z pętli. ## Podsumowanie Cztery poziomy to mapa, nie drabina do przebiegnięcia na siłę. Pokazują, że dojrzałość agentowa rośnie wraz z dojrzałością deterministycznego szkieletu: im lepsze polityki, walidacja i obserwowalność, tym więcej pętli platforma może domknąć bezpiecznie. W następnej części schodzę do tego szkieletu — pokazuję, jak walidacja-pętla i policy-as-code czynią agentów bezpiecznymi w praktyce. Ustaw sobie szczerze, na którym poziomie jesteś dziś — bo to on wyznacza, ile autonomii możesz bezpiecznie oddać.