Blok I · Jak AI zmienia codzienną pracę analityka i architekta Jak AI zmieni sposób prowadzenia analizy i projektowania systemów IT

„Jeszcze nigdy jako programista nie czułem, że tak bardzo nie nadążam. Nasz zawód przechodzi gruntowną przebudowę” - Andrej Karpathy, grudzień 2025 r.

Słowa Karpathy’ego, byłego dyrektora ds. AI w Tesli i współzałożyciela OpenAI, nie były odosobnioną refleksją programisty z Doliny Krzemowej. Stały się trafną diagnozą tektonicznego przesunięcia, które właśnie wstrząsa fundamentami inżynierii oprogramowania.

Podczas gdy uwaga branży przez ostatnie dwa lata skupiała się głównie na programistach i generowaniu kodu, w cieniu toczy się transformacja o znacznie głębszych konsekwencjach. Dotyczy ona tych, którzy decydują o kształcie całych ekosystemów cyfrowych: analityków biznesowo-systemowych oraz architektów korporacyjnych i rozwiązań.

W trakcie inauguracji konferencji „Analityk & Architekt w erze AI” Andrzej Sobczak przedstawił kompleksową wizję tej transformacji. Wnioski są jednoznaczne: tradycyjny cykl wytwarzania oprogramowania (SDLC), jaki znamy z podręczników akademickich i metodyk zwinnych, przestaje odpowiadać realiom rynkowym.

Oto dlaczego stoimy w obliczu fundamentalnej zmiany warsztatu analityka i architekta oraz co to oznacza dla zespołów IT w perspektywie najbliższych kilku lat.

1. Twarde dane z globalnego rynku: kod piszą dziś maszyny

Zanim przejdziemy do warstwy analitycznej, warto spojrzeć na twarde dane z rynków globalnych. To, co w wielu polskich organizacjach wciąż uchodzi za „eksperyment wysokiego ryzyka”, u globalnych liderów stało się standardem produkcyjnym:

• Intercom: 93,6% Pull Requestów jest prowadzonych bezpośrednio przez autonomicznych agentów.
• Anthropic: ponad 80% scalonego kodu w repozytoriach tworzy model Claude.
• Google: ponad 75% nowego kodu w firmie jest generowane przez sztuczną inteligencję.
• Ramp: 75% zmian w kodzie trafia na produkcję za pośrednictwem agenta Inspect.
• Uber: ponad 70% PR-ów przypisanych jest maszynom.

Badania przekrojowe potwierdzają, że nie jest to wyłącznie domena gigantów technologicznych. Z raportu platformy DX (obejmującego ponad 500 firm technologicznych) wynika, że średnio 52,7% kodu powstaje przy udziale AI. Z kolei badanie Sonar na próbie 1100 inżynierów wskazuje na poziom 42%.

Przykład Stripe Minions: nowy paradygmat wytwarzania

Szczególnie pouczający jest przypadek platformy Stripe - podmiotu działającego w restrykcyjnym, silnie regulowanym sektorze fintech. Stripe wdrożył wewnętrzny ekosystem agentowy Stripe Minions:

Zadanie programistyczne jest definiowane jako wątek na Slacku. Za pośrednictwem otwartego protokołu MCP (Model Context Protocol) agenci pobierają kontekst z Jiry, Confluence, GitHuba i wewnętrznych repozytoriów. W izolowanym kontenerze agent pisze kod, kompiluje go, uruchamia testy jednostkowe i integracyjne CI. Gdy testy wykazują błędy, agent samodzielnie analizuje logi, iteruje i poprawia implementację. Efekt? Ponad 1300 scalonych Pull Requestów tygodniowo przy dokładnie zero liniach kodu napisanych ręcznie przez człowieka. Człowiek pełni wyłącznie rolę bramki kontrolnej (Human-in-the-Loop), weryfikując i podpisując zmianę.

2. Dlaczego analitycy zostali w tyle?

Podczas gdy deweloperzy otrzymali wyspecjalizowane środowiska agentowe (takie jak Claude Code, GitHub Copilot Workspace, Cursor czy Codex), analitycy i architekci znaleźli się w pułapce technologicznego wykluczenia.

W większości dużych organizacji warsztat pracy analityka wciąż opiera się na pakiecie biurowym (Word, Excel), podstawowym systemie ticketowym oraz generycznym asystencie AI, który służy głównie do parafrazowania tekstu i podsumowywania spotkań.

