Poza Horyzont: nowe sposoby pracy | Analityk & Architekt

Warsztat pracy, który zmieniał się wolniej niż technologia

Przez ostatnie dwie dekady warsztat analityka i architekta zmieniał się zaskakująco powoli.

Przybywało notacji i narzędzi. Przyszła chmura, mikrousługi, platformy integracyjne, DevOps, kolejne podejścia do zarządzania wymaganiami i projektowania systemów. Technologia się zmieniała, lecz podstawowy rytm pracy analityków i architektów pozostawał ten sam:

rozmawialiśmy z ludźmi, pozyskiwaliśmy wiedzę, porządkowaliśmy wymagania, modelowaliśmy procesy, analizowaliśmy dane, projektowaliśmy rozwiązania, rozważaliśmy warianty, podejmowaliśmy decyzje, tworzyliśmy dokumentację i przekazywaliśmy ją kolejnym uczestnikom procesu wytwarzania oprogramowania.

Sztuczna inteligencja zmienia właśnie ten rytm.

Nie chodzi już o to, żeby szybciej napisać dokument, wygenerować kilka przypadków użycia albo naszkicować pierwszą wersję diagramu. To był etap, który mamy za sobą.

Dzisiejsze możliwości AI

01

Agenci potrafią pracować bardzo długo

Modele przestały działać w rytmie „pytanie - odpowiedź”. Agenci realizują dziś zadania trwające godziny, a w niektórych zastosowaniach dni: budują całe moduły na podstawie ogólnej specyfikacji, samodzielnie sygnalizują niepewność, a wyniki jednych agentów sprawdzają kolejne, co daje kilkustopniową kontrolę jakości. Zamiast reagować na pojedynczy prompt, agent pracuje w pętli - i coraz częściej nie w pojedynkę, lecz w zespole o wyspecjalizowanych rolach: planisty, architekta, wykonawcy, testera i recenzenta.

02

Modele rozumujące dojrzały - również te uruchamiane lokalnie

Modele, które przed odpowiedzią prowadzą wielokrokowe rozumowanie, stały się codziennym narzędziem: potrafią rozpisać wariant, wychwycić sprzeczność w zestawie wymagań i wskazać krok, na którym same się pomyliły. Równolegle dojrzały modele o otwartych wagach, możliwe do uruchomienia we własnej infrastrukturze. Dla organizacji działających pod nadzorem regulatora to zmienia sytuację: rozumowanie na wrażliwych danych nie musi już opuszczać firmy, a wybór między modelem dostępnym przez API a własnym staje się decyzją architektoniczną, nie tylko zakupową.

03

Integracja modeli AI z narzędziami doczekała się standardu

Model Context Protocol (MCP) robi dla integracji AI to, co Language Server Protocol zrobił dla narzędzi programistycznych: buduje się raz, działa z dowolnym modelem, klientem i agentem. Standard przeszedł pod zarządzanie Agentic AI Foundation, działającej w ramach Linux Foundation, a plan rozwoju na 2026 rok skupia się na potrzebach dużych organizacji: ścieżkach audytowych, uwierzytelnianiu i wzorcach bram dostępowych, a także na podstawowych mechanizmach komunikacji między agentami.

04

Specyfikację można dziś wykonać, nie tylko przeczytać

W podejściu spec-driven development to wersjonowana, wykonywalna specyfikacja - a nie kod - jest jedynym źródłem prawdy: najpierw powstaje opis tego, co system ma robić, potem plan, potem zadania, a dopiero na końcu implementacja. Dla analityka znaczy to o wiele więcej niż kolejne narzędzie do rysowania diagramów.

05

Modele widzą i słyszą

Analiza nagrań, zrzutów ekranu, rozmów i dokumentacji w formatach, których automaty przez lata nie umiały czytać, to dziś codzienność, a nie eksperyment.

06

Kontekst przestał być ograniczeniem, a stał się decyzją projektową

Ograniczenie okna kontekstowego omija się dziś podsumowaniami, pamięcią trwałą i przekazywaniem zadań podagentom. Pytanie nie brzmi już „ile zmieści się w kontekście”, lecz „co powinno się w nim znaleźć, w jakiej formie i kto za to odpowiada”.

