Dlaczego Twój agent AI działa 50x wolniej, niż powinien

Różnica między deweloperem osiągającym 2x wartość z narzędzi AI a tym, który osiąga 100x, nie leży w modelu, którego używa. Leży w architekturze, która ten model otacza. Steve Yegge stwierdził na początku 2026 roku, że osoby korzystające z agentów AI do kodowania są od 10 do 100 razy bardziej produktywne niż te, które nadal używają interfejsów czatowych i autouzupełniania. Te same modele. Ta sama bazowa inteligencja. Zmienną jest struktura.

W ciągu jednego tygodnia w kwietniu 2026 roku pięciu niezależnych twórców opublikowało frameworki dotyczące architektury agentów AI. Garry Tan (Y Combinator), Andrej Karpathy, Viv Trivedy, Daniel Miessler oraz repozytorium społecznościowe, które zebrało 19 700 gwiazdek na GitHubie, zbiegły się na tej samej tezie: umieszczaj inteligencję w przenośnych plikach markdown, utrzymuj infrastrukturę orkiestracji jak najcieńszą, pozwól modelowi wykonywać rozumowanie. Ten artykuł opisuje, w czym się zgodzili, gdzie się różnią i co to oznacza dla każdego, kto buduje z AI.

Kluczowe wnioski

• Inteligencja należy do plików skill w markdown, nie do kodu frameworku. Skille są przenośne, wersjonowalne i automatycznie się poprawiają wraz z poprawą modelu.

• Harness powinien robić cztery rzeczy i nic więcej. Uruchamiać model w pętli, czytać i pisać pliki, zarządzać kontekstem, wymuszać bezpieczeństwo. Każda dodana funkcja ponad to pochłania kontekst i spowalnia rozumowanie.

• Pięciu twórców niezależnie opublikowało tę samą tezę w ciągu trzech dni (12 do 15 kwietnia 2026). Garry Tan, Andrej Karpathy, Viv Trivedy, Daniel Miessler oraz repozytorium społecznościowe z 19,7 tys. gwiazdek. Ta zbieżność jest sygnałem.

• LangChain się nie zgadza i ma benchmarki na poparcie swojego stanowiska. Harrison Chase argumentuje, że harness JEST produktem. Odpowiedź może zależeć od tego, czy budujesz narzędzia konsumenckie, czy pipeline'y enterprise.

• Instrukcje przepisowe wygasają. Kontekst nie. Każdy przewodnik krok po kroku napisany dla AI degraduje się wraz z kolejną wersją modelu. Kontekst o tym, kim jesteś i czego chcesz, narasta jak procent składany.

Cała architektura mieści się na kartce papieru

31 marca 2026 roku Anthropic przypadkowo opublikowało cały kod źródłowy Claude Code w rejestrze npm. 512 000 linii. Garry Tan go przeczytał. To, co znalazł, potwierdziło wzorzec, który od miesięcy wykładał w Y Combinator: przepaść produktywności nie dotyczy inteligencji modelu. Dotyczy tego, co model otacza.

Tan zebrał tę architekturę w trzy warstwy:

Zasada jest kierunkowa. Inteligencję przesuń w górę do skillów. Wykonanie pchnij w dół do deterministycznych narzędzi. Utrzymuj harness cienkim. 90% wartości żyje w warstwie skillów. Harness to dyrygent, który czyta pliki. Nie jest ich właścicielem.

Własne doświadczenie Tana ilustruje ten punkt. Jego osobisty CLAUDE.md zaczął od 20 000 linii. Każda szczególna cecha, każda konwencja, każda lekcja, z jaką kiedykolwiek się zetknął. Efekt: uwaga Claude Code zaczęła degradować. Model dosłownie powiedział mu, żeby go skrócił. Jego rozwiązaniem były 200 linii wskaźników do dokumentów ładowanych na żądanie. Pełne 20 000 linii wiedzy nadal istnieje. Ładują się tylko wtedy, gdy są istotne, zamiast zaśmiecać okno kontekstu przy każdej turze.

Jeśli budujesz narzędzia lub przepływy pracy oparte na AI dla swojej firmy, właściwe zaprojektowanie architektury od początku decyduje o tym, czy skończy się na demie robiącym wrażenie, czy systemie, który trafia na produkcję.

Pięć definicji oddziela twórców 100x od pozostałych

Architektura opiera się na pięciu konceptach. Pominięcie któregokolwiek sprawia, że system działa poniżej swojego potencjału.

