Większość zespołów już używa AI przy programowaniu, najczęściej jako podpowiadania kodu w edytorze. Agentic SDLC to coś innego. Agent nie podpowiada kolejnej linijki. Bierze zadanie, planuje je, zmienia kod, uruchamia testy, czyta błędy, poprawia i oddaje gotowy pull request człowiekowi, który decyduje, czy zmiana wchodzi.
Pracuję w ten sposób na co dzień z Claude Code i Codexem, a do pracy poza kodem używam frameworków agentowych takich jak OpenClaw i Hermes. Poniżej opisuję, gdzie to się opłaca, gdzie nie, i jak zacząć, nie ryzykując całego zespołu.
Co naprawdę zmienia „agentowość”
W klasycznym cyklu wytwarzania każdy etap czeka na człowieka: ktoś pisze zadanie, ktoś koduje, ktoś pisze testy, ktoś robi review. W cyklu agentowym agenci wykonują pierwsze podejście na każdym etapie, a ludzie przechodzą na bramki między etapami. Praca zespołu przesuwa się z pisania kodu na określanie, co znaczy „gotowe”, i sprawdzanie, czy to zostało spełnione.
- Analiza: agent zamienia ogólną prośbę w kryteria akceptacji i wypisuje otwarte pytania.
- Implementacja: agent wprowadza zmianę na osobnej gałęzi i pracuje, aż testy przejdą.
- Testy: agent dopisuje brakujące testy, a zgłoszone błędy najpierw odtwarza jako test, który nie przechodzi.
- Code review: agent robi pierwsze przejście, człowiek ostatnie.
- Wdrożenie: agent przygotowuje opis wydania i kroki migracji, człowiek naciska przycisk.
W czym agenci są już dobrzy
- Dobrze opisane zmiany w kodzie, który ma testy: nowe endpointy, pola, walidacje, małe funkcje.
- Testy, szczególnie do istniejącego kodu, którego nikt nie chciał pokryć.
- Refaktoryzacje i migracje powtarzające ten sam wzorzec w wielu plikach.
- Dokumentacja, changelogi i notatki wdrożeniowe aktualne względem kodu.
- Triage: grupowanie zgłoszeń, wyszukiwanie duplikatów, wskazywanie prawdopodobnego modułu.
Wspólny mianownik jest prosty: istnieje szybki i obiektywny sposób sprawdzenia wyniku. Jeśli testy albo typy mogą powiedzieć „to jest źle”, agent poprawi to sam.
Gdzie wciąż zawodzą
- Niejasne wymagania. Agent zbuduje dokładnie to, co napisano, łącznie z tym, co napisano źle.
- Decyzje architektoniczne i kompromisy zależne od kontekstu biznesowego, którego nikt nie spisał.
- Kod wrażliwy na bezpieczeństwo: logowanie, płatności, uprawnienia. Agent może przygotować szkic, ale odpowiada za to człowiek.
- Stary kod bez testów. Bez możliwości weryfikacji agent zgaduje, a Ty razem z nim.
- Wszystko, gdzie jedynym sprawdzianem jest „wygląda dobrze”.
Zabezpieczenia, dzięki którym to jest bezpieczne
- Wykonywalna definicja „gotowe”. Testy, typy i lintery są prawdziwym kierownikiem agenta.
- Małe pull requesty. Jedno zadanie, jedna gałąź, jedna zmiana do przejrzenia.
- Piaskownica. Agenci pracują na gałęzi i w jednorazowym środowisku, nigdy z produkcyjnymi dostępami.
- Bramki ludzkie. Merge i wdrożenie zostają w rękach ludzi.
- Ślad zmian. Każda zmiana agenta jest powiązana z zadaniem i ma swój log, więc wiadomo, skąd się wzięła.
- Kontrola kosztów. Dobór modelu do trudności: model frontierowy do trudnego rozumowania, mniejszy otwarty model jak Qwen czy GLM do pracy masowej, np. testów i dokumentacji.
Pilotaż na jednym zespole w 30 dni
- Tydzień 1: wybierz jedno repozytorium z przyzwoitymi testami i jeden typ zadań. Zmierz stan wyjściowy: czas od zgłoszenia do merge’a, czas review, błędy znalezione po wydaniu.
- Tydzień 2: ustaw przepływ pracy agentów, piaskownicę i bramki. Zacznij tylko od testów i małych zmian.
- Tydzień 3: puść to na prawdziwe zadania. Prowadź prosty rejestr: co agent zrobił dobrze, co trzeba było poprawić, czego nie umiał.
- Tydzień 4: porównaj ze stanem wyjściowym i zdecyduj, co skalować, co zmienić, a co porzucić.
Mierz te same trzy rzeczy przed i po: czas realizacji, obciążenie review i błędy, które wyciekły do użytkowników. Jeśli czas realizacji spada, a błędów po wydaniu przybywa, to tylko przerzuciłeś pracę na klientów.
W skrócie
Agentic SDLC nie polega na zastąpieniu programistów. Polega na przesunięciu ludzi z pisania na decydowanie i oddaniu agentom powtarzalnego pierwszego podejścia według jasnych reguł. Najwięcej zyskują zespoły, które dobrze definiują „gotowe”. Zespoły, które nie potrafią powiedzieć, co znaczy „gotowe”, zaczną po prostu szybciej produkować nie to, co trzeba.
Jeśli chcesz sprawdzić to w swoim zespole, 20 minut rozmowy wystarczy, żeby wybrać pierwszy proces i sensowny pilotaż. Umów rozmowę.