Pytanie, które przestało wystarczać

Jeszcze niedawno pytaliśmy: jak wykorzystać AI w pracy analityka i architekta?

Dziś to pytanie jest za wąskie. Zakłada, że sposób pracy się nie zmieni, a AI będzie tylko kolejnym narzędziem dołożonym do dotychczasowych.

Bardziej interesuje nas inne:

Jak będzie wyglądała praca analityka i architekta, jeżeli możliwości, które dzisiaj uznajemy za zaawansowane, za kilkanaście miesięcy staną się czymś zwyczajnym?

Nie znamy odpowiedzi. I właśnie dlatego powstała inicjatywa Poza Horyzont.

Nie przewidujemy przyszłości. Sprawdzamy ją

W dyskusji o sztucznej inteligencji roi się od prognoz. Programiści przestaną programować. Agenci przejmą procesy biznesowe. Dokumentacja zniknie. Analitycy staną się zbędni. Architekci będą już tylko zatwierdzać rozwiązania wygenerowane przez modele.

Część tych przewidywań okaże się trafna. Większość zapewne nie. Nas interesuje coś bardziej praktycznego:

Jeżeli ktoś twierdzi, że AI potrafi przeprowadzić wywiad analityczny - chcemy taki wywiad przeprowadzić i porównać jego rezultat z pracą doświadczonego analityka.
Jeżeli agent ma odtworzyć działanie systemu bez aktualnej dokumentacji - damy mu prawdziwy system legacy i sprawdzimy, co rzeczywiście uda mu się ustalić, a czego nie zauważy.
Jeżeli AI ma projektować architekturę - wygenerowany diagram nam nie wystarczy. Sprawdzamy, czy potrafi zaproponować istotnie różne warianty, nazwać kompromisy, zbudować niewielkie prototypy i uzasadnić rekomendację wynikami, a nie retoryką.
Jeżeli specyfikacja ma być źródłem dla agentów budujących oprogramowanie - sprawdzamy, co dzieje się wtedy z wymaganiami, modelami, testami, odpowiedzialnością i sposobem prowadzenia projektu.
Jeżeli architekturę można rekonstruować z kodu, infrastruktury i telemetrii - sprawdzamy, jak bardzo różni się ona od tej, którą mamy w repozytorium.

Punktem wyjścia jest model pracy, a nie technologia

Poza Horyzont nie jest miejscem testowania kolejnych modeli tylko dlatego, że właśnie się pojawiły. Nowy model bywa ciekawy, ale sam z siebie nie zmienia jeszcze sposobu pracy.

Znacznie ciekawsze pytanie brzmi: co nowa możliwość technologii pozwala zrobić inaczej niż dotąd?

Nie pytamy„Model analizuje wideo.”

PytamyCzy na podstawie nagrania pracy użytkownika potrafimy odtworzyć rzeczywisty przebieg procesu i wskazać czynności, których nie ma w oficjalnej dokumentacji?

Nie pytamy„Model ma długi kontekst.”

PytamyCzy da się zbudować wspólną warstwę wiedzy o projekcie, z której korzystają różni agenci - bez tego, żeby każdy z nich budował własną, sprzeczną z innymi wersję wiedzy?

Nie pytamy„Agent pisze kod.”

PytamyJak powinna wyglądać specyfikacja, jeżeli jej głównym odbiorcą coraz częściej nie jest programista, lecz agent wykonujący zadanie?

Nie pytamy„AI ocenia architekturę.”

PytamyCzy kilka niezależnych mechanizmów kontrolnych wykryje problemy, których nie zauważył zespół projektowy - i czy koszt takiej kontroli uzasadnia jej stosowanie?

Trzy horyzonty zmiany

Eksperymenty porządkujemy według logiki trzech horyzontów. Nie są to jednak trzy kolejne etapy w czasie. Wszystkie istnieją równocześnie, a różni je to, jak głęboko zmieniają sposób pracy.