1. Pliki skill

Skill to wielokrotnego użytku dokument markdown uczący model, jak coś zrobić. Nie co zrobić. Użytkownik dostarcza zadanie. Skill dostarcza proces. Działa jak wywołanie metody: ta sama procedura, różne argumenty, radykalnie różne wyjścia.

Przykład Tana: skill o nazwie /investigate ma siedem kroków (określ zakres zbioru danych, zbuduj oś czasu, diaryzuj każdy dokument, syntetyzuj, argumentuj po obu stronach, cytuj źródła). Skieruj go na naukowca zajmującego się bezpieczeństwem i 2,1 miliona e-maili odkrycia, a otrzymasz analityka badań medycznych. Skieruj go na spółkę-przykrywkę i dokumenty FEC, a otrzymasz śledczego finansowego. Te same siedem kroków. Wywołanie dostarcza świat.

2. Resolvery

Resolver to tabela routingu dla kontekstu. Kiedy pojawia się typ zadania X, załaduj najpierw dokument Y. Bez resolvera deweloper zmienia prompt i go wdraża. Z resolverem model najpierw czyta dokumentację zestawu ewaluacyjnego, uruchamia benchmarki i cofa zmiany, jeśli dokładność spada o więcej niż 2%. Deweloper nie wiedział, że zestaw ewaluacyjny istnieje. Resolver załadował właściwy kontekst we właściwym momencie.

3. Latentne a deterministyczne

Każdy krok w systemie jest jednym lub drugim. Mylenie ich to najczęstszy błąd w projektowaniu agentów. LLM może posadzić 8 osób przy stole kolacyjnym, biorąc pod uwagę ich osobowości. Poproś go o posadzenie 800 osób, a wygeneruje plan sadzenia, który wygląda wiarygodnie, ale jest całkowicie błędny. To problem deterministyczny wtłoczony do przestrzeni latentnej. Najlepsze systemy są bezwzględne w kwestii tej granicy.

4. Diaryzacja

Model czyta wszystko o danym podmiocie i tworzy ustrukturyzowany profil. Żadne zapytanie SQL tego nie produkuje. Żaden pipeline RAG tego nie produkuje. Model musi czytać, trzymać sprzeczności w głowie, zauważać co się zmieniło i kiedy, oraz syntetyzować ustrukturyzowaną inteligencję.

Zespół Tana zbudował system dla YC Startup School, który zarządza w ten sposób 6 000 profilami założycieli. Wynik diaryzacji wychwytuje rzeczy, których żadne wyszukiwanie po słowach kluczowych nie znajdzie: założyciel, który mówi "Datadog dla agentów AI", ale którego commity na GitHubie są w 80% kodem rozliczeniowym. Buduje narzędzie FinOps zamaskowane jako obserwowalność. Ta rozbieżność między "mówi" a "faktycznie buduje" wymaga jednoczesnego przeczytania historii commitów, aplikacji i transkryptu rozmowy z doradcą. Żadne wyszukiwanie podobieństwa embeddingów tego nie znajdzie.

5. Trwałe usprawnienia

Instrukcja Tana dla jego AI: "Jeśli poproszę Cię o zrobienie czegoś i jest to rodzaj rzeczy, który będzie musiał się powtarzać, skodyfikuj to w pliku skill. Jeśli ma się uruchamiać automatycznie, ustaw to na cronie. Jeśli musisz mnie o coś prosić dwa razy, to porażka." Każdy napisany skill to trwałe usprawnienie. Nigdy nie degraduje. Gdy pojawia się następny model, każdy skill natychmiast staje się lepszy. System narasta jak procent składany.

Pięć frameworków opublikowanych w jednym tygodniu mówi to samo

Zbieżność jest najsilniejszym sygnałem. Te pięć dorobków pojawiło się niezależnie między 12 a 15 kwietnia 2026 roku. Żaden z tych twórców nie współpracuje ze sobą. Doszli do tej samej architektury z różnych punktów wyjścia.

Tan doszedł tu po wdrożeniu 600 000 linii kodu produkcyjnego w 60 dni z gstack (ponad 23 000 gwiazdek GitHub w pierwszym tygodniu). Karpathy doszedł tu po debugowaniu trzech trwałych trybów awarii asystentów AI do kodowania. Trivedy doszedł tu po iterowaniu nad projektem harness przez ponad 30 wersji. Miessler doszedł tu po zastosowaniu gorzka lekcja Richarda Suttona do narzędzi AI.

