Twoje prompty kuleją

O czym jest ten film

1. Theo rozprawia się z modą na „inżynierię promptów”: nie wzywa do dokręcania promptów śrubą inżynierską — przeciwnie, problemem jest nadmiar tego myślenia i patrzenie na wszystko jak na kod do napisania.
2. Sedno tezy: większość ludzi nie dociska promptów. Agenci potrafią o wiele więcej, niż zakładamy, bo wciąż czekamy na „funkcję w produkcie”, zamiast poprosić o wynik.
3. Przykład z życia: znajomy czekał na funkcję analizującą czasy wywołań narzędzi w T3 Code — okazało się, że wystarczy poprosić agenta o raport, i to nawet w aplikacji mobilnej.
4. Spora część „funkcji” to tak naprawdę informacja; jeśli da się ją zdobyć pytaniem, nie musi istnieć jako przycisk w interfejsie.
5. Promptami diagnozuje się własne środowisko: Theo w ten sposób znalazł m.in. przeszukiwania katalogu trwające 41 minut i 70 tysięcy tokenów śmieci wstrzykiwanych przez proxy do każdego zapytania.
6. Gdy ta sama prośba wraca jak bumerang, czas ją utrwalić — jako skill albo wpis w plikach agent.md/claude.md; to sygnał, że prompt „dojrzewa” do stałej formy.
7. Nawykowe narzekania na agentów też da się obsłużyć promptem: wybór subagenta czy modelu do zadania można po prostu opisać słowami, zamiast budować rozwijane menu.
8. t3 triage: funkcja planowana na tysiące linii kodu zmieściła się w pięciu linijkach kodu i trzydziestu linijkach markdownu — cały proces wsparcia użytkownika to jeden prompt przepuszczony przez Claude Code albo Codexa.
9. Agentów można odpytywać o nich samych: do jakich danych i dostępów sięgają, czego im brakuje, czemu czegoś nie zrobili — odpowiedzi to gotowy backlog prymitywów do zbudowania.
10. Domknięcie emocjonalne: po „dolinie rozpaczy” (dewaluacja starych umiejętności) inżynieria wraca na wyższym piętrze — systemy, kompilatory, runtime’y — i jest intensywniejsza niż kiedykolwiek.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Najpierw poproś agenta, dopiero potem planuj funkcję

Na czym polega: Zanim pomyślisz „przydałaby mi się funkcja X w narzędziu”, poproś agenta o wynik, który ta funkcja miałaby dostarczyć. Spora część potrzeb to jednorazowe pytania o dane, a nie trwałe elementy interfejsu.

Jak stosować: Sformułuj potrzebę jak zamówienie: „przeanalizuj wszystkie wywołania narzędzi na tej maszynie i wskaż najwolniejsze” albo „zrób raport z otwartych wątków i zaproponuj, co zamknąć”. Wynik często przychodzi jako raport albo strona HTML — bez linijki kodu po twojej stronie.

Na co uważać: Takie zadania potrafią trwać kilka minut; odpalaj w tle i wracaj, gdy się skończą. Jeśli prosisz o to samo co tydzień, to sygnał, by zapisać to jako skill — albo jednak zbudować funkcję.

2.Odpytuj agentów o telemetrię własnego środowiska

Na czym polega: Agent ma w zasięgu historię wywołań, czasy działań i zużycie kontekstu — danych, których często nie wystawia żaden interfejs. Wystarczy o nie zapytać.

Jak stosować: Wprowadź do rutyny pytania w stylu: „pokaż, jak zużywane jest okno kontekstowe tego wątku”, „które polecenia trwają najdłużej i dlaczego”. Na tej podstawie poprawiaj konfigurację: powłokę, proxy, ustawienia narzędzi.

Na co uważać: Analiza jest tylko tak dobra, jak zgromadzone dane — czego nie logujesz, tego agent nie zobaczy. Wtedy zapytaj go wprost, co warto zacząć zapisywać.

3.Rozróżniaj funkcję od informacji

Na czym polega: Część „funkcji”, o które prosimy, wcale nie musi być funkcją — to informacja. Jeśli da się ją zdobyć inaczej, wystarczy, że narzędzie wystawia dane w dogodnej formie.

Jak stosować: Przy każdym pomyśle na nową opcję zapytaj: czy użytkownik potrzebuje trwałego interfejsu, czy jednorazowej odpowiedzi? Jeśli odpowiedzi — zaprojektuj ekspozycję danych (logi, API, plik stanu), a nie przyciski.

Na co uważać: Nie każda prośba jest informacją — jeśli ludzie potrzebują czegoś codziennie i szybko, klasyczna funkcja nadal ma sens. Granicę wyznacza częstotliwość użycia i wygoda.

4.Zamiast skomplikowanego przepływu — jeden porządny playbook

Na czym polega: Procesy o wielu gałęziach (np. wsparcie użytkownika, triage błędów) można opisać jako instrukcję w markdownie i przepuścić przez agenta, zamiast budować maszynerię stanów i formularzy. W t3 triage zamiast tysięcy linii kodu wyszło pięć linii kodu i trzydzieści markdownu.

Jak stosować: Zapisz cały scenariusz jako prompt: rola („jesteś inżynierem wsparcia”), kroki (zbierz opis problemu, dopytaj przy ogólnikach, przeczytaj dane z maszyny, sprawdź nowszą wersję playbooka, zbadaj źródła, zaproponuj rozwiązania, zgłoś issue), zasady (usuń sekrety, wol istniejące zgłoszenia od nowych). Podłącz pod jedną komendę.

Na co uważać: Jakość doświadczenia zależy od modelu — testuj także na słabszych. Twarde gwarancje (bezpieczeństwo, audyt) nadal wymagają kodu, nie promptu.

5.Pytaj agenta, jakich danych i narzędzi mu brakuje

Na czym polega: Po nieudanym debugowaniu możesz zapytać: „czy miałbyś dane, by ustalić, co się stało? jakie dane powinniśmy zacząć zbierać?”. Odpowiedzi to gotowa lista prymitywów do zbudowania.

Jak stosować: Po każdej sesji, w której agent utknął, zapytaj o przyczynę: brak logów? brak narzędzia? brak dostępu? Wprowadzaj je iteracyjnie — projektujesz system pod agentów zamiast zgadywać.