H1 · Wzmocnienie H2 · Przeprojektowanie H3 · Podważenie

H1

Wzmocnienie

Usprawniamy obecny warsztat analityka i architekta

W pierwszym horyzoncie zachowujemy dotychczasowy sposób pracy, ale wykonujemy niektóre czynności szybciej, dokładniej lub mniejszym wysiłkiem.

Analityk nadal prowadzi wywiad - AI pomaga mu wychwycić brakujące informacje. Architekt nadal pisze ADR - model próbuje podważyć jego argumentację. Zespół nadal formułuje wymagania - AI sprawdza ich spójność. Diagram nadal powstaje ręcznie - model analizuje jego kompletność.

To ważny obszar, bo właśnie tutaj wiele organizacji osiąga już wymierne korzyści. Ale to dopiero początek.

H2

Przeprojektowanie

Zmieniamy sposób pracy analityka i architekta

W drugim horyzoncie przestajemy pytać: „jak dodać AI do obecnego procesu?” Zaczynamy pytać: „czy obecny proces nadal ma sens, skoro część działań można wykonać zupełnie inaczej?”

Wywiad nie musi być rozmową człowieka, po której powstaje transkrypcja. AI może uczestniczyć w rozmowie, utrzymywać mapę zdobytej wiedzy, wskazywać luki i proponować kolejne pytania.

Specyfikacja nie musi być dokumentem przygotowanym przed implementacją. Może być żywym opisem tego, co chcemy osiągnąć, z którego powstają kontrakty API, scenariusze testowe, modele procesów i zadania dla agentów.

Przegląd architektoniczny nie musi być jednorazowym spotkaniem. Może działać stale: sprawdzać, czy implementacja jest zgodna z decyzjami projektowymi, i obserwować, jak system zachowuje się na produkcji.

Decyzja architektoniczna nie musi kończyć się wpisem w ADR. Może mieć zapisane warunki, po których spełnieniu wraca do ponownego rozpatrzenia.

W H2 nie przyspieszamy starego sposobu pracy, tylko projektujemy nowy. Tu dziś skupia się większość naszej uwagi.

H3

Podważenie

Wymyślamy na nowo sposób pracy analityka i architekta

Trzeci horyzont zaczyna się tam, gdzie przestajemy traktować dzisiejszy warsztat jako punkt wyjścia.

Nie pytamy: „jak AI może pomóc stworzyć dokument wymagań?”, lecz: czy dokument wymagań pozostanie dobrą formą zapisu intencji?

Nie pytamy: „jak szybciej aktualizować diagram architektury?”, lecz: czy diagram powinien być aktualizowany ręcznie, skoro architekturę można na bieżąco odtwarzać z implementacji i z zachowania systemu?

Nie pytamy: „jak AI może wspierać radę architektoniczną?”, lecz: czy klasyczna rada będzie jeszcze potrzebna w obecnej formie, skoro zgodność z architekturą można sprawdzać na bieżąco?

Nie pytamy: „jak architekt powinien projektować system agentowy?”, lecz: czy częścią pracy architekta stanie się projektowanie organizacji agentów - ich odpowiedzialności, pamięci, kontekstu, narzędzi, granic autonomii i sposobów wzajemnej kontroli?

H3 nie jest prognozą odległej przyszłości. Niektóre pomysły przejdą stąd do H2 w ciągu kilku miesięcy. Inne pozostaną tu latami. Jeszcze inne okażą się ślepą uliczką. Tego nie da się przewidzieć - i właśnie dlatego to sprawdzamy.

Horyzont się przesuwa

Najciekawsze w ostatnich latach jest tempo, w jakim to, co niedawno było niewykonalne, staje się codziennością.

Rozwiązanie, które pół roku temu wymagało skomplikowanego prototypu, dziś bywa dostępne w standardowym API. Pomysł, który rok temu wydawał się mało realistyczny, po premierze nowego modelu nadaje się do pilotażu.

Dlatego nie oceniamy niczego raz na zawsze. Obserwujemy, jak pomysły przesuwają się między horyzontami:

