SDLC umarł: Agenci AI i nowa pętla rozwoju

SDLC zniknął: jak AI-agenty skróciły cykl życia oprogramowania do wąskiej pętli Intent → Build → Observe

AI-agenty nie zoptymalizowały SDLC — one go zlikwidowały. Klasyczny cykl życia oprogramowania, oparty na kolejnych etapach, ręcznych przekazach, tiketach i ceremoniach, już nie odzwierciedla rzeczywistości rozwoju. Zamiast tego powstała nowa paradigma: ciągła, asynchroniczna, sterowana kontekstem pętla, w której człowiek wyraża intencję, agent generuje kod roboczy wraz z testami i infrastrukturą, a system obserwacyjny automatycznie weryfikuje, koryguje i zarządza rozmieszczeniem. To nie jest przyspieszenie — to zmiana fundamentu.

Dlaczego SDLC nie istnieje już jako proces

Klasyczny SDLC (Waterfall, Agile, DevOps) zakładał dyskretne fazy: gromadzenie wymagań → projektowanie → realizacja → testowanie → przegląd → wdrożenie → monitoring. Każda faza miała swoje narzędzia, metryki, role i rytuały: Jira do śledzenia, Figma do projektowania, GitHub PRs do przeglądów, Datadog do alertów. Ale kluczowy znak upadku to nie skomplikowanie, a konieczność ręcznego przekazania. Gdy agent obsługuje cały zestaw — od intencji po gotowy do produkcji artefakt — granice między etapami fizycznie znikają. Nie ma „przekazu” od projektanta do programisty, bo agent jednocześnie interpretuje specyfikację UX, generuje komponenty i weryfikuje je za pomocą testów E2E. Nie ma „oczekiwania na przegląd”, bo sprawdzanie jest wbudowane w generację: agenci adversarial analizują kod pod kątem bezpieczeństwa, wydajności i spełniania kontraktu jeszcze przed commitem. To nie jest „Agile 3.0” — to przejście od modelu procesowo-orientowanego do architektury driven by intent.

Jak każdy etap SDLC został skompresowany do kontekstu

Gromadzenie wymagań przestało być dokumentem i stało się dynamicznym kontekstem. PRD już nie jest ustalany z góry: inżynier opisuje zadanie w języku naturalnym („Dodaj wsparcie OAuth2 dla SSO przez Okta, z fallbackiem na lokalną autoryzację i rygorystyczną walidacją tokenów”), a agent generuje 3 warianty realizacji z różnymi kompromisami (stateless vs stateful session store, strategia parsowania JWT), a wybór dokonywany jest na podstawie benchmarków i telemetryki. Wymagania stają się produktem ubocznym iteracji, a nie wejściem.

System Design teraz to dialog w czasie rzeczywistym. Agenci nie tylko implementują gotową architekturę: oni ją proponują. Na pytanie „Potrzebna bezawaryjna szyna zdarzeń dla 10K RPS” agent może porównać Kafka, NATS JetStream i Materialize z uwzględnieniem SLA latency, kosztu na milion zdarzeń i trudności operacyjnej, wygenerować moduł terraform, konfigurację obserwacyjności, a nawet skrypt testu obciążeniowego. Architektura przestaje być statyczną diagramem — staje się wykonywalnym, adaptacyjnym kontraktem.

Realizacja jest całkowicie delegowana. Nowoczesne agenci (Cursor, Continue.dev, Tabby) generują nie tylko funkcje, ale całe mikroservisy ze Swagger-dokumentacją, endpointami health-check, łańcuchami middleware i typowo-bezpiecznymi DTO. Obsługują przypadki graniczne: np. przy generacji klienta HTTP dla REST API agent automatycznie dodaje policy retry z eksponencjalnym backoffem, circuit breaker i anulowanie kontekstu — bez wyraźnego wskazania w promptie. Człowiek skupia się na walidacji intencji, a nie na pisaniu linijek kodu.

