Jeden operator, flota agentów

Raport MIT Project NANDA z lipca 2025 dał światu liczbę 95 procent i zgubił po drodze zdanie o wiele ciekawsze. W ponad 90 procentach badanych firm pracownicy zgłaszali regularne używanie do pracy własnych narzędzi AI, choć oficjalną subskrypcję modelu językowego deklarowało tylko około 40 procent firm. Dostęp do tych samych modeli leży więc po obu stronach podziału na sukces i porażkę. Twierdzę, że przewaga jednoosobowego operatora z flotą agentów wyrasta z czegoś, czego nikt nie fakturuje: odpada u niego wewnętrzna warstwa uzgodnień między pracownikami, więc w wynik idzie większa część dźwigni niż w organizacji. Decyzja, która od tego zależy, jest twoja i niewygodna — czy zatrudnić następną osobę, czy kupić następny stopień autonomii dla agenta, którego już masz.

Liczba, która zmieniła jednostkę już w samym raporcie

Zespół MIT Project NANDA opublikował w lipcu 2025 raport The GenAI Divide: State of AI in Business 2025 (Aditya Challapally, Chris Pease, Ramesh Raskar, Pradyumna Chari). Podstawą był przegląd ponad 300 publicznie ujawnionych inicjatyw z AI. Do tego doszły wywiady z przedstawicielami 52 organizacji oraz 153 odpowiedzi ankietowe kadry kierowniczej, zebrane na czterech konferencjach branżowych; okres badania to styczeń–czerwiec 2025. Autorzy nazywają swoje ustalenia wstępnymi i zastrzegają, że sześciomiesięczny okres obserwacji mógł zaniżyć odsetek sukcesów wdrożeń długoterminowych. W jednym akapicie streszczenia raport pisze, że 95 procent organizacji nie ma zwrotu z AI. Pisze też, że tylko 5 procent zintegrowanych pilotaży przynosi korzyści liczone w milionach, a ogromna większość nie ma mierzalnego wpływu na rachunek wyników.

Pierwsze zdanie dotyczy organizacji, drugie pilotaży.

Różnica nie jest pedantyczna. Firma prowadząca dwadzieścia pilotaży, z których jeden zarabia, trafia jednocześnie do tych 5 procent i do reszty, więc drugie zdanie niewiele mówi o samej firmie. Dalej raport przypisuje liczbę 5 procent narzędziom enterprise oraz przedsiębiorstwom i nie podaje, z jakiej próby ją wyliczył. Zastrzega natomiast, że liczby są kierunkowo trafne i pochodzą z wywiadów indywidualnych, a nie z oficjalnego raportowania firm, oraz że wielkość prób zależy od kategorii. Ustalenia opierają się na wywiadach i odpowiedziach deklaratywnych, raport jest dokumentem inicjatywy i nie ukazał się jako recenzowany artykuł, a w aneksie są kwestionariusze, ale nie ma danych.

Nazwijmy ten mechanizm od razu: jednostka liczby zmienia się w jednym akapicie streszczenia, więc ten, kto ją cytuje, musi wybrać jedną z dwóch, a nikt po drodze nie kłamie.

W tym samym materiale stoi ustalenie, na którym opieram całą tezę. Autorzy piszą, że pracownicy z ponad 90 procent badanych firm zgłaszali regularne używanie osobistych narzędzi AI do pracy, i nazywają to szarą strefą AI. Proza mówi o firmach, a wykres na tej samej stronie odnosi te 90 procent do pracowników, czyli do innej jednostki, więc przyjmuję wersję firmową. Traktuję tę liczbę jako rząd wielkości, bo pochodzi z ankiety i wywiadów, nie z telemetrii. Rząd wielkości wystarczy. Jeśli w zdecydowanej większości badanych firm, także tych, których inicjatywy nie dowożą, ktoś sięga prywatnie po te same modele co ja, to dostęp do nich przestaje być zmienną wyjaśniającą cokolwiek. Nie dowodzi to, że ci pracownicy pracują dzięki temu lepiej. Raport twierdzi wprawdzie, że ta strefa często daje lepszy zwrot niż inicjatywy oficjalne, ale pomiaru nie pokazuje, a samo sięganie po narzędzie nie jest jeszcze wynikiem ani nawet zapowiedzią wyniku. Moim zdaniem bariera nie stoi po stronie dostępu.

Jest jeszcze trzecia obserwacja z tego raportu i jest najbardziej szydercza ze wszystkich. Raport pisze, że lepszy zwrot często dawała automatyzacja zaplecza, a jedne z najbardziej spektakularnych udokumentowanych oszczędności pochodzą z zastąpienia zewnętrznych usług i agencji. Tymczasem w hipotetycznym podziale budżetu, o który poproszono dyrektorów, sprzedaż i marketing brały około połowy, a w innym miejscu raportu około 70 procent. Wydatków nie zmierzono, więc to deklaracja o tym, dokąd poszłyby pieniądze, nie o tym, dokąd poszły. Wskazuje jednak w jedną stronę: sam raport wiąże budżetową przewagę frontu z tym, że jego wynik łatwiej przypisać i zobaczyć. Technologia nie rozstrzygnęła tu niczego. Deklarowany podział budżetu układał się według widoczności wyniku, a widoczność ustala ten, kto ten wynik zatwierdza.