Tymczasem biznes nie czeka. Właściciele produktów i menedżerowie linii biznesowych coraz częściej używają narzędzi GenAI do samodzielnego prototypowania interfejsów, generowania logiki biznesowej, a nawet tworzenia wstępnych specyfikacji (tzw. Spec-Driven Development).

Jeśli analityk i architekt nie będą potrafili wejść na ten sam poziom operacyjny, staną się wąskim gardłem projektów - lub zostaną całkowicie pominięci w procesie decyzyjnym.

3. Ewolucja paradygmatu: od prostego prompta do „Roju Agentów”

Profesor Sobczak zwrócił uwagę na tempo, w jakim zmienia się podejście do wykorzystania AI w inżynierii systemów:

• 2024, prompting: generowanie pojedynczego diagramu PlantUML / Mermaid.
• 2025, asystenci: liniowa orkiestracja asystentów przez człowieka (BPMN, reguły, makiety).
• 2026 i później, systemy wieloagentowe: zarządzanie „rojem” wyspecjalizowanych agentów.

Dziś wkraczamy w erę systemów wieloagentowych. Architekt nie promptuje już pojedynczego modelu w oknie czatu. Zamiast tego projektuje architekturę współpracujących ze sobą jednostek AI, wyposażonych w pamięć, uprawnienia i reguły decyzyjne.

Kluczowym pojęciem staje się tu uprząż (ang. harness). Model językowy sam w sobie jest tylko silnikiem probabilistycznym podatnym na halucynacje. Uprząż to cała warstwa wykonawcza, inżynieryjna i kontrolna, która go otacza:

• protokoły pobierania kontekstu (MCP),
• narzędzia i wtyczki do repozytoriów wiedzy,
• uprawnienia i sztywne reguły walidacji,
• pętle kontroli jakości (Quality Gates).

4. Wirtualne Biuro Analizy i Architektury (VBA)

Czy to tylko teoria? Aby udowodnić wykonalność tego podejścia, prof. Sobczak zaprezentował działający prototyp wdrożeniowy: Wirtualne Biuro Analizy i Architektury (VBA), przetestowane w warunkach korporacyjnych.

Punktem wyjścia nie była technologia, lecz rygorystycznie zdefiniowany proces. System został zintegrowany dwukierunkowo z narzędziami enterprise: Atlassian Confluence (jako warstwą wejścia/wyjścia dokumentacyjnego) oraz Sparx Enterprise Architect (jako repozytorium architektury korporacyjnej).

Struktura organizacyjna roju agentów

W ramach VBA działa 10 wyspecjalizowanych agentów pod nadzorem wirtualnego Team Leada:

• Business Analyst: dekompozycja scenariuszy i wymagań biznesowych.
• Enterprise Architect: weryfikacja zgodności z pryncypiami i standardami firmy.
• Solution Architect: proponowanie alternatywnych wariantów architektury rozwiązania.
• Security Architect: analiza wektorów zagrożeń (Threat Modeling wg metodologii STRIDE).
• Integration Architect & Data Architect: projektowanie interfejsów, modeli danych i przepływów.
• Cloud/Platform Architect: weryfikacja wykonalności infrastrukturalnej.
• Compliance Analyst: zgodność z regulacjami prawnymi (np. RODO, DORA, sektorowe wytyczne KNF).
• Technical Editor (Redaktor Techniczny): kluczowy agent, którego zadaniem jest eliminowanie tzw. AI slopu - wycinanie pustosłowia, dbanie o zwięzłość, precyzję terminologiczną i czytelność dokumentacji dla inżynierów.

Wyniki eksperymentu

Materiałem wejściowym był realny, 4-godzinny warsztat z udziałem biznesu i IT dotyczący wdrożenia aplikacji obsługi reklamacji opartej na AI (884 linie surowej transkrypcji).

Rój agentów, orkiestrowany przez uprząż i nadzorowany przez człowieka na kluczowych bramkach decyzyjnych, w ciągu 3 dni wygenerował:

• 13 kompletnych artefaktów architektonicznych (ok. 18 000 linii ustrukturyzowanego tekstu, zero błędów składniowych i logicznych walidatora),
• ponad 1200 elementów i relacji wprowadzonych automatycznie do repozytorium Sparx Enterprise Architect (komponenty, serwisy, decyzje, wymagania, diagramy C4 i UML),
• 43 formalne decyzje architektoniczne (ADR),
• 290 wymagań funkcjonalnych i niefunkcjonalnych,
• 133 zidentyfikowane ryzyka i podatności bezpieczeństwa.