Pomysł pojawia się jako słaby sygnał i trafia do H3. Budujemy prototyp. Wynik jest obiecujący, więc powtarzamy eksperyment. Pojawiają się lepsze modele albo narzędzia i praktyka przechodzi do H2. Sprawdzamy ją w prawdziwym projekcie. Jeżeli okaże się dość niezawodna, opłacalna i powtarzalna, trafia do H1.

Co badamy

Nie ograniczamy się do sztucznej inteligencji rozumianej jako kolejny model językowy. To ona najmocniej napędza dziś zmianę, ale interesuje nas każda technologia i praktyka, która może zmienić sposób analizowania, projektowania i budowania systemów.

Odkrywanie

Czy AI potrafi aktywnie pozyskiwać wiedzę?
Prowadzić wywiad?
Odtworzyć działanie systemu legacy?
Zrekonstruować proces z dokumentacji, logów, nagrań i obserwacji użytkownika?

Definiowanie

Czy wymagania mogą być żywym modelem zamiast dokumentem?
Czy intencję da się zapisać w formie zrozumiałej jednocześnie dla ludzi, modeli i narzędzi?
Czy specyfikacja może być wykonywalna?

Projektowanie

Czy AI przegląda więcej możliwych rozwiązań niż człowiek?
Czy potrafi świadomie budować warianty o różnych kompromisach?
Czy zamiast dyskutować o architekturze możemy coraz częściej po prostu przeprowadzić eksperyment?

Budowanie

Co realnie zmienia spec-driven development?
Co dzieje się, gdy agent dostaje specyfikację i samodzielnie realizuje znaczną część implementacji?
Jak zmienia się wtedy odpowiedzialność analityka, architekta i programisty?

Weryfikowanie

Jak kontrolować rezultaty w świecie, w którym koszt ich wytworzenia gwałtownie maleje?
Jak odróżnić artefakt przekonujący od poprawnego?
Jak zapewnić spójność między wymaganiem, modelem, kodem i zachowaniem działającego systemu?

Nadzór

Kto odpowiada za decyzję podjętą przez agenta?
Jak wyznaczać granice autonomii?
Jak audytować pracę, której nikt w całości nie przeczytał?

Założenia, które sprawdzamy

To założenia robocze, a nie tezy do obrony. Każde z nich sprawdzamy, zamiast budować na nim argumentację.

Hipoteza pierwsza

Coraz mniej generowania, coraz więcej weryfikacji

W pierwszych latach generatywnej AI fascynowało nas przede wszystkim to, co model potrafi stworzyć: tekst, kod, diagram, analizę, dokument, test.

W miarę jak modele stawały się lepsze, koszt pierwszej wersji dokumentu, diagramu czy kodu spadł niemal do zera. Wąskie gardło przesunęło się gdzie indziej:

Skąd wiemy, że rezultat jest właściwy?

Jeżeli agent generuje pięć wariantów architektury w trzy minuty, problemem nie jest brak wariantów - problemem jest ich rzetelna ocena.

Jeżeli AI potrafi napisać kilkaset wymagań, nie potrzebujemy mechanizmów zwiększających ich liczbę. Potrzebujemy mechanizmów rozpoznających, które z nich są prawdziwe, potrzebne, spójne i możliwe do zweryfikowania.

Jeżeli agent modyfikuje kilkadziesiąt plików w repozytorium, człowiek nie utrzyma kontroli przez ręczne przeczytanie wszystkiego. Potrzebuje kontroli zbudowanej zupełnie inaczej.

Dlatego rośnie znaczenie tego, skąd pochodzi każda informacja, a także testów, prób obalenia tezy, śledzenia powiązań, obserwowalności i niezależnych mechanizmów kontroli.

Być może najważniejszą zmianą w pracy architekta okaże się przejście od projektowania artefaktów do projektowania dowodu na to, że rozwiązanie odpowiada pierwotnej intencji.

Hipoteza druga

Gdy wykonanie tanieje, błąd w intencji kosztuje coraz więcej

