Kategoria: Automatyzacja i autonomia
„Kod stał się tani.” To najkrótsze streszczenie konferencji Budowa oprogramowania w erze AI, która odbyła się online 4 listopada 2026 roku, i brzmi jak dobra wiadomość. Wniosek, który z niej wynoszę, jest inny: skoro kod przestał być barierą, to wszystko, co było za nim schowane, właśnie przestało się chować.
Konferencję zorganizowała Fundacja Ośrodek Studiów nad Cyfrowym Państwem, a cały program jest publicznie dostępny: trzy równoległe ścieżki, dwie debaty i ponad trzydzieści wystąpień. Ten tekst ma dwie warstwy i trzymam je rozdzielone. Dziesięć wniosków poniżej to podsumowanie stanowisk z tego programu, a nie mój pomiar. Pod każdym z nich dopisuję jeden akapit o tym, jak ta sama rzecz wygląda u mnie, i w tym akapicie podaję wyłącznie liczby odczytane na własnych maszynach, z datą i z linkiem do tekstu, w którym je rozpisałem. Czego tu nie ma: pomiaru przyspieszenia pracy dzięki AI, bo takiego pomiaru nie mam, ani żadnej liczby z firm, w których wdrażałem automatyzację, bo tych pokazać nie mogę.
Gdzie przesunęło się wąskie gardło
1. Kod stał się tani, oprogramowanie nie
Z konferencji: generowanie kodu przestało być barierą i stało się tanim, powszechnym zasobem, tylko że kod nigdy nie był głównym kosztem wartościowego oprogramowania. Wydajniejsze kodowanie przesunęło zatory na początek procesu, czyli na odkrywanie produktu, wymagania i architekturę, oraz na jego koniec, czyli na przegląd, testy, bezpieczeństwo i utrzymanie. Najdroższe są dziś błędne decyzje i brak kontekstu.
U mnie wygląda to dokładnie tak. Klikalny prototyp podłączony do danych mam tego samego dnia i opisałem ten proces razem z jego granicami: pierwsze polecenie w każdej sesji brzmi „opisz plan i nie pisz kodu”, ponieważ tani kod bez planu tylko szybciej dowozi rzecz niewłaściwą. Mocniejszy dowód na to, że kod nie jest kosztem, jest dla mnie nieprzyjemny: po latach budowania własnego systemu nie umiem podać, ile czasu on mi oszczędza. Kodu mam dużo. Pomiaru wartości nie mam.
2. Rola się przesuwa, nadzór człowieka zostaje
Z konferencji: programista odchodzi od pisania powtarzalnych linii w stronę architektury kontekstu, orkiestracji agentów i rozwiązywania złożonych problemów, a zespoły UX i analitycy przechodzą w stronę strategii produktu. Jednocześnie w punktach decyzyjnych, procesowych i bezpieczeństwa człowiek w pętli pozostaje konieczny.
To jest wniosek, który sprawdzałem na sobie przez kilka miesięcy. Rozpisałem pięć poziomów autonomii i czwarty z nich, agentowy z człowiekiem w pętli, jest najbardziej niewygodny i najważniejszy. Nie dlatego, że jest z definicji bezpieczniejszy, ale dlatego, że tylko na nim widać, czy system decyduje dobrze. Kiedy u mnie system w końcu przestał pytać, nie stało się to przez decyzję „teraz ufam”, lecz przez licznik: pięć moich zgód z rzędu dla jednego typu operacji awansowało tę jedną operację z trybu „zapytaj” do trybu „wykonaj i pokaż wynik”. Osobno, jedna po drugiej, każda po własnych dowodach.
3. Specyfikacja zamiast promptu
Z konferencji: praktyka przesuwa się od pojedynczych promptów w czacie do wieloagentowych pętli i do podejścia opartego na specyfikacji. Specyfikacja spisana w języku naturalnym, najczęściej w Markdownie, staje się głównym źródłem prawdy i wspólnym interfejsem komunikacji dla ludzi i dla modeli.
U mnie tym dokumentem jest wynik tego pierwszego polecenia bez kodu i pełni trzy funkcje: jest punktem odniesienia między sesjami, gdy kontekst rozmowy już się nie mieści, jest listą kontrolną zakresu i jest miejscem, w którym widać, że model zaczął przyjmować założenia, których mu nie dałem. Drugi, techniczny wymiar tego samego wniosku jest w mojej bazie: 43 workflow mam udostępnione agentowi AI jako gotowe części składowe. To jest ten wspólny interfejs. Różnica między opisanym kontraktem a obrazem na ekranie jest dokładnie tą samą różnicą, którą pokazałem, porównując n8n z klasycznym RPA.
Co się psuje, kiedy kodu jest więcej
4. Testy wygenerowane szybko dają złudzenie pokrycia
Z konferencji: AI generuje scenariusze testowe szybko, lecz często powierzchownie, po szczęśliwej ścieżce, co daje złudne poczucie bezpieczeństwa i pokrycia. Rzeczywista wartość leży w błędach integracji, w stanach współbieżności i w analizie ryzyk biznesowych, co przesuwa testera w stronę nadzorcy ryzyk.
Liczba, która to u mnie potwierdza, nie pochodzi z testów, tylko z eksploatacji. Przez czternaście dni, w oknie od 16 do 30 października 2026, moja instancja n8n wykonała 5 245 przebiegów, z czego 1 044 zakończyły się błędem. To 19,9 % i rozkłada się na 31 różnych workflow, a żaden z tych przebiegów nie został powtórzony automatycznie, bo nigdzie nie włączyłem ponowień. Cały odczyt razem z zastrzeżeniami opisałem osobno, pokazując, jak czytam dziennik przebiegów. Przyczyny są prawie zawsze po drugiej stronie kontraktu: wygasł token, zmienił się format odpowiedzi, usługa odpowiedziała inaczej niż wczoraj. Szczęśliwa ścieżka nie pokazałaby ani jednej z nich. Osobne pytanie, które zadaję przy każdym takim błędzie, brzmi: awaria czy zmiana.
5. Dług poznawczy i dług intencji
Z konferencji: niekontrolowana generacja kodu tworzy dwa nowe rodzaje długu. Dług poznawczy to utrata przez zespół zrozumienia, jak i dlaczego dany kod działa. Dług intencji to zagubienie celu biznesowego i uzasadnienia funkcji. W drugą stronę AI działa jak narzędzie archeologiczne i pozwala szybko odzyskać wiedzę o nieudokumentowanych systemach odziedziczonych.
Dług intencji miał u mnie bardzo konkretną postać: rok pracy, który istniał wyłącznie na jednym dysku, bez historii i bez odpowiedzi na pytanie, co się zmieniło. Cztery tygodnie poszły na to, czego w domu nikt nie wymaga, i opisałem ten miesiąc bez ani jednej nowej funkcji: dziewięć projektów docker compose, 32 kontenery, 112 paczek w dokładnych wersjach i jedna przypięta wersja Pythona, czyli jeden plik, z którego odtworzę maszynę. Repozytorium od razu pokazało, że moje reguły ignorowania kłamały i ukrywały przed mną śledzony kod. Przy systemie, który działa siódmy rok, nie jest to kwestia porządku, lecz różnica między aktywem a pamiątką.
6. Bezpieczeństwo jako wykonywalny kod
Z konferencji: kod generowany przez AI przynosi zmyślone zależności i podatności, a wolumen zmian jest już taki, że audyt bezpieczeństwa nie może być osobnym etapem przed wdrożeniem. Musi zostać zapisany jako wykonywalny kod i automatycznie egzekwowany w potokach ciągłej integracji.
U mnie bramek jest osiem i wszystkie osiem blokuje zmianę: od analizy statycznej i skanu sekretów, przez walidację wstępną i testy jednostkowe, po kontrolę kontraktu API i skan bezpieczeństwa zależności. Integrację uruchamiam na własnym runnerze, na tej samej maszynie co system, bo moje dane nie wychodzą z domu. Druga granica w tym samym wniosku nie jest techniczna, lecz dotyczy tego, co wolno wysłać do cudzego modelu, i rozstrzygam ją osobno: czy mogę wrzucić dane klienta do ChatGPT.
Czym to otoczyć, żeby dało się utrzymać
7. Low-code nie znika, zmienia się w środowisko dla agentów
Z konferencji: platformy low-code nie zostają wyparte przez AI, lecz przekształcają się w środowiska dla agentów. Połączenie agentów ze strukturami low-code pozwala dostarczać ustandaryzowane i audytowalne aplikacje bez drastycznego uzależnienia od surowego kodu i od opłat za modele.
U mnie tę warstwę pełni n8n i audytowalność nie jest tu hasłem, lecz skutkiem. To, że mogłem w ogóle policzyć 223 workflow, 3 449 bloków i 229 bloków związanych z modelem, wynika z jednej rzeczy: przepływ jest u mnie danymi w bazie, a nie obrazem na ekranie. Robot pracujący na ekranie nie daje się policzyć w ten sposób i to jest praktyczna, a nie teoretyczna, różnica między dwoma miejscami podłączenia. n8n stoi u mnie w kontenerze na własnym serwerze, więc o uzależnienie od dostawcy platformy się nie martwię. O uzależnienie od dostawcy modelu martwię się słusznie i wracam do tego w punkcie dziesiątym.
8. Kontekst danych: drugi mózg i grafy wiedzy
Z konferencji: skuteczne działanie agentów w organizacji wymaga zbudowania spójnego kontekstu danych, czyli drugiego mózgu albo repozytorium wiedzy skompilowanego do grafu semantycznego. Zamiast polegać na surowych odpowiedziach modeli, organizacje wdrażają ład danych w oparciu o ustalone ramy architektoniczne.
Mój kontekst to jeden serwer PostgreSQL, przed nim PgBouncer jako jedyna droga połączeń, a za nim osiem baz dziedzinowych: finanse, trening, spiżarnia, zdrowie, cyfrowy bliźniak, nauka, logistyka, kariera. Reguła, która trzyma to w całości, nie dotyczy liczby baz, tylko dostępu: żaden skrypt nie łączy się z bazą sam. Uczciwie dodam, że ten podział w połowie jest kroniką, nie decyzją, bo bazy powstawały jedna po drugiej przez kilka lat, a dziś zacząłbym od jednej bazy z ośmioma schematami. Warstwa, która u mnie odpowiada drugiemu mózgowi, to cyfrowy bliźniak, i warto przeczytać, czym on nie jest, zanim się tę nazwę podniesie.
9. Paszport AI dla agenta
Z konferencji: wraz ze wzrostem autonomii agentów pojawia się potrzeba formalnego nadzoru. Koncepcja paszportu AI zakłada nadanie agentowi ustrukturyzowanej tożsamości, przypisanie mu jasnych uprawnień i ograniczeń zasobowych oraz wyznaczenie imiennego sponsora i nadzorcy po stronie człowieka.
Tego dokumentu nie mam i to jest luka, którą konferencja pokazała mi najwyraźniej. Działającą część mam: te 43 workflow udostępnione agentowi to zamknięta lista tego, co model może u mnie wywołać, a licznik zaufania rozstrzyga uprawnienia osobno dla każdej operacji. Czego nie mam, to zapisu. Limit zasobów, warunki wycofania zaufania i powód, dla którego dana operacja awansowała, siedzą w mojej głowie, a nie w pliku. Przy jednej osobie wygląda to na formalność, ale brak zapisu jest dokładnie tym, co po roku staje się długiem intencji z punktu piątego.
10. Rachunek za tokeny i metryki biznesowe
Z konferencji: złożone pętle agentowe i brak kontroli nad zapytaniami windują opłaty za tokeny i chmurę, a mierzenie wydajności liczbą commitów albo wygenerowanych linii kodu jest błędne. Potrzebne są świadome zarządzanie kosztem, inteligentny routing modeli, czyli tańsze lub lokalne modele do prostych zadań i najdroższe do orkiestracji, oraz wskaźniki biznesowe w miejsce technicznych.
Jednostką tego rachunku nie jest abonament, lecz milion tokenów, ponieważ agent jest procesem w pętli i za każdym obrotem wysyła do modelu cały dotychczasowy kontekst, a nie samo nowe zdanie. Cennik i datę odczytu zestawiłem osobno, licząc, ile kosztują tokeny agenta AI. Routing mam zbudowany: bramę pełni LiteLLM pod adresem lokalnym na porcie 4000, a klienci nie znają adresu maszyny, która liczy modele, więc jej zmiana nie jest zmianą w kliencie.
I tu jest mój najbardziej nieprzyjemny pomiar z całego tego tekstu. Na 229 bloków modelu w moich 223 workflow dokładnie 10 pracuje na mojej maszynie, czyli cztery procent. Pozostałe 219 wysyła dane do cudzego centrum danych. Zbudowałem maszynę do lokalnego AI, zmierzyłem jej prędkości, postawiłem przed nią bramę i w warstwie, która wykonuje właściwą pracę, prawie z tego nie korzystam. Sam rachunek za maszynę policzyłem do końca: 900 EUR raz, około 2,90 EUR miesięcznie za prąd i zwrot po 53 miesiącach przy abonamencie 20 EUR miesięcznie. To nie jest rachunek, który wygrywa się ceną.
Debata dyrektorów i CIO: sześć wniosków menedżerskich
Debatę otwierającą moderował prof. SGH Andrzej Sobczak, a w panelu zasiedli Piotr Ciecierski (TVN), Wojciech Pozarzycki (DSV), Tomasz Żelski (Optima Logistics), Mariusz Gromada (Bank Millennium) i Barbara Płucienniczak (Bank Pekao). Poniższe sześć punktów to wnioski z całej dyskusji. Nie przypisuję żadnego z nich pojedynczej osobie i nikogo nie cytuję. W tej sekcji nie podaję ani jednej własnej liczby, bo jej nie mam: to wymiar organizacyjny, a mój pomiar pochodzi z laboratorium jednej osoby.
Transformacja zaczyna się od ludzi, nie od narzędzi. Udana adopcja wymaga podnoszenia kompetencji i kultury eksperymentowania, a nie zakupu. Drugie zdanie z tego samego punktu jest ostrzejsze: AI nie służy do przykrywania bałaganu procesowego. Najpierw ustrukturyzuj proces, potem włączaj agentów.
Kod stanieje, wzrośnie koszt złych decyzji. Ciężar finansowy i ryzyko przenoszą się na precyzyjne definiowanie wymagań, na kontekst architektoniczny i na bezpieczeństwo, bo to błędne decyzje funkcjonalne generują najwyższy koszt.
Granica autonomii wynika z apetytu na ryzyko. Agenci dobrze radzą sobie z analizą i rozwiązywaniem problemów, ale ile autonomii im oddać, zależy od branży i od tolerancji ryzyka w danym procesie. Kluczowe decyzje nadal podejmuje człowiek i nadal za nie odpowiada. To jest ten sam czwarty poziom, tylko opisany językiem zarządu.
Zintegrowane zespoły i język ekonomii w IT. Granica między IT a biznesem się zatarła. Osoby z technologii muszą opanować język ekonomiczny i mierzyć efekty wskaźnikami biznesowymi, takimi jak czas do klienta czy wpływ na rachunek zysków i strat, a biznes musi brać współodpowiedzialność za architekturę i jakość danych.
Dwa strumienie adopcji trzeba prowadzić równolegle. Z jednej strony duże inicjatywy z umocowaniem i ze sponsorem biznesowym, z drugiej oddolny ruch pracowników, który trzeba uporządkować lekkim nadzorem, zamiast go gasić. Bez tego powstają rozwiązania bez ciągłości utrzymania.
Mniejsze zespoły, a ciężar przenosi się na drożność dostarczania. Duże zespoły będą się zmniejszać, żeby kompetencje nie nakładały się na siebie i nie blokowały prac. Głównym wyzwaniem kadry zarządzającej staje się przepustowość całego procesu dostarczania, tak aby wygenerowany kod trafiał na produkcję bez pogłębiania długu technologicznego.
Co z tego zmieniam u siebie
Trzy rzeczy, każda sprawdzalna.
Spiszę paszport dla swojego agenta. Lista tych 43 udostępnionych workflow jako uprawnienia, limit zasobów i warunki wycofania zaufania, w pliku obok specyfikacji, a nie w pamięci.
Dociągnę routing do liczby, którą już znam. Cztery procent bloków na własnej maszynie to nie wynik decyzji, lecz wynik zaniechania. Celem nie jest sto procent, a świadomy podział: co musi zostać w domu, a co spokojnie może iść do chmury.
Zmierzę coś innego niż liczbę workflow. 223 to liczebnik, nie wynik. Dopóki nie potrafię powiedzieć, ile czasu ten system oszczędza, mierzę commity, tylko pod inną nazwą.
Konferencja nie dała mi ani jednej liczby, której wcześniej nie znałem. Dała mi nazwy dla dwóch rzeczy, których u siebie nie zapisałem: długu intencji i paszportu.
