O czym jest ten film
- Dlaczego benchmarki kodowania (SWE-bench i pochodne) nie mierzą tego, co naprawdę ważne — jakości i utrzymywalności kodu.
- Czym jest „fabryka oprogramowania” i co się zmienia, gdy w miejsce człowieka budującego funkcję wstawimy agenta.
- Dlaczego przegląd kodu stał się głównym wąskim gardłem i co realnie pomaga go skrócić.
- Krytyka „lekkiej fabryki oprogramowania”, w której człowiek w ogóle nie czyta kodu — z opisem konkretnej porażki, jaka spotkała zespół Dexa.
- Czterowarstwowy proces przygotowania przed uruchomieniem agenta: produkt → architektura systemu → program design → pionowe plastry.
- Dlaczego decyzje podjęte przy 40 tysiącach tokenów są tańsze niż poprawki po napisaniu tysięcy linii kodu.
- Rola mierzalnego celu jako „ciśnienia zwrotnego” dla agenta — od LLM jako sędziego po realne metryki biznesowe.
- Praktyka wciągania do repozytorium wszystkiego, co dotąd żyło w głowach ludzi: ADR-y, konfiguracja zewnętrzna, kontekst produktowy.
- Historia terminu context engineering, „strefa głupoty” w oknie kontekstowym i dlaczego optymalizacja tokenów bywa pozorną poprawą.
- Teoria ograniczeń zastosowana do pracy z agentami: nie każda nieefektywność jest wąskim gardłem.
Redakcyjne tłumaczenie
Wprowadzenie
David Ondrej: To jest Dexter, znany też jako Dex. To on ukuł termin context engineering i to on zbudował fabrykę oprogramowania, w której agenty AI pracowały przez cztery miesiące bez żadnej ingerencji człowieka. W tym odcinku rozmawiamy o tym, dlaczego benchmarki nie mają znaczenia, o jego autorskim systemie projektowania programu i o tym, dlaczego pull requesty są martwe. Jeśli chcesz należeć do jednego procenta najlepszych inżynierów pracujących z agentami — obejrzyj do końca.
(Informacja dodatkowa: Dex Horthy jest współzałożycielem HumanLayer, firmy budującej narzędzia do pracy z agentami kodującymi. Wcześniej pracował m.in. w NASA — stąd tytuł odcinka).
Benchmarki mierzą nie to, co trzeba
David: Miałeś przemyślenie, że benchmarki nie oddają wiernie możliwości agentów. Rozwiniesz?
Dex: Chodzi o to, że większość benchmarków to jednorazowe zadania. Szybkie, jednostrzałowe: napraw testy, zrób to i tamto. Nie jestem ekspertem od uczenia maszynowego, ale zrobiłem sporo researchu, bo chciałem zestawić swoje przeczucie z tym, jak to faktycznie działa w prawdziwym świecie.
Fabryka oprogramowania: co się zmienia po wejściu agentów
David: Puściłeś agenty, żeby pracowały same. Opowiedz historię od początku.
Dex: Pojęcie fabryki oprogramowania funkcjonuje od 1968 roku, ale ja lubię myśleć o „fabryce oprogramowania roku 2022” — czyli tuż przed AI. Miałeś zespół ludzi, wrzucaliście rzeczy na listę zadań: Jira, Linear, wasza maszyna stanów, wasz tracker. Ktoś szedł i budował daną rzecz, potem robiliście pull request, potem CI/CD i całą resztę. Zautomatyzowaliśmy mnóstwo rzeczy, ale kod nadal recenzujemy ręcznie. Jeśli coś jest nie tak, wraca do etapu budowania. W końcu trafia na produkcję, dociera do użytkowników, oni narzekają, proszą o funkcje, więc kręcimy tę pętlę od nowa. Na koniec wdrażamy monitoring, żeby móc budzić ludzi o trzeciej w nocy — bo najwyraźniej uwielbiamy budzić inżynierów o trzeciej w nocy, kiedy coś się psuje.
Pierwsza rzecz, jaka się zmienia, to podmiana „człowiek buduje rzecz” na „agent buduje rzecz”. Nie będę się zagłębiał w orkiestrację, harness, sandbox i model — to wszystko jest potrzebne — ale w skrócie: każda pozycja schodząca z listy trafia do agenta. Ramp, Work OS, Brax, Stripe ze swoimi Minionami — wszyscy mają taki system. To jest pierwszy element, który podmieniasz, a resztę zwykle zostawiasz jak było. I teraz ten etap zajmuje minuty albo godziny, a przegląd nadal zajmuje godziny albo dni.
(Informacja dodatkowa: harness to warstwa uruchomieniowa wokół modelu — pętla narzędziowa, zarządzanie kontekstem i uprawnieniami, np. Claude Code czy Codex).
Zanim mieliśmy fabryki agentowe, ludzie zauważyli, że budowanie zajmuje godziny lub dni i przegląd zajmuje godziny lub dni. Zaczęliśmy więc szukać dźwigni: siedzieliśmy na spotkaniach i rozmawiali z innymi inżynierami o tym, co zamierzamy zrobić — po to, żeby zamiast sześciu godzin recenzji było większe prawdopodobieństwo, że PR odpowiada temu, co ustaliliśmy, i zmian będzie niewiele. Chodziło o to, żeby wydać godzinę z góry i zaoszczędzić godziny przy przeglądzie i budowie, upewniając się przy okazji, że nie budujemy czegoś niewłaściwego.
Teraz ten dział jest szybki, ale przegląd nadal jest wolny. Dokładamy agentowy code review, który wyłapuje wszystkie drobiazgi. Pozwalamy agentom klikać po aplikacji i testować ją w przeglądarce. To przyspiesza sprawy — ale jeśli chcesz przeczytać kod, który ma znaczenie, albo jakikolwiek kod, albo cały kod, to nadal jest twoje wąskie gardło. Jak zbudować zaufanie, że to, co powstało, będzie działać dziś i nie będzie cię spowalniać za miesiąc?
David: Jeśli dostajesz dziesiątki tysięcy linii, nie przejrzysz tego ręcznie. To zdecydowanie jest wąskie gardło.
Dex: Więc robisz, co możesz, żeby zbudować zaufanie. Mówisz: dobra, puściliśmy na to Codeksa i Opusa, obaj znaleźli po dziesięć rzeczy, naprawiliśmy wszystkie dziesięć — mam teraz większe zaufanie, że nie zaleje mnie fala skarg i próśb o funkcje i że nikt mnie nie obudzi o trzeciej nad ranem.
Można też zrobić rzeczy w rodzaju kierowania incydentów prosto do fabryki. Kiedy o trzeciej w nocy odpala się alarm, nie budzę się do alertu — budzę się do pull requesta. To samo z prośbami użytkowników o funkcje: zamiast przechodzić przez kolejkę wsparcia, część zgłoszeń kierujemy od razu do agenta, a on idzie i naprawia błąd. Robiłeś już coś takiego?
David: Tak, wdrażam to na tyle, na ile mogę. W moim obecnym projekcie, Deep API, mam GLM 5.2, które przegląda każdy incydent dostępności. Wcześniej wszystko podejrzane albo każdą awarię musiałem sam czytać i rozumieć, albo posiłkować się AI. Teraz dostaję gotowy raport: „to jest wina dostawcy, nic nie zrobimy” albo „to przez brakującą migrację, zrób to i to”.
Dex: Czyli: „Anthropic ma teraz awarię, musisz po prostu poinformować użytkowników, a tu masz szkic komunikatu na Discorda”. Fajne. Gdzie to hostujesz? W jakimś chmurowym sandboksie?
David: To podzielone między render.com, crony na Vercelu i GitHub Actions.
Dex: Rozumiem — crony na Vercelu wciągają incydenty, a na render.com kręci się mała pętla agentowa, która robi inferencję i wysyła wynik dalej.
David: Dokładnie.
Materiał sponsorowany
David: Uruchomienie aplikacji to dopiero pierwszy krok. Gdy pojawiają się użytkownicy, pytanie brzmi: w co klikają, gdzie odpadają, co się psuje? Zwykle te informacje są porozrzucane — jedno narzędzie do analityki, drugie do ankiet, trzecie do błędów. PostHog daje to wszystko na jednej platformie. Możesz podpiąć wszystkie źródła danych i odpytywać je razem z danymi produktowymi, więc znajdujesz realne korelacje zamiast zgadywać. Jest też session replay — nagrania sesji użytkowników pokazujące, gdzie dokładnie się zacinają. Ale nie musisz tego oglądać sam: nowe narzędzie PostHoga, Replay Vision, ogląda nagrania za ciebie, automatycznie wykrywa punkty tarcia, a agent otwiera pull request z konkretną poprawką. Tobie zostaje przegląd i merge. Chodzi o to, żeby produkt sam się poprawiał. Większość ludzi nie ma pojęcia, jak monitorować własne wywołania modeli — PostHog śledzi prompt, odpowiedź, koszt tokenów i opóźnienie, w rozbiciu na użytkowników. Widzisz, które funkcje palą pieniądze, które agenty się rozjeżdżają i które prompty faktycznie działają. Możesz wypróbować PostHoga za darmo, link w opisie. Dzięki dla PostHoga za sponsorowanie tego odcinka.
„Lekka fabryka”, czyli próba całkowitego wyjścia z pętli
Dex: Kiedy ludzie mówią o pełnej fabryce oprogramowania, chodzi o to, jak wyjąć siebie z pętli. Jeśli coś da się załatwić jednym strzałem agenta — nawet jeśli to tylko trzydzieści procent twojej pracy albo trzydzieści procent incydentów — to już jest ogromne. Jeżeli zautomatyzujesz połowę pracy, dowozisz dwa razy więcej. I nagle twoja rola sprowadza się do proszenia o funkcje, rozwijania platformy, myślenia o strategii — no i pytania, jak szybko potrafisz przejrzeć zmiany.
To prowadzi do rzeczy, w którą nie wierzę: do „lekkiej fabryki oprogramowania”, gdzie mówimy — po prostu nie będziemy czytać kodu. Jak zbudować system, w którym nie musimy czytać kodu albo czytamy go jak najmniej? Ty recenzujesz jeszcze PR-y pisane przez agenty?
David: Nie wszystkie. Jeśli zmiana jest mała, wypuszczam prosto na produkcję. Mam może kontrowersyjną opinię — i zastrzegam, że mam mniej doświadczenia niż ty — ale dobrze wyczuwam własny prompt. Przy drobnej poprawce frontendowej wiem, co agent zrobi. Mam za sobą tysiące godzin budowania z AI, w tym pewnie ponad sto godzin z nowymi modelami. Po prostu wiem, co agent najpewniej spieprzy, a czemu mogę zaufać. Jeśli nie jestem pewien, robię podstawy: przegląd innym modelem frontierowym i więcej własnych testów.
Dex: To ma sens. Zasadniczo, jeśli chcesz wyjść z przeglądu kodu, musisz zainwestować w całą resztę. Robisz tak, żeby agent mógł przetestować swoje zmiany na żywo. Może nawet przysyłać ci krótkie wideo, kiedy skończy — tak działają sandboksowe agenty w Cursorze. Robisz dużo lepszy agentowy code review. Robisz dużo lepsze testy regresyjne. Za każdym razem, gdy coś padnie, ustalasz, co to było, i dbasz, żeby ten konkretny tryb awarii już nigdy nie wrócił. Ulepszasz i uodparniasz CI/CD. Dokładasz różne typy linterów, monitoring złożoności, całą tę maszynerię. I wtedy twoja praca to naprawdę tylko: ile rzeczy zdołasz wymyślić, o ile funkcji poprosisz, o ile funkcji poproszą użytkownicy. Da się to prowadzić tak, żeby nigdy nie czytać kodu. Osobiście uważam, że to nie działa — to było moje olśnienie. Jeśli używałeś agentów przez dłuższy czas, masz to przeczucie: kiedy robisz to zbyt długo…
David: …całkowicie tracisz kontakt z bazą kodu. Więc może dodałbym jeszcze jedną warstwę: poświęcanie czasu na to, żeby agent edukował ciebie. Sprawdzał, czy człowiek nadal panuje nad sytuacją. Zadawał ci quizy, generował wizualizacje HTML i celowo zwalniał, kiedy zaczynasz tracić grip.
Dex: Dokładnie tak.
David: Szybka informacja: dokładny system projektowania programu, którego używa Dexter, znajdziecie w pierwszym linku pod filmem. Całkowicie za darmo.
Dex: Mieliśmy nawet prototypową funkcję, której ostatecznie nie wypuściliśmy, ale możemy do niej wrócić: gdy agent pracuje, otwierasz sesję, a ona odpytuje cię z tego, jaki jest obecny stan bazy kodu i jak ona dziś działa, a potem — jak działa nowa implementacja i co ona zmienia. Testujesz swoje rozumienie pytaniami wielokrotnego wyboru, diagramami Mermaid i tym podobnymi.
Sedno jest takie: jeśli przestaniesz czytać kod, to prędzej czy później — a raczej na pewno — trafisz na problem, którego agent nie rozwiąże. Mówisz: „to jest zepsute, napraw”. „To jest zepsute, napraw”. Próbujesz najbardziej wyrafinowanego promptowania, zwołujesz radę trzech najmądrzejszych modeli, a one uparcie uważają, że przyczyna jest gdzie indziej, i wypuszczają poprawki, które niczego nie naprawiają. Musisz więc wejść do bazy kodu, której nie czytałeś od trzech miesięcy, i spędzić dni albo tygodnie na dwóch rzeczach: brnięciu przez niechlujny kod, bo przestałeś go czytać, i ustalaniu, co właściwie jest nie tak.
Zdarzyło nam się to co najmniej raz czy dwa i dlatego to porzuciliśmy. Robiliśmy tak w lipcu 2025. Mieliśmy tę lekką fabrykę, w której mocno wyszliśmy na wysoki poziom i praktycznie nie zaglądaliśmy w kod. Recenzowaliśmy plany, wspólnie pracowaliśmy nad ticketami i nad tym, co trafia na listę zadań, ale kodu nie czytaliśmy. Potem trafiliśmy na błąd i przez tygodnie… Budowaliśmy aplikację desktopową, aplikacja była zabugowana, użytkownicy wściekli, a my przekopywaliśmy się przez stertę bylejakiego kodu, próbując zrozumieć, co się, u licha, stało. Było źle.
Mam taką tezę, że jeśli przestaniesz czytać kod, szanse, że cię to spotka, są znacznie wyższe niż szanse, że cię ominie — albo że modele zmądrzeją na tyle szybko, by rozwiązać to za ciebie.
David: Może podważę słowo. Czy „kod” to właściwe określenie? Możesz je zastąpić „logiką”. Jeśli rozumiesz logikę swojego oprogramowania — czy używamy takiego a nie innego schematu API, jaka jest różnica między haszowaniem a szyfrowaniem — to niekoniecznie musisz oglądać sam kod. Musisz znać logikę: jak wyglądają pierwsze pięć minut onboardingu, co się dzieje, gdy ktoś próbuje anulować subskrypcję, co się dzieje, gdy odpala się dany endpoint.
Dex: Chodzi o to, żeby wiedzieć, czym jest produkt.
Cztery warstwy przygotowania
Dex: Przeskoczę do przodu, a potem wrócę do tego, dlaczego tak uważam — mamy cały wywód o uczeniu ze wzmocnieniem i o tym, jak to działa. Przechodzimy przez cztery etapy. Mogę je za chwilę pokazać na naszym narzędziu, ale nie potrzebujesz żadnego narzędzia ani szczególnych umiejętności, żeby to robić. To po prostu — moim zdaniem — właściwy sposób myślenia o dogadywaniu się z AI i pozostawaniu w pętli.
Warstwa pierwsza: produkt
Pierwsza rzecz to warstwa produktowa. Jaki problem użytkownika próbujemy rozwiązać i — jeśli to możliwe — jak to zmierzymy? Bo jeśli umiesz postawić eksperyment na stronie i powiedzieć „to jest trudne w obsłudze”, agent może wypróbować trzy warianty, codziennie sprawdzać dane i zdecydować, który działa najlepiej. To niesamowite. Wtedy naprawdę wchodzisz na autopilota.
David: To jest coś, w czym najnowsza generacja agentów jest dużo lepsza. Zauważyłem przy Fable i przy 5.6, że nie muszę im mówić, żeby uruchamiały testy. Jeśli robią coś średniego albo dużego, same z siebie testują znacznie więcej. Więc w pewnych obszarach nadal trzeba wymyślać sposoby mierzenia, ale wraz z lepszymi modelami one robią to same.
Dex: Mówiąc „testowanie”, masz na myśli testy przeglądarkowe, coś w rodzaju agenta sterującego przeglądarką?
David: Nie, nie. Jeśli buduję jakąś funkcję — powiedzmy deep research albo scraping — i zmieniają dostawcę, to same przetestują koszt, szybkość i jakość, używając LLM-a jako sędziego, bez mojego polecenia „przetestuj to po zmianie”. W poprzedniej generacji modeli to się nie zdarzało.
Dex: Świetne. My też widzimy tego trochę więcej. Modele mocno podciągnęły się w obsłudze komputera i przeglądarki i znacznie chętniej robią to bez proszenia. Cała idea to ciśnienie zwrotne: jak dostarczyć modelowi deterministyczny sygnał. LLM jako sędzia jest w porządku, modele potrafią oceniać kod i wyniki, ale jeśli możesz powiedzieć „oto liczba — konwersja na mojej stronie, powiązana bezpośrednio z sukcesem biznesu, z przychodem, z liczbą konwertujących użytkowników” — to jest szalenie mocne.
David: Chciałem to właśnie powiedzieć — to ta sama idea, co za komendą /goal. Jeśli podasz agentowi mierzalny wynik, przeniesie dla ciebie góry.
Dex: To dokładnie to samo, co automatyczny research: „przyspiesz ten kernel CUDA, aż osiągniesz dwudziestoprocentową redukcję zużycia zasobów”.
(Informacja dodatkowa: kernel CUDA to program liczony na GPU — klasyczny przykład zadania z twardą, mierzalną metryką wydajności).
Pokażę wam dokument, który zrobiliśmy. To PRD napisany w HumanLayer o tym, jak wnieść własne przepływy pracy do Riptide. Jest problem do rozwiązania, jest sposób pomiaru sukcesu. Zastosowaliśmy też podejście Amazona: napisz wpis blogowy, zanim zbudujesz funkcję. Zastanów się, jak wytłumaczysz ją użytkownikom i dlaczego jest wartościowa, zanim napiszesz linijkę kodu. Budujemy nowy format JSON, a do tego robimy makiety w HTML-u, żeby zrozumieć, jak to będzie wyglądać. Zrobiłem sporo iteracji, a potem po prostu prototypujemy wszystkie istotne widoki aplikacji w czystym HTML-u — świetnie się sprawdza. To wciąż jest warstwa produktowa: żadnej techniki, żadnej architektury, nie mówimy o bazach danych ani schematach. Tylko: co widzi użytkownik.
(Informacja dodatkowa: PRD — product requirements document, dokument wymagań produktowych. „Working backwards” Amazona to praktyka pisania komunikatu prasowego i FAQ przed rozpoczęciem prac).
David: Tak — pełna jasność co do tego, co właściwie chcesz zbudować i po co, zanim zaczniesz promptować i kodować.
Dex: I ludzie mówią: „przecież to dodatkowa robota, modele są już wystarczająco dobre”. Czasem tak. Możesz rzucić kością i zobaczyć, co wyjdzie. Ale jeśli spędzisz dwadzieścia minut na ustaleniu, jak to ma wyglądać, wyraźnie podnosisz szansę, że to, co agent dowiezie, nie będzie wymagało ręcznego polerowania, poprawek i całej listy zmian w UI.
David: Modele są też wystarczająco dobre w robieniu tego, co im każesz, i nigdy nie powiedzą ci wprost: „stary, siedzisz nad tym od kilku dni, nie ma żadnego postępu i nadal masz zero użytkowników”. To jest niebezpieczna część.
Warstwa druga: architektura systemu
Dex: Kolejna rzecz to architektura systemu. Jeśli chcesz oszczędzić czas przy przeglądzie, wybierasz osobę, która ten PR będzie recenzować — jeśli działasz solo, to inna historia, ale w zespole to kluczowe. Pracujemy dużo ze spółkami giełdowymi i firmami fintechowymi po rundzie B, czyli tam, gdzie nie da się „zwibować i mieć nadzieję”. Nie ma opcji „jak się zepsuje, naprawimy jutro”, bo w tych branżach za błąd możesz dostać milion dolarów kary. Więc oni kod recenzują.
Robimy więc architekturę wysokiego poziomu: jak usługi mają się ze sobą połączyć, jaki jest przepływ, jakie nowe endpointy powstaną, jakie nowe tabele, zarysy zapytań. To jest zejście o poziom niżej. Wielu ludzi to robi — sporo osób doszło już do etapu, w którym swobodnie projektuje architekturę w dialogu z modelem. To bardzo dobre. Robisz coś takiego?
David: Nie jestem na tym poziomie. Właśnie uruchamiam nowy startup z dwoma programistami, więc jeszcze tam nie doszedłem.
Dex: No i tu jest gwiazdka: są momenty na vibe coding. To bardziej kwestia etapu niż samego vibe codingu. Jeśli jesteś startupem przed dopasowaniem produktu do rynku i musisz dopiero ustalić, co warto budować — musisz wystawiać klientom jak najwięcej różnych rzeczy i sprawdzać, za co są gotowi zapłacić. Wtedy to prawdopodobnie przerost formy. Ale jeśli jesteś w dowolnym zespole, choćby pięcioosobowym, gdzie wiadomo, co budujecie, ludzie za to płacą i musicie mieć pewność, że to przetrwa pół roku i da się utrzymać — to jest krok pierwszy.
Warstwa trzecia: program design
Rzecz, którą według mnie większość ludzi pomija, to coś, co nazywam program design. Zanim puścisz agenta do gotowania, są decyzje, które on podejmie, a które mogą ci się nie spodobać.
Widzimy coraz więcej osób schodzących jeszcze o warstwę niżej: jak będzie wyglądał stos wywołań programu. Dylan Mulroy z Cloudflare napisał o tym niedawno bardzo dobry wpis — większość jego planów kończy się tym, jak będą wyglądać testy i jak będzie wyglądał stos wywołań, gdy to zbudujemy. I znowu wraca słowo, którego często używam: dźwignia. Jak wydać trochę czasu z góry, żeby zwiększyć szansę, że wynik nie będzie wymagał masy poprawek przed mergem — albo sprzątania po mergu.
David: To w zasadzie proces odwrotny. Nie wiem, czy widziałeś wpis Victora Taelina: kiedy model wprowadzi zmianę, zapytaj go, których decyzji podjętych po drodze nie jest pewien.
Dex: Widziałem, tak.
David: No więc to jest robienie tego samego, tylko zanim model ruszy.
Dex: Dokładnie. Mój pogląd jest taki, że kiedy model napisał już tysiące linii kodu — albo choćby setki — zmiana jest trudniejsza, bo jesteś głęboko w oknie kontekstowym. Nawet jeśli używasz dużo subagentów, kontekstu jest sporo i jesteś już nastawiony w jednym kierunku przez to, co model wybrał na początku.
Sesje generujące te dokumenty są bardzo lekkie kontekstowo. Model ma pełne zrozumienie, ale osiąga je w bardzo oszczędny tokenowo sposób. Mam jedną taką w toku — to jest rozmowa tam i z powrotem, jesteśmy na 43 tysiącach tokenów i podjęliśmy już mnóstwo decyzji. Wczytaliśmy w tej sesji PRD i już ustaliliśmy, jak to ma się zazębiać, jak będą wyglądać endpointy, jaki jest przepływ. To zresztą wciąż jest architektura, do samego program design jeszcze nie doszedłem. Ale rzecz w tym, że wiele tych decyzji możesz podjąć bardzo tanio kontekstowo — a to znaczy, że dostajesz maksimum inteligencji modelu. Im głębiej w oknie kontekstowym, tym gorzej.
Po stronie program design patrzymy na konkrety: gdzie umieścimy te pliki? Na pewno widzicie czasem: „chwila, czemu to wylądowało tam?”. To jest właśnie pytanie, które możesz przedyskutować z modelem. Dużo używamy bloków kodu — promptujemy model, żeby produkował rzeczy, które człowiek szybko przeczyta i oceni, czy są dobre, czy złe. Definiujemy tylko typy i sygnatury metod, bez wchodzenia w szczegóły implementacji.
Warstwa czwarta: pionowe plastry
Ostatnia rzecz, którą polecam, to coś, co nazywam pionowymi plastrami. Matt Pocock mówi o tym cały czas — nagrywaliśmy razem w styczniu, rozmawialiśmy o „pociskach smugowych”. Rzecz w tym, że modele uwielbiają budować poziomo. Lubią w każdej fazie zrobić wszystko w jednym fragmencie bazy kodu. I nie ma po drodze niczego, co dałoby się przetestować. Robisz bazę danych, potem serwisy, potem API, potem frontend — a na końcu siedzisz po drugiej stronie tysięcy linii kodu i po drodze nie było nic do sprawdzenia. Wracamy do tego samego: kiedy kod jest już napisany, przekierowanie go kosztuje więcej i trudniej wprowadzić dużą zmianę.
Dlatego zawsze zalecamy pionowe plastry. Masz warstwy systemu, ale kiedy budowałem kod przed AI, zawsze zaczynałem od zaślepionego endpointu API. Potem szkicowałem frontend. Potem doprowadzałem frontend do porządku. Potem podpinałem go pod backend. Potem robiłem migrację. Potem całą logikę biznesową. Potem obsługę błędów. Nigdy nie widziałem modelu, który zrobiłby to sam, bez człowieka mówiącego mu, w jakiej kolejności ma działać. A dzięki temu możesz testować po drodze — ręcznie, curlem, agentem przeglądarkowym, czymkolwiek. Najpierw doprowadź to do działania od początku do końca, a potem dokładaj logikę i przypadki biznesowe. Ma to sens?
David: Tak. Uświadamiam sobie, że nigdy nie widziałem modelu, który powiedziałby: „zbuduję pustą wersję tego endpointu, sprawdzę, czy działa, dodam pięćdziesiąt linii, znowu sprawdzę”. Zawsze jest: „to wymaga kompletnej funkcji frontendowej, plus pięćset linii na froncie, potem plus czterysta”. Kiedy to mówisz, przypominam sobie, że sam tak robiłem przed erą LLM-ów — nie tyle co ty, ale gdy miałem piętnaście, szesnaście lat i budowałem gry mobilne, robiłem to dokładnie tak. Czy uda mi się w ogóle coś uruchomić? Działa. To zróbmy to odrobinę bardziej złożonym. Nadal działa. I krok po kroku.
Dex: Tak samo uczysz się nowego języka programowania. Robisz Hello World, a potem zmieniasz go, aż zacznie przypominać to, czego chcesz. Testujesz granice języka i rozumiesz kształt problemu w trakcie. To świetny sposób na oszczędzenie mnóstwa czasu — zwłaszcza jeśli i tak przeczytasz cały kod na końcu. Równie dobrze możesz sprawdzić te pierwsze dwa kroki, zerknąć w kod i powiedzieć: „nie podoba mi się kierunek, w którym to idzie, zmieniam kurs teraz, kiedy to tanie” — zamiast dojść do samego końca i mieć nadzieję, że wyszło dobrze, bo jeśli nie, zmiana kosztuje znacznie więcej.
David: To jak w biznesie. Pierwszemu klientowi po prostu dostarcz i zrób wszystko. Nie spędzasz dziesięciu miesięcy na projektowaniu idealnej kampanii reklamowej na Facebooku, żeby być gotowym na dziesięć milionów dolarów miesięcznie. Nikt tak nie działa.
Dlaczego modele nie piszą kodu, który da się utrzymać
Dex: To wszystko opiera się na tezie, że na razie będziesz musiał czytać kod. Modele bardzo, bardzo dobrze rozwiązują problemy, ale nie napiszą utrzymywalnego kodu bez ciebie w pętli. Miałem takie przeczucie, wiele osób, z którymi rozmawiałem, też — i chciałem zrozumieć dlaczego. Zagłębiłem się więc mocno w to, jak faktycznie działa uczenie ze wzmocnieniem i dlaczego nie da się nakłonić modeli do tego.
Na pewno próbują i pracują nad tym, może wkrótce to rozwiążą, ale jedna z rzeczy, na których się skupiam, brzmi tak: jeśli chcesz rozwiązywać problemy dziś, a nie siedzieć i rzucać prompty na chybił trafił, czekając na GPT-7 z nadzieją, że będzie lepiej — to powinieneś rozumieć o poziom głębiej, dlaczego modele są słabe w tym, w czym są słabe. Wtedy masz intuicję, gdzie się angażować, a gdzie — jak sam powiedziałeś — po prostu wiesz, że model to zrobi dobrze i nie musisz być w pętli.
Zrobiłem wizualizację zainspirowaną moim kumplem Calvinem French-Owenem, który pracował przy Codeksie. Dajemy modelowi problem, pozwalamy mu spróbować go rozwiązać wiele razy, podkręcamy temperaturę, żeby próbował różnych rzeczy. Potem oceniamy każdy przebieg: czy faktycznie go rozwiązał, czy kod był zwięzły, czy da się to zweryfikować z zewnątrz. I wzmacniamy — przebiegi, które wypadły dobrze, czynimy bardziej prawdopodobnymi przez przesunięcie wag, a te, które wypadły źle, mniej prawdopodobnymi.
Rzecz w tym, że jeśli spojrzysz na te problemy, nie ma tu żadnej kary za złe projektowanie. We wszystkich tych benchmarkach — możesz otworzyć SWE-bench Multilingual i przejrzeć każde zadanie po kolei. Tu jest „złota łatka” do jednego z zadań, czyli poprawne rozwiązanie. To są krótkie zmiany, może sto, dwieście linii. Do tego są nowe testy, które muszą przejść po rozwiązaniu problemu przez model. Model nie musi więc rozwiązać tego tak jak człowiek, ale musi doprowadzić do zaliczenia testów napisanych przez człowieka — co bywa chwiejne, bo w zależności od implementacji rozwiązanie może być poprawne, a testy i tak nie przejdą.
To jest bardzo prosty problem z rubypowego projektu Fast Language: jeśli wywołasz to w określony sposób, dostajesz wyjątek null pointera i stos się wysypuje. Ludzka poprawka polegała po prostu na podstawieniu pustej listy, gdy wartość jest nil. Do tego są testy, które mają przejść po zakończeniu pracy modelu. To jest skala i zakres tych zadań.
Ocena wygląda tak: mamy opis problemu, wyciągamy bazę kodu z commita sprzed rozwiązania danego problemu open source — może sprzed dziesięciu lat. Agent próbuje go rozwiązać, buduje łatkę, a my oceniamy ją w sandboksie. Zachowujemy zmiany, które agent wprowadził w testach — bo na pewno widziałeś agenty zakomentowujące testy, żeby przeszły — potem wstawiamy nasze testy i sprawdzamy, czy przechodzą. Czy naprawiliśmy nowy problem i czy przy okazji nie zepsuliśmy starych testów. Wtedy dostajesz punkt.
David: Czyli w tym przypadku nie ma dla ciebie znaczenia, czy to konkretne rozwiązanie open source jest w danych treningowych?
Dex: To jeden z problemów. Pokażę, co robią nowsze benchmarki. Jedną z rzeczy jest pilnowanie, żeby zbiór testowy był naprawdę odseparowany, bo modele przeczytały mnóstwo kodu i mogły w treningu widzieć ten kod, ten pull request, to repo. Ale to jest problem całkowicie ortogonalny wobec tego, że ten benchmark nie karze modelu za pisanie bylejakości. Po prostu nie karze. Więc jeśli model dostaje 99% na SWE-benchu, mam to gdzieś, bo wiem, że nie jest karany za śmieciowy kod. Tak, jest lepszy w rozwiązywaniu problemów, ale to mnie nie przekona, że mogę w najbliższym czasie przestać czytać kod.
David: No i jeśli rozwiązuje to, pisząc dziesiątki albo setki tysięcy linii kodu, to zdecydowanie nie chcesz tego w prawdziwej firmie. Technicznie problem rozwiązany, ale takiego inżyniera prawdopodobnie byś zwolnił.
Dex: Dokładnie. Stąd biorą się wzorce w rodzaju: JSON.parse, łapiemy błąd, logujemy go i rzucamy dalej albo zwracamy nic. To jest kompletnie zbędne i pogarsza kod. Wszędzie dostajemy dziwne rzutowania typów, bo model po prostu próbuje doprowadzić do zaliczenia testów.
Powód, dla którego nie weryfikujemy jakości, jest taki, że to naprawdę, naprawdę trudne. W uczeniu ze wzmocnieniem potrzebujesz wyroczni — czegoś, co zweryfikuje, czy rozwiązanie jest poprawne. A utrzymywalność nie ma szybkiej wyroczni. Testy uruchomisz w kilka sekund, możesz przepuścić miliony pętli RL na tysiącach problemów całkiem wydajnie — ale funkcja kosztu złej architektury mierzy się w tygodniach i miesiącach. Podejmujesz złą decyzję tutaj, potem wypuszczasz kolejne rzeczy po omacku, a nagle masz incydent spowodowany czymś, co wydarzyło się tam, bo wszystko coraz bardziej zamieniało się w spaghetti. Bardzo trudno zrobić z tego propagację wsteczną w trakcie treningu tak, żeby model przestał to robić.
Drugi mój problem z dzisiejszymi benchmarkami: oprogramowanie polega na odkrywaniu problemów w trakcie. Wypuszczasz coś, dajesz użytkownikom, dostajesz feedback, wypuszczasz kolejną rzecz. A w każdym benchmarku, nawet tym frontierowym, model zna cały problem z góry. Nie mamy benchmarku, który podałby modelowi pięć funkcji jedna po drugiej i sprawdził, czy potrafi nie tylko rozwiązać problem, ale też uczynić bazę kodu łatwiejszą do zmiany — tak, żeby przy kolejnym zadaniu dało się dalej pracować i robić postępy.
David: Myślę, że wielkim wyzwaniem będzie zaufanie do benchmarków. W 2023 i 2024 wszyscy patrzyli tylko na nie, teraz ludzie są bardziej sceptyczni. Naprawdę trudno znaleźć benchmark, który się nie nasyca i jest realnie użyteczny.
Dex: Dokładnie. Mam pomysły: masz mapę drogową dwudziestu funkcji, model nie zna żadnej z góry, dostaje je po jednej. Takiemu benchmarkowi ufałbym znacznie bardziej niż temu, w którym mówimy „sklonuj całego Redisa, napisz dwieście tysięcy linii Rusta zgodnego z Redisem”, a potem „o rany, sklonował Redisa, jakie to imponujące”. No tak, ale czy zdołasz dodać do tego funkcję za dwa tygodnie, czy będzie kompletny chaos?
Jest nowy benchmark od Cognition — i kilka innych, które wymieniam we wpisie — który idzie w dobrym kierunku. Jedna z ciekawszych rzeczy: nadal masz historię zgłoszeń tworzonych przez ludzi. Bierzesz zgłoszenie i bazę kodu z tamtego momentu, LLM próbuje rozwiązać, a weryfikator sprawdza, czy nowe testy przechodzą i czy nic się nie zepsuło. Ale dodatkowo jest złote rozwiązanie i osobny LLM, który porównuje to, co napisał model, z tym, co napisał człowiek, i ocenia, czy są funkcjonalnie równoważne — czy model pominął jakiś niuans, albo czy mimo niezaliczonych testów faktycznie rozwiązał problem. To jest elastyczniejsze, bo nie karzemy modelu za napisanie kodu inaczej niż zrobił to człowiek. Ciekawe, ale nie rozwiązuje problemu bylejakości.
Naprawdę fajna rzecz to sędzia jakości oparty na LLM. Częścią zbioru danych jest zestaw reguł jakościowych: jeśli piszesz w C++, nigdy nie loguj w ten sposób, tylko w tamten. Ten model patrzy na reguły i na łatkę i mówi: kciuk w górę albo w dół, czy reguły zostały dotrzymane. To wszystko rzeczy, które ludzie robią dziś w swoich fabrykach oprogramowania.
Najbardziej nowatorska rzecz — nowatorska nie w sensie inżynierii oprogramowania, ale w sensie benchmarku — jest taka: biorą testy napisane przez model, usuwają łatkę modelu i uruchamiają te testy na kodzie sprzed łatki. Czy testy tam padają? Jeśli nie padają, to dowód, że model napisał testy, które niczego nie testują.
David: Czyli — tłumacząc prościej — chcecie wpiec do procesu te mniej oczywiste rzeczy, które zwykle nazywa się gustem. Chcecie wyciągnąć zawartość ze słowa „gust”, które samo w sobie nic nie daje, i przełożyć ją na liczby, testy i pomiary.
Dex: Dokładnie. Jak dać deterministyczny feedback albo coś do niego zbliżonego. Sędzia jakości oparty na LLM oczywiście nie jest deterministyczny, ale jeśli utrzymasz go w bardzo wąskim zakresie — „powiedz tak albo nie, czy reguły zostały dotrzymane” — dostaniesz stabilniejszą ocenę niż samo „czy testy przeszły”. Idziemy więc w dobrym kierunku, ale model oceniający jakość kodu może dojść tylko do pewnego punktu. Modele coraz lepiej rozwiązują problemy programistyczne — i dlatego Fable jest trochę przełomowe, i dlatego rodzina 5.6 jest przełomowa — ale to zasługa tego, co zrobiliśmy podczas RL: przebiegi i zadania stały się bardziej wyrafinowane. Gdyby model odróżniał dobry kod od złego, spodziewałbym się, że będzie to widać, bo od razu pisałby dobry kod.
Jeśli piszesz coś Fable, a potem dajesz to Codeksowi do recenzji — no dobrze, jeśli w ogóle musimy robić tę recenzję… Owszem, podnosi to podłogę, dorzucenie tokenów prawdopodobnie wyłapie drobiazgi. Ale tego jednego nie potrafię dowieść, choć każdy, kogo znam, ma to przeczucie: gdyby model wiedział, jak wygląda dobry kod, toby go od razu pisał. Wszyscy używamy przecież tych samych modeli.
David: Jak sam powiedziałeś, wiele zależy od stanu biznesu. Znam ludzi, którzy dają się całkowicie porwać i spędzają siedem miesięcy na budowaniu idealnego systemu, nie zdobywając pierwszego użytkownika. Znam też ludzi, którzy ogarniają biznes i marketing, ale kiedy przychodzi do skalowalności i utrzymania, są ugotowani, bo nie włożyli w to wysiłku i nie mają pojęcia, co się dzieje. Więc: masz dopasowanie produktu do rynku, masz klientów enterprise, chcesz nie stracić ich zaufania i nie dać się pozwać. Jeśli nie masz dopasowania, musisz działać szybko i możesz bardziej polegać na modelach — nadal staraj się projektować tak, żeby to skalowało, nadal trzymaj rękę na pulsie bazy kodu, ale jeśli masz zero klientów, najpierw ustal, czy budujesz coś, co warto budować.
Dex: Zgadzam się w stu procentach.
Intuicja inżyniera jako niewykorzystany kapitał
David: A propos — spakowałem cały system projektowania programu, którego używa Dex, w jeden pakiet. Jest w pierwszym linku pod filmem, całkowicie za darmo.
Dex: Jest taka myśl Jake’a Nationsa, który — takie odniosłem wrażenie — był swego czasu najlepszym inżynierem Claude Code w Netfliksie. Nie sądzę, żeby kiedykolwiek sam tak powiedział, ale tak to wyglądało. Prowadził temat agentowego kodowania długo przed tym, jak stało się mainstreamem. Jego pointa brzmi tak: jako inżynier oprogramowania masz mnóstwo ciężko wypracowanej intuicji — nieważne, czy z kodowania z AI, czy bez. Rozpoznajesz zły wzorzec, kiedy go widzisz, bo utknąłeś kiedyś nad jego naprawianiem o drugiej w nocy albo spędziłeś trzy dni na przepisywaniu go tak, żeby dało się go utrzymać. Jeśli tego nie wykorzystujesz, zostawiasz na stole pieniądze, jakość, prędkość i stabilność.
Moja teza jest taka: jak rozplątać ten kłąb tego, w czym dobre są modele, w czym dobrzy są ludzie, czemu możemy zaufać, a czemu nie — i rozdzielić to. Jaki przepływ pracy pozwala tobie, człowiekowi, wnieść swoją intuicję jako dźwignię, bez tego spowalniającego scenariusza z rzuceniem dwutysiąclinijkowej funkcji na żywioł i przeglądaniem całego kodu na końcu. Wszyscy wiemy, że to brzmi okropnie. Nikt tego nie chce. Więc jak wyciągnąć tę intuicję wcześniej, w sposób łatwy, przyjemny i interesujący dla człowieka — a potem pozwolić modelowi gotować to, w czym jest dobry?
Wciągnij kontekst do repozytorium
David: Mój największy wkład w to jest taki, że staram się wciągnąć więcej rzeczy do bazy kodu. Tradycyjnie baza kodu dotyczy kodu. Ale — jak powiedziałeś — modele są coraz lepsze, a jest sporo rzeczy, które normalnie po prostu wisiały w powietrzu: to jest nasza strategia marketingowa, to jest nasz wizerunek publiczny. Wszyscy inżynierowie to rozumieją. Modele nie.
Więc osobiście w każdym projekcie, nawet małym, robię /docs/adr i jawnie dokumentuję wszystkie decyzje architektoniczne: uruchamiamy cennik w taki sposób; nigdy nie zmieniamy schematu API — jeśli będzie wielka zmiana, wypuszczamy /v2, żeby nie łamać kontraktu. Do tego /docs/external: jak wygląda moje środowisko zmiennych — oczywiście nie wartości, tylko co tam jest; jak wygląda konfiguracja operatora płatności; jakich adresów e-mail używam do testów; gdzie kontaktują się ze mną klienci. Wszystkie rzeczy zewnętrzne wobec kodu, żeby modele mogły je znaleźć jako czytelne pliki markdown i wykorzystać jako kontekst.
(Informacja dodatkowa: ADR — architecture decision record, krótka notatka opisująca podjętą decyzję architektoniczną, jej kontekst i konsekwencje).
Dex: To bardzo ciekawa myśl o kontekście w ogóle. Nasz produkt działa tak, że wszystko jest plikami na dysku. Kiedy Claude pracuje nad planami albo dokumentami projektowymi, po prostu korzysta z systemu plików — z rzeczy, w której jest naprawdę dobry. A pod spodem mamy hooki: przy każdej edycji pliku następuje synchronizacja z chmurą albo powiadomienie zespołu, ludzie mogą wstawiać komentarze, a komentarze wracają do środka. Jeśli uczynisz środowisko jak najbliższym temu, w czym model jest dobry — czyli read, write, edit, grep, bash — to bardzo skutecznie dostarczysz mu kontekst. Wciąganie tego wszystkiego do systemu plików jest bardzo mądre.
Ta idea — jak wpakować jak najwięcej do bazy kodu, żeby nie mówić „a, musisz jeszcze włączyć ten serwer MCP, a tak sprawdzasz najnowsze zgłoszenia” — jest kluczowa. Wszystkie te instrukcje o tym, jak zdobyć kontekst, marnują uwagę modelu w trakcie pracy. A możesz to załatwić deterministycznie. Możesz dosłownie przy każdym starcie sesji odpalić hooka: „pobierz dziesięć ostatnich zgłoszeń z Sentry, na wypadek gdybyśmy ich potrzebowali”. To jest za darmo. Dosłownie za darmo — to zwykły kod, kosztuje cykle procesora, ale nie kosztuje inferencji. A inferencję powinieneś oszczędzać na to, do czego modele są naprawdę potrzebne: przemyślenie złożonych problemów, wypracowanie z tobą rozwiązania i wypluwanie kodu.
Context engineering: geneza i stan na 2026
David: Pomówmy więcej o context engineeringu, bo krążymy wokół tematu, a ty jesteś jedną z pierwszych osób, które ukuły to pojęcie. Jak to się zmieniło od 2025 do 2026?
Dex: Włączę z powrotem udostępnianie ekranu. W marcu–kwietniu 2025, jakieś piętnaście miesięcy temu, napisaliśmy dokument „12 Factor Agents”. Tam po raz pierwszy pojawiło się u nas określenie context engineering. Wymieniliśmy dwanaście rzeczy, o których powinieneś pomyśleć, budując agenty. Powiedziałbym, że co najmniej dziewięć z nich jest nadal aktualnych. Część dostajesz dziś za darmo, bo zostały wchłonięte przez większość harnessów.
Ale najciekawszy — ten, który wystrzelił najmocniej — brzmiał: miej na własność swoje okno kontekstowe. Chodzi o to, że wszystko, co robisz z LLM-ami — czy piszesz skrypt, który buduje prompt, wysyła go do modelu i parsuje wynik, czy używasz agenta kodującego, który sam składa sobie okno kontekstowe, a ty tylko mówisz mu, skąd brać materiał: RAG, historia, pamięć, prompt engineering — wszystko to jest po prostu: tokeny wchodzą, tokeny wychodzą. Jedyny sposób na lepsze wyniki to wsadzić właściwe tokeny do modelu — nie więcej tokenów, tylko właściwe. Tak podnosisz swoje szanse.
Trzeba więc zrozumieć, że jedynym prymitywem, na którym pracujesz, jest to okno kontekstowe — czy będzie listą wiadomości, czy jednym wielkim promptem. Są dwie drogi: możesz mieć układ system–user–assistant–tool albo po prostu wiadomość systemową i wiadomość użytkownika w innym sformatowanym układzie. Dziś raczej nie zrobisz tego drugiego, bo cache’owanie stało się bardzo ważne, a takie podejście wysadza cache za każdym razem. Ale przy agentach naprawdę ważne jest zrozumienie, co wchodzi do twojego okna kontekstowego — a wtedy możesz zrobić dosłownie, co chcesz. Możesz modelować to jak stan w programie: zamienić wszystko, co się wydarzyło, w prompt i wrzucić do środka.
Jeśli rozumiesz to na poziomie tokenów — że JSON w oknie kontekstowym to co innego niż XML, i że XML jest oszczędniejszy tokenowo — to możesz przekazać informację modelowi najefektywniej jak się da. Zasady są trzy: upewnij się, że nie masz błędnych informacji, upewnij się, że nie brakuje informacji, a potem zrób to jak najmniejsze. To dotyczy tak samo budowania pipeline’u AI na backendzie, jak i myślenia o pracy z agentem kodującym.
To był kwiecień 2025, a w czerwcu Andrej Karpathy i Tobi Lütke postanowili o tym mówić. Za każdym razem, kiedy ktoś tweetuje o context engineeringu, przychodzę i mówię: „to jest sprzed dłuższego czasu”. Andrej nigdy nie odpowiedział, ale w porządku. Andrej, wybaczam. Nie mogłeś wiedzieć. Może to moment jak z Newtonem i Leibnizem. Zresztą Jeff Huber z Chroma DB też wrzucił te słowa jakieś dwa tygodnie po publikacji „12 Factor Agents”. Jestem prawie pewien, że tego nie czytał — po prostu wpadł na to sam i wrzucił dwa słowa: context engineering. I to było wszystko. Chyba wiele osób dochodziło do tych idei mniej więcej w tym samym czasie.
(Informacja dodatkowa: Newton i Leibniz niezależnie opracowali rachunek różniczkowy, co wywołało jeden z najsłynniejszych sporów o pierwszeństwo w historii nauki).
David: Ten sam schemat powtarzał się w historii nauki i techniki wielokrotnie: wiele osób dochodzi do tego samego wniosku równocześnie, bo myślą nad tymi samymi problemami.
A jak myślisz o tym dziś? Bo jest ta krzywa midwita: kompletni początkujący piszą króciutko „napraw to”, bez zrzutu ekranu, bez logów. Ludzie pośrodku spędzają trzydzieści minut na pisaniu idealnego promptu. A ci naprawdę zaawansowani po prostu wrzucają jeden zrzut ekranu i mówią: „to jest w tym pliku, przeczytaj go i napraw”. Czy context engineering sprowadza się dziś do tego, żeby mieć jak najwyższy sygnał przy jak najmniejszej liczbie tokenów i nie ograniczać przy tym modelu, bo może on wpaść na lepsze rozwiązanie?
(Informacja dodatkowa: „krzywa midwita” to internetowy mem — na obu końcach rozkładu inteligencji pojawia się to samo proste rozwiązanie, a przekombinowuje osoba ze środka).
Dex: Ciekawa jest strona sterowania. Wspomniałeś o czymś istotnym: możesz powiedzieć modelowi, jak chcesz, żeby coś zrobił, i wtedy jest większa szansa trafienia dokładnie w to, o co ci chodziło. A jeśli nie powiesz, jak — otwiera się szerszy zakres możliwości. Owszem, może zrobić to fatalnie, ale może też wymyślić lepszy sposób, na który nigdy byś nie wpadł. To oddzielam od context engineeringu, bo to bardziej kwestia tego, jak promptujesz i na co jesteś otwarty.
Ale wiele pojęć z context engineeringu wciąż jest bardzo aktualnych. To był przypadek — nie zakładałem tego. Większość rzeczy w AI jest kompletnie nieaktualna po pół roku, ale ta jedna trzyma się, bo context engineering dotyka fizyki okien kontekstowych i tego, jak działa uwaga w transformerach. Dopóki nie dojdziemy do architektur post-transformerowych albo liniowej uwagi, zawsze będzie tak, że im mniejsze, ciaśniejsze i bardziej konkretne okno kontekstowe, tym lepsze wyniki.
Ale podłoga stale się podnosi. Nie myślę głęboko o każdym tokenie w oknie kontekstowym, chyba że robię coś naprawdę trudnego. Jak sam powiedziałeś: przy zmianie w UI po prostu mówię, czego chcę, i ufam, że Codex pójdzie sobie sporo poczytać i się połapie. Jeśli przeczyta parę zbędnych plików, trudno. Spokojnie dochodzi do 200–300 tysięcy tokenów i nie sypie się.
Strefa głupoty
Mówiliśmy o „strefie głupoty”. Wymyśliłem to pojęcie, siedząc w biurze z inżynierami, którzy byli dość świeży w kodowaniu z AI — mieliśmy szkolenie. Ciągle zwracałem uwagę: „dobra, jesteśmy na jakichś 100 tysiącach tokenów, około pięćdziesięciu procent okna, 120 tysięcy — czas wziąć wszystko, co robimy, skompresować do dokumentu, nad którym pracujemy, i powiedzieć: weź wszystko, o czym rozmawialiśmy, i zapisz to. A potem zacząć nową sesję od tego dokumentu i pracować dalej”. To było na Opusie 4.1 i 4.5. I ukułem wtedy: „model jest teraz w strefie głupoty, dlatego nie mamy dobrych wyników”.
Traktuję to jak kółka boczne przy rowerze. Jeśli nie masz intuicji co do LLM-ów i nie przepracowałeś z agentami siedemdziesięciu godzin, dojdziesz do tego w jakieś trzy tygodnie rozmawiania z Claude’em po siedemdziesiąt godzin tygodniowo. Sam wyczujesz: „to wyjechało z torów, powinienem zacząć od nowa”. Wystarczy spróbować kilka razy. Ja regularnie wychodzę powyżej 200–300 tysięcy tokenów, w zależności od zadania — bo mi się nie chce robić porządnego przekazania i zaczynać nowej sesji. No i kompaktowanie jest ostatnio dużo lepsze. To już nie jest „musisz zostać pod stoma tysiącami tokenów, bo inaczej…”. To właśnie szczyt krzywej midwita. Druga strona brzmi: rób to, co działa. Masz intuicję, wiesz, czego się spodziewać, a jeśli coś nie działa, jedną z rzeczy do wypróbowania jest zacząć od nowa i zresetować problem.
David: Dwie największe pułapki. Pierwsza: cel uświęca środki. Jeśli osiągasz wynik, którego chciałeś — użyj tego modelu albo tamtego, innego harnessu, wyślij kilka promptów więcej, to nie ma znaczenia. Jest mnóstwo ludzi, którzy spędzają osiemdziesiąt procent czasu na budowaniu narzędzi, a dwadzieścia na faktycznej pracy. Moim celem jest w ogóle nie być taką osobą. Jeśli mam suboptymalny setup, a ktoś inny ma o jeden token lepiej, jestem z tym w porządku. Ja po prostu chcę zbudować rzecz.
Druga: to samo dotyczy człowieka. Bez trudu potrafię pracować trzy godziny nad jakimś problemem, potem idę na długi spacer i myślę: „to w ogóle nie ma znaczenia dla biznesu”. To była moja strefa głupoty.
Dex: No właśnie, ludzie też mają strefę głupoty. Jak jesteś zmęczony, wyniki spadają. Inna metafora, którą lubię, jest od Calvina — tego od Codeksa, założyciela Segmenta. Okno kontekstowe jest jak uczeń zdający egzamin: przechodzisz przez pierwszą połowę myśląc „mam mnóstwo czasu, przemyślę te zadania”, a potem orientujesz się w połowie, że zostało ci pięć minut, i zaczynasz przelatywać przez wszystko na łapu-capu. Modele robią dokładnie to samo — zwłaszcza Opus 4.5 i Sonnet 4.5 miały „lęk kontekstowy”: orientowały się, że okno się kurczy, więc zaczynały iść na skróty, gorączkowo coś klepać, a w końcu po prostu się poddawały.
David: To chyba największy problem.
Dex: Kiedy jesteś zmęczony i leniwy, wyniki spadają — u ludzi i u agentów.
Teoria ograniczeń: nie każda nieefektywność jest wąskim gardłem
David: I to jest mój problem z całym tym „token maxingiem”. Powiedziałeś to dokładnie: nie potrzebuję najefektywniejszego setupu, potrzebuję dbać o rezultaty.
Dex: Czytałeś kiedyś książkę „Cel”?
David: Nie.
Dex: To książka Eliyahu Goldratta z lat siedemdziesiątych. To historia faceta, który próbuje uratować fabrykę. Fabryki w Ameryce w latach sześćdziesiątych i siedemdziesiątych działały tak, że miałeś stanowiska — maszyny. Wjeżdżają surowce, wyjeżdża samochód albo część, którą wysyłasz do innej fabryki, żeby zrobić samochód. I zatrudniałeś stado ludzi po MBA, każdy dostawał swoje stanowisko i maksymalizował jego wykorzystanie. Bo uruchomienie maszyny kosztuje, a każda minuta bezczynności to strata. Wszyscy więc optymalizowali swoje stanowiska — a to prowadziło do tego, że różne stanowiska pracowały w różnym tempie, zawsze istniało jakieś wąskie gardło, a przed nim piętrzyła się produkcja w toku, której magazynowanie w fabryce jest bardzo drogie.
(Informacja dodatkowa: „Cel” Goldratta to powieść dydaktyczna, która wprowadziła teorię ograniczeń — koncepcję, że wydajność całego systemu wyznacza jego najwęższy punkt).
To jest opowieść o tym, że istnieją nieefektywności, które nie są wąskimi gardłami. I dokładnie tym jest token maxing wynikający z abonamentów — „muszę wyczerpać cały limit co pięć godzin”.
David: …i skończyć w szpitalu.
Dex: No tak, to było szalone. Nie wiem, czy w to do końca wierzę, może to był mem, ale mam nadzieję, że wszyscy są cali. Ale to jest ten fabryczny bank tokenów: ile możesz wydać, ile da się wycisnąć z maszyny i zamienić w kod. Coś w tym jest — pchaj granicę, zrób rzecz największą i najbardziej ambitną, jaką się da, i zobacz, co wyjdzie. Ale potem prawdopodobnie powinieneś się z tego wycofać, bo jeśli wąskim gardłem jest przegląd kodu, dokładanie agentów kodujących tego nie rozwiąże. Musisz rozwiązać faktyczne wąskie gardło, a nie cieszyć się, że stanowisko agentowe jest bardzo wydajne i stanowisko wdrożeniowe jest bardzo wydajne. Przyspieszanie ich nie dostarcza wartości szybciej, bo od początku do końca liczy się wartość dostarczona użytkownikom. To za to ludzie płacą.
David: Najlepszym przykładem kogoś, kto robi to dobrze, jest Elon. Zawsze pracuje nad największym wąskim gardłem i nie przeszkadza mu, że ktoś inny w firmie robi coś innego, prawdopodobnie nie na jego poziomie. Jeśli to nie jest wąskie gardło, nie ma znaczenia — jeśli zrobią to na osiemdziesiąt procent, w porządku. On musi pracować nad wąskim gardłem. To samo dotyczy budowania firmy programistycznej albo fabryki oprogramowania. Jeśli ulepszasz swój multiagentowy setup o wymyślny routing i delegowanie — super, ale produkcja właśnie leży.
Dex: Mamy w biurze taki żart: przestań się bawić swoimi agentami kodującymi i wracaj do pracy. Bo to jest tak łatwe i tak przyjemne — budować rzecz, która buduje rzecz. Ja miałem to jeszcze przed AI. W pierwszej pracy po studiach byłem w firmie od analityki mediów społecznościowych. Mieliśmy dużo danych i dobrych inżynierów, ale zauważyłem, że najważniejszą osobą w firmie był gość, który zbudował platformę deweloperską. Sposób, w jaki wypuszczasz kod, w jaki wdrażasz środowisko sandbox, żeby wysłać podgląd product managerowi. Ten, który umiał zdebugować nie samą bazę danych, tylko procedurę jej wdrażania.
Od tamtej pory mam obsesję: za każdym razem, gdy w firmie CI/CD było wolne, myślałem „o Boże, musimy przyspieszyć CI/CD, musimy skrócić cykle, wypuszczamy raz na dwa tygodnie, musimy wypuszczać codziennie”. Mam obsesję na punkcie fabryk oprogramowania — nie wiedziałem, że tak się to nazywa — od dwunastu czy piętnastu lat, odkąd pracuję. I często byłem po drugiej stronie takiej rozmowy: „Dex, przestań przyspieszać CI i po prostu dowieź tickety, które ci dałem. Proszę”. Odbywałem tę rozmowę z szefem wielokrotnie, w wielu firmach. A ja na to: „nie, musimy zbudować rzecz, która buduje rzecz, bo to przyspieszy wszystkich”.
Najtrudniejsza lekcja jest taka, że istnieją nieefektywności, które nie są wąskimi gardłami. Możesz widzieć rzeczy, od których cierpnie ci skóra: „to jest okropne, czemu tak robimy, dałoby się o tyle lepiej”. A jeśli zależy ci na przedsiębiorczości i budowaniu, najważniejszą umiejętnością jest umieć się cofnąć i zapytać: czy to jest wąskie gardło? Czy mogę zatkać nos i skupić się na tym, co naprawdę ma znaczenie?
David: Im większy sukces — w biznesie czy w oprogramowaniu — tym więcej pożarów wokół. Musisz nauczyć się komfortowo pozwalać niektórym pożarom płonąć. Który z nich jest pożarem, który spali całe miasto, a które to tylko żarzące się węgielki, które można zostawić na później.
Dex: Właśnie: idziemy zakręcić wyciek gazu w ratuszu, czy gasimy ten pożar tutaj? Ten pierwszy jeszcze się nie pali, ale jeśli się zapali… To jest jak oczekiwany ból. Trudne jest trzymanie w głowie tych wszystkich prawdopodobieństw i ocenianie, nad czym warto pracować.
Grałeś kiedyś w StarCrafta? Byłeś fanem RTS-ów?
David: Nie, jestem na to za młody. Gram w World of Warcraft, ale StarCraft to chyba pokolenie wcześniej.
Dex: To gra, która uczy podejmowania trudnych decyzji przy niepełnej informacji. Podejmujesz setki decyzji na minutę i nie wiesz wszystkiego — wiesz tylko to, co zobaczyłeś. Mówisz sobie: widziałem, że zrobił to, i widziałem tamto, więc jest dziesięć procent szans, że robi X, trzydzieści, że Y, siedemdziesiąt, że Z. A moje najlepsze zagranie ma czterdzieści procent szans na pokonanie tego i dwadzieścia na tamto. To gra w układanie prawdopodobieństw po obu stronach. Dobra gra, ale nie polecam — jest potwornie stresująca. Ta umiejętność, żeby wiedzieć, co się widziało, i obstawiać, jest cenna.
Założyciele mówią o budowaniu w kategoriach inwestycji i długu technologicznego. Rozmawiałem wczoraj z kimś na kolacji, kto powiedział: „my nie robimy inwestycji w infrastrukturę. My się zakładamy. Wszyscy zakładamy się cały dzień, codziennie, próbując ustalić, co ma najwyższą wartość oczekiwaną”.
David: Albo: czy w ogóle powinienem budować tę firmę? Poświęcę na to pół roku i będzie fatalnie, czy po pół roku po prostu zastąpi mnie OpenAI albo Anthropic? To wszystko są zakłady. I nie możesz przegrać ich zbyt wielu, bo staniesz się nieistotny.
Czy warto budować, skoro laby i tak wygrają
Dex: Dobrze się bawisz?
David: Tak.
Dex: To dobry początek. Jeśli dobrze się bawisz i się uczysz, to co z resztą? Dwadzieścia lat temu było sto startupów istniejących do dziś i gwarantuję, że w dziewięciu na dziesięć spotkań z inwestorami słyszeli: „e tam, Google i tak to zrobi”. I wiesz co? Google to zrobił.
David: Widać to nawet w tej generacji. Rozmawiałem z Magnusem z Browser Use i wszyscy mówili: „Anthropic już to buduje, nie ma sensu”. A jednak zrobili to lepiej niż Anthropic. I to w rok, dwa lata. Więc nawet dziś: najprawdopodobniej te wielkie firmy nie skupiają się na twojej małej niszy i pewnie powinieneś to zbudować, jeśli naprawdę chcesz.
Dex: Jeden z moich ulubionych cytatów na ten temat: nie konkurujesz z Google ani z Anthropikiem — konkurujesz z jednym product managerem w Anthropiku. Owszem, są tam bardzo, bardzo utalentowani ludzie. Ale zwłaszcza wersja z Google jest ciekawa: masz zespół wewnątrz wielkiej organizacji, pełnej reguł i biurokracji, gdzie wszystko idzie wolno. Nie obchodzi mnie, ile mają pieniędzy i zasięgu. Mały założyciel i mały zespół, któremu naprawdę zależy, przegoni większość zespołów w gigantycznej korporacji.
To, co zrobiły OpenAI i Anthropic — rozmawiałem z wieloma byłymi pracownikami — polega na tym, że bardzo dobrze utrzymali startupową energię, pomagają ludziom działać jak najszybciej i zatrudniają naprawdę świetnych ludzi. Boris i Katya są niesamowici, są znakomici w tym, co robią. Więc to jest PM, przy którym dwa razy bym się zastanowił, zanim wszedłbym mu w paradę. Ale bardzo łatwo popaść w „nie warto nic budować, laby i tak wygrają”. Ja lubię budować rzeczy zgodne ze światem, w którym chcę żyć. A ten świat to taki, gdzie istnieją duże i małe firmy, gdzie innowacja jest możliwa i gdzie razem rozwiązujemy problemy. Przyjaźnię się ze wszystkimi założycielami agentów kodujących w San Francisco. Jesteśmy konkurentami, ale rynek jest ogromny i w mojej głowie to nie jest założyciel przeciwko założycielowi — to raczej założyciele przeciwko zasiedziałym graczom albo przeciwko ludziom, którzy nienawidzą innowacji.
David: Dokładnie. Ludzie, którzy nie lubią technologii i tkwią w przeszłości. Im więcej osób poznaję w świecie AI, tym bardziej widzę, że chodzi o to, czy jesteś prawdziwym wyznawcą, czy nie. Wielu jest tu, bo to następna fala, bo tu są pieniądze i szum. Ale gdy z nimi rozmawiasz, okazuje się, że nie wierzą naprawdę w technologię. Nawet gdy wychodzi nowy model albo nowe narzędzie, zamiast to przetestować i spróbować, od razu mówią: „a, kolejne takie” albo „za drogie”. A my przecież wymyślamy przyszłość.
Dex: …i „próbowałem rok temu, było słabe”. No cóż.
Zoom out: AI a reszta świata
David: Jeśli chcecie faktycznie wdrożyć wszystko, o czym rozmawialiśmy z Dexterem — cały system projektowania programu, który wymyślił, jest za darmo w pierwszym linku pod filmem.
Dex: To może dobry moment, żeby wyjść o poziom wyżej i zacząć zamykać. Byłem wczoraj na wydarzeniu, gdzie Dwarkesh przeprowadzał wywiad z dr Fei-Fei Li, a potem Michael Grinich z Work OS przez chwilę przepytywał Dwarkesha. Wszyscy jesteśmy tu w San Francisco i bardzo łatwo dać się wciągnąć: co najfajniejszego możemy zbudować, jaki najtrudniejszy problem rozwiązać, jak bardzo możemy to podkręcić, jak szybko możemy działać.
Grinich dobrze nas wyciągnął o poziom wyżej: AI jest teraz jedną z najbardziej niepopularnych rzeczy na świecie. Odrobinę mniej niepopularna niż ISIS i odrobinę bardziej niepopularna niż wojna z Iranem. Jest gdzieś tam nisko. Większość ludzi jej nie ufa. Uważam, że jako budowniczowie powinniśmy od czasu do czasu się cofnąć i uznać: musimy pomyśleć, jak ta technologia działa w szerszym kontekście. Dwarkesh mówi o tym, że za pięć czy dziesięć lat nie będzie pracy — nie będzie co robić — więc jak wtedy działa gospodarka? Czy powinniśmy pogadać z ekonomistami po doktoratach, czy oni w ogóle przemyśleli, jak świat funkcjonuje w tym nowym układzie? Na to nikt nie ma odpowiedzi. I dopóki nie dasz komuś nietechnicznemu, kto nie jest wkręcony w AI, przekonującej odpowiedzi — „tak będzie działał świat, będzie dobrze i wszyscy wygrają” — poza bardzo prostym „no wiesz, rewolucja przemysłowa, życie znacznie się poprawiło”… Bo ono się dla części ludzi na wiele sposobów pogorszyło, ale ogólnie mamy dziś więcej dobrobytu niż w XVI wieku. Nie sądzę, żeby to było wystarczająco satysfakcjonujące wyjaśnienie dla większości ludzi.
David: Ludzi obchodzi, czy stracą pracę.
Dex: Tak — czy będę w stanie wyżywić rodzinę. Ale i tak uważam, że warto.
David: Łatwo w tym utknąć — szczególnie na Twitterze albo w San Francisco, gdzie zresztą nadal muszę pojechać, nigdy tam nie byłem. Chyba wybiorę się pod koniec września albo na początku października. Łatwo utknąć w bańce, czy to na Twitterze, czy w SF. A większość ludzi nie ma pojęcia. Jedyne AI, jakiego używają, to podsumowania Google w wyszukiwarce, i nie chcą stracić pracy. Więc jeśli mówisz „idziemy po rynek pracy”, znienawidzą cię natychmiast.
Dex: Nie wiem, po co ludzie ciągle to powtarzają. Może lepiej powiedzieć i się mylić, niż nie powiedzieć i mieć rację. Zobaczymy. Mam taką teorię, jak myśleć o AI. Jest mnóstwo rzeczy, którymi można panikować. Jest scenariusz, w którym uderzamy w osobliwość, mamy pełną obfitość, nikt nie musi pracować i wszystko jest cudownie — to ten niesamowicie dobry świat. Jest jakiś procent szans, że schrzanimy alignment i będziemy żyć w fabule „Terminatora”, gdzie maszyny próbują nas wybić. A pośrodku biegnie linia, na której rzeczy po prostu stają się coraz lepsze — może dwa razy szybciej, może półtora raza szybciej, co roku, co miesiąc — ale zasadniczo pozostaje stabilnie i nie dzieje się nic szalonego, nie zostajemy kompletnie zdestabilizowani.
I czy uważasz, że dobry scenariusz ma trzydzieści procent, czy trzy, i czy zły ma trzydzieści procent, czy trzy — jedynym światem, który warto planować, jest moim zdaniem ta środkowa ścieżka. Bo jeśli zdarzy się którakolwiek z tych dwóch skrajności, nic, co dziś zrobisz, nie ma znaczenia — chyba że pracujesz w labie nad alignmentem.
David: To bardzo trafna uwaga i myślę, że na tym możemy zakończyć. Chcę uszanować twój czas, przekroczyliśmy już godzinę. Gdzie mamy wysłać ludzi?
Dex: Śledźcie mnie na Twitterze — Dex Horthy — i zajrzyjcie na humanlayer.com, jeśli chcecie nauczyć się, jak to robić.
David: Podlinkuję jedno i drugie pod filmem. Dzięki za twój czas i miłego dnia.
Dex: Dobra robota.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Wysoki wynik w benchmarku nie znaczy, że kod nadaje się do utrzymania
Na czym polega: Benchmarki typu SWE-bench nagradzają zaliczenie testów, a nie jakość projektu. Model może rozwiązać zadanie brzydko i dostać ten sam punkt co człowiek, który napisał sto czystych linii. Nie istnieje szybka „wyrocznia” utrzymywalności, bo koszt złej architektury ujawnia się w tygodniach i miesiącach — a to zbyt wolno dla pętli uczenia ze wzmocnieniem.
Jak stosować: Wybierając model do pracy produkcyjnej, nie kieruj się rankingiem. Zrób własny test: daj modelowi trzy–pięć kolejnych zmian w tej samej bazie kodu i sprawdź, czy po trzeciej kod jest nadal czytelny i łatwy do rozszerzenia.
Na co uważać: Nie wpadnij w drugą skrajność i nie odrzucaj benchmarków całkowicie — one uczciwie mierzą zdolność rozwiązywania problemów. Mylące jest tylko przenoszenie tego wyniku na „mogę już nie czytać kodu”.
2.Nie przestawaj czytać kodu — a przynajmniej rozumieć logikę
Na czym polega: Zespół Dexa próbował w lipcu 2025 prowadzić „lekką fabrykę”, gdzie recenzowano plany, ale nie kod. Trafili na błąd, którego żaden model nie umiał naprawić, i przez tygodnie brnęli przez nieznany, niechlujny kod przy wściekłych użytkownikach. David proponuje złagodzenie: kluczowe jest rozumienie logiki — przepływów onboardingu, anulowania, zachowania endpointów — niekoniecznie każdej linii.
Jak stosować: Zdefiniuj sobie minimum kontaktu z kodem: czytaj pierwszy plaster każdej funkcji i całość zmian w krytycznych ścieżkach (płatności, auth, dane). Resztę możesz oddać agentowemu review. Rozważ też prośbę do agenta o okresowe „egzaminowanie” cię z aktualnego stanu systemu.
Na co uważać: Utrata kontaktu z kodem jest niewidoczna dopóki wszystko działa. Sygnał ostrzegawczy to moment, w którym nie potrafisz sam wskazać, gdzie leży dany fragment logiki.
3.Cztery warstwy przed uruchomieniem agenta
Na czym polega: Produkt (jaki problem użytkownika, jak mierzymy) → architektura systemu (usługi, endpointy, tabele) → program design (stos wywołań, rozmieszczenie plików, typy i sygnatury) → pionowe plastry (kolejność budowania). Trzecia warstwa jest tą, którą prawie wszyscy pomijają.
Jak stosować: Przy średniej i większej funkcji przeznacz dwadzieścia–trzydzieści minut na dialog z modelem przed pisaniem kodu. Poproś o bloki kodu z samymi typami i sygnaturami metod — bez implementacji — bo taki artefakt człowiek ocenia w minutę.
Na co uważać: To przerost formy dla startupu przed dopasowaniem produktu do rynku, który dopiero szuka, co warto budować. Sensowne od momentu, gdy wiadomo, co budujecie, ktoś za to płaci i kod musi przeżyć pół roku.
4.Decyzje podejmuj przy niskim kontekście
Na czym polega: Sesja projektowa na 40 tysiącach tokenów daje ci maksimum inteligencji modelu. Gdy model napisał już tysiące linii, jesteś głęboko w oknie kontekstowym i dodatkowo nastawiony w kierunku pierwszego wyboru modelu — zmiana kursu kosztuje wielokrotnie więcej.
Jak stosować: Prowadź osobne, lekkie sesje na PRD, architekturę i program design. Zapisuj wyniki do plików i startuj sesję implementacyjną od tych plików, nie od rozmowy.
Na co uważać: Nie myl „lekkiego kontekstu” z „mało informacji”. Model musi mieć komplet — chodzi o to, żeby dostał go w formie skondensowanej, nie żeby dochodził do niego przez pół okna kontekstowego.
5.Pionowe plastry zamiast poziomych warstw
Na czym polega: Modele domyślnie budują poziomo: cała baza danych, potem cały serwis, potem całe API, potem cały frontend. Po drodze nie ma nic, co dałoby się przetestować. Dex nigdy nie widział modelu, który sam z siebie zbudowałby najpierw działającą ścieżkę end-to-end.
Jak stosować: Wprost narzuć kolejność: zaślepiony endpoint → szkielet frontendu → połączenie → migracja → logika biznesowa → obsługa błędów. Po każdym plastrze sprawdź działanie ręcznie, curlem albo agentem przeglądarkowym i zajrzyj w kod.
Na co uważać: To wymaga twojej dyscypliny — model nie zaproponuje tego sam, a każdy plaster to dodatkowa runda dialogu. Przy trywialnych zmianach to niepotrzebny narzut.
6.Mierzalny cel zamienia agenta w maszynę do optymalizacji
Na czym polega: Gdy podasz agentowi twardą metrykę — konwersję, koszt, czas odpowiedzi, redukcję zużycia zasobów — może iterować sam i sam ocenić, który wariant wygrał. To jest „ciśnienie zwrotne”: deterministyczny sygnał zamiast opinii.
Jak stosować: Przy każdej funkcji dopisz w PRD sekcję „jak mierzymy sukces”. Jeśli da się to spiąć z rzeczywistymi danymi produktu, pozwól agentowi wystawić kilka wariantów i codziennie sprawdzać wynik.
Na co uważać: LLM jako sędzia jest znacznie słabszym sygnałem niż liczba z produkcji — działa najlepiej, gdy zawęzisz jego zadanie do binarnego „czy reguły dotrzymane: tak/nie”. I uważaj na metryki proxy: agent zoptymalizuje dokładnie to, co zmierzysz.
7.Wciągnij do repozytorium wszystko, co żyje poza kodem
Na czym polega: ADR-y w /docs/adr, konfiguracja zewnętrzna w /docs/external — jakie zmienne środowiskowe istnieją (bez wartości), jak wygląda setup płatności, jakie e-maile testowe, gdzie piszą klienci. Modele nie mają dostępu do wiedzy plemiennej zespołu, ale świetnie radzą sobie z plikami: read, write, edit, grep, bash.
Jak stosować: Zacznij od ADR-ów dla decyzji, które już podjęliście i których nie chcecie co miesiąc renegocjować. Dołóż hooka startowego, który deterministycznie pobiera to, co potrzebne (np. ostatnie zgłoszenia z Sentry) — to kosztuje cykle procesora, nie inferencję.
Na co uważać: Nie wrzucaj do repozytorium sekretów ani wartości zmiennych — tylko ich strukturę. I pilnuj aktualności: nieaktualny ADR jest gorszy od jego braku, bo model potraktuje go jako prawdę.
8.Właściwe tokeny, nie więcej tokenów
Na czym polega: Jedynym prymitywem, na którym pracujesz, jest okno kontekstowe. Trzy zasady: żadnych błędnych informacji, żadnych braków, a poza tym możliwie zwięźle. Ta reguła wynika z fizyki uwagi w transformerach, więc będzie aktualna do czasu zmiany architektury.
Jak stosować: Przy trudnych zadaniach świadomie dobieraj, co trafia do kontekstu, i wybieraj oszczędniejsze formaty (XML zamiast JSON). Przy prostych zmianach po prostu zaufaj modelowi, że sam doczyta — 200–300 tysięcy tokenów nie jest dziś problemem.
Na co uważać: Nie zabijaj przestrzeni na kreatywność. Powiedzenie modelowi jak ma coś zrobić zwiększa szansę trafienia w twoje oczekiwania, ale odbiera szansę na rozwiązanie lepsze niż twoje.
9.Strefa głupoty istnieje — u modeli i u ludzi
Na czym polega: Gdy okno kontekstowe się zapełnia, jakość spada; niektóre modele wpadały wręcz w „lęk kontekstowy” — zaczynały iść na skróty i się poddawać, jak uczeń, któremu na egzaminie zostało pięć minut. Dokładnie to samo dotyczy zmęczonego człowieka pracującego trzy godziny nad czymś, co nie ma znaczenia dla biznesu.
Jak stosować: Gdy wyniki się psują, jedną z pierwszych rzeczy do wypróbowania jest skompresowanie stanu do dokumentu i start nowej sesji. U siebie: wyjdź na spacer i zapytaj, czy to, nad czym siedzisz, w ogóle wpływa na biznes.
Na co uważać: Sztywna reguła „nigdy powyżej 100 tysięcy tokenów” to szczyt krzywej midwita — kompaktowanie i modele są dziś dużo lepsze. Buduj intuicję zamiast trzymać się liczby.
10.Optymalizuj wąskie gardło, nie stanowisko
Na czym polega: Teoria ograniczeń z „Celu” Goldratta: maksymalizacja wykorzystania każdego stanowiska z osobna piętrzy produkcję w toku przed wąskim gardłem. Jeśli twoim wąskim gardłem jest przegląd kodu, dokładanie agentów kodujących nic nie da. Liczy się wartość dostarczona użytkownikom end-to-end.
Jak stosować: Zanim ulepszysz setup, nazwij swoje aktualne wąskie gardło. Jeśli to przegląd — inwestuj w testy regresyjne, agentowy review, lintery, monitoring złożoności i w to, żeby agent sam weryfikował swoje zmiany. Jeśli to brak klientów — przestań dopieszczać routing multiagentowy.
Na co uważać: Będziesz widział nieefektywności, od których cierpnie skóra, a które nie są wąskim gardłem. Naucz się je świadomie zostawiać — jak żarzące się węgielki, których nie trzeba gasić, dopóki nie zagrażają całemu miastu. „Przestań się bawić agentami i wracaj do pracy” to najkrótsza wersja tej rady.