Testowanie jest zintegrowane na poziomie generacji. Agent tworzy testy unit-, integration- i E2E równolegle z kodem, używając tej samej semantyki. Przy generacji funkcji calculateTax(amount, region) od razu pisze testy na wartości graniczne, nieważny region i konwersję walut. TDD — to nie metodologia, a domyślne zachowanie. QA jako rola zniknęła: nie ma „przekazania do QA”, bo weryfikacja odbywa się wewnątrz pętli.

Przegląd kodu stracił sens jako ręczny proces. Rozpatrywanie 500 PR/dzień przez człowieka to techniczny absurd. Zamiast tego stosuje się:

• Adversarial code review: drugi agent analizuje wygenerowany kod pod kątem vulnerabilności bezpieczeństwa (CWE-79, CWE-89), antypatrnów wydajności (N+1 queries, nieograniczona rekursja) i zgodności z wewnętrznymi RFC.
• Linting świadomy kontekstu: reguły są wbudowane w serwer LSP agenta i uruchamiane w czasie rzeczywistym.
• Human-in-the-loop tylko dla zmian o wysokim wpływie: rozwiązań architektonicznych, zmian w core domain logic lub gdy score pewności agenta jest niższy niż 0,92.

Wdrożenie stało się ciągłe i autonomiczne. Agenci generują nie tylko kod, ale także CI/CD-pipeliny z feature flags, canary analysis i automatycznym rollbackem. Przykład:

deploy_with_traffic_shift:
  uses: actions/deploy@v3
  canary-percent: 5
  success-threshold: "latency_p95 < 200ms && error_rate < 0,1%"
  rollback-on-failure: true

Rozpowszechnienie to nie zdarzenie, a stan: kod trafia do produkcji natychmiast po przejściu gate, a włączenie funkcjonalności jest sterowane regułami routingu (np. przez Envoy RDS). Agenci monitorują rozmieszczenie i korygują ruch w czasie rzeczywistym.

Co zostało: kontekst i zamknięta informacja zwrotna

Z całego SDLC przetrwały tylko dwa elementy:

• Kontekst — jedyny źródło prawdy. Jego jakość (precyzja specyfikacji, głębia modelu domenowego, aktualność ograniczeń architektonicznych) bezpośrednio determinuje rezultat. Context engineering to nowy systemowy skill: formalizacja intencji, zarządzanie historią zmian kontekstu, wersjonowanie zasad biznesowych.
• Obserwacyjność — nie jako narzędzie dla dyżurnych, ale jako zamknięta informacja zwrotna dla agentów. Metryki, logi i trace powinny być tak zorganizowane, aby agent mógł je interpretować: np. error_rate{service="payment", version="v2.4"} powinien wywołać agenta, który porówna v2.4 z v2.3, znajdzie regression w validateCardExpiry() i zaproponuje hotfix.

Co jest ważne

• SDLC nie przyspieszył — zniknął jako liniowy proces; pozostała tylko pętla Intent → Build → Observe.
• Code review jako ręczna weryfikacja PR — ludyzm; zamiast tego — adversarial agents i human-in-the-loop dla high-risk rozwiązań.
• Wymagania i architektura są teraz generowane i weryfikowane w czasie rzeczywistym, a nie utrwalane w dokumentach.
• Wdrożenie i release są rozluźnione: kod jest wdrażany ciągle, a włączanie funkcjonalności jest sterowane ruchem.
• Kluczowy skill przyszłości — context engineering, a nie znajomość Jira czy GitFlow.

W świecie, gdzie agenci wysyłają setki zmian dziennie, tradycyjne procesy nie są tylko powolne — są źródłem błędów. Zespoły, które przerzuciły się na zamknięte systemy obserwacyjności, gdzie telemetryka bezpośrednio steruje agentami, uzyskują nie tylko szybkość, ale i stabilność: regresje są naprawiane szybciej, niż ludzie zdążą je zauważyć. Pozostali nadal konfigurują dashboarde w Datadog, nie wiedząc, że dane są już wykorzystywane przez agentów do automatycznego przywracania — bez ich udziału.

— Editorial Team