Kiedy pięć niezależnych źródeł zbiega się na tej samej architekturze w ciągu 72 godzin, architektura jest prawdopodobnie właściwa.

LangChain się nie zgadza i ma benchmarki na poparcie

Harrison Chase (CEO LangChain) wypuścił Deep Agents w tym samym tygodniu i argumentował odwrotnie: harness JEST produktem. Wbudowane planowanie zadań, uruchamianie subaganetów, middleware, hooki, pełna infrastruktura orkiestracji. Jego dowód: zmiana tylko harness przeniosła DeepAgent LangChain z pozycji poza top 30 do top 5 na TerminalBench 2.0.

To nie jest marginalny sprzeciw. LangChain przetwarza miliony wywołań agentów dziennie. Ich benchmarki są publiczne. Prawdziwy podział: stanowisko Tana mówi, że każdy element logiki w harnessie ogranicza rozumowanie, które model mógłby sam wykonać. Im lepszy model, tym cieńszy powinien być harness. Stanowisko Chase'a mówi, że inżynieria harness rozszerza możliwości modelu, zamiast go zastępować.

Oba stanowiska mogą być poprawne w różnych kontekstach. Agenty konsumenckie i osobiste (gdzie przenośność i długowieczność mają znaczenie) faworyzują cienki harness. Pipeline'y enterprise (gdzie niezawodność i audytowalność mają znaczenie) mogą uzasadniać gruby harness. Żadna ze stron nie kwestionuje, że skille powinny być grube. Pytanie dla Twojego projektu nie brzmi, który obóz ma rację. Brzmi: po której stronie granicy leży Twój przypadek użycia.

Większość firm budujących funkcje AI po raz pierwszy powinna zacząć od cienkiego rozwiązania i dodawać infrastrukturę tylko wtedy, gdy natkną się na konkretne ściany niezawodności. Nie wiesz, gdzie leży Twój projekt? Porozmawiaj z naszym zespołem o tym, która architektura pasuje.

Twoje instrukcje wygasną. Twój kontekst nie.

Daniel Miessler opublikował najostrzejszą diagnozę tygodnia. Nazywa ją audytem inżynierii według gorzka lekcji, nawiązując do obserwacji Richarda Suttona z 2019 roku, że ogólne podejścia skalujące się wraz z obliczeniami konsekwentnie pokonują podejścia zakodowane ręcznie w dłuższej perspektywie.

Zastosowane do narzędzi AI: zła inżynieria harness to instrukcje przepisowe. "Najpierw skopiuj ten plik, potem załaduj to, potem zrób to, potem tamto." Mikromanagement krok po kroku wykonania AI. To podejście degraduje się wraz z mądrzejszymi modelami. Zbyt sztywne kroki uniemożliwiają modelowi stosowanie własnego rozumowania.

Dobra inżynieria harness jest kontekstowa. Kim jesteś, nad czym pracujesz, co chcesz osiągnąć, jak wygląda dobre i złe rozwiązanie. Tożsamość, gust, standardy, cele. Model sam wymyśla jak.

Diagnostyka Miessler jest prosta. Jeśli Twoja konfiguracja brzmi jak przepis (krok 1, krok 2, krok 3), to zła inżynieria harness. Jeśli brzmi jak dokument briefingowy (oto kim jestem, oto co jest ważne, oto narzędzia), to dobra inżynieria harness. Kontekst o tym, kim jesteś, nigdy nie wygasa. Instrukcje przepisowe stają się przestarzałe wraz z każdą poprawą modelu.

Architektura nie jest skomplikowana. Grube skille, cienki harness, bezwzględne rozdzielenie pracy latentnej i deterministycznej. Trudna jest dyscyplina: kodowanie osądu w wielokrotnego użytku skillach zamiast wykonywania jednorazowej pracy, utrzymywanie harness cienkim, gdy kusi, żeby dodawać funkcje, i zaufanie modelowi, że sam wymyśli "jak", gdy dasz mu właściwe "co" i "dlaczego".

W webvise budujemy systemy oparte na AI zgodnie z tymi zasadami architektonicznymi. Niezależnie od tego, czy potrzebujesz przepływu pracy agenta, zautomatyzowanego pipeline'u, czy integracji AI klasy produkcyjnej, architektura ma większe znaczenie niż model.