Na co uważać: Rekomendacje bywają ogólnikowe; przefiltruj je przez koszt logowania i prywatność. Nie zbieraj danych „na zapas” bez konkretnego zastosowania.

6.Odpytuj agenta o jego własne możliwości

Na czym polega: Agent potrafi opisać, do czego ma dostęp: mysz, klawiatura, zrzuty ekranu, drzewo dostępności, pliki, karty przeglądarki. Taki opis można wykorzystać do budowy i porównań między narzędziami.

Jak stosować: Pytaj: „opisz szczegółowo możliwości sterowania komputerem, do których masz dostęp”. Jeśli w innym narzędziu agent ma więcej — poproś o streszczenie różnicy i przekaż je jako specyfikację do sklonowania.

Na co uważać: Samoopis bywa niepełny lub nieaktualny — weryfikuj testami. Różnice mogą wynikać z ograniczeń bezpieczeństwa, a nie z braku pomysłu.

7.„Dlaczego tego nie zrobiłeś?” — pytaj, zanim obwinisz

Na czym polega: Zamiast zakładać, że agent „nie umie”, pytaj o przyczyny: dlaczego nie dodał zrzutu ekranu do PR-a, jakiego narzędzia by mu brakowało, czemu nie rozgryzł buga.

Jak stosować: Traktuj wyjaśnienia jako hipotezy i wskazówki projektowe — często wskazują brakujący prymityw (narzędzie, dostęp, dane), który wystarczy dodać, by problem zniknął.

Na co uważać: Wyjaśnienia modelu to nie zawsze prawda o świecie — bywają konfabulacją. Potwierdzaj je eksperymentem, zanim zbudujesz pod nie infrastrukturę.

8.Powtarzane instrukcje koduj jako skills i pliki wytycznych

Na czym polega: Gdy zauważysz, że formułujesz w kółko to samo polecenie, przestań je klepać — zapisz jako skill albo dopisz do agent.md/claude.md.

Jak stosować: Zaczynaj od gołych promptów; utrwalaj dopiero po kilku powtórzeniach. Prowadź mały katalog sprawdzonych skills i podpinaj go do swoich środowisk.

Na co uważać: Zbyt wczesne kodowanie zamraża prompt, zanim się sprawdzi. Pliki wytycznych wymagają konserwacji — przeterminowane instrukcje psują zachowanie agentów.

9.Buduj prymitywy i rurociągi (MCP), nie przyciski

Na czym polega: Skoro agent może tworzyć własne „funkcje” na zamówienie, pracę inżynierską warto kierować w to, co pomnaża możliwości promptów: ekspozycję interfejsów przez MCP, dostęp do danych, łączenie narzędzi.

Jak stosować: Wystaw interfejs aplikacji po MCP, żeby inne agenty mogły nim sterować; podepnij źródła danych (pocztę, dashboardy, repozytoria) do jednego miejsca. Wtedy jedno zdanie uruchamia całą kaskadę agentów.

Na co uważać: Prymitywy to projektowany system — pomyśl o uprawnieniach, sekretach i audycie. Nie wystawiaj „wszystkiego”; każdy dostęp to też potencjalna powierzchnia ataku.

10.Przeżyj „dolinę rozpaczy” świadomie i wyjdź z niej z planem

Na czym polega: Dewaluacja starych umiejętności (języki, frameworki, detale zapytań SQL) boli i bywa odczuwana jako koniec inżynierii. To etap przejściowy — po nim praca wraca na wyższym poziomie abstrakcji.

Jak stosować: Daj sobie czas; testuj głębsze tematy (własny runtime, kompilator, warstwa połączeń), które dawniej nie miały sensu. Zadawaj sobie pytanie: co zbudować, żeby agenci mogli więcej?

Na co uważać: Akceptacja wygenerowanego kodu nie zwalnia z testów i przeglądu — „działa i jest pokryte testami” to warunek, nie opcja. Nie lekceważ też krytyków zbyt pochopnie: część zarzutów o jakość bywa zasadna.

Redakcyjne tłumaczenie

Koniec z mitem inżynierii promptów

Pamiętacie całą tę wrzawę wokół „inżynierii promptów” — idei, że żeby nasi agenci odnosili sukcesy, musimy pisać prompty coraz bardziej szczegółowo? Że wyrośnie z tego zupełnie nowa, poważna dziedzina, którą trzeba studiować i w której trzeba się doskonalić? Tak, to bzdura. Nie będę udawać, że jest inaczej. Nie zamierzam też przekonywać, że inżynierowie powinni jeszcze mocniej „inżynierować” swoje prompty. Chcę powiedzieć coś odwrotnego.

Moim zdaniem inżynierowie promptują słabo — ale nie dlatego, że wkładają w to za mało inżynierii, tylko dlatego, że wkładają w to zbyt dużo. I nie korzystają z okazji, jaką daje promptowanie: żeby na moment się cofnąć i od nowa przemyśleć, jak komputer może pracować dla nas. Zastanawiam się, gdzie przebiega granica między promptem a inżynierią i kiedy opłaca się sięgnąć po jedno albo drugie. Ale jedno chcę podkreślić przede wszystkim: większość z nas po prostu nie dociska promptów.

Sam jestem dopiero na początku tej drogi. Pomagam znajomym inżynierom docierać do tego olśnienia, rozmawiając szczerze o tym, jak na co dzień używamy AI — i wciąż mnie zaskakuje, ile osób nie przeżyło jeszcze tego pierwszego „aha”: że agent potrafi więcej. Zeszłego tygodnia miałem niemal identyczną rozmowę z inżynierem, który właśnie założył firmę i przeszedł przez Y Combinator, i ta rozmowa odmieniła sposób, w jaki myśli o swoich agentach. Uświadomiłem sobie, że muszę znaleźć czas i wytłumaczyć to wam wszystkim — żebyście choć na chwilę wyszli z inżynierskiego pudełka i naprawdę pomyśleli o tym, jak agenci mogą pomóc w codziennej pracy: przy tym, co budujecie i kodujecie, i przy wielu innych rzeczach. To jest przewodnik po lepszym promptowaniu i po wydostaniu się z inżynierskiego pudełka we własnej głowie.