Model: nakład na uzgodnienie rośnie kombinatorycznie

Frederick P. Brooks Jr. opisał ten rachunek w The Mythical Man-Month (Addison-Wesley, 1975), na podstawie własnej pracy przy systemie OS/360. Jeśli każdą część zadania trzeba osobno uzgodnić z każdą inną, nakład rośnie jak n(n−1)/2. Czterech ludzi to sześć kanałów. Dziesięciu to czterdzieści pięć. Pięćdziesięciu to tysiąc dwieście dwadzieścia pięć kanałów, przy czym nikt nie przydzielił nikomu doby dłuższej niż dwadzieścia cztery godziny. Stąd prawo Brooksa: dodanie ludzi do opóźnionego projektu programistycznego opóźnia go jeszcze bardziej.

Brooks dał model analityczny i obserwację z jednego przedsięwzięcia; badania na próbie nie przeprowadził.

Pokrewny związek między strukturą organizacyjną a jakością kodu zbadał Nachiappan Nagappan z Brendanem Murphym i Victorem Basilim w pracy The Influence of Organizational Structure on Software Quality (ICSE '08, Lipsk 2008). Autorzy wzięli dane z Windows Visty i sprawdzili, co przewiduje awaryjność pojedynczej binarki po wydaniu. Model z ośmiu metryk organizacyjnych osiągnął precyzję 86,2 procent i czułość 84,0 procent. Wśród tych metryk były liczba inżynierów, którzy dotknęli binarki i nadal pracują w firmie, liczba tych, którzy ją dotknęli i odeszli, głębokość własności kodu i liczba organizacji, z których każda wnosiła ponad 10 procent zmian. Wynik był wyższy niż w modelach zbudowanych na zmienności kodu, jego złożoności, pokryciu testami, zależnościach i liczbie błędów sprzed wydania.

Struktura organizacji przewidywała awaryjność lepiej niż metryki samego kodu. To studium przypadku jednego produktu jednej firmy i korelacja predykcyjna, nie eksperyment przyczynowy, a prawa Brooksa o opóźnianiu projektu ta praca nie bada. Autorzy sami piszą, że danych o tym związku było niewiele. Kierunek zgadza się z tezą Brooksa, że struktura organizacji wpływa na jakość.

Drugą ramę dał ekonomista. Ronald H. Coase w The Nature of the Firm („Economica”, 1937) zapytał, dlaczego firmy w ogóle istnieją, skoro rynek rzekomo alokuje zasoby sprawniej. Odpowiedź: korzystanie z mechanizmu cenowego kosztuje. Trzeba znaleźć kontrahenta, wynegocjować warunki, spisać umowę, wyegzekwować ją. Firma powstaje po to, żeby te transakcje przenieść do środka i zapłacić za nie mniej, a rośnie tak długo, aż koszt zorganizowania kolejnej transakcji w środku zrówna się z kosztem załatwienia jej na rynku.

Agenci obniżają jedną stronę tego równania, bo część uzgodnień między ludźmi przestaje być potrzebna. Firma jednej osoby może więc wziąć do środka pracę, która dotąd wymagała zatrudnienia, i to jest cały rachunek ekonomiczny, na którym stoi moje jednoosobowe studio produktowe z flotą agentów. Coase ma jednak drugą stronę, o której się w tekstach o AI milczy: opisał też malejącą sprawność przedsiębiorcy przy rosnącej liczbie transakcji. Jedna głowa ma przepustowość. Agent nie dokłada głowy, tylko ręce.

Brakujące ogniwo znalazłem u Nicholasa Blooma, Luisa Garicano, Raffaelli Sadun i Johna Van Reenena w artykule The Distinct Effects of Information Technology and Communication Technology on Firm Organization („Management Science” 60(12), 2014). Rozdzielili dwie rzeczy, które zwykle wrzuca się do jednego worka pod nazwą „cyfryzacja”. Technologia informacyjna daje wiedzę temu, kto jest na dole, i zwiększa jego autonomię decyzyjną. Technologia komunikacyjna tanio przesyła informację do góry i decyzję centralizuje.

To rozstrzyga spór o to, czy narzędzie samo skraca pętlę decyzyjną. Nie skraca. Skraca ją wtedy, gdy wiedza ląduje u tego, kto decyduje. U jednoosobowego operatora te dwie osoby są tą samą osobą z definicji, więc każde narzędzie działa u niego jako technologia informacyjna. W organizacji ten sam agent bardzo często pracuje jako technologia komunikacyjna: produkuje materiał na kolejne uzgodnienie, slajd na kolejny przegląd, uzasadnienie do kolejnego wniosku budżetowego.

Ostatni element układanki dołożyli Oriana Bandiera, Andrea Prat, Stephen Hansen i Raffaella Sadun w CEO Behavior and Firm Performance („Journal of Political Economy” 128(4), 2020). Zebrali dzienniki czasu 1114 prezesów w sześciu krajach i sklasyfikowali ich zachowania bez zakładania kategorii z góry. Wyszły dwa typy. Jedni siedzą na spotkaniach wielofunkcyjnych i wysokiego szczebla, drudzy na rozmowach jeden na jeden z funkcjami rdzeniowymi. Firmy pierwszego typu radzą sobie lepiej, tyle że efekt widać dopiero po trzech latach, a sami autorzy przypisują różnicę dopasowaniu stylu do firmy, nie wyższości jednego typu nad drugim.

Mnie interesuje coś, czego autorzy nie musieli podkreślać, bo dla nich było oczywiste. Materiałem pracy prezesa jest spotkanie. Nie z lenistwa. W organizacji uzgodnienie po prostu jest pracą, a najdroższa godzina w firmie idzie w to, żeby dwie inne godziny mogły ruszyć.

Mechanizm: czego agent nie robi i co za to zabiera

Weźmy dowolne zadanie, które w organizacji przechodzi przez trzy piony. Policzmy, co się z nim po drodze dzieje.

Ktoś musi zdefiniować zakres. Ktoś inny musi go zaakceptować, bo to on odpowiada za budżet. Trzecia osoba sprawdzi, czy zadanie nie narusza niczego, za co ona odpowiada. Czwarta zapyta, czemu nie zrobiono tego w jej zespole. Każda z tych osób wnosi do sprawy prawdziwą wiedzę i prawdziwy interes, i żadna nie jest złoczyńcą. Wszystkie razem produkują koszt, którego nikt nie księguje, bo koszt uzgodnienia nie ma pozycji w planie kont.

Teraz to samo zadanie u operatora z agentem. Agent nie negocjuje zakresu. Nie broni budżetu, bo nie ma budżetu do obrony. Nie ma kariery, którą mógłby przy tej okazji zabezpieczyć, nie ma pionu, którego interes reprezentuje, i nie musi wyglądać na zajętego w kwartale, w którym akurat nie ma czego dowozić. Dostaje polecenie i albo dowozi wynik, albo nie dowozi. Nie twierdzę przy tym, że uzgodnienia w organizacji są zbędne, bo spora ich część istnieje po to, żeby ktoś w porę powiedział „nie”, i tej funkcji agent nie pełni.

Praca, która w programie enterprise rozkłada się na uzgodnienia, u jednoosobowego operatora zostaje pracą.

W tym jednym zdaniu upatruję przyczyny dysproporcji widocznej w liczbach NANDA i nie potrzebuję do tego założenia, że w korporacjach pracują gorsi ludzie. Pracują tam zwykle lepsi. Mają lepsze dane, lepszą infrastrukturę i większe budżety na tokeny, niż ja kiedykolwiek będę miał. Mają też więcej ludzi, którzy muszą się ze sobą dogadać, zanim decyzja stanie się wynikiem, a liczba możliwych par rośnie jak n(n−1)/2.

Zmierzmy tę pętlę, bo bez liczby zostaje ładne zdanie. Decyzja o zmianie ceny w moim studiu wymaga sprawdzenia dwóch rzeczy: czy nowa cena pokrywa koszt obsługi i czy nie psuje zobowiązań wobec obecnych klientów. Godzina, czasem dwie. W organizacji ta sama decyzja przechodzi przez właściciela produktu, finanse, prawnika i komunikację, a żaden z nich nie pracuje nad nią w trybie ciągłym. Czas kalendarzowy liczy się wtedy w tygodniach, choć suma roboczogodzin bywa podobna do mojej. Nakład wychodzi porównywalny. Kalendarz nie wychodzi porównywalny wcale.

Uczciwość każe zaraz dopisać drugą stronę tego bilansu, bo jest równie mechaniczna. Firma nie utrzymuje tych kanałów z upodobania do spotkań. Utrzymuje je, bo dają rzeczy, których pojedyncza osoba nie kupi za żadne pieniądze. Kapitał, który pozwala przeżyć osiemnaście miesięcy bez przychodu. Dystrybucję, czyli gotową listę klientów, do których wystarczy zadzwonić. Zaufanie instytucjonalne, czyli to, że dział zakupów w banku w ogóle otworzy ofertę. I ciągłość: jeśli osoba prowadząca projekt trafi do szpitala, projekt idzie dalej.

Ta sama cecha, która zdejmuje z jednoosobowego studia wewnętrzną warstwę uzgodnień, odbiera mu wszystkie cztery. Nie da się mieć jednego bez drugiego, bo to jest ten sam parametr widziany z dwóch stron. Kto tego nie policzy przed, a nie po, sprzedaje sobie bajkę o wolności.

Dźwignia jest wąskopasmowa, a szerokość pasma da się zmierzyć

Obie liczby kładę na stół, także tę niewygodną.

Kontrolowany eksperyment opisali Sida Peng, Eirini Kalliamvakou, Peter Cihon i Mert Demirer (The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590, 2023). Zadaniem było napisanie serwera HTTP w JavaScripcie. Uczestnicy dostali szablon repozytorium z opisem zadania i szkieletem kodu, a ukończenie sprawdzał zestaw dwunastu testów. Wśród tych, którzy zadanie ukończyli, grupa z asystentem skończyła o 55,8 procent szybciej, a przedział ufności sięgał od 21 do 89 procent. Odnotujmy przy tym, że współautorami są pracownicy producenta narzędzia.

Teraz drugie badanie. Zespół METR pod kierunkiem Joela Beckera i Nate'a Rusha przeprowadził randomizowany eksperyment (Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, arXiv:2507.09089, 2025). Losowanie szło na poziomie zadania: szesnastu doświadczonych deweloperów open source, 246 zadań w dojrzałych repozytoriach, w których mieli średnio pięć lat stażu. Przed badaniem uczestnicy prognozowali skrócenie czasu o 24 procent. Po badaniu oceniali, że pracowali o 20 procent szybciej.

Pomiar pokazał, że byli o 19 procent wolniejsi.

Rozstrzał między samooceną a pomiarem wyniósł trzydzieści dziewięć punktów procentowych. Przedział ufności dla tego spowolnienia sięgał od plus dwóch do plus trzydziestu dziewięciu procent, a próba liczyła szesnaście osób z jednej populacji, więc nie jest to wyrok na branżę. Jest to natomiast najlepiej udokumentowany przypadek, w którym praktycy mylili się co do własnej prędkości, pracując przy tym własnymi rękami.

Najuczciwszy ruch w tej całej historii wykonali sami autorzy. W lutym 2026 METR opublikował notatkę o zmianie projektu eksperymentu. Dane z nowszej rundy, rozpoczętej w sierpniu 2025, uznał za niewiarygodny sygnał, głównie dlatego, że coraz więcej deweloperów nie chciało brać udziału w badaniu bez AI. Napisał też, że deweloperzy przyspieszają dziś prawdopodobnie bardziej niż w 2025 roku. Surowe wyniki tej rundy to zmiana czasu pracy o minus 18 procent dla tych z pierwotnych deweloperów, którzy wzięli udział w nowszej rundzie, i o minus 4 procent dla nowo rekrutowanych. Minus oznacza tu krótszy czas, a przedziały w obu wypadkach przechodzą przez zero. Autorzy nazwali to bardzo słabym dowodem na to, o ile przyspieszenie wzrosło od 2025 roku. Do tego od 30 do 50 procent ankietowanych deweloperów przyznało, że nie zgłasza niektórych zadań, nie chcąc robić ich bez AI. Brakuje więc zadań o wysokim spodziewanym uzysku, a nota traktuje te szacunki jako prawdopodobne zaniżenie.

Oba badania różnią się niemal wszystkim naraz. W Copilocie z 2022 roku pracował model Codex, a 95 freelancerów z Upworka robiło jedno standardowe zadanie z gotowego szablonu, a ukończyło je 35. W badaniu METR z 2025 roku działał głównie Cursor Pro z modelami Claude 3.5 i 3.7 Sonnet, a szesnastu doświadczonych opiekunów dużych repozytoriów robiło 246 własnych zadań. Różnią się model, narzędzie, uczestnicy, zadanie, miara i rok, więc z samego zestawienia nie wynika, co odwróciło znak wyniku. METR podejrzewa tu doświadczenie w repozytorium i jego rozmiar. Sam jednak ocenia ten dowód jako sugestywny, ale niepewny. Mam własną hipotezę, choć nic tu jej nie dowodzi: znak mogła zmienić klasa zadania. Inaczej pracuje się nad zadaniem świeżym i weryfikowalnym, a inaczej nad osadzonym w dojrzałym systemie z rozproszonym kontekstem, gdzie doświadczony deweloper po prostu wie lepiej. Zanim więc policzysz swoją dźwignię, nazwij klasę zadania, którą mierzysz.

Jak zbudować flotę

Flota agentów nie sprowadza się do liczby subskrypcji. Rozstrzyga o niej podział zadań na te, które puszczasz bez patrzenia, i te, które sprawdzasz przed każdym użyciem. Reszty nie oddajesz wcale.

W praktyce flota wygląda u mnie prościej, niż sugeruje samo słowo. Kilka równoległych sesji, każda z własnym zakresem i własnym plikiem reguł, żadna nie wie o pozostałych. Tak jest celowo. W chwili, w której dwa agenty muszą się dogadać co do wspólnego kontekstu, wracam do rachunku Brooksa, tyle że płaconego w tokenach i w moim czasie na scalanie sprzecznych wyników. Dlatego dzielę pracę po granicach, które i tak są rozdzielne: osobne repozytorium albo osobny dokument.

Podstawę liczbową dają pomiary METR z pracy Measuring AI Ability to Complete Long Software Tasks (arXiv:2503.14499, 2025). Metryka nazywa się horyzontem zadaniowym: to najdłuższe zadanie, które model kończy z pięćdziesięcioprocentową skutecznością, mierzone czasem ludzkiego eksperta. Horyzont podwajał się mniej więcej co siedem miesięcy od 2019 roku. Dla modelu z początku 2025 wynosił około pięćdziesięciu minut.

Liczba, która naprawdę steruje decyzją o autonomii, jest jednak inna. Horyzont dla osiemdziesięciu procent skuteczności jest około pięciokrotnie krótszy — dla tego samego modelu mówimy o mniej więcej dziesięciu minutach. W nocie o ograniczeniach ze stycznia 2026 autorzy dopowiadają resztę. Słupki błędu rozciągają się typowo dwukrotnie w każdą stronę, horyzonty różnią się o rzędy wielkości między domenami, a zadania krytyczne dla niezawodności i słabo weryfikowalne wymagają skuteczności powyżej 98 procent. Podwojenie horyzontu nie podwaja stopnia automatyzacji, bo awarie dłuższych zadań są bardziej złożone i kosztują więcej ludzkiej pracy przy naprawie.

Autonomia nie skaluje się więc z mocą modelu. Skaluje się z niezawodnością, której wymaga klasa zadania — a tę wyznaczasz ty, nie dostawca.

Z tego wychodzi kryterium delegowania, które u mnie zastąpiło wszystkie wcześniejsze heurystyki. Odwracalność razy weryfikowalność. Pytanie brzmi nie „czy model da radę”, tylko „ile kosztuje cofnięcie, jeśli nie da, i czy w ogóle zauważę”. Stopniowaną autonomię i mechanikę degradowania agenta, który zaczął się mylić, rozpisałem osobno w degradacjach agentów; tutaj zostawiam sam szkielet decyzyjny.

Kryterium odebrania zadania agentowi jest krótsze od tabeli. Jeśli weryfikacja wyniku kosztuje cię więcej niż samodzielne wykonanie, odbierz mu je. Zrób tę rzecz własnymi rękami. To jest ta sama pułapka, w którą wpadli doświadczeni deweloperzy z badania METR: dostali pomoc przy wykonaniu i zapłacili za nią między innymi czasem przy sprawdzaniu. Rachunku nie zauważyli. Reguła działa też w drugą stronę i wtedy jest przyjemniejsza. Tam, gdzie weryfikacja jest tania i natychmiastowa, flota daje najwięcej.

Zostaje weryfikacja, czyli miejsce, gdzie jednoosobowe studio najczęściej sobie kłamie. Operator jest złym czujnikiem własnej prędkości; pokazał to rozstrzał trzydziestu dziewięciu punktów u METR. Jest też złym czujnikiem własnej jakości. Veracode w zestawieniu 2025 GenAI Code Security Report przepuścił ponad sto modeli przez osiemdziesiąt zadań programistycznych w czterech językach. Wynik: 45 procent próbek kodu wprowadziło podatność z listy OWASP Top 10, czyli z kanonu najczęstszych błędów bezpieczeństwa w aplikacjach internetowych. Java wypadła najgorzej, z porażką w 72 procentach przypadków. Podatność typu cross-site scripting, czyli wstrzyknięcie cudzego skryptu na stronę, została bez zabezpieczenia w 86 procentach odpowiednich próbek. To benchmark firmy, która sprzedaje skanery kodu, więc ma interes w takim wyniku — metodologia jest jednak jawna, a kierunek zgodny z tym, co widać w praktyce.

Stąd reguła, której u siebie nie negocjuję: oceniam wynik. Nie interesuje mnie, czy agent „wyglądał na pewnego” ani ile kroków rozumowania pokazał. Interesuje mnie zielony test, przeczytana zmiana w kodzie, sprawdzona liczba i skan bezpieczeństwa, który przeszedł. Dlaczego pomiar bije ceremonię, rozbierałem w governance bez teatru, więc tu wystarczy wniosek operacyjny: bramka, której nie da się oblać, nie jest bramką.

Zastrzeżenia należą się też mojej własnej regule. Po pierwsze, weryfikacja wyniku działa tylko tam, gdzie wynik ma postać sprawdzalną w skończonym czasie, a duża część pracy, którą ludzie nazywają strategią, takiej postaci nie ma. Tam flota jest bezużyteczna. Po drugie, ocena samego wyniku wystarcza tylko tam, gdzie błąd da się cofnąć po fakcie. Jeśli w trakcie pracy agent może ujawnić dane albo wykonać krok nieodwracalny, ocena wyniku przychodzi za późno, więc obowiązuje wiersz tabeli, w którym agent przygotowuje, a wykonuję ja.

Na koniec rzecz, której nie oddaję agentowi nigdy. Akurat tej listy nie musiałem wymyślać, bo prawodawca unijny spisał ją dla systemów wysokiego ryzyka. Artykuł 14 rozporządzenia (UE) 2024/1689 o sztucznej inteligencji wymaga, by taki system był zaprojektowany z myślą o nadzorze sprawowanym przez osoby fizyczne. Osoby wyznaczone do tego nadzoru mają, w stosownym i proporcjonalnym zakresie, móc zrozumieć system i pozostać świadome możliwej skłonności do automatycznego polegania na jego wyniku. W tym samym zakresie mają też umieć poprawnie zinterpretować ten wynik. W tym samym zakresie mają móc zdecydować o nieskorzystaniu z systemu albo o odwróceniu jego wyniku, a także go zatrzymać. Wymogi dla systemów wysokiego ryzyka będą stosowane od 2 grudnia 2027 (załącznik III) i od 2 sierpnia 2028 (załącznik I), po odroczeniu z 2026 roku. Nie każdy agent jest takim systemem. Traktuję więc ten przepis jako wzorzec rozumowania i nie wywodzę z niego własnego obowiązku. Nadzór jest tam przypisany osobom fizycznym. Żadna procedura ani drugi agent nie przejmą tej roli.

Sufit, ryzyko koncentracji i warunek falsyfikacji

Zacznijmy od rozkładu, którego moja teza nie opisuje. US Census Bureau podało w maju 2025, że w roku referencyjnym 2022 w Stanach Zjednoczonych działało 29,8 miliona firm bez płatnych pracowników, a ich łączne przychody wyniosły 1,7 biliona dolarów. To średnio około 58 tysięcy dolarów na firmę rocznie, licząc z niezaokrąglonych danych. W łącznym zestawieniu Census, obejmującym firmy z pracownikami i bez, za ten sam rok było 35,7 miliona firm i 51,7 biliona dolarów przychodów. Firmy bez płatnych pracowników to więc około 83 procent firm i około 3,3 procent przychodów.

W 2022 roku pięć na sześć amerykańskich firm nie miało płatnych pracowników. I razem robiły jedną trzydziestą obrotu.

Model jednoosobowy skaluje się w liczbie, nie w wolumenie. W tych zestawieniach Census nie podaje mediany przychodów, ale z jego klas wielkości wynika, że około 61 procent takich firm miało przychody poniżej 25 tysięcy dolarów, a około 38 procent poniżej 10 tysięcy. Około 87 procent to działalności indywidualne (sole proprietorships), a reszta to spółki osobowe i kapitałowe. Firma bez płatnych pracowników nie zawsze oznacza więc jedną osobę. Census zaznacza też, że nie musi to być główne źródło dochodu właściciela. Typowy przedstawiciel tej grupy nie jest studiem produktowym z flotą agentów. Ten esej opisuje górny ogon rozkładu i musi to powiedzieć wprost, bo inaczej jest opowieścią zwycięzcy o sobie samym.

Drugi sufit wynika z regulacji. Rozporządzenie (UE) 2022/2554, znane jako DORA, obowiązuje od 17 stycznia 2025. Artykuły 28–29 każą podmiotowi finansowemu ocenić przed podpisaniem umowy na usługi technologii informacyjno-komunikacyjnych, czy umowa wzmacnia ryzyko koncentracji, a przy usługach wspierających funkcje krytyczne lub ważne także czy dostawcę da się łatwo zastąpić. Do tego dochodzą rejestr wszystkich zawartych umów oraz, dla takich usług, strategie wyjścia. Rozporządzenie nie wyklucza dostawcy jednoosobowego. Ocena zastępowalności dotyczy jednak także jego, a moja interpretacja, której w przepisie nie ma, idzie dalej: dostawca będący jedną osobą jest dla tej oceny oczywistym czynnikiem ryzyka. Na części rynków ciągłość jest produktem, więc jednoosobowość może przesądzać o wyniku rozmowy o zakupie.

Artykuł 14 rozporządzenia o sztucznej inteligencji, który przed chwilą dał mi listę rzeczy nieoddawanych agentowi, tnie tu w drugą stronę, o ile studio dostarcza albo uruchamia system wysokiego ryzyka. Obowiązki nadzorcze (art. 14 i 26) i dokumentacyjne (między innymi art. 11) są wtedy kosztem stałym. Koszt stały jest regresywny wobec wielkości: korporacja rozkłada go na dział, a jednoosobowe studio płaci z tej samej doby, z której ma robić produkt. Im więcej regulacji wchodzi w moją klasę zadań, tym węższe robi się pasmo, w którym mam przewagę.

Trzeci zarzut jest techniczny i dotyczy samej floty. Anthropic opisał w czerwcu 2025, jak zbudował wieloagentowy system badawczy: układ z modelem prowadzącym i podagentami pobił pojedynczego agenta o 90,2 procent na wewnętrznej ewaluacji. Rachunek za to jest jawny w tym samym tekście. Agenci zużywają około czterokrotnie więcej tokenów niż zwykła rozmowa, a systemy wieloagentowe około piętnastokrotnie. Autorzy wskazują też klasę zadań, w której zrównoleglenie szkodzi: wszędzie tam, gdzie wszyscy agenci potrzebują tego samego kontekstu albo gdzie zależności między nimi są gęste, jeden agent z długim kontekstem bije pięciu.

Rachunek Brooksa nie znika przy przejściu na agentów. Wraca jako faktura za tokeny.

Różnica wobec organizacji jest realna, ale trzeba ją nazwać precyzyjnie. U mnie koszt uzgodnienia jest pieniężny i rozliczalny tego samego dnia, bo widzę go w rachunku za interfejs programistyczny. W organizacji jest czasowy i polityczny, a księgowość go nie widzi. To różnica rodzaju i widoczności, a uzgodnienie z agentami nadal kosztuje.

Najtrudniejszy zarzut dotyczy mojej głowy. Jednoosobowa pętla decyzyjna jest szybka i nieodporna na błąd pojedynczej osoby. W organizacji sprzeciw bywa jedyną działającą bramką jakości, i to nawet wtedy, gdy jest motywowany politycznie — zła intencja też potrafi wyłapać dziurę w rozumowaniu. U mnie nikt się nie sprzeciwi, bo nie ma komu. Zastępuję ten sprzeciw trzema rzeczami i wiem o każdej z nich, że jest słabsza od żywego oponenta. Bramka pomiarowa zwraca liczbę niezależną ode mnie. Agent uruchamiany wyłącznie w roli oponenta dostaje gotowy materiał i ma zadanie go rozbić. Ruchu nieodwracalnego nie wykonuję tego samego dnia, w którym go wymyśliłem. Kto twierdzi, że taki zestaw jest pełnym ekwiwalentem zespołu, kłamie.

Ostatni zarzut trafia w sam gatunek tego tekstu i nie umiem go zbić. Manifesty pisze ten, komu wyszło. Gdyby moje studio padło w zeszłym roku, nie czytałbyś eseju o tym, ile daje brak wewnętrznej warstwy uzgodnień, tylko o tym, dlaczego jednoosobowość jest pułapką. Ten drugi esej miałby równie dobre źródła, bo materiał na obie tezy leży w tych samych badaniach, które przed chwilą przeczytałeś. Błędu przeżywalności nie da się usunąć lepszym pisaniem. Można go nazwać i podać warunek, po którym poznasz, że autor się mylił.

I dlatego manifest kończę warunkiem, który pozwala mi się pomylić w sposób sprawdzalny. Teza upada, jeśli w ciągu dwunastu miesięcy zespół w programie enterprise dowiezie w tej samej klasie zadań — weryfikowalnych i odwracalnych, bez wymogu podpisu instytucji — wynik porównywalny jakościowo w porównywalnym czasie kalendarzowym. Upada też drugą drogą: jeśli moje studio przegra dlatego, że dźwignia agentów wymagała więcej weryfikacji, niż zaoszczędziła wykonania. Ten drugi człon nie jest ozdobą. To ten sam rodzaj wyniku, który METR zmierzył u doświadczonych deweloperów w 2025 roku, choć dziś METR oznacza go jako nieaktualny; nie mam powodu zakładać, że mnie omija.

Po co to piszę

Nie prowadzę studia jednoosobowego dlatego, że mam lepsze modele. Mam te same, do których dostęp ma każda korporacja z budżetem, a prawdopodobnie gorszą infrastrukturę wokół nich. Prowadzę je dlatego, że w wąskim paśmie zadań, które umiem zweryfikować i cofnąć, moja pętla decyzyjna trwa tyle, ile trwa moja decyzja, i nikt nie musi jej po drodze zatwierdzić.

Poza tym pasmem przegrywam z zasobami i przegrywam zasłużenie.

Jeśli prowadzisz program w dużej organizacji, nie kupuj z tego eseju wniosku, że twoi ludzie są problemem. Nie są. Policz zamiast tego, ilu ludzi musi się dogadać w twojej typowej decyzji, i wstaw tę liczbę jako n do wzoru Brooksa: wyjdzie liczba par, które mogą się rozjechać. Potem sprawdź jedno: czy agent, którego właśnie wdrażasz, daje wiedzę temu, kto decyduje, czy tylko produkuje materiał na kolejny przegląd?

Bibliografia

1. Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley 1975 (wydanie rocznicowe 1995) — prawo Brooksa i rachunek n(n−1)/2 dla parami uzgadnianej komunikacji. Model analityczny z obserwacji przy OS/360, nie badanie z próbą.
2. Ronald H. Coase, The Nature of the Firm, „Economica”, N.S. 4(16), 1937, s. 386–405 — koszty transakcyjne jako powód istnienia firmy i wyznacznik jej granicy, wraz z tezą o malejącej sprawności przedsiębiorcy. Nagroda Nobla 1991 między innymi za ten tekst.
3. Nachiappan Nagappan, Brendan Murphy, Victor Basili, The Influence of Organizational Structure on Software Quality: An Empirical Case Study, ICSE '08 (także Microsoft Research TR-2008-11) — model z ośmiu metryk organizacyjnych przewidujący awaryjność binarek Windows Vista po wydaniu. Studium przypadku jednego produktu jednej firmy, predykcja bez identyfikacji przyczynowej, a nie test prawa Brooksa o opóźnianiu projektu.
4. Nicholas Bloom, Luis Garicano, Raffaella Sadun, John Van Reenen, The Distinct Effects of Information Technology and Communication Technology on Firm Organization, „Management Science” 60(12), 2014, s. 2859–2885 — rozdzielenie technologii informacyjnej od komunikacyjnej i przeciwne kierunki ich wpływu na autonomię decyzyjną. Ekonometria na danych World Management Survey, identyfikacja instrumentowana.
5. Oriana Bandiera, Andrea Prat, Stephen Hansen, Raffaella Sadun, CEO Behavior and Firm Performance, „Journal of Political Economy” 128(4), 2020, s. 1325–1369 — dzienniki czasu 1114 prezesów w sześciu krajach, klasyfikacja nienadzorowana, typy „leaders” i „managers”.
6. METR — dwie prace pomiarowe wraz z autorskimi zastrzeżeniami. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Joel Becker, Nate Rush i in., arXiv:2507.09089, 2025; wpis METR): randomizowany eksperyment, prognoza −24%, samoocena −20%, pomiar +19% czasu pracy; w nocie We are Changing our Developer Productivity Experiment Design z lutego 2026 autorzy uznali dane z nowszej rundy za niewiarygodny sygnał z powodu selekcji (część deweloperów i zadań wypadła, bo nie chciano pracować bez AI), a wpis z 2025 roku ma adnotację, że jego wyniki są nieaktualne. Measuring AI Ability to Complete Long Software Tasks (arXiv:2503.14499, 2025) wraz z notą o ograniczeniach metryki ze stycznia 2026: horyzont zadaniowy przy 50% i 80% skuteczności oraz próg 98% dla zadań krytycznych dla niezawodności i słabo weryfikowalnych.
7. Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590, 2023 — standardowe zadanie (serwer HTTP w JavaScripcie, szablon repozytorium z dwunastoma testami) ukończone o 55,8% szybciej przez grupę z Copilotem wśród tych, którzy je ukończyli; 95 freelancerów (zadanie ukończyło 35), model Codex. Współautorstwo producenta narzędzia odnotowane w tekście eseju.
8. US Census Bureau, Census Bureau Releases Demographic Characteristics of Nonemployer Business Owners, komunikat z 8 maja 2025, rok referencyjny 2022 — 29,8 mln firm bez płatnych pracowników i 1,7 bln USD przychodów oraz łączne zestawienie 35,7 mln firm z 51,7 bln USD przychodów (Annual Business Survey i Nonemployer Statistics by Demographics). Średnia, udziały form prawnych i klas wielkości przychodów to moje obliczenia na danych Nonemployer Statistics 2022 (wydanie z grudnia 2024, plik nonemp22us); definicje wg FAQ. Dane administracyjne z zeznań podatkowych, zasięg Stany Zjednoczone; Census zaznacza, że działalność nie musi być głównym źródłem dochodu właściciela, a próg 1000 USD przychodów (w budownictwie 1 USD) współwyznacza populację.
9. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA), art. 28–29 — ocena ryzyka koncentracji ICT, rejestr umów i strategie wyjścia; stosowane od 17 stycznia 2025.
10. Rozporządzenie (UE) 2024/1689 (akt o sztucznej inteligencji), art. 14 — wymogi nadzoru człowieka nad systemem wysokiego ryzyka; w mocy od 1 sierpnia 2024. Rozporządzenie (UE) 2026/1744 (Digital Omnibus on AI) zmieniło terminy stosowania (art. 113): dla systemów wysokiego ryzyka od 2 grudnia 2027 (załącznik III) i od 2 sierpnia 2028 (załącznik I), zob. wersja skonsolidowana. Stan na 11 października 2026.
11. Aditya Challapally, Chris Pease, Ramesh Raskar, Pradyumna Chari (MIT Project NANDA), The GenAI Divide: State of AI in Business 2025, lipiec 2025 (plik v0.1, ustalenia wstępne) — raport inicjatywy badawczej, nie artykuł recenzowany; wywiady, ankieta i przegląd inicjatyw, wyniki w znacznej mierze samo-raportowane; w aneksie są kwestionariusze, nie dane. Liczby 95% i 5% wg sformułowań ze s. 3, a 90% i 40% wg prozy ze s. 8; wykres na s. 8 opisuje te 90% jako pracowników.
12. Anthropic, How we built our multi-agent research system, materiał inżynierski, czerwiec 2025 — przewaga 90,2% układu wieloagentowego, koszt piętnastokrotny w tokenach, klasa zadań nieodpowiednia dla floty. Ewaluacja wewnętrzna producenta, kierunek wiarygodny, wielkość nieodtwarzalna z zewnątrz.
13. Veracode, 2025 GenAI Code Security Report, aktualizacja z października 2025 — 45% próbek kodu z podatnością z OWASP Top 10, ponad 100 modeli, 80 zadań. Benchmark producenta skanerów kodu: metodologia jawna, interes komercyjny w takim wyniku odnotowany.