Poza Horyzont: nowe sposoby pracy | Analityk & Architekt

Punkt wyjścia

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 narusza 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ą.

Stan na dziś

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, dni, a w niektórych zastosowaniach tygodnie: budują całe moduły na podstawie ogólnej specyfikacji, samodzielnie sygnalizują niepewność, a wyniki jednych agentów sprawdzają kolejne, co daje warstwową kontrolę jakości. Zamiast reagować na pojedynczy prompt, agent działa w pętli wykonawczej - 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, przestały być osobną klasą narzędzi: 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 objętych rygorem regulacyjnym zmienia to rachunek: 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) pełni wobec integracji AI rolę, jaką Language Server Protocol odegrał wobec narzędzi programistycznych: buduje się raz, działa z dowolnym modelem, klientem i agentem. Standard przeszedł pod zarządzanie 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

Specyfikacja stała się artefaktem wykonawczym

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 waży to nieporównanie 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óre przez lata były dla automatyzacji nieczytelne, przestała być eksperymentem.

06

Kontekst nie jest już wąskim gardłem, lecz problemem projektowym

Limit okna kontekstowego obchodzi się dziś podsumowaniami, pamięcią trwałą i delegowaniem zadań do podagentów. 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”.

Zmiana perspektywy

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 bowiem, że warsztat pozostanie niezmienny, a AI będzie tylko kolejnym dokładanym do niego narzędziem.

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.

Metoda

Nie przewidujemy przyszłości. Sprawdzamy ją

Debata o sztucznej inteligencji jest przeładowana prognozami. 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.

Kryterium doboru

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 interesujący, ale sam w sobie nie stanowi jeszcze zmiany sposobu pracy.

Znacznie ciekawsze pytanie brzmi: co nowa zdolność technologiczna pozwala zrobić inaczej niż dotychczas?

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 tworzenia przez każdego z nich własnej, sprzecznej wersji rzeczywistości?

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

Trzy perspektywy zmiany

Eksperymenty porządkujemy według logiki trzech horyzontów. Nie traktujemy ich jednak jako trzech kolejnych dat. Wszystkie trzy istnieją równocześnie, a różni je głębokość zmiany w warsztacie.

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 nakładem sił.

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 modelem intencji, 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 być ciągłym mechanizmem sprawdzającym zgodność implementacji z decyzjami projektowymi i obserwującym zachowanie systemu na produkcji.

Decyzja architektoniczna nie musi kończyć się wpisem w ADR. Może mieć zapisane warunki, których spełnienie automatycznie otwiera ją ponownie.

W H2 nie przyspieszamy starego trybu pracy, tylko projektujemy nowy. Tutaj koncentruje się dziś większość uwagi inicjatywy.

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 właściwą formą przechowywania intencji?

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

Nie pytamy: „jak AI może wspierać radę architektoniczną?”, lecz: czy przy ciągłym zapewnianiu zgodności architektonicznej klasyczna rada będzie jeszcze potrzebna w obecnej formie?

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.

Mechanizm

Horyzont się przesuwa

Najciekawsze w ostatnich latach jest tempo, w jakim przesuwa się granica praktycznej wykonalności.

Rozwiązanie, które pół roku temu wymagało skomplikowanego prototypu, dziś bywa dostępne przez standardowe API. Pomysł, który rok temu uchodził za mało realistyczny, po premierze nowego modelu bywa kandydatem do pilotażu.

Dlatego nie wydajemy ocen raz na zawsze. Obserwujemy ruch pomiędzy horyzontami:

Sygnał
Hipoteza
Eksperyment
Dowód
Pilotaż
Praktyka

Pomysł pojawia się jako słaby sygnał i trafia do H3. Budujemy prototyp. Wynik okazuje się obiecujący, więc powtarzamy eksperyment. Pojawiają się lepsze modele lub narzędzia - praktyka przechodzi do H2. Testujemy ją w rzeczywistym projekcie. Jeżeli okaże się wystarczająco niezawodna, ekonomiczna i powtarzalna - trafia do H1.

Zakres

Co badamy

Nie ograniczamy się do sztucznej inteligencji rozumianej jako kolejny model językowy. To ona napędza dziś zmianę najmocniej, ale interesuje nas każda technologia i praktyka zdolna przeobrazić analizę, projektowanie i budowanie 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 eksploruje przestrzeń rozwiązań szerzej niż człowiek?
Czy potrafi świadomie budować warianty o różnych kompromisach?
Czy zamiast dyskusji architektonicznej możemy coraz częściej 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ł?

Trzy hipotezy

Założenia, które sprawdzamy

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

Hipoteza pierwsza

Coraz mniej generowania, coraz więcej weryfikacji

Przez pierwsze lata popularyzacji generatywnej AI fascynowało nas przede wszystkim to, co model potrafi stworzyć: tekst, kod, diagram, analizę, dokument, test.

Wraz ze wzrostem możliwości modeli koszt wytworzenia pierwszej wersji artefaktu spadł niemal do zera. Powstało inne wąskie gardło:

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 takich, które rozpoznają, 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 proweniencji, testów, prób obalenia tezy, śledzenia powiązań, obserwowalności i niezależnych mechanizmów kontrolnych.

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

Intencja drożeje, gdy wykonanie tanieje

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, definiowanie semantyki, 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,
przesądzeniu, 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ć.

Granice autonomii

Nie wszystko trzeba automatyzować

Inicjatywa Poza Horyzont nie wychodzi z założenia, że duża autonomia jest zawsze najlepszym rozwiązaniem. 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 bije pojedynczy model. Nie sądzimy też, by generatywność była potrzebna tam, gdzie wystarczy prosta reguła.

Dłuższa perspektywa

Obserwujemy nie tylko technologię, ale 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.