Przerwa na sponsora: Macroscope

Inżynierowie uwielbiają rzeczy, o których tu rozmawiamy — na przykład dzisiejszego sponsora.

Może zauważyliście, że ostatnio sporo wysyłamy na rynek. Trzymanie ręki na pulsie graniczy z niewykonalnością, a ludzie ciągle pytają, jak udaje mi się nie zgubić. Bez dzisiejszego sponsora, Macroscope, raczej by mi to nie wychodziło. Ci goście zbudowali nie tylko ulubione narzędzie mojego zespołu do przeglądu kodu — także sporo rzeczy przydatnych mnie jako prowadzącemu drużynę. Widać to od razu po zalogowaniu. Dashboard, na który trafiam, pokazuje, kto nad czym pracuje, i podsumowuje wszystko, co niedawno wypuściliśmy: moją szaloną robotę nad portem TypeScriptu do Rusta, generalny remont klienta T3 Code, zmiany w runtime agentów i w końcu wylądowanie Orkiestratora V2, narzędzia dokładane do Lakebed, warstwę Web MCP i całą resztę. Dostaję też rozpiskę per współpracownik: kto co wysyła i jaka część jego pracy faktycznie trafia do maina. Moje liczby są tu trochę napompowane — dane pochodzą z 2 października, a nagrywam 6 — ale to dlatego, że autonomiczny wątek właśnie ląduje całą serię zmian w przepisywaniu na Rusta.

Lubię tych ludzi na tyle, że zrobię coś, czego w reklamie nie robiłem od dawna: zajrzymy do kodu w prawdziwym repozytorium. W Macroscope możesz wrzucić do projektu folder .macroscope i definiować własnych agentów, którzy odpalają się na pull requestach i wypatrują konkretnych rzeczy. Mieliśmy sporo problemów z tym, że ludzie tworzyli nowe komponenty zamiast korzystać z istniejących — więc uruchomiliśmy agenta „spójność UI”. Dobra, to markdown, nie prawdziwy kod. Przepraszam, jeśli ktoś poczuł się naciągnięty. Definiujemy, czym ten agent jest, na jakim modelu działa, jakie ma narzędzia i czego ma szukać. I teraz przy każdym PR-ie, który dotyka wskazanych plików — z pominięciem innych, bo nie chcę, żeby ruszały wszystkie pliki TSX; jeśli zmiana dotyczy samych testów, nie ma co sprawdzać drugi raz — pracuje osobny agent. Macroscope sprawiło, że mój zespół wysyła lepszy kod, a ja zostałem lepszym szefem. Sprawdźcie, jak to działa, na swyx.io/macroscope.

Chwila w skórze zwykłego użytkownika

Koniec przerwy. Na moment musimy wyjść z inżynierskiego pudełka. Zamieszkajmy w świecie, w którym nie istnieją JavaScript ani TypeScript, w którym nie narzekamy, że aplikacja siedzi na Electronie zamiast w Ruście. Musimy się zanurzyć w doświadczeniu zwykłego śmiertelnika.

Zacznijmy od jednego z moich ulubionych pasków XKCD (Informacja dodatkowa: klasyczny komiks o tematyce technicznej). Zwykły człowiek zgłasza inżynierowi: „Kiedy użytkownik robi zdjęcie, aplikacja powinna sprawdzić, czy jest w parku narodowym”. Inżynier: „Jasne, prosty odczyt z GPS-a, dajcie mi kilka godzin”. Da się przecież wyznaczyć obszary dla interesujących nas parków i sprawdzić, czy współrzędne mieszczą się w którymś — to klasyczne zadanie algorytmiczne, którego rozwiązałem w życiu dość. A potem pada druga część: „Aplikacja powinna też sprawdzić, czy zdjęcie przedstawia ptaka”. — „Do tego będę potrzebował zespołu badawczego i pięciu lat”.

Ten komiks jest oczywiście sprzed ery AI — dziś mnóstwo modeli wizyjnych załatwia takie rzeczy bez wysiłku. Ale wtedy naprawdę trzeba byłoby pięć lat badań, bo rozpoznawanie ptaka na zdjęciu wymagałoby wynalezienia AI. Zwykli ludzie nie potrafią ocenić, co jest technicznie trudne. A my, inżynierowie, siedzimy teraz na drugim biegunie: tak bardzo przywykliśmy do złożoności, że nie wiemy, o co wolno nam prosić agenta — bo wciąż myślimy kodem.

Rozmowa, która otwiera oczy: „To już mamy”

Będę teraz bardzo dosłowny i opowiem o rozmowie, którą kilka dni temu odbyłem ze znajomym. Chciałem pogadać o wywołaniach narzędzi w T3 Code (Informacja dodatkowa: open source’owe narzędzie Theo do pracy z agentami kodującymi). I wbrew pozorom wcale nie jest to reklama tego produktu — w wielu miejscach wręcz przeciwnie.

Ostatnio sporo czasu spędzam w T3 Code i innych narzędziach na audycie wszystkiego, co agenty narobiły na moich maszynach. Wyłapałem kilka charakterystycznych typów błędów. Na przykład: większość nieudanych wywołań narzędzi przez Claude wynikała z tego, że model wołał Ripgrep ze składnią i sposobem łamania linii, które działały w Bashu, ale nie w Zsh. A że na większości moich linuksów i na wszystkich makach mam Zsh, tam, gdzie pracował Claude, błędów było wyraźnie więcej — model zapisywał polecenia w sposób niekompatybilny z powłoką.

Wspomniałem o tym znajomemu, a on odparł mniej więcej tak: „O, ciekawe. Już od dawna chciałbym w T3 Code funkcji, która rozpisze mi, ile trwają poszczególne wywołania narzędzi. Żebym wiedział, które są najwolniejsze, które komendy ciągną się godzinami, i mógł lepiej poukładać środowisko”.

Jeśli używacie T3 Code, moja odpowiedź albo w ogóle was nie zdziwi, albo zdziwi mocno. Odpowiedziałem: „To już mamy”. I nie tylko w aplikacji desktopowej — mamy to także w mobilnej. Był szczerze zaskoczony, więc kazałem mu wyjąć telefon, otworzyłem aplikację i pokazałem mu, gdzie tego szukać.

