Po co ją prowadzimy, jak pracujemy i co chcemy sprawdzić.
Przez ostatnie dwie dekady warsztat analityka i architekta ewoluował zaskakująco powoli.
Przybywało notacji i narzędzi. Pojawiła się chmura, a potem mikrousługi, DevOps i nowe metody pracy z wymaganiami. Technologia się zmieniała, ale rytm naszej pracy pozostawał ten sam:
rozmawialiśmy z ludźmi, porządkowaliśmy wymagania, modelowaliśmy procesy, projektowaliśmy rozwiązania, pisaliśmy dokumentację i przekazywaliśmy ją dalej.
Sztuczna inteligencja zmienia właśnie ten rytm.
Etap, w którym AI pomagała nam tylko szybciej pisać dokumenty i szkicować diagramy, mamy już za sobą.
Agent pracuje w pętli nad zadaniem trwającym godziny, a czasem dni: buduje cały moduł z ogólnej specyfikacji i sam zgłasza, czego nie jest pewien. Coraz częściej współpracuje z innymi agentami: planista, architekt, wykonawca, tester i recenzent sprawdzają nawzajem swoje wyniki.
Modele, które rozumują krok po kroku, są dziś codziennym narzędziem: rozpisują warianty, wychwytują sprzeczne wymagania i wskazują własne błędy. Równie dobre bywają modele o otwartych wagach, które można uruchomić na własnych serwerach. Dla firm pod nadzorem regulatora to duża zmiana: wrażliwe dane nie muszą opuszczać organizacji, a wybór modelu staje się decyzją architektoniczną, nie tylko zakupową.
Model Context Protocol (MCP) robi dla AI to, co Language Server Protocol zrobił dla edytorów kodu: integrację buduje się raz, a działa ona z każdym modelem. Standardem zarządza Agentic AI Foundation w ramach Linux Foundation, a plan na 2026 rok skupia się na potrzebach dużych firm: ścieżkach audytu, uwierzytelnianiu, bramach dostępowych i komunikacji między agentami.
W podejściu spec-driven development źródłem prawdy jest wersjonowana, wykonywalna specyfikacja, a nie kod. Najpierw powstaje opis tego, co system ma robić, potem plan i zadania, a dopiero na końcu implementacja. Dla analityka to coś więcej niż kolejne narzędzie do diagramów.
Modele analizują dziś nagrania, zrzuty ekranu, rozmowy i dokumenty, z którymi automaty przez lata sobie nie radziły. To już codzienność, a nie eksperyment.
Limit okna kontekstowego omija się podsumowaniami, pamięcią trwałą i podagentami. Pytanie brzmi więc: co powinno trafić do kontekstu, w jakiej formie i kto za to odpowiada?
Jeszcze niedawno pytaliśmy: jak wykorzystać AI w pracy analityka i architekta?
Dziś to za mało. Takie pytanie zakłada, że sama praca się nie zmieni, a AI będzie tylko kolejnym narzędziem.
Nas interesuje inne:
Jak będzie wyglądać praca analityka i architekta, gdy to, co dziś uważamy za zaawansowane, za kilkanaście miesięcy stanie się standardem?
Nie znamy odpowiedzi. Dlatego powstała inicjatywa Poza Horyzont.
Na temat AI krąży mnóstwo prognoz: programiści przestaną programować, agenci przejmą procesy biznesowe, dokumentacja zniknie, analitycy staną się zbędni, a architekci będą tylko zatwierdzać to, co wygenerują modele.
Niektóre okażą się trafne, większość pewnie nie. My wolimy to sprawdzić:
Nie testujemy nowych modeli tylko dlatego, że się pojawiły. Sam model nie zmienia jeszcze sposobu pracy.
Pytamy raczej: co nowa możliwość pozwala zrobić inaczej niż dotąd?
Eksperymenty dzielimy na trzy horyzonty. To nie są kolejne etapy: wszystkie istnieją jednocześnie, a różni je głębokość zmiany.
Pracujemy jak dotąd, tylko niektóre czynności robimy szybciej, dokładniej lub mniejszym wysiłkiem.
Analityk nadal prowadzi wywiad, a AI wyłapuje brakujące informacje. Architekt nadal pisze ADR, a model szuka słabych punktów w uzasadnieniu. Zespół nadal pisze wymagania, a AI sprawdza ich spójność.
W tym obszarze wiele organizacji osiąga już wymierne korzyści, ale to dopiero początek.
Nie pytamy już, jak dodać AI do obecnego procesu, tylko czy ten proces ma jeszcze sens, skoro część pracy można wykonać zupełnie inaczej.
Wywiad nie musi kończyć się transkrypcją. AI może brać udział w rozmowie, na bieżąco budować mapę wiedzy, wskazywać luki i podpowiadać pytania.
Specyfikacja nie musi być dokumentem pisanym przed implementacją. Może być żywym opisem celu, z którego powstają kontrakty API, testy, modele procesów i zadania dla agentów.
Przegląd architektury nie musi być jednorazowym spotkaniem. Może działać w sposób ciągły: sprawdzać zgodność kodu z decyzjami i obserwować system na produkcji.
Decyzja architektoniczna nie musi kończyć się na ADR. Może mieć zapisane warunki, po których wraca do ponownej oceny.
Na tym horyzoncie skupiamy dziś najwięcej uwagi: nie przyspieszamy dawnego sposobu pracy, tylko projektujemy nowy.
Tu dzisiejszy warsztat przestaje być punktem wyjścia.
Nie pytamy: „jak AI pomoże napisać dokument wymagań?”, lecz: czy dokument wymagań to nadal dobra forma zapisu intencji?
Nie pytamy: „jak szybciej aktualizować diagram architektury?”, lecz: po co aktualizować go ręcznie, skoro architekturę można na bieżąco odtwarzać z kodu i z zachowania systemu?
Nie pytamy: „jak AI może wspierać radę architektoniczną?”, lecz: czy taka rada będzie potrzebna, skoro zgodność z architekturą można sprawdzać na bieżąco?
Nie pytamy: „jak projektować system agentowy?”, lecz: czy architekt będzie projektował organizację agentów: ich role, pamięć, narzędzia, granice autonomii i wzajemną kontrolę?
H3 to nie prognoza odległej przyszłości. Część pomysłów trafi stąd do H2 w ciągu kilku miesięcy, część zostanie tu latami, a część okaże się ślepą uliczką. Nie da się tego przewidzieć, dlatego to sprawdzamy.
To, co niedawno było niewykonalne, szybko staje się codziennością.
Rozwiązanie, które pół roku temu wymagało złożonego prototypu, dziś bywa zwykłą funkcją API. Pomysł, który rok temu wydawał się nierealny, po premierze nowego modelu nadaje się do pilotażu.
Dlatego niczego nie oceniamy raz na zawsze. Obserwujemy, jak pomysły przechodzą między horyzontami:
Nowy pomysł trafia do H3 jako słaby sygnał. Budujemy prototyp, a jeśli wynik jest obiecujący, powtarzamy eksperyment. Gdy pojawią się lepsze modele lub narzędzia, praktyka przechodzi do H2 i sprawdzamy ją w prawdziwym projekcie. Jeśli okaże się niezawodna, opłacalna i powtarzalna, trafia do H1.
Najmocniej zmianę napędza dziś AI, ale nie ograniczamy się do modeli językowych. Interesuje nas każda technologia i praktyka, która może zmienić analizę, projektowanie i budowę systemów.
To robocze założenia, nie tezy do obrony. Każde z nich sprawdzamy.
W pierwszych latach generatywnej AI fascynowało nas, co model potrafi stworzyć: tekst, kod, diagram, test.
Dziś pierwsza wersja dokumentu czy kodu nie kosztuje prawie nic. Wąskim gardłem stało się co innego:
Skąd wiemy, że wynik jest dobry?
Pięć wariantów architektury wygenerowanych w trzy minuty trzeba rzetelnie ocenić. Z kilkuset wymagań trzeba wybrać te prawdziwe, potrzebne, spójne i sprawdzalne. Zmian w kilkudziesięciu plikach nikt nie przeczyta w całości, więc kontrola musi działać inaczej.
Dlatego rośnie znaczenie śledzenia źródeł informacji i powiązań między artefaktami, testów, prób obalenia tez, obserwowalności i niezależnych kontroli.
Najważniejszą zmianą w pracy architekta może okazać się przejście od projektowania artefaktów do projektowania dowodu, że rozwiązanie spełnia pierwotną intencję.
Gdy implementacja jest droga, to ona pochłania większość wysiłku. Gdy tanieje, relatywnie drożeją błędy popełnione wcześniej: źle zrozumiany problem, nieprecyzyjne wymaganie, przemilczane założenie, zła granica systemu, różne rozumienie tego samego pojęcia.
Agent wykona błędne polecenie szybciej i sprawniej niż człowiek.
AI nie musi więc umniejszać znaczenia analizy. Może wręcz podnieść wartość dobrze określonej intencji i zmienić rolę analityka.
Mniej pisania dokumentów, więcej rozumienia problemu, wyłapywania sprzeczności, uzgadniania pojęć, rozmów i pilnowania, czy rozwiązanie wciąż odpowiada potrzebie.
Skoro kolejny wariant, zestaw wymagań czy model procesu jest tani, wartość nie leży w ich liczbie. Leży w umiejętności:
Obie role mogą iść w tę samą stronę: od opinii do eksperymentu, od dokumentacji do obserwowalności, od jednorazowego przeglądu do stałej kontroli zgodności, od statycznego modelu do żywego obrazu systemu.
To właśnie chcemy sprawdzić.
Nie zakładamy, że im więcej autonomii, tym lepiej. Jedno z ważniejszych pytań brzmi:
Gdzie AI ma działać sama, a gdzie tylko pomagać człowiekowi?
Czasem najlepszym rozwiązaniem będzie agent, czasem zwykła automatyzacja albo model, który wykonuje jedną klasyfikację. Bywa, że wystarczy człowiek wspierany przez AI.
Nie mierzymy dojrzałości liczbą agentów. System wieloagentowy nie jest z założenia lepszy od jednego modelu, a tam, gdzie wystarczy prosta reguła, model generatywny jest zbędny.
Najciekawsze wnioski pojawią się pewnie dopiero po kilkudziesięciu eksperymentach. Pokażą nie tylko, co potrafi AI, ale też jak zmienia się praca analityków i architektów.
Może mniej czasu zajmie nam ręczne tworzenie artefaktów, a więcej określanie intencji, budowanie kontekstu, podejmowanie decyzji, eksperymenty, weryfikacja i zarządzanie autonomią.
Mogą pojawić się kompetencje, których nie ma dziś w żadnym opisie stanowiska: projektowanie kontekstu dla agentów, projektowanie systemów wieloagentowych i kontroli AI, ciągłe sprawdzanie zgodności z architekturą, inżynieria dowodów, zarządzanie specyfikacją wykonywaną przez agentów.
Część dzisiejszych umiejętności pewnie straci znaczenie. Nie chcemy tego zgadywać, tylko zobaczyć w praktyce.
Nie wiemy, jak za dwa lata będzie wyglądać praca analityka i architekta, które narzędzia przetrwają ani co przyniosą kolejne modele.
Zamiast zgadywać, obserwujemy, stawiamy hipotezy, budujemy prototypy, mierzymy, mylimy się i powtarzamy eksperymenty. Krok po kroku sprawdzamy, które nowe sposoby pracy zasługują na miejsce w naszym warsztacie.
Gdy któryś okaże się wystarczająco dobry, opiszemy go, udostępnimy i włączymy do codziennej praktyki. Przestanie być poza horyzontem, a my zajmiemy się następnym pytaniem.
Nie przewidujemy przyszłości naszej pracy. Sprawdzamy, jak zaczyna się ona zmieniać.