Co najważniejsze: agenci wchodzili ze sobą w merytoryczne interakcje. Przykładowo, Architekt Bezpieczeństwa zakwestionował propozycję Architekta Rozwiązań, wskazując na ryzyko wstrzyknięcia promptu (prompt injection) ukrytego w załącznikach graficznych reklamacji, a Architekt Danych wychwycił konflikt identyfikatorów w planowanej migracji systemu CRM.

5. Dług poznawczy i dług intencji

W sesji Q&A Jan Maria Kowalski zadał kluczowe pytanie: „Skoro maszyna generuje 13 dokumentów, setki wymagań i tysiące powiązań w kilkadziesiąt minut, to ile czasu zajmie człowiekowi ich przeczytanie, zrozumienie i rzetelna weryfikacja?”

Odpowiedź prof. Sobczaka dotyka sedna problemu współczesnego IT. W erze AI wąskie gardło przesunęło się z wytwarzania na odbiór i audyt. Rodzi to dwa fundamentalne zagrożenia:

• Dług poznawczy (Cognitive Debt): stan, w którym złożoność wygenerowanych przez AI struktur i relacji przewyższa zdolność percepcyjną zespołu. System działa, ale nikt w organizacji nie ma pełnego, intuicyjnego wglądu w całość jego architektury.
• Dług intencji (Intent Debt): utrata świadomości, dlaczego dany komponent został zaprojektowany w określony sposób. Maszyna dobrała parametry na podstawie promptu, ale głęboki kontekst biznesowy ulega zatarciu.

W pilotażu VBA samo generowanie artefaktów zajęło modelom 2 dni. Jednak trójka doświadczonych architektów poświęciła półtora tygodnia na skrupulatną weryfikację i walidację materiału.

Oznacza to, że najważniejszą kompetencją przyszłości dla analityków i architektów nie jest umiejętność promptowania, lecz bezkompromisowa zdolność do weryfikacji, krytycznego myślenia i wykrywania subtelnych błędów logicznych w maszynowo wygenerowanych modelach.

6. Model Trzech Horyzontów: jak zmienią się zespoły IT?

Adaptując klasyczny model trzech horyzontów McKinseya do realiów inżynierii systemów, prof. Sobczak nakreślił mapę drogową zmian w perspektywie do 2030 roku:

• Horyzont 1 (do 2028 r.): porządkowanie praktyki. Agenci AI wchodzą w istniejące procesy jako akceleratory. Człowiek uczy się sterować rojami i budować „uprzęże”.
• Horyzont 2 (2028–2029 rr.): przebudowa ról i struktur. Zespoły deweloperskie kurczą się z 10–12 osób do 3–4 osób. Wygasa sztywny podział na analityka i architekta - wyłania się rola Solution Designera.
• Horyzont 3 (po 2030 r.): nowy paradygmat wytwarzania. Oprogramowanie powstaje w fabrykach kodu (Software Factories). Człowiek definiuje specyfikację i warunki brzegowe; implementacja jest w pełni zautomatyzowana.

Twoje portfolio agentów to Twój nowy GitHub

Stajemy przed koniecznością odrobienia fundamentalnej pracy domowej. Sztuczna inteligencja nie naprawi chaosu organizacyjnego - przeciwnie, zwielokrotni go w zastraszającym tempie. Jeśli firma nie ma uporządkowanych pryncypiów architektonicznych, spójnych słowników danych i czytelnych standardów, agenci AI w kilka minut wygenerują logiczny śmietnik o monumentalnych rozmiarach.

Dla profesjonalistów zajmujących się analizą i architekturą płynie stąd jednoznaczne przesłanie podsumowane przez prof. Sobczaka:

„Za dwa lata kandydat na analityka lub architekta bez własnego portfolio agentów będzie na rozmowie kwalifikacyjnej traktowany dokładnie tak, jak dziś programista bez GitHuba.”

Deklaracja „potrafię korzystać z ChatGPT” za chwilę straci jakąkolwiek wartość rynkową. Liczyć się będzie to, czy potrafisz zaprojektować rój agentów, osadzić go w bezpiecznej uprzęży, zintegrować z repozytorium architektury i przeprowadzić rygorystyczną walidację wyniku pod kątem celów biznesowych.

Czas przestać traktować AI jak ciekawostkę w oknie przeglądarki. Czas zacząć budować własne środowiska agentowe.