Pokażę wam to samo. Zakładam nowy wątek bez projektu, żeby było szybko przy nagrywaniu; przełączam się na GPT-6 Astra w trybie ultra-szybkim, więc powinno pójść żwawiej. Kopiuję prośbę znajomego: „Przeanalizuj wszystkie moje wywołania narzędzi w T3 Code, żebym znalazł najwolniejsze i zoptymalizował środowisko”. Mogę dodać „na tej maszynie”, jeśli o nią chodzi — mogę też wspomnieć o pozostałych. Klikam wyślij i po jakichś trzech minutach, miejmy nadzieję krócej, mam szczegółową rozpiskę wszystkiego, co robiły moje agenty na tym komputerze.

I o to chodzi: wielu inżynierów wciąż traktuje takie przepływy jak funkcje, które ktoś musi zbudować w produkcie. Przyzwyczailiśmy się, że żeby coś wyciągnąć z narzędzia, najpierw musi istnieć w nim odpowiednia opcja. A teraz wystarczy poprosić — i to jest fundamentalnie inna sytuacja. Nie mówię, że każdy ma zacząć dodawać własne funkcje do T3 Code (choć bardzo chcę dopiąć rozszerzenia i wewnętrzne forkowanie, to będzie świetne). Mówię o funkcjach, które nie są funkcjami. To informacja. Jeśli da się ją zdobyć inną drogą, nie musi istnieć jako funkcja — wystarczy, że narzędzie wystawia dane tak, by dało się z nimi zrobić coś fajnego.

Dashboard, który powinien być rozmową

Teraz przykład, w którym sam się pomyliłem. Miała być (i z przerwami jest) funkcja T3 Code: alternatywny panel dla całej pracy w toku. Lista zadań i ich statusów, plus agent, który programowo przechodzi po wszystkich i mówi, w jakim są stanie oraz co z nimi zrobić. Umie zmieniać nazwy wątków, zamykać je, scalać PR-y: „Masz czterdzieść wątków. Te osiem jest gotowe do scalenia i zamknięcia, te dwadzieścia nadają się tylko do kosza, reszcie zmienię nazwy i posegreguję, a do tamtych wyślij takie a takie polecenia”. Czułem się bardzo sprytny, że to wymyśliłem — panel, na którym widać wszystkie trwające zadania w jednym miejscu i którym można nimi sterować. No i zacząłem dorzucać kolejne elementy: przyciski na każdą możliwą potrzebę, przycisk do automatycznej regeneracji wszystkich tytułów i tak dalej. Aż w pewnym momencie zrozumiałem: mogę dokładać kolejne gadżety na wszystkie wyobrażalne sposoby użycia — albo mogę zrobić z tego czat. Meta-wątek w T3 Code, spięty ze wszystkimi instancjami T3 Code na wszystkich moich środowiskach, w którym po prostu prosisz o to, czego chcesz. Chcesz ładny panel? Powiedz — a on go zrobi.

Tymczasem raport jest gotowy. Nie prosiłem nawet, żeby robił z tego stronę, a zrobił. Mam raport wszystkich wywołań narzędzi i czasów ich trwania na tej maszynie. Okazuje się, że jedno przeszukiwanie katalogu domowego ciągnęło się 41,7 minuty, inne prawie dziesięć. Przeszukiwanie repozytorium czy znanego katalogu… To są użyteczne dane, których wcześniej nie miałem — bo nie zapytałem modelu w ten sposób. Zobaczcie, jak łatwo o taką wiedzę, gdy się po prostu prosi.

Pytaj o kontekst — i nie przejmuj się, że chwilę potrwa

Kolejna rzecz, o którą zapytacie częściej, niż myślicie, to zużycie kontekstu w T3 Code. Sprawdźmy: „Rozbierz bieżące okno kontekstowe tego wątku w T3 Code i zrób czytelną wizualizację”. Za chwilę dostanę obraz tego, jak mój kontekst jest wykorzystywany. Wiem, że to zadziała, bo użyłem tego wczoraj, nagrywając inny materiał — i właśnie tak odkryłem, że przez konfigurację mojego proxy Railway wstrzykiwało 70 tysięcy tokenów do każdego pojedynczego zapytania. Co ciekawe, mamy przycisk pokazujący zużycie kontekstu, ale schowaliśmy go za opcją dla starszych wersji — bo w ogóle nie powinniśmy musieli o takich rzeczach myśleć. I skoro przez dwa miesiące nosiłem na początku każdego prompta 70 tysięcy tokenów śmieci, nie zauważywszy tego — to zastanówcie się, ile naprawdę znaczy dziś ręczne zarządzanie kontekstem.

Oczywiście, gdy odpalicie Opusa 5.5 na najwyższych ustawieniach, danych nie dostaniecie od ręki. Ale gdy tylko wejdzie wam w krew tryb „odpal w tle, niech wyskoczy, gdy będzie gotowe”, zobaczycie, że czas wykonania ma drugorzędne znaczenie — byle nie potrzebować wyniku natychmiast.

Najważniejsze, do czego chcę was zachęcić: myślcie o rzeczach, których chcecie, i sprawdzajcie, jak je zdobyć, nie budując — tylko prosząc o nie. I nie mówię tego po to, żebyśmy się ustatkowali w lenistwie i palili tokeny zamiast pisać wydajny kod. Wręcz odwrotnie. Gdy zrozumiecie, że istnieją rzeczy, których budowanie nigdy nie byłoby warte zachodu, a które tu i teraz mają dla was wyraźną wartość, nagle zaczniecie ich robić mnóstwo. Budowałem głębokie, złożone wizualizacje, żeby przemyśleć jednego buga. Zbudowałem własną platformę do zarządzania historią słuchania muzyki, bo chciałem łatwiej spiąć zrzut danych z Tidala ze starymi scrobblami z Last.fm (Informacja dodatkowa: scrobbling to automatyczne zapisywanie historii odsłuchiwanych utworów w serwisie Last.fm). To wszystko funkcje, które można by wbudować w cudze produkty — albo produkty do zbudowania dla siebie. Nauczyłem się po prostu traktować je jako prompty. A zdziwilibyście się, ile użytecznych rzeczy da się znaleźć i zrobić, gdy zacznie się o nie prosić.