Kiedy implementacja jest kosztowna, większość wysiłku pochłania jej wytworzenie. Kiedy koszt implementacji maleje, relatywnie droższe stają się błędy popełnione wcześniej: źle zrozumiany problem, nieprecyzyjne wymaganie, niewypowiedziane założenie, źle postawiony cel, błędnie wyznaczona granica systemu, nieuzgodnione znaczenie pojęcia.

Agent wykona błędne polecenie bardzo sprawnie. Sprawniej, niż zrobiłby to kiedykolwiek człowiek.

Dlatego rozwój AI nie musi zmniejszać znaczenia analizy. Paradoksalnie może podnieść wartość dobrze zdefiniowanej intencji - i zmienić rolę analityka.

Mniej czasu na ręczne wytwarzanie dokumentacji. Więcej na rozumienie problemu, wykrywanie sprzeczności, uzgadnianie znaczenia pojęć, prowadzenie rozmów i pilnowanie, czy powstające rozwiązanie wciąż odpowiada pierwotnej potrzebie.

Hipoteza trzecia

Analityk i architekt nie muszą tworzyć więcej - muszą trafniej podejmować decyzje

Skoro wytworzenie kolejnego wariantu rozwiązania, zestawu wymagań czy modelu procesu staje się tanie, wartość nie leży już w ich liczbie. Leży w:

rozpoznaniu istotnych kompromisów i ryzyk,
odróżnieniu rzeczywistej potrzeby od zgłoszonego życzenia,
rozstrzygnięciu, gdzie przebiega granica systemu,
trafnym sformułowaniu kryteriów oceny,
odrzuceniu rozwiązań pozornie atrakcyjnych,
zaprojektowaniu eksperymentu, który rozstrzygnie spór,
utrzymaniu spójności decyzji w czasie,
wyznaczeniu granic autonomii agentów,
oraz w umiejętności powiedzenia: „nie mamy jeszcze wystarczających danych, aby podjąć tę decyzję”.

Obie role mogą się przesuwać w tę samą stronę: od opinii do eksperymentu, od dokumentacji do obserwowalności, od jednorazowego przeglądu do ciągłego zapewniania zgodności, od statycznego modelu do żywego obrazu systemu.

To są obszary, które chcemy testować.

Nie wszystko trzeba automatyzować

Nie zakładamy, że im więcej autonomii, tym lepiej. Wręcz przeciwnie - jedno z ważniejszych pytań brzmi:

Gdzie AI powinna działać samodzielnie, a gdzie jedynie wspierać człowieka?

Raz najlepszym rozwiązaniem będzie agent, innym razem zwykła automatyzacja deterministyczna albo model wykonujący pojedynczą klasyfikację. Bywa, że wystarczy człowiek wspierany przez AI.

Nie mierzymy dojrzałości liczbą agentów ani nie zakładamy, że system wieloagentowy przewyższa pojedynczy model. Nie sądzimy też, że model generatywny jest potrzebny tam, gdzie wystarczy prosta reguła.

Obserwujemy nie tylko technologię, ale i profesję

Najciekawszy rezultat pojawi się prawdopodobnie dopiero po kilkudziesięciu eksperymentach. Zobaczymy wtedy nie tylko, co potrafi AI, lecz jak zmienia się struktura pracy analityków i architektów.

Być może mniej czasu poświęcimy ręcznemu wytwarzaniu artefaktów, a więcej - definiowaniu intencji, budowaniu kontekstu, podejmowaniu decyzji, prowadzeniu eksperymentów, weryfikacji wyników, gromadzeniu dowodów i zarządzaniu autonomią.

Możliwe, że powstaną kompetencje, których dziś nie ma w żadnym opisie stanowiska: projektowanie kontekstu dla agentów, projektowanie systemów wieloagentowych, projektowanie mechanizmów kontroli AI, ciągłe zapewnianie zgodności architektonicznej, inżynieria dowodów, zarządzanie specyfikacją wykonywaną przez agentów.

Część dzisiejszych umiejętności zapewne straci na znaczeniu.

Nie chcemy tego rozstrzygać na podstawie prognoz. Chcemy to obserwować w praktyce.