I wracając do zwykłego użytkownika z komiksu i jego niewinnego „sprawdź, czy na zdjęciu jest ptak”: zamiast prosić mnie o zbudowanie funkcji w T3 Code, spróbujcie poprosić agenta o sam wynik.

Narzekasz na agenta? Powiedz mu, czego chcesz

Najlepiej widać to na skargach, jakie ludzie mają na agentów. Ktoś niedawno proponował, żebyśmy w nowej warstwie orkiestracji T3 Code dodali opcję wyboru subagenta dla modeli. Brzmi nieźle — dopóki nie przypomnicie sobie, że subagenta wybiera model. Więc wystarczy mu powiedzieć. Nie chcę tu wcale wychwalać T3 Code, ale gdybym przełączył się na — nie wiem — 6.1 Soul w średnio szybkim trybie, mógłbym poprosić: „Odpal dwóch delegatów na Opusie 5.5, żeby zbadali możliwości podniesienia wydajności w T3 Code, streść ich wnioski, a potem otwórz nowy wątek na Groku 4.7 i wprowadź ustalenia w życie”. Mogę wybrać komputer, na którym to poleci — rzucam to na laptopa, żeby dało się podejrzeć i żeby Grok zadziałał. Teraz mój abonament Codex wystartuje to zadanie, przywoła dwie instancje Claude Code w ramach tego wątku, a po zakończeniu założy nowy wątek z wynikami. Mógłbym dorobić rozwijane menu czy sekcję „jakiego subagenta użyć”. Ale można też po prostu poprosić. Patrzcie: dwaj delegaci pracują, eksploracja po stronie serwera i klienta na Opusie 5.5 ruszyła, bo im tak kazałem. Nie wybierałem modelu subagenta z listy. Powiedziałem, czego chcę.

A jeśli zauważycie, że powtarzacie w kółko to samo — to właśnie moment, żeby zacząć dopieszczać swoje skills i pliki agent.md / claude.md (Informacja dodatkowa: skills to zapisane, wielokrotnego użytku instrukcje, które agent przywołuje w razie potrzeby; pliki agent.md i claude.md to stałe wytyczne czytane przy każdym zadaniu). O, patrzcie — rozbiór okna kontekstowego właśnie się skończył. I proszę: zamiast budować w T3 Code funkcję wizualizacji kontekstu — zapytałem i mam wizualizację. Chcę coś zmienić, dopytać albo pójść dalej? Mogę poprosić i zostanie zrobione. A jeśli okaże się wystarczająco użyteczne, zapamiętam to jako skill na przyszłość.

Powrót do inżynierii: t3 triage

Dotąd było o promptowaniu i wychodzeniu z inżynierskiego pudełka. Teraz sedno sprawy: co się dzieje, gdy z tym nastawieniem wracamy do inżynierii. Kiedy przeniosłem ten nawyk do pracy inżynierskiej i budowania produktów — zwłaszcza w T3 Code — fundamentalnie zmieniło mi się spojrzenie na to, co dodajemy i jak to dodajemy.

Pokażę przykład. Ktoś miał poważne kłopoty z T3 Code na Windowsie — aplikacja bez przerwy się wywalała — a ja w praktyce pisałem dla niego prompty do Claude Code, żeby debugował problem na swojej maszynie. To wystarczyło, żeby zrodził się pomysł na funkcję. Jedna z fajniejszych rzeczy, jakie mamy w T3 Code, nie znajduje się w T3 Code, tylko w CLI: npx t3 triage. Wbudowany triager do diagnozowania problemów na twojej maszynie. Umieściłem go w terminalu, bo ma działać nawet wtedy, gdy aplikacji desktopowej nie da się otworzyć.

Pewnie już domyślacie się, co zrobiłem. Na pewno nabazgrałem szaloną, złożoną maszynę, która podpina się pod wszystkie zakamarki T3 Code i — jak lekarz zbierający dane z każdej strony — zgaduje, gdzie leży błąd? Nic z tych rzeczy. Chcecie zobaczyć, co robi? Enter. Zgadzam się na instalację, bo nie mam tu najnowszego stabilnego builda. Pyta, czy użyć Claude Code czy Codexa — Claude Code. I tyle: triager po prostu wstrzykuje prompt wprost do Claude Code, przesyłając go przez wybrany przez ciebie program agentowy. A w prompcie siedzą bardzo konkretne instrukcje — mogę wam je pokazać.

Zaczyna się tak: „Użytkownik T3 Code ma problem z instalacją i rozpoczął tę sesję przez t3 triage. Dane o maszynie: podstawowe informacje o T3 Code na tym komputerze zostały zrzucone do pliku pod podaną ścieżką. Postępuj zgodnie z playbookem poniżej”. Potem: „Jesteś inżynierem wsparcia technicznego. Pracujesz wewnątrz sesji agenta kodującego: pomóż zdiagnozować problem, odblokuj użytkownika, a jeśli jest powód, spisz wszystko jako dobrze napisany issue na GitHubie”.

A playbook? Najpierw: zapytaj, co się stało. Pierwsza wiadomość do użytkownika prosi o opisanie problemu własnymi słowami, najlepiej z dołączeniem zrzutu ekranu, jeśli taki ma; dopytuj, gdy opis jest mglisty, bo dobre kroki odtworzenia błędu to najcenniejsza rzecz, jaką da się z rozmowy wyciągnąć. Potem: przeczytaj dane o maszynie i sprawdź, czy nie ma nowszej wersji playbooka — linkuję go publicznie, bo projekt i tak jest open source, żeby na wersjach nocnych agent łapał świeże informacje. Dalej: pobierz źródła — skoro jesteśmy open source, agent może sklonować kod i poszukać usterki w nim samym. Następnie: zbadaj, sprawdź w upstreamie, czy błąd nie został już naprawiony, zaproponuj użytkownikowi rozwiązania. Zgłoś issue, jeśli jest co zgłaszać, a problem nie wynika wyłącznie ze złej konfiguracji u użytkownika. Przed zgłoszeniem wyczyść z danych wszystkie sekrety. I wol istniejące zgłoszenia od nowych: jeśli temat już istnieje, dopisz komentarz tam.

To wszystko, czego potrzeba, żeby użytkownik rozwiązał swój problem. Jedna komenda, ląduje w Claude albo Codexie i może naprawić swoją sprawę. Gdy zaczynałem nad tym pracować, miała to być funkcja na tysiące linii skomplikowanego kodu. Wyszło pięć linii kodu i trzydzieści linii markdownu — a działa o niebo lepiej. Nie opiszę, ile sił włożyłem w to, żeby dało się wkleić obrazek bezpośrednio do t3 triage i go sensownie pokierować, zanim dotarło do mnie: przecież Claude albo Codex może po prostu poprosić użytkownika o wklejenie obrazka. Tak jest łatwiej. Odpal komendę i opowiedz agentowi, co ci dolega.

To jeden z dwóch filarów tego materiału. Mnóstwo przepływów jest zbyt dynamicznych, ma za dużo rozgałęzień i dziur, w które użytkownik może wpaść, żeby budować złożoną funkcję obejmującą wszystko. Gdybym znał wszystkie sposoby, w jakie T3 może się wysypać, ta funkcja w ogóle nie byłaby potrzebna — po prostu naprawiłbym wszystko. Ale nie znam. T3 Code może się wysypywać tak, że użytkownik nie uruchomi aplikacji albo nie ustawi jej tak, jak chce. I skierowanie takich spraw przez Claude Code albo Codexa sprawia, że gdy ktoś trafi na krawędź, rośnie szansa, że da się z niej wybrnąć — bez specjalnej funkcji wbudowanej w produkt.

Skoro połowa rzeczy to markdown — to co budować? Zapytajmy

Skoro połowa tego, co powinniśmy budować, powinna być plikiem markdown — to co w ogóle budować? Nie wiem. Zapytajmy.

Przykład. Właśnie w tym oknie t3 triage męczyłem się z niedawnym buildem, który migotał przy tworzeniu nowych wątków. Chyba już naprawione, ale kosztowało mnóstwo pracy, bo moim zdaniem nie logujemy dość danych o renderowaniu aplikacji. Zadałem więc agentowi pytanie: „Gdybym poprosił cię teraz o zdebugowanie problemów z renderowaniem w T3 Code — czy masz dostęp do danych pokazujących, co działo się w przeszłości? Jeśli nie, jak zaleciłbyś nam te dane zbierać, żebyś w przyszłości miał pod ręką więcej przydatnych informacji?”.

Przy okazji: nie pojmuję, jak ludzie potrafią żyć w swoich terminalach. Właśnie nadyktaowałem głosowo akapit i nie mogę go odczytać. Wynoście się z tych cholernych terminali, ludzie. Przestańcie się wywyższać. Po prostu się mylicie. Sam byłem wielbicielem terminala i już nie dam rady. Serio, fizycznie nie dam rady.

Ta sesja oczywiście przejdzie przez sporo dodatkowych kroków, bo rusza cały przepływ triage, ale w końcu powie mi, do czego ma dostęp, do czego nie — i co warto wystawić na zewnątrz. I regularnie mnie zadziwia, jak mało inżynierów wie, że może tak zrobić.

Odpytuj agentów o nich samych

Inny świeży przykład. Próbowałem ustalić, czego potrzeba, żeby donieść do T3 Code więcej wartościowych możliwości sterowania komputerem. Wiem, że computer use w desktopowej aplikacji Codex od ChatGPT jest świetne. Więc po prostu zapytałem: „Opisz szczegółowo możliwości sterowania komputerem, do których masz dostęp”. Wszystkie te informacje siedzą w jego oknie kontekstowym — są tam, ja tylko proszę, żeby mi je podał i wyjaśnił. A potem mogę użyć tego opisu i zbudować to sam. Skopiowałem całą listę jego umiejętności do Opusa w T3 Code z poleceniem: „Sklonuj z tego, ile się da”. I sklonował. Wisi w PR-ie, mamy też inne plany. Ale rozumiecie, jakie to fajne — że można po prostu zapytać narzędzie, do czego ma dostęp? A jeśli zauważysz, że w innym narzędziu agent ma dostęp do czegoś więcej, poproś, żeby streścił różnicę.

A oto pełna lista: potrafi wykrywać aplikacje, otwierać je, czytać interfejsy — obejrzeć ekran i zrobić zrzut, zamiast dostawać tylko ustrukturyzowane dane tekstowe. Posługuje się myszą: klik, podwójny klik, prawy przycisk, przeciąganie, przewijanie. Używa klawiatury. Wypełnia pola. Obsługuje karty przeglądarki i pliki, a nawet weryfikuje własne wyniki. Czyta na dwa sposoby: przez drzewo dostępności oraz przez zrzuty ekranu.

I mam pełny obraz tego, na co go stać — zdobyty jednym pytaniem. A jeśli widzisz, że model czegoś nie potrafi albo nie robi, o to też możesz pytać. Dlaczego nie dodałeś zrzutu ekranu do tego PR-a? Jakie narzędzie by ci pomogło, żebyś w kolejnych PR-ach mógł je dołączać? Dlaczego nie rozgryzłeś tego buga? Dlaczego problem wciąż wraca? Możesz sam to uruchomić i sprawdzić, co się stało? Możesz przejrzeć transkrypt z innego wątku i ustalić, gdzie poszło nie tak?

Można promptować o własnych promptach i o własnych programach. O systemach. O własnych pytaniach. O mnóstwie rzeczy, które z inżynierią nie mają nic wspólnego. Niedawno promptowałem, żeby zebrać wszystkie moje wyniki rezonansu z portali moich lekarzy. Mógłbym napisać program, który przejdzie po wszystkich portalach, zbierze i uporządkuje PDF-y. Albo mogę poprosić agenta, żeby to zrobił.

„Brain rot”? To samo mówiono o e-mailach

Podobno takie myślenie to dziś „zgnilizna mózgu”. Odważę się twierdzić, że dokładnie to samo mówiono o poczcie elektronicznej, gdy się pojawiła. „Po co iść do lekarza albo wysyłać list, skoro można napisać maila?” — absurd, prawda? Nic mądrego z tego nie przyjdzie. No właśnie: jest mnóstwo spraw, w których wysłanie tego maila jest po prostu nieporównanie łatwiejsze. I nie chodzi o to, że „wyślę maila i już nigdy nikogo nie zobaczę”. Chodzi o to, że mailem załatwiam rzeczy, z którymi w ogóle nie pojechałbym się spotykać.

Czy spędzam z przyjaciółmi mniej czasu twarzą w twarz niż jako pięciolatek, zanim był internet? Ilościowo — pewnie tak. Ale rozmawiam z dziesięciokrotnie większą liczbą osób, a większość z nich to ludzie, z którymi nigdy nie miałbym kontaktu: nie mieszkali w pobliżu i nie miałem jak do nich dotrzeć. Z promptami jest identycznie. Nie wybieram promptowania zamiast budowania. Wybieram promptowanie rzeczy, których budowanie nigdy nie byłoby dla mnie warte zachodu. A kiedy uświadamiam sobie, jak to działa, idę krok dalej: swoją energię budowniczego kieruję na prymitywy — przepływy pracy, narzędzia, rurociągi i dostęp do danych, których potrzebują moi agenci — żeby moje prompty mogły więcej.

Podłączcie wreszcie pocztę do ChatGPT

I dochodzimy do najbłahszego przykładu, który — jestem o tym przekonany — każdy z was powinien wdrożyć, a większość tego nie zrobiła. Podłączcie swoją pocztę do ChatGPT. Wiem, że brzmi to absurdalnie. Sam zwlekałem wieki i wiem, że jeszcze absurdalniej brzmi to, jak bardzo mi to odmieniło życie. A jednak. Mam pięć skrzynek, z których cztery muszę obserwować na bieżąco. Ile godzin przesiedziałem, naganiając zespół Superhuman (Informacja dodatkowa: kiedyś uważany za najlepszy klient poczty elektronicznej), żeby działał tak, jak powinien! Superhuman był najlepszy i powoli się rozpadł. Strona Gmaila to kupa. Pozostałe aplikacje pocztowe to jeszcze większa kupa. Cztery lata byłem o krok od zrobienia własnego klienta. Ostatnio znowu się zbliżyłem. A potem skaleczyłem rękę, nie mogłem wygodnie przeglądać maili i niechętnie spróbowałem funkcji podpinania poczty — nawiasem mówiąc, wielu skrzynek naraz — do konta ChatGPT. Z dziesięciu razy dziennie ze skrzynką spadłem do mniej więcej jednego. Teraz po prostu pytam agentów. To bez porównania lepsze.

A mając narzędzia typu Dot, mogę kazać pilnować konkretnej kategorii maili. Na przykład: „Czuwaj na wiadomościach od Amazona — wiesz, że zaraz przyjdzie potężny rachunek za AWS”. Albo mogę pójść dalej. Widzę maila z rachunkiem i pytam Dotta: „Słuchaj, to wygląda na sporo. Wejdź na mój panel AWS, ustal, skąd te koszty, i pomóż mi je zbić”. I kazać mu odpalić całą chmarę innych agentów i narzędzi — u mnie zwykle T3 Code. Odkąd podpiąłem MCP T3 Code pod Codex, Codex i Dot potrafią podnosić wątki Claude’a w T3 Code (Informacja dodatkowa: MCP, czyli Model Context Protocol — otwarty standard łączenia modeli i agentów z zewnętrznymi narzędziami i danymi). Zbudowałem rurociągi, które to wszystko łączą, i spiąłem dane, których agenci potrzebują do działania. I teraz droga od wyśledzenia jednego maila do wprowadzenia realnych zmian przez kolejne agenty i programy w moich systemach jest krótka.

Nigdy nie czułem się bardziej inżynierem

I najdziwniejsze w tym wszystkim: nigdy nie czułem się bardziej inżynierem. Bywały zjazdy, momenty, gdy to uczucie gasło — i zdarzyło mi się za nie słono zapłacić. Kiedy zaczynasz przechodzić obojętnie obok kodu i akceptujesz, że język programowania czy dobierane frameworki nie znaczą już tyle co kiedyś, czujesz się mniej inżynierem. Rzeczy, którym oddałeś tyle czasu i serca, tracą dawne znaczenie — i to boli. Ale to tylko dolina rozpaczy (Informacja dodatkowa: aluzja do znanej krzywej hype’u technologicznego — etapu rozczarowania po fazie zachwytu). Bo gdy się z niej wychodzi i uświadamia, że agenci, żeby robić to, czego chcemy, potrzebują lepszych systemów do działania, rozumiesz: sprytne pomysły, dla których pokochałem inżynierię, nigdy nie były cenniejsze.

Takie błahostki jak uświadomienie sobie, że tamto pytanie czy tamta funkcja to zwykły prompt. Sprytne rozwiązanie polegające na tym, że debugowy przepływ po prostu przerzuca cię do Claude Code albo Codexa. Wystawienie interfejsu aplikacji po MCP, żeby inne agenty mogły się nim posługiwać i nim sterować. Dorzucenie Web MCP do świeżo skleconego dashboardu, żeby dało się z niego wycisnąć więcej i sięgać po niego inaczej.

Inżynieria jest właśnie cholernie zabawna. W tym roku zbudowałem ze pięć aplikacji w Ruście i mam nieporównanie głębsze rozeznanie w nowoczesnym zarządzaniu pamięcią — bo buduję pod przyszłość, w której nasi agenci działają na mocy obliczeniowej praktycznie za darmo, bo możemy ją uruchamiać w izolatach (Informacja dodatkowa: izolaty — lekkie, odseparowane środowiska wykonawcze, umożliwiające tanie uruchamianie kodu na ogromną skalę). I mam cały katalog kosmicznych pomysłów inżynierskich, które wcześniej nie wchodziły w grę: brakowało ludzi, by je zbudować, a i tak nie były specjalnie użyteczne, bo tych, którzy piszą kod (a dziś piszą go także agenci), było za mało, by te nowe prymitywy miały dla kogoś wartość. Rozwiązuję dziś problemy, które kiedyś nie były dość ważne, a ich rozwiązanie zbyt drogie — bo problem nagle zyskał na wadze, a rozwiązanie stało się na wyciągnięcie ręki.

I wszystko to sprowadza się — mówiąc szczerze — do porzucenia sposobu, w jaki przez lata robiliśmy inżynierię, żeby z promptami budować lepsze rzeczy. Nie umiem powiedzieć, jak często przewijam propozycje funkcji do T3 Code, issuesy w repo i wiadomości od ludzi. Co najmniej połowa to rzeczy, które mogliby uzyskać samodzielnie, po prostu prosząc agenta. Nie po to, żeby rozbudować T3 Code — po prostu żeby z niego korzystać. Sama liczba „funkcji”, które istnieją w T3 Code tylko dlatego, że można o nie poprosić agenta, jest szalona. Trzeba tylko budować więcej prymitywów, by je udostępniać. Przykład: dziś, gdy proszę o wizualizację, dostaję stronę HTML do otwarcia w przeglądarce. Super — ale po co wychodzić z T3 Code, żeby ją zobaczyć? Mogę otworzyć ją w przeglądarce wbudowanej (u mnie wyłączonej z rozmaitych głupich powodów) — o, proszę: „otwórz w zintegrowanej przeglądarce”. Da się. Ale czy nie byłoby lepiej, gdyby agent potrafił osadzić wizualizację wprost w rozmowie? W Codexie to mają. W T3 Code jeszcze nie. I ważne: takie dodatkowe prymitywy to nie są funkcje w klasycznym sensie — nie kolejny przycisk do klikania. Sens takiego narzędzia jest taki, żeby użytkownik mógł sam budować sobie dynamiczne funkcje. I to mnie niesamowicie kręci.

Do tych, którzy jeszcze tego nie czują

Na koniec — do ludzi, którzy tego nie czują. Którzy wciąż mają wrażenie, że tracą to, co kochali, i że inżynieria robi się z każdym dniem mniej fajna. Naprawdę to rozumiem, zwłaszcza że rozmawiałem już z wieloma osobami w tym samym punkcie. Ale szczerze wierzę, że większość z was jest blisko końca tego etapu.

Rozrysujmy krzywą: „jak bardzo czuję się inżynierem” w czasie. Na starcie — niezbyt. Potem zaczyna być całkiem nieźle. Potem odkrywasz, że jednak jesteś trochę głupi. I powoli robisz się coraz lepszy. Większość z nas przeszła już coś takiego jako inżynier. Teraz krzywa się komplikuje, bo szliśmy w górę, stawaliśmy się coraz lepsi — i nagle przyszła AI. I myślisz: to, co robię, to nie jest rozplątywanie złożonych systemów ani debugowanie kodu — ja po prostu wysyłam prompty. Ale z czasem zrozumiesz: rzeczy warte budowania są dziś znacznie głębsze i bardziej złożone.

Jestem inżynierem produktu. Buduję rzeczy, za które ludzie płacą abonamentem, zarabiam na reklamach — cześć wam, oglądający na YouTube. Kiedyś problemy warte mojego wysiłku polegały na składaniu klocków i tworzeniu rozwiązań dla użytkownika. Teraz piszę własny system operacyjny i własne kompilatory. Nie dlatego, że wcześniej nie chciałem, a nagle zachciało mi się. Robię to teraz, bo to nabrało sensu. Problemy, które można tak rozwiązać, ważą dziś więcej, a samo zbudowanie stało się realne. Zachęta wzrosła i złożoność tego, co dasz radę zbudować w pojedynkę, wzrosła.

Czy główkuję jeszcze nad detalami każdego zapytania SQL w moim kodzie? Nie, skąd. Ale czy myślę o tym, jak działa połączenie między bazą SQL a warstwą serwerową, czy da się to dalej zoptymalizować i czy nie zbudować własnej warstwy połączeń, trzymającej je na ciepło bez wywindowania kosztów? Jak najbardziej. Czy buduję kolejne stacki, które odpalicie przez npx create-t3-app? Nie. Buduję własne środowisko uruchomieniowe JavaScriptu pod własną chmurę. Pracuję dziś jako inżynier ciężej niż kiedykolwiek, a głowa chodzi mi na wyższych obrotach niż kiedykolwiek.

Jeśli widzicie, jak przewijam bez mrugnięcia oka trochę wygenerowanego przez model kodu — zwanego slopem — w projekcie, w którym wszystko działa i jest świetnie przetestowane, i wnioskujecie, że zgnili mi mózg, to po prostu nie rozumiecie, jak dużo większą pracę inżynierską możemy dziś wykonywać. I moim zdaniem spora część ludzi krytykujących deweloperów AI za „brain rot” krytykuje właśnie dlatego, że sami tkwią w tym dołku. I jest im okropnie, bo całą karierę wspinali się na szczyt, na którym stali przedtem. Tyle lat wchodzenia na ten poziom — a AI sprawiło, że wszystko wydało się bezwartościowe, bezużyteczne i głupie. Ale gdy tylko przebrniecie przez tę dolinę, gdy dołek dobiegnie końca — nagle wasz mózg zacznie pracować ciężej niż kiedykolwiek.

Mam nadzieję, że skorzystacie z okazji, by wszystko przemyśleć, i trochę pomieszkacie w tej dolinie. Spędźcie tam chwilę. Jest beznadziejnie. Boli. Wygląda, jakby wszystko, co robiliście przez lata, było na darmo — bo funkcje, które chcecie dodać, to zwykłe prompty, nie funkcje. Ale gdy dotkniecie krawędzi, gdy zobaczycie, co potrafi AI, zrozumiecie, że do zbudowania jest jeszcze góra rzeczy, żeby wycisnąć z tego maksimum. Tak chce, żebyście myśleli od dziś — bo to właśnie to olśnienie mną tak wstrząsnęło.

A jeśli wolicie wrócić do tezy, że jestem opłacany przez OpenAI i dlatego tak mówię — proszę bardzo, to dużo łatwiejsze. Z niecierpliwością czekam, aż zostaniecie bez pracy, jeśli dalej będziecie tak myśleć. Ale wy, pozostali, którzy naprawdę kochacie budowanie: nigdy nie było więcej do budowania i nigdy nie było ważniejszych powodów, żeby to robić. Mam nadzieję, że was to zainspiruje. Idźcie zbudować coś fajnego. Do następnego razu — pa, nerdzi.