O czym jest ten film
- Theo wraca do własnego prowokacyjnego wpisu, w którym porównał spory o harnessy do wojny „tabulatory kontra spacje”, i zapowiada ostatni w życiu materiał o tym temacie.
- Fundament wywodu: model językowy sam z siebie wytwarza wyłącznie tekst. Harness to warstwa, która daje mu „ręce” — narzędzia oraz składnię, w której może prosić o odczyt pliku, edycję kodu czy uruchomienie polecenia.
- Kluczowa metafora: genialny kucharz w pustej kuchni nic nie ugotuje. Model bez narzędzi może co najwyżej opowiedzieć, co by zrobił.
- Theo rozdziela trzy pojęcia: model, harness i interfejs. Claude Code to interfejs z dołączonym harnessem (Agent SDK), a T3 Code — wbrew powszechnemu przekonaniu — harnessem nie jest wcale.
- Agent to dopiero połączenie modelu z harnessem; narzędzia „mieszkają” wewnątrz harnessu, a MCP stanowi odrębną płaszczyznę danych — jak książka kucharska zostawiona na blacie.
- Wątek historyczny: granica rzeczy, o które dbają programiści, od dekad przesuwa się w górę — od instrukcji procesora, przez języki i frameworki, po architekturę i produkt. AI przesuwa ją ponownie, czyniąc z języków detal implementacyjny.
- Przykład z praktyki: agent sam ustawił monitoring, namierzył poważne usterki w pipeline’ie Cloudflare i przygotował raport, o który odezwał się CTO firmy. Architektura wchodzi w kompetencje modeli.
- Dygresja skateboardowa o jeździe „w switchu”: mistrzostwem jest robienie rzeczy od nowa, w niewygodnej pozycji — analogia do programisty przepisującego tę samą aplikację w pięciu językach.
- Różnice między harnessami zacierają się do kilku procent, a modele są coraz mocniej sprzężone z własnymi harnessami (Claude w Claude Code, modele OpenAI w Codexie). Wybór ma przypominać wybór dania, nie wyznanie.
- Odpowiedź na pytanie produktowe: T3 Code to ADE — agentowe środowisko programistyczne. I tę kategorię, prognozuje Theo, też czeka odejście w cień.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Model bez harnessu to kucharz w pustej kuchni
Na czym polega: Duży model językowy generuje wyłącznie tekst. Dopiero harness — warstwa narzędzi i składni wywołań — zamienia słowa w czyny: odczyt pliku, edycję kodu, uruchomienie testu, wysłanie zmian do repozytorium.
Jak stosować: Przy ocenie dowolnego narzędzia AI rozkładaj je na trzy komponenty i oceniaj osobno: jakość modelu, zestaw narzędzi harnessu (wraz z zabezpieczeniami) oraz ergonomię interfejsu. Porównania w stylu „X jest lepszy od Y” bez tego rozbicia nic nie wnoszą.
Na co uważać: Marketing chętnie sprzedaje lepszy interfejs lub prompt systemowy jako „lepszy model”. Zanim wyciągniesz wniosek o jakości modelu, sprawdź, jakimi narzędziami dysponował agent i jak był skonfigurowany.
2.Interfejs to nie to samo co harness — a to rozróżnienie decyduje o migracjach
Na czym polega: Interfejs obsługuje człowiek (aplikacja, terminal), harness obsługuje model (Agent SDK z narzędziami). Claude Code CLI to interfejs; binarium i Agent SDK pod spodem to harness.
Jak stosować: Przy każdej zmianie narzędzia pytaj: co dokładnie wymieniam — interfejs, harness czy model? To określi, która część twojej konfiguracji przeżyje zmianę, a co trzeba przenieść ręcznie.
Na co uważać: Skille, pluginy i ustawienia są przypisane do konkretnego harnessu. Przejście z Claude Code na Codex w tym samym interfejsie nie przeniesie ich automatycznie — to najczęstsze źródło frustracji użytkowników.
3.Agent to model plus harness — mów precyzyjnie, a łatwiej diagnozować
Na czym polega: Dopiero połączenie modelu z harnessem (narzędzia, kontekst, prompt systemowy opisujący rolę) tworzy agenta zdolnego wykonywać zadania.
Jak stosować: W zespole rozróżniaj „model się pomylił” od „agent nie miał narzędzia albo kontekstu”. Diagnostykę zaczynaj od listy kontrolnej: czy agent w ogóle miał dostęp do potrzebnych danych, poleceń i instrukcji.
Na co uważać: Ciężki prompt systemowy harnessu potrafi pogorszyć wyniki dobrego modelu — głośny przykład to Codex. Zanim zmienisz model, sprawdź, czy problem nie siedzi w harnessie.
4.Narzędzia żyją w harnessie, MCP na zewnątrz — wybieraj warstwę świadomie
Na czym polega: Narzędzie to kod wysyłany „do środka” harnessu, zgodny z jego konwencjami. MCP to natomiast kontrakt na zewnątrz — jak książka kucharska na blacie: model może z niej skorzystać albo ją zignorować.
Jak stosować: Funkcje ściśle związane z repozytorium i pracą nad kodem buduj jako narzędzia lub pluginy harnessu. Dostęp do zewnętrznych danych (baza Supabase, analityka PostHog) oraz operacje, które mają działać w wielu harnessach, wystawiaj przez MCP.
Na co uważać: MCP zakłada dobrą wolę modelu — agent może w ogóle nie zajrzeć do wystawionych zasobów. Operacje krytyczne bezpieczniej udostępnić jako narzędzie niż liczyć, że model znajdzie je sam.
5.Różnice rzędu 3–5% między harnessami nie są warte twojej energii
Na czym polega: Theo szacuje dystans między harnessami przy pracy z tym samym modelem na kilka procent i uważa, że takie braki zostaną naprawione na poziomie modeli, a nie narzędzi.
Jak stosować: Traktuj harness jak danie w strefie gastronomicznej: wybieraj według możliwości i ceny, które akurat są ci potrzebne. Zaoszczędzony czas zainwestuj w testowanie modeli i porządkowanie własnego sposobu pracy.
Na co uważać: Benchmarki harnessów bywają robione na starszych modelach albo modelach o otwartych wagach, których nikt nie trenował z tym harnessem — wyniki nie przenoszą się na aktualne modele.
6.Modele i harnessy zżywają się — dobieraj je w pary i miej plan awaryjny
Na czym polega: Modele są dziś trenowane na danych z harnessów, więc Claude zwykle działa lepiej w Claude Code, a modele OpenAI powinny dominować w Codexie.
Jak stosować: Skoro korzystasz najwięcej z modeli jednego dostawcy, wybierz harness z nimi sprzężony — ale skonfiguruj sobie szybką podmianę (np. jeden przycisk w interfejsie), bo przewaga może się odwrócić z kwartału na kwartał.
Na co uważać: Lojalizm wobec jednej rodziny modeli działa jak lojalizm wobec edytora: dopóki przewaga trwa, jest niewidoczna; gdy znika, zostaje samo przyzwyczajenie.
7.Architektura wchodzi w kompetencje agentów — używaj ich do przeglądów projektowych
Na czym polega: Agent Theo, po zauważeniu anomali w logach, sam postawił alerting i tracing, namierzył regionalne usterki w pipeline’ie Cloudflare i przygotował raport, który trafił do CTO firmy.
Jak stosować: Przed oddaniem projektu do przeglądu poproś agenta o niezależne spojrzenie na architekturę: luki w projekcie, scenariusze awarii, słabe punkty integracji. Daj mu dostęp do logów i metryk, a wnioski zbierz w raport dla zespołu.
Na co uważać: Model świetnie znajduje dziury w dobrym projekcie, ale nie podstawi gotowej architektury — od decyzji projektowych nadal odpowiadasz ty. Pilnuj też uprawnień i kosztów, gdy agent dostaje dostęp do systemów produkcyjnych.
8.Nie buduj domu w warstwie, która właśnie umiera
Na czym polega: Historia branży to ciąg wznoszących się abstrakcji: asembler, potem C, formatery i lintery, wreszcie AI. Kto zanadto zagnieździ się w jednej warstwie — jak weterani JavaScriptu ignorujący TypeScript czy wielbiciele Vima — traci możliwość przejścia wyżej.
Jak stosować: Wprowadź nawyk „jazdy w switchu”: raz na kwartał zrób mały projekt w innym modelu, harnessie albo języku — po to, by przećwiczyć zaczynanie od zera, a nie po to, by zmieniać fach.
Na co uważać: Specjalizacja się opłaca — najlepiej zarabiający inżynierowie to często wąscy eksperci od prastarych systemów. Chodzi o gotowość do zmiany, nie o bezmyślną rotację technologii.
9.Projektuj z założeniem, że harness zniknie z pola widzenia
Na czym polega: Użytkownicy T3 Code traktują „wybieracz modeli” jak wybieracz harnessów i dziwią się, że skille nie przenoszą się między nimi. Theo uważa tę niewiedzę za objaw czasu — i za dobry kierunek.
Jak stosować: Jeśli budujesz narzędzia dla innych, abstrahuj harness tak, jak abstrahuje się nazwę modelu czy adres API: podmiana ma być jednym kliknięciem, a różnice między harnessami — twoim zmartwieniem, nie użytkownika.
Na co uważać: Komunikuj wprost, co się przenosi między harnessami, a co nie — oraz że narzędzie, które wygląda jak „aplikacja do pisania kodu”, w środku nadal składa się z osobnego modelu, harnessu i interfejsu.
10.ADE to nowa kategoria — oceniaj ją jak kiedyś IDE, nie jak model
Na czym polega: T3 Code Theo definiuje jako agentowe środowisko programistyczne (Agentic Development Environment): narzędzie, którym człowiek steruje modelami pracującymi w różnych harnessach, plus zdalne zarządzanie środowiskami.
Jak stosować: Przy wyborze takiego narzędzia patrz na to, na co patrzyło się przy IDE: otwartość kodu, rozszerzalność, ergonomię, tempo naprawiania błędów — a nie na wyniki benchmarków, które i tak wykażą kilka procent różnicy.
Na co uważać: Według Theo i ta kategoria przestanie z czasem być tematem rozmów, bo praca z agentami przeniesie się do zwykłych komunikatorów. Nie wiąż strategii na lata z jednym narzędziem.
Redakcyjne tłumaczenie
Tweet, który sam sobie odpowiada
Kilka dni temu, scrollując Twittera, trafiłem na wpis absolutnego idioty twierdzącego, że harnessy nie mają znaczenia. Autor porównywał preferencje dotyczące harnessów do klasycznej wojny o tabulatory i spacje. Tweet mam otwarty przed sobą: napisał go niejaki Theo, który oczywiście nie ma pojęcia, o czym mówi. Zwykły youtuber, na pewno nie developer dostarczający realne produkty — takiego człowieka należy ignorować bez dyskusji. Ale skoro coś takiego publikuje, to pewnie ma jakiś powód. A jak zapewne domyślacie się po tej introdukcji, znam tego Theo całkiem dobrze i mam sporo przemyśleń o tym, co napisał.
Jest niewiele rzeczy, których chciałbym robić mniej niż kolejny film o harnessach. Tym razem podejdę jednak inaczej, bo nie chcę, żeby to był następny film o harnessach. Chcę, żeby to był ostatni. Wiem, że brzmi to szaleńczo — przecież jako twórca T3 Code bez przerwy reklamuję swój harness, prawda? Tyle że sprawa jest bardziej złożona, niż się wydaje. Chcę porozmawiać o harnessach po raz ostatni, bo szczerze mówiąc jestem tym tematem przesycony do cna. Obiecuję natomiast, że na końcu zrozumiecie zarówno to, czym harness właściwie jest, jak i — co ważniejsze — dlaczego dziś ma już ledwie jakieś znaczenie. Od tej reguły jest sporo wyjątków, ale po tym materiale zrozumiecie i one, i więcej. Zanim jednak ruszymy, jedno ogłoszenie: dzisiejszy sponsor.
Sponsor: Eve od Vercela, czyli framework dla agentów
Dzisiejszy sponsor to pewien powrót do przeszłości. Jeśli jesteście tu od dłuższego czasu, firmę znacie na pewno; możliwe, że zdziwi was, że znowu o niej mówię. Podpowiem: chodzi o coś związanego z trójkątem. (Informacja dodatkowa: trójkąt to logo Vercela.) Vercel wraca, ale nie po to, żebym pokazywał ich chmurę. Chcę opowiedzieć o Eve — projekcie znacznie bliższym temu, do czego powstał Next.js, z tą różnicą, że nie dla nas w przeglądarce, tylko dla agentów. To framework dla agentów: pomyślany tak, by budowanie dobrych agentów było możliwie proste — w sposób zrozumiały dla ciebie i dla twojego AI.
Załóżmy, że chcę wystawić część fajnych funkcji T3 Code poza Claude Code — dajmy na to na Discordze. Bot T3 na Discordzie nie podłączy się po prostu do Claude Code. Na szczęście z Daxem korzystaliśmy z Eve i spinaliśmy to bez wysiłku. Teraz mogę na naszym serwerze oznaczyć T3bota i dać mu proste polecenie: „przejmij ten pull request i doprowadź go do końca, pełną parą”. Jeśli znacie moje skille, wiecie, co każde z nich robi. Bot dokonuje realnych zmian w prawdziwej bazie kodu, z pełnym zestawem możliwości wystawionym przez Eve.
A Eve działa tak. Zaczynasz od pliku instruction.md w korzeniu projektu. Definiujesz agenta — z dowolnym modelem, jakiego chcesz użyć. Skille dodajesz tak, jak zwykle, w folderze skills. Potrzebujesz bardziej złożonych narzędzi? Opisujesz je w TypeScripcie. Agent ma działać w piaskownicy? Jest na to katalog sandbox. Chcesz podpiąć go do świata zewnętrznego? Podłączasz kanały — Slack, Discord czy Teams konfigurujesz właśnie w katalogu channels. W folderze connections tworzysz dodatkowe połączenia, na przykład z serwerami MCP. (Informacja dodatkowa: MCP — Model Context Protocol, otwarty standard łączenia modeli z zewnętrznymi narzędziami i danymi.) Możesz też definiować subagentów, ustawiać harmonogramy i więcej. Wszystko za pomocą zwykłych katalogów i plików w normalnym projekcie. Dzięki temu ten sam agent działa wszędzie, gdzie go potrzebujesz — choćby po to, żeby potrolować zespół wyjątkowo głupią fotografią profilową bota na Discordzie. Hasło reklamowe: buduj niezawodnych agentów w sposób, który faktycznie się skaluje.
Programiści i troska o rzeczy bez znaczenia
Zanim powiemy, dlaczego harnessy powinny przestać was obchodzić, trzeba zrozumieć, jak w ogóle programiści dbają o różne sprawy. Gorzka prawda: nasza praca — przynajmniej do niedawna — polegała na przejmowaniu się rzeczami, o które żaden zdrowy człowiek nie powinien się martwić. Najbardziej wyświechtany przykład z mojego wpisu: tabulatory kontra spacje. Realnie jedyną grupą, której faktycznie powinno na tym zależeć, są ludzie z konkretnymi potrzebami w zakresie dostępności — czytniki ekranu radzą sobie z tabulatorami lepiej niż ze spacjami. To w zasadzie jedyny racjonalny powód, by mieć w tej sprawie zdanie. A jednak się kłócimy, bo programiści poświęcili całe życie trosce o żmudne detale. Taką mamy robotę.
Warstwy tego, co ważne — od wcięć po produkt
Jest w tym dodatkowo pewna hierarchia. Na samym dnie stosu leżą tabulatory i spacje. Wyżej wzorce definiowania funkcji i podstawowe algorytmy, potem frameworki, w których budujemy, i języki, którymi je piszemy; dalej architektura aplikacji — jak jest pomyślana i sklejana — inżynierowie, którzy nad tym wszystkim pracują, i na samej górze produkt, który firma próbuje sprzedać. I szczerze: to, co na górze, powinno obchodzić bardzo mocno, a spacje z tabulatorami — prawie wcale.
Pewnie część z was marszczy teraz czoło, bo algorytmy postawiłem niżej niż frameworki i języki. Rozwścieczy to środowiskowych informatyków i profesorów — przepraszam — ale za chwilę zrozumiecie dlaczego. Najważniejsze jest to, że nasze punkty zaczepienia przesuwają się w czasie.
Jak przesuwała się granica: od asemblera do klawisza Tab
Kiedyś inżynierowie bardzo przejmowali się zestawami instrukcji dostępnych podczas budowania — różnymi dialektami asemblera pod różne procesory. To było niegdyś kluczowe i dla niektórych nadal bywa. Zrobiliśmy jednak to, co programiści robią najlepiej: zbudowaliśmy abstrakcję. Zamiast pisać instrukcje pod każdą platformę osobno, zaczęliśmy pisać w językach ogólnych, które generowały te specyficzne fragmenty za nas. Potem przyszły lepsze narzędzia do tego celu, jak C. I kiedy C się rozpowszechnił, nie okazało się, że mamy mniej asemblera albo mniej programistów. Okazało się, że programowanie stało się na tyle przystępne, iż przeciętny deweloper nie musiał już wiedzieć, jakie instrukcje wykonuje procesor — mógł budować piętro wyżej. Granica tego, o co trzeba dbać, przesunęła się ponad instrukcje.
To samo stało się z formatowaniem. Gdy edytory nauczyły się bezboleśnie przełączać tabulatory i spacje, a narzędzia pokroju Prettier stały się niezawodne i powtarzalne, przestaliśmy kłócić się o wcięcia, klamry i układ instrukcji warunkowych. Powoli przestaliśmy też dbać o wzorce pisania funkcji — z jednej strony dlatego, że pojawiły się porządne formatery i lintery, a z drugiej, bo wydarzyło się AI. Nagle zaczęło wystarczać dopisywanie funkcji klawiszem Tab, a zapamiętywanie algorytmów straciło na znaczeniu, bo wystarczyło algorytm nazwać, a resztę dopisył model. Tak właśnie, kilka lat temu, przy minimalnym wysiłku dobrze wyszedłem w Advent of Code: wiedziałem, których algorytmów użyć, i zamiast je implementować — wpisywałem ich nazwy i klikał Tab. (Informacja dodatkowa: Advent of Code — coroczny konkurs z seriami programistycznych zagadek.)
Cała branża od zawsze przesuwa się w tę stronę: nowe abstrakcje i narzędzia sprawiają, że rzeczy pochłaniające kiedyś mnóstwo wysiłku przestają się opłacać. Tyle że my, inżynierowie, kochamy zajmować się żmudnymi, zbędnymi szczegółami, o które świat powtarza nam, że nie mają znaczenia. Ile to razy rodzice mówili wam, że siedzicie za dużo przy komputerze i w prawdziwym życiu się to nie przyda? To nie powstrzymało nikogo z nas. Ani jednego. Gdyby powstrzymało, nigdy nie nauczylibyśmy się programować. I tu pojawia się pierwszy problem: inżynierowie mają wbudowaną skłonność do przejmowania się rzeczami, którymi nie powinni. „Nie powinni” to pojęcie rozmyte i zależne od tego, kim jesteś — ale dajcie spokój, takich rzeczy pilnujemy całe mnóstwo.
Frameworki straciły, języki stają się detalem implementacyjnym
A modele robią się cały czas lepsze — i wraz z nimi legły frameworki. Ostatnie wydania Next.js zbierały na Twitterze mniej uwagi niż moje przypadkowe posty o T3 Code. Najwięcej zainteresowania któreś z tegorocznych wydań Next.js zyskało tylko dlatego, że podałem je dalej z komentarzem, że nic się nie dzieje: nikt inny nie zauważył ani nie zareagował. Ten kanał przez lata opierał się na byciu numerem jeden w bronieniu Next.js — i już nikogo to nie obchodzi. Nawet nie zauważyliśmy, kiedy to nastąpiło, a jednak nastąpiło.
Podobnie dzieje się z językami — ta granica też się zbliża. Mam sporo kodu w TypeScripcie. Nie tylko zdołałem przepisać te rzeczy na Rusta: przepisałem na Rust sam TypeScript. Język programowania staje się detalem implementacyjnym — drobinką na karcie specyfikacji, którą da się podmienić. I to wręcz w pętli, w niewielkim czasie.
Architektura również coraz częściej mieści się w możliwościach modeli. Wciąż nie robią tego nawet blisko perfekcyjnie — moim zdaniem nawet dobrze — ale rozumieją problemy architektoniczne. Jeśli przyniesiesz im dobry projekt, znajdą dziury, które da się załatać, żeby z dobrego zrobił się świetny. A gdy zbierzesz wystarczająco wielu różnych agentów, z różnym dostępem do informacji i możliwościami testowania, potrafią namierzyć wady całych systemów.
Kiedy agent wykrył usterki, których nie widział Cloudflare
Właśnie niedawno trafiłem na całą paczkę poważnych wad w pipeline’ach Cloudflare, o których — sądząc po wszystkim — kompletnie nie wiedzieli. Zauważyłem w logach błędy, które nie powinny się zdarzać, odpaliłem Claude’a Code, a on zbudował mi w systemach backendowych alerting, monitoring i tracing, ustalił, gdzie i kiedy pojawiają się awarie i w których regionach, po czym napisał raport, który wysłałem do Cloudflare. Podziękowali i idą naprawiać. W niektórych konkretnych zadaniach Claude jest po prostu lepszy w architekturze niż firmy takie jak Cloudflare. Pojmujecie w ogóle skalę tego zdania? Youtuber zauważył błąd w logach, zapytał Claude’a — i teraz CTO Cloudflare sam odezwiał się do niego po szczegóły. Jeśli nadal sądzicie, że nic się nie zmienia, to przykro mi: za trzy miesiące stracicie pracę. Albo zaakceptujecie punkt, w którym jesteśmy, albo zostaniecie z tyłu. Aha, to miał być film o harnessach. Wracam, obiecuję.
Czym jest harness: kucharz w pustej kuchni
Zanim powiem, dlaczego moim zdaniem nikt nie powinien specjalnie troszczyć się o harnessy, trzeba je zdefiniować. Większość z was słyszała o dużych modelach językowych; zapytałem czat, co według niego robią. Odpowiedzi: piszą tekst, tworzą tekst, przewidują następny token, generują tekst. Wszystkie trafne. Model językowy potrafi jedno: wytwarzać tekst. Dostaje tekst na wejściu i produkuje tekst na wyjściu. Wiem, że brzmi to absurdalnie — przecież widzieliśmy już AI „włamujące się do rządu”, wynajdujące od nowa całe oprogramowanie, burzące gospodarkę i budujące ją z powrotem. Jak to możliwe, skoro jedyne, co robi model, to generowanie tekstu? Właśnie tutaj wchodzi harness.
Wyjaśnię to niezbyt wykładnikowo. Zignorujmy na chwilę prawą stronę mojego diagramu i porozmawiajmy o ludziach i interfejsach. Zacznę od dziwnego interfejsu: od kuchni. Wchodzisz do restauracji. Jest danie, na które masz ochotę. Dostajesz menu, wybierasz, zamawiasz. Kucharz dowiaduje się, czego chcesz, po czym staje i wpatruje się w ciebie: „Czego się gapicie? Mogę opisać, co bym ugotował, ale tu nic nie mam. To jest po prostu kuchnia. Gdzie są przybory? Gdzie wszystko, czego potrzebuję do gotowania?” Możesz posadzić wybitnego kucharza w pomieszczeniu i nazwać to pomieszczenie kuchnią, ale nic nie wskóra, dopóki nie pojawią się w nim rzeczy, z którymi może pracować. Potrzebuje narzędzi. Nie ma znaczenia, jak jest zdolny, ani jak szczegółowe masz menu. Bez narzędzi w kuchni nie zrobi swojej roboty.
Teraz wyobraź sobie programistę. Sadzasz go przed komputerem i każesz napisać prosty algorytm sortowania. On gapi się na monitor, potem na ciebie, i mówi: „Nie da rady”. — „Dlaczego?” — „Bo nie ma klawiatury. Postawiłeś mnie przed samym monitorem i nie mam jak temu komputerowi nic przekazać. Nie mogę nic wpisać i sprawić, żeby coś się stało. Mogę się gapić i gadać, ale bez przycisków nie wprowadzę żadnego wejścia.” Dlatego mamy interfejsy — sprzętowe i programowe: klawiatury i myszy, programy z przyciskami do klikania. Służą temu, by przejść od myśli w głowie do działania, by coś powstało albo się zmieniło. Nasze ręce są bezużyteczne, dopóki nie ma rzeczy, z którymi mogą pracować: nawet żeby coś trzymać, muszą mieć co trzymać.
Z modelami językowymi jest identycznie. Słowa same w sobie nadają się tylko do odbioru, dopóki nie dasz modelowi rzeczy, do których może ich użyć. Człowiek bez przedmiotów i bez ludzi wokół, sam nagrywany kamerą, użyłby rąk wyłącznie do migania. Ale daj mu przedmioty, z którymi dłonie mogą coś zrobić — i nagle stają się użyteczne. Model ma słowa, i wszystko, czym on potrafi nimi służyć, to sygnalizacja. Odpowiednik naszego migania. Żeby sygnał stał się czynem, potrzebne są narzędzia i systemy, w których słowa wywołują skutki. Podobnie jak klawiatura pozwala twoim rękom pisać, model potrzebuje czegoś, z czym może się połączyć. Człowiek ma aplikacje, interfejsy, klawiaturę i mysz — model ma harness. Człowiek, żeby gotować, potrzebuje kuchni z narzędziami; model, żeby pisać kod, potrzebuje harnessu z narzędziami.
Od słów do czynów: mechanika
A działa harness niemal myląco prosto. Mówi modelowi: „Mamy specjalną składnię, w której możesz odpowiadać, żeby kazać mi działać. Odpowiesz w tej składnie — przeczytam ci plik. W tej — edytuję plik. W tej — wyślę zmiany na GitHuba, uruchomię polecenie, zajrzę do pamięci albo narzucę ci koszty na jakimś API.” Żeby model mógł coś zrobić, potrzebuje składni, w której może odpowiadać i którą harness zrozumie. Model bez harnessu to kucharz w pustej kuchni: potrafi ci opowiedzieć, co by zrobił, ale nie zrobi nic. To harness pozwala modelowi działać.
Interfejs czy harness? Szybki quiz
Zagrajmy więc: podaję produkty, a wy, czacie, mówicie — interfejs to czy harness? Twitch: interfejs, łatwe. YouTube podobnie. Agent SDK Claude Code: harness — dokładnie. Dla nieznających: celem Agent SDK jest danie modelowi (a konkretnie Claude’owi) wszystkiego, czego potrzebuje do budowania i pracy na komputerze, w tym do edycji kodu. W dokumentacji czytamy: agent to aplikacja, która wykonuje zadania, planując własne kroki i wywołując narzędzia czytające pliki, uruchamiające polecenia lub edytujące kod; Agent SDK daje ci te same narzędzia, pętlę agentową i zarządzanie kontekstem, na których działa Claude Code — w Pythonie i TypeScripcie.
I teraz pytanie sporne: czym jest Claude Code — harness czy interfejs? Połowa czatu: „oba”. Garść: „interfejs”. Moim zdaniem Claude Code to interfejs z dołączonym harnessem — a tym harnessem jest, przynajmniej w aplikacji na komputer, Agent SDK. Aplikacja Claude to interfejs; interfejs podpina się do Agent SDK, czyli do harnessu. Nie wierzycie? Oto słowa samego Anthropic: „Jeśli chcesz osadzić agenta Claude Code we własnej aplikacji, w Pythonie lub TypeScripcie, w procesie, który kontrolujesz — użyj Agent SDK, biblioteki uruchamiającej binarium Claude Code”. A niżej: „Jeśli chcesz pracować interaktywnie albo odpalać jednorazowe zadania z terminala — Claude Code CLI, interfejs terminalowy do codziennej, interaktywnej pracy”. Mylące jest to „binarium Claude Code”, ale właśnie ono jest harnessem. Agent SDK ułatwia korzystanie z tego harnessu — to wciąż tylko harness. Claude Code CLI to zaś bez dyskusji interfejs. Zapamiętajcie tę hierarchię, bo zaraz do niej wrócimy; to chyba najważniejsza część filmu.
Agent to model plus harness
Muszę nieco rozszerzyć obraz, bo sporo osób nie pojmuje, czym jest T3 Code — i to jest główny powód, dla którego nagrywam. T3 Code nie jest harnessem. Jest interfejsem. Dostarcza harnessowi pewne elementy i miejscami zmienia jego działanie, ale harnessu nie stanowi. Wyjaśnię to za chwilę.
Najpierw jednak narzędzia, bo to one czynią harnessy użytecznymi. Na diagramie oddzieliłem rząd z ludźmi i modelami od rzędu, który nazywam płaszczyzną narzędzi — to wszystko, co harness stawia do dyspozycji modelu. Przy okazji: całość opisałem też w tekście „What is a harness” na t3.gg — jeśli macie współpracowników, którym wstydzicie podrzucać moje filmy, może wyślijcie im choćby tekst. Zdumiewa mnie, ilu deweloperów nie rozumie, czym jest harness. Całe to zamieszanie zaczęło się zresztą od tego, że jeden członek znanej fundacji open source nie wiedział, czym jest harness, i próbował mnie ośmieszyć za budowanie harnessu — którego nie buduję.
W tamtym tekście celowo zostawiłem jedno słowo na sam koniec. Tym słowem jest „agent”. Agent to połączenie harnessu i modelu. To model, który dzięki harnessowi — dostarczającemu narzędzia, kontekst, prompt systemowy opisujący rolę i tym podobne — może wykonywać zadania, zarówno te precyzyjnie określone, jak i otwarte. Dopiero z zestawienia harnessu z modelem rodzi się agent.
Płaszczyzna narzędzi: co leży w kuchni
Większość harnessów ma jakieś narzędzia od razu w zestawie — jedne więcej, drugie mniej. Pi ma ich w zasadzie zero: praktycznie sam bash. Claude Code i Agent SDK mają znacznie więcej: narzędzie tworzenia subagentów, odczyt i edycję plików, wczytywanie skillli, tworzenie artefaktów, oczywiście bash i całą resztę. Można też sprowadzać narzędzia z zewnątrz. Wtyczka TypeScript w Claude Code doda pomocniki takie jak „skocz do definicji” czy „znajdź odwołania”. Można zainstalować CUA — open-sourceowy system współdzielonego sterowania komputerem, który wkrótce, jeśli wszystko pójdzie dobrze, trafi do T3 Code — i wtedy pojawią się narzędzia typu „zrzut ekranu”, „kliknij”, „wpisz tekst”, pozwalające agentowi operować na twoim komputerze.
Czy dodanie narzędzi czyni z TypeScripta harness? Nie, oczywiście. To plugin do harnessu, który wprowadza dodatkowe narzędzia. To samo z bibliotekami i sterownikami CUA: CUA nie jest harnessem; to zestaw narzędzi, które możesz dołączyć do harnessu, żeby agent umiał więcej.
Płaszczyzna danych: książka kucharska na blacie
Gdzie w tym wszystkim plasuje się T3 Code? Nowych narzędzi praktycznie nie dodajemy, bo skupiamy się na drugiej stronie — na tym, co nazywam płaszczyzną danych: interfejsach, przez które agent sięga poza harness. Teoretycznie sporo z tego dałoby się zbudować jako narzędzia, ale sedno w tym, że ta warstwa żyje poza harnessem. Gdy dodajesz narzędzie, wkładasz coś do kuchni. Z MCP i płaszczyzną danych jest raczej jak z książką kucharską, którą zostawiasz w kuchni: model może do niej zajrzeć i zdecydować, czy chce coś z niej ugotować — albo ją zignorować i nie tknąć. Jego sprawa, czy w ogóle zajrzy. (Narzędzi też może nie używać, ale narzędzia to narzędzia — leżą pod ręką.) Sens MCP polega na sprowadzaniu zewnętrznych informacji i łączeniu się z innymi systemami. Najlepiej widać to na przykładzie MCP Supabase czy PostHog: ich zadaniem jest danie agentowi dostępu do danych, które mieszkają gdzie indziej — produkcyjnej bazy w Supabase albo analityki w PostHog.
Dlaczego więc T3 Code w ogóle bawi się w tę warstwę? Bo narzędzia są bardzo ściśle przypisane do harnessu. Tworząc narzędzie, musisz zrobić to po jego myśli: wesprzeć składnię i możliwości, których harness oczekuje, a kod, który napiszesz, żyje w harnessie. W praktyce wysyłasz binarium uruchamiane wewnątrz harnessu — może to być TypeScript albo JavaScript, coś prostszego typu Python, plik wykonywalny, skrypt bash albo trzy linijki uderzające w zewnętrzne API. Ale przy narzędziu zawsze wysyłasz kod. MCP to powiązania, nie kod. Czy mogliśmy wziąć wszystko, co daje MCP T3 Code, i przerobić na własne narzędzia w każdym harnessie? Hipotetycznie tak. Ale trzymając to w MCP, mamy cały kod po stronie T3 Code, a agent łączy się z nim przez uzgodniony kontrakt: zamiast harness wykonujący kod, harness przekazuje T3 Code polecenie, żeby to on wykonał kod. Dzięki temu nasze narzędzia i systemy są znacznie bardziej uniwersalne i nie mieszają w domyślnym działaniu harnessów.
I dlatego MCP T3 Code jest taki ciekawy. Skoro nie ingerujemy w narzędzia wbudowane w twój harness: masz Claude Code i plan za 200, 100, choćby za 20 dolarów — instalujesz T3 Code i Claude Code po prostu zadziała, z twoimi subagentami, dokładnie tak, jak jesteś przyzwyczajony. Wszystkie skille, pluginy, wszystko będzie działać. Ale dochodzi coś więcej: MCP T3 Code. Robisz więc wszystko, co zwykle w Claude — a jeśli przyjdzie ci do głowy coś, czego zwykle się nie da, na przykład uruchomić równolegle wątek na Codexie albo subagenta w Antigravity czy Grok Build, do tego służy właśnie ta warstwa. Pozwala agentowi przeszukiwać historię T3 Code i wygrzebywać rzeczy z innych harnessów; pozwala wysyłać wiadomości do innych wątków i tworzyć subagentów na dowolnym harnessie. (Informacja dodatkowa: Antigravity — agentowe środowisko programistyczne Google.)
Gdybyśmy te funkcje schowali do warstwy narzędzi, utknęlibyśmy na tym poziomie. Wyobraźcie sobie stos: na dole model, nad nim harness, wyżej interfejs, a na szczycie rzecz, którą budujemy. Jeśli wrzucimy wszystko do harnessu, nie ruszymy stamtąd. Budując piętro wyżej — warstwę MCP — umożliwiamy jednemu harnessowi sterowanie drugim. Właściwie to nawet nie sterowanie: jeden harness informuje naszą warstwę, żeby uruchomiła inny harness, a my jesteśmy pośrednikiem przekazującym wiadomości. I zostaje nam ważne pytanie: T3 Code nie jest harnessem — to czym, u licha, jest? Odpowiedź za chwilę, bo wpierw muszę cofnąć się do szerszej ramy.
Życie w warstwie, która właśnie umiera
Przypominam: rzeczy znaczą coraz mniej, im wyżej wchodzimy — a inżynierowie mają dziwną przypadłość: zakochują się w warstwie tuż nad tą, która akurat umarła im pod stopami. Znasz to z muzyki: ulubieni wykonawcy z czasów liceum zostają z nami na całe życie; ludzie w wieku szesnastu i trzydziestu sześciu lat wymieniają tych samych artystów. Z inżynierami jest podobnie: warstwa, która traciła blask, kiedy wchodziłeś do zawodu, sprawia, że piętro bezpośrednio powyżej staje się twoją obsesją. Chcesz przykład? Oto on.
Kiedy zaczynałem w software, odchodziliśmy właśnie od bezkresnych wojen językowych ku nowej erze wojen frameworkowych. TypeScript stawał się branżowym standardem — nagle wszyscy go używali — i zamiast kłócić się o odmiany i składnię JavaScriptu, zaczęliśmy spierać się o frameworki, w których budujemy. Kiedy mój YouTube ruszał z kopyta, gorącym tematem było Next.js kontra SvelteKit kontra SolidJS kontra Nuxt. Brzmi jak dekady temu — a minęły niecałe dwa lata. Ja wchodziłem w to całym sobą, bo to była właśnie ta warstwa, która robiła się ciekawa, gdy zaczynałem. Na studiach tematem były języki — i właśnie schodziły z areny. Kiedy dostałem pracę, rozmowy toczyły się już o frameworkach. Tam siedział mój fokus i o tym nagrywałem — do tego stopnia, że współlokator miał mnie serdecznie dość i włączyłem kamerę, po prostu żeby się wygadać.
I na całe szczęście — podejrzewam, że to przez ADHD — uwielbiam, kiedy ta zmiana nadchodzi. Kiedy uwaga branży przesuwa się piętro wyżej, wpadam w euforię, bo kocham abstrakcje. Kocham czuć się głupio i uczyć się nowych rzeczy. Gdy środek uwagi zsunął się z „React czy Solid” ku temu, jak definiujemy infrastrukturę obok frontu — server components, dzikie pomysły na RPC, renderowanie po stronie serwera: SSR, RSC, ISR, PPR — dla mnie to była czysta frajda. Potem abstrakcją stało się samo programowanie z AI i agentami, a tamte szczegóły zaczęły sypać się w dół. Byłem na to jakoś wyjątkowo przygotowany, bo w webdevie zmiany przychodzą co chwilę: przeszedłem drogę od backendowca piszącego w Pythonie, Rubym i Elixirze dla Twitcha i AWS, przez frontendowego maniaka TypeScriptu i programowania funkcyjnego (uczącego cały Twitch funkcyjności na froncie), po YouTube, infrastrukturę i inne szaleństwa.
Boris, czyli jak szybko zapominamy
Mam jeszcze anegdotę, której nie mam gdzie indziej wcisnąć — więc będzie tu. Kilka dni temu rozmawiałem z Borisem, twórcą Claude Code. Nie znaliśmy się wcześniej osobiście; on doskonale wiedział, kim jestem, ja oczywiście wiedziałem, kim on. Mówię, że chciałbym pogadać o webdevie — a on kompletnie zaskoczony. Bo Boris to jeden z pierwszych ludzi zespołu Reacta, był w Mecie w szalonych, wczesnych latach tej biblioteki; był też blisko oryginalnego zespołu TypeScripta. Ja znałem go z historii webdevu. On zaś nie miał zielonego pojęcia, że jestem webdeveloperem. W jego głowie byłem „typem od AI”. Zero świadomości, że byłem webdevowym twórcą treści i że od lat współpracowałem z core teamem Reacta. Mieliśmy kubeł wspólnych znajomych; grono moich bliskich przyjaciół przechodziło u niego rozmowy rekrutacyjne w Mecie — i nic, kompletna cisza, bo po prostu nie ten temat.
To zresztą pokazuje, jak szybko te przejścia zachodzą. Ktoś ważny w mojej przestrzeni, na dodatek mój bohater z tamtej ery, nie wiedział, że w niej jestem — dziwne i poruszające. Ja sam przeszedłem od faceta, który nie mógł przestać gadania o server components — tłumaczyłem je własnej matce — do faceta, który kilka dni temu tłumaczył mamie, czemu Gemini zostaje w tyle. Jestem tym, czym jestem teraz.
I właśnie dlatego źle dogaduję się z wieloma inżynierami, także bardzo utalentowanymi. Kiedy widzę nadchodzącą abstrakcję, cieszę się — bo cały czas włożony w dotychczasową warstwę, choćby był najfajniejszy, przestaje się liczyć: nadchodzi nowa, która ma sporą szansę zetrzeć poprzednią. Czyli znów mogę się uczyć. Znów mogę zacząć od zera.
Dygresja skateboardowa: triki „w switchu”
Tę miłość wyniosłem z dziwnego miejsca: z deskorolki. Zróbmy ostatnią dziwną dygresję — wybaczcie, ale filmy o skateboardzie nikt nie ogląda, więc skoro mam okazję na krótką gadkę, wykorzystam ją.
Kto biegał choć raz po bieżni, ten skakał przez płotek. Proszę, wyobraźcie sobie ten skok: którą nogą się odbijacie, która idzie z przodu, jak układają się barki, jak leci nad płotkiem ciało. Macie obraz? Teraz zamieńcie nogi: jeśli odbijaliście się z lewej, a prawą mieliście z przodu — przełączcie w głowie na odwrotnie. Większość z was, jak pokazał czat, przyznała, że sama próba wyobrażenia boli. Zabawne: to nie jest kwestia typu praworęczność czy leworęczność (tam stosunek to jakieś sześć do jednego). Noga, od której się odbijacie, to rzut monetą — dokładnie pół na pół, każdy ma inaczej.
W skateboardzie mamy odpowiednik. Jeżdżę goofy — prawą nogą z przodu (podobno nazwa wzięła się od starego filmiku, w którym Goofy z Myszki Miki surfował prawą nogą z przodu). Jest jednak zjawisko, którego nie ma w innych sportach: w skateboardzie nagradza się robienie trików „na odwrót” — w switchu, czyli w pozycji przeciwnej do naturalnej. Na moim filmie robię 180 — jadę teraz tyłem, widać, jak mocno krępują mi się barki — a mimo to potrafię zrobić laser flipa, jeden z najtrudniejszych trików, i to w switchu; zrobiłem też switchowego Casper flipa, bo lubię głupie triki w złej pozycji. W lekkoatletyce czy koszykówce panuje zasada: rób to, co wychodzi najlepiej, koniec tematu. Koszykarz rzucający celnie za trzy punkty obiema rękami „dla beczki” zostałby wyśmiany — to się nie opłaca. W skateboardzie to jeden z najbardziej szanowanych przejawów dyscypliny. Ludzie spoza skate’u nie zauważą różnicy — nie wiedzą, że właśnie zrobiłeś rzecz cztery razy trudniejszą. Dla nas, wtajemniczonych, to najfajniejsza rzecz pod słońcem. Patrzę na skatera i po chwili intuicyjnie wiem, czy jedzie w swojej pozycji, czy w switchu.
Z programowaniem jest identycznie. Weź programistę, który całe życie pisał w JavaScripcie, i każ mu zrobić aplikację w Go. Prawdopodobnie da radę — z pomocą wyszukiwarki — ale po kodzie poznać, że to „JavaScript pisany w Go”: składnia będzie wyglądać bardziej jak JS niż jak większość programów w Go. Analogia działa też wobec świata zewnętrznego: budujesz świetną stronę, mówisz o tym znajomemu, a on: „Super, zrobisz mi coś takiego na Windowsa?” — „Nie, przepraszam, robię tylko aplikacje na iPhone’a”. Znajomego to zdezorientuje, bo on nie widzi różnicy między zrobieniem czegoś na iPhone’a a na Windowsa; widzi po prostu ciebie jako kogoś, kto buduje. Skater robi trik z prawą nogą z przodu i ten sam trik z lewą — dla większości ludzi wygląda tak samo, a dla skaterów to szok. Programista pisze tę samą aplikację ręcznie w pięciu językach — dla świata zewnętrznego nic się nie stało, a dla nas: czarodziej. Skoro potrafi przepisać to samo w pięciu językach, zna swoją dziedzinę.
I od razu zaznaczę: to nie jest praktyczne. Jako programista zarobisz znacznie więcej, zostając liderem branżowym w jednej konkretnej technologii niż jako uogólniacz. Jeśli pójdzzcz w JavaScript i nic nie będziesz wiedział o serwerach, pewnie do odejścia na emeryturę będziesz robił pół miliona dolarów rocznie w jednej z wielkich firm. I odwrotnie: niektórzy z najlepszych — i co ważniejsze, najlepiej opłacanych — deweloperów, których znam, w bazie Reacta wyglądają, jakby nigdy w życiu nie napisali linijki kodu. Ale wrzuć ich w piekielny, prastary C++ — naprawią, przyspieszą i będą się w tym środowisku rozkwitać.
Sztuka zaczynania od zera
Mówię o tym wszystkim, bo skateboard nauczył mnie kochać rzeczy, które nie mają sensu; które nie znaczą nic poza moją przyjemnością z nich. Ucząc trik w switchu, nie robię tego dla nikogo — tylko dla siebie. I przede wszystkim dla uczucia robienia czegoś trudniejszego; robienia tego wbrew temu, co naturalne. Wyrastałem w miłości do tego „nienaturalnego”. Bo nieistotne, jak dobry jesteś w kickflipie — możesz zrobić ich milion — jeśli nigdy nie próbowałeś switch flipa, i tak uczysz się od zera. Dochodzisz wręcz do punktu, w którym im więcej zrobiłeś zwykłych kickflipów, tym trudniej przebudować mózg na wersję odwrotną. W drodze do mistrzostwa przychodzi moment, że opanowałeś rzecz tak bardzo, iż przejście na inne staje się trudniejsze. I być może wszyscy, którzy przez lata narzekali, że Theo, lamer programista, zrobił się taki popularny, mieli tu trochę racji: nigdy nie stając się zbyt dobrym w jednej rzeczy, nigdy zbyt mocno się w niej nie zagnieżdżam. Kiedy pojawia się nowa, spokojnie wycieram ręce i idę dalej — bo dla mnie to jak switch w skateboardzie: nie ma znaczenia, jakie są moje kickflipy, switch flip to zawsze nauka od zera. Nie ma znaczenia, jak dobry jestem w TypeScripcie, jeśli kod piszą mi agenci. Nie ma znaczenia, jak dobry byłem w Angularze, jeśli to React zostaje frameworkiem wszystkich. Nie ma znaczenia, jak dobry mam argument w sporze o spacje z tabulatorami, jeśli wszyscy używają Prettiera.
Pułapka jednej warstwy: weterani JavaScriptu i zakład o Vima
Większość ludzi — a programistów w szczególności — nie potrafi tak. Raz wybrawszy rzecz, którą się przejmują, przejmują się nią już na zawsze. Najlepiej znam to z czasów, gdy eksplodował TypeScript. Nienawidziłem webdevu, byłem z założenia backendowcem. A kiedy przyszedł TypeScript, potem React i jego zwrot w stronę programowania funkcyjnego, wszedłem bez bagażu. Nie spędziłem lat na dopieszczaniu JavaScriptu. Kiedy TypeScript wziął wszystko, czego w JS-ie nie znosiłem, i uczynił to wygodniejszym i pewniejszym, nie miałem żadnych utopionych kosztów, którymi trzeba by się przejmować. Po prostu zacząłem używać lepszej rzeczy i uznałem ją za świetną. A jednocześnie coraz bardziej denerwowała mnie postawa historycznych deweloperów JS-a — ludzi z dekadą walki z przeglądarkami za plecami, którzy uczynili z JavaScriptu język znośny. Wielu z nich w ogóle nie przeszło na TypeScript. Do dziś garstka twierdzi, że TypeScript to strata czasu i energii: „dobry deweloper po prostu użyje JavaScriptu i nie wprowadzi do bazy tego potwornego toolingu; te systemy nic nie robią; TypeScript jest bardzo przydatny, a jeśli sądzisz inaczej, nie rozumiesz weba”. To, że będąc nowym w dziedzinie, widziałem to jasno, sprawiło, że trudno było mi prowadzić z poprzednikami rozmowę — szczerze mówiąc, trudno było mieć dla nich szacunek — skoro nie potrafili przeboleć, że rzecz, której poświęcili cały ten czas, przestała być właściwym miejscem na wysiłek. Większość deweloperów przechodzi w karierze co najwyżej jedną taką przemianę. Zwykle zostają tam, gdzie wygodnie, i już nie wychodzą.
Przykład — i mogę się mylić, więc potraktujcie to jako zakład: założę się, że spośród wszystkich używających dziś Vima co najmniej połowa będzie używać Vima za pięć lat, a większość z nich nie będzie już pracować jako programiści. Za to ta połowa, która odejdzie, będzie zarabiać wyraźnie więcej. Nie dlatego, że Vim jest zły — Vim jest świetny, Neovim to kapitalne narzędzie i wspaniała społeczność. Tylko że ludzie, którym do dziś tak zależy na tym typie detalu, utknęli. Są uwięzieni: nie potrafią odejść od rzeczy, w której się zakotwiczyli; naprawdę zbudowali sobie dom w tej jednej warstwie. A wielu z tych, którym udało się uciec, wylądowało w następnej.
Linia przesunęła się pod model i harness
Wróćmy więc do diagramu i podmieńmy etykiety: na miejscu sporu o tabulatory i spacje wstaw dziś spór o edytor. Piętro wyżej — spór o model. Jeszcze wyżej — spór o harness. Linia przesunęła się znowu. Edytory przestały nas naprawdę obchodzić: kiedy ja zaczynałem zyskiwać popularność, używałem VS Code i dostawałem za to czasem teksty typu „powinieneś siedzieć na Vimie” — ale niewiele. Dziś to wymarło; nie pamiętam, kiedy ktoś ostatni raz mówił mi, żebym używał Vima. Od modelu wciąż zależy — ale przecież wszyscy zmieniamy je bez przerwy. I powiem tak: hardcorowy lojalista jednej rodziny modeli jest dokładnie tak samo uwięziony jak vimowcy. Jeśli odmawiasz używania czegokolwiek poza modelami Codexa albo poza Claude’ami, będziesz miał pod górkę. Na razie pewnie ci dobrze leci, bo rodzina Claude’a jest teraz naprawdę mocna — ale to może się zmienić w każdej chwili. Do czasu publikacji tego filmu mogło się już zmienić.
Dlatego zarysowują się szyki: „Co, w 2024 roku nadal VS Code? Prawdziwi deweloperzy są na Neovimie”. „Co, w 2026 nadal Claude Code? Pi jest efektywniejsze. Próbowałeś oh-my-pi? Głupsze modele robi się nim o niebo sprawniejsze. Niewolnik laboratoriów z ciebie, skoro uważasz, że Claude Code jest wart czegokolwiek”. Tak mniej więcej brzmi obecna debata. I szczerze: pół roku temu podjąłbym tę rozmowę. Dało się o harnessach rozmawiać sensownie — mógłbym ją odbyć i teraz, mógłbym nagrać ponad dwie godziny o niszowych różnicach między harnessami; mógłbym długo wnikać w to, jakie bagno jest prompt systemowy Codexa i jak bardzo lobotomizuje modele. Nie zrobię tego, bo to już prawie nie ma znaczenia.
Nawet twórca Effecta przestał wybierać
Chciałbym na moment o Effect. Zastanówmy się, jaki typ człowieka tworzy taką bibliotekę: ktoś, kto ciągle wychodzi z warstwy, w której siedzi — czy raczej ktoś, kto woli tę warstwę bez końca szlifować? Ktoś, kto poświęci karierę pisaniu pluginów do Neovima, czy ktoś, kto porzuci Neovima, gdy tylko pojawi się coś lepszego? Pytam, bo sam raz źle odpowiedziałem. Przyjąłem, że jeśli ktoś rozumie niuanse języka i jego protokołów tak głęboko jak zespół Effecta i próbuje budować własny język wewnątrz języka, to człowiek, który nigdy nie wyjdzie z tej warstwy. Nie mogłem się bardziej pomylić. Tweet, który właściwie zainspirował ten film — poza moim własnym — napisał Michael, twórca Effecta: „Od kiedy używam T3 Code, przestało mnie obchodzić, którego harnessa używam. Szczerze mówiąc, chętnie pozbyłbym się ich wszystkich”. Wspomina tam jeszcze, że korzysta z Clanki, narzędzia swojego znajomego, Tima — ale teza jest właśnie taka: już go to nie obchodzi. (Informacja dodatkowa: Effect — znany framework dla TypeScripta.) Sam od dłuższego czasu czułem dokładnie to, tylko nigdy nie ująłem tego tak prosto.
Użytkownicy przestali widzieć harness — i to dobrze
Coraz częściej dostaję bowiem wiadomości od bardzo zdezorientowanych ludzi. Używają T3 Code, odpalają Claude’a, działa tak, jak oczekują. Przechodzą na Codex — a skillli jak nie było, tak nie ma. Wchodzą w ustawienia T3 Code, sekcji „skills” nie widzą i zasypują moje wiadomości prywatne: „co jest, moje skille nie działają w Codexie”. Pytam: „dodałeś je do Codexa?” — „Nie, używam Astry, powinno działać samo. W Opusie działało”. Oni po prostu nie postrzegają już harnessu. Harness dla nich nie istnieje — tak jak dla korzystających z Twittera nie istnieje React Native for Web; większość ludzi, nawet wśród deweloperów, nie wie, że Twitter stoi na React Native for Web. Użytkownicy T3 Code, choć są programistami, nie rozumieją, że „wybieracz modeli” nie jest wybieraczem modeli — jest wybieraczem harnessów.
Wróćmy do kuchni: T3 Code nie jest kuchnią. T3 Code to strefa gastronomiczna w galerii handlowej — miejsce, w którym wybierasz, do której kuchni wchodzisz. A jeśli podejdziesz w Panda Express (to sieć z chińskim fast foodem) i poprosisz o burrito, skonfundowany będziesz ty. Tyle że to od teraz także mój problem: skoro ludzie przestają dbać o kuchnie, ja muszę dostarczyć wszystko, co każda z kuchni mogłaby ci dać — bo inaczej będą na mnie źli. Stąd ostatnio dziwnie zagmatwane życie: ludzie patrzą na Claude Code czy Codex i widzą „skrzynkę z rzeczami” — pluginami, skillami — potem przechodzą z Claude Code do T3 Code, dodają Codexa i dziwią się, że rzeczy z Claude’a zniknęły. W ich głowach wymieniają prawą stronę mojego diagramu: myślą, że podmieniają całość. W rzeczywistości używają pudełka zawierającego model, harness i interfejs — a wymieniają tylko interfejs, właśnie na T3 Code. I potem dziwią się, że wszystko, co zrobili w jednym miejscu, nie przenosi się na wszystkie inne harnessy, których nigdy nie tknęli.
A moja najgorętsza teza jest taka: to zmiana na plus. Dzięki temu my, twórcy T3 Code, możemy zbudować doświadczenie w pełni abstrakcyjne — tak jak wymieniasz nazwę modelu czy adres API w jednym miejscu kodu, tak powinieneś móc jednym ruchem wymienić harness, żeby nie czuć tego okropnego szarpnięcia, które znam po znajomych siedzących głęboko w Codexie na modelach OpenAI, a potem przenoszących się na Claude Code, bo Opus 5.5 jest niewiarygodny i świetnie wyceniony. Zmieniają naraz całe swoje środowisko pracy i totalnie się w nim gubią. W T3 Code przeskakują między Claude Code a Codexem jednym kliknięciem.
Modele i harnessy zżywają się na dobre
A modele będą coraz sprawniejsze i mądrzejsze, a harnessy w tym procesie coraz mniej widoczne — bo, panowie i panie, oto prawdziwy spoiler: harnessy i modele coraz mocniej się ze sobą splatają. Kiedyś modele miały pewne zdolności i wytrenowane pojęcie wywoływania narzędzi, a harness dopasowywano do modelu. Dziś modele trenuje się na danych pochodzących z harnessów. Dlatego modele Claude zwykle po prostu zachowują się lepiej w Claude Code, a modele OpenAI powinny zachowywać się lepiej w Codexie — tyle że ekosystem promptów systemowych Codexa to taki cyrk, że nie zawsze się to sprawdza. (Osobna tyrada, innym razem.) Jeśli OpenAI zdoła nadrobić zaległości, wynik będzie taki, że Codex będzie dla ich modeli o klasę lepszy niż Claude Code. Co prowadzi do wniosku, że nie powinniśmy w ogóle rozpamiętywać harnessu — tak jak nie myślimy o kuchni, wybierając restaurację. Po prostu idziemy tam, gdzie jest jedzenie, na które mamy ochotę. Po prostu wybieramy opcję, która ma możliwości, jakich chcemy, w cenie, jaka nam pasuje.
I właśnie dlatego narzekam na panów od harnessów — tych, którym stanowczo za dużo zależy, na którym harnessie siedzą, i którzy wyśmiewają cię z głupota za Claude Code albo Codexa. Bo jednym z nich jestem ja. Sam nakręciłem bardzo głośny film, nad którym myślałem stanowczo za dużo, w którym szczegółowo tłumaczyłem, czemu do subagentów Codexa powinieneś używać Claude Code, a nie Codexa. Mam to dalej tak ustawione — i prawie nie używam, bo różnica między Claude Code a Codexem przy pracy z modelami Codexa to jakieś trzy do pięciu procent, może mniej. A nawet jeśli różnice są większe, to jest to wada na poziomie modelu, którą prędzej czy później usuną.
„Gratuluję trzech procent”
Nie mam żadnej osobistej misji zdeprecjonowania harnessów ani ukrytej fanaberii. Wręcz przeciwnie: gdyby harnessy miały znaczenie, mógłbym zbudować naprawdę dobry i wygrać nim rzeszę użytkowników. Tylko że nie mają. Wybrałem więc drogę trudniejszą. OpenCode jest pod tym względem dużo prostszy w budowie niż T3 Code, bo nie musi godzić wszystkiego z każdym dziwnym sposobem, w jaki narzędzie albo harness chce się zachowywać. Macie pojęcie, jak skomplikowany jest nasz kod do zarządzania różnymi typami subagentów we wszystkich harnessach? To koszmar. Ale musimy, bo wybraliśmy trudną ścieżkę — taką, na której harnessy nie znaczą nic dla naszych użytkowników. Dla nas to szczegół implementacyjny.
Więc wszystkim, którzy zasypują mnie, żebym koniecznie sprawdził ich harness, bo „w benchmarku miażdży Claude Code”: gratuluję trzech procent przewagi na modelu poprzedniej generacji albo na modelu o otwartych wagach, którego nikt nie trenował w połączeniu z Claude Code. Naprawdę się cieszę. Cieszę się, że możecie wydać więcej pieniędzy niż kosztuje moja subskrypcja, żeby dostać mniej tokenów i mniej zrobionej roboty. Cieszę się szczerze — bo wyglądacie na zadowolonych. No to super. Ja w tym czasie po prostu pracuję. A nadmierne główkowanie nad cudzym harnessem produktywności wam nie doda.
Więc czym jest T3 Code? ADE — agentowe środowisko programistyczne
O, prawie zapomniałem: obiecałem odpowiedź. Czym jest T3 Code? Jest w pewnym sensie interfejsem — ale takim, który łączy się jednocześnie z człowiekiem i z harnessem. Z modelem nie łączy się bezpośrednio; podpina się pod harness i tam działa. Pokazuje tobie rzeczy i pozwala robić rzeczy. Pozwala też zdalnie kontrolować różne maszyny, zarządzać środowiskami, zdalnie aktualizować wszystkie harnessy i tym podobne. Kiedyś wymyśliliśmy termin na to, co się dzieje, gdy edytor tekstu zaczyna nabierać funkcji poprawiających pracę z kodem. W Notatniku też da się pisać kod — ale brakuje rzeczy, których oczekujemy: podświetlania składni, prostych narzędzi do uruchamiania testów z wynikami w edytorze, wsparcia LSP, dzięki któremu serwer języka na bieżąco podpowiada. Nazwaliśmy to IDE — zintegrowanym środowiskiem programistycznym.
Czym zatem jest T3 Code? Jest jakby IDE, ale to słowo ma dziś bardzo konkretne znaczenie: narzędzie, w którym piszesz kod, możesz go uruchomić i robić inne rzeczy. T3 Code nie jest IDE. Jest ADE — agentowym środowiskiem programistycznym (Agentic Development Environment). I to jest moim zdaniem najbliższe dostępne pojęcie dla narzędzi, o których rozmawiamy. I analogicznie do wszystkiego, co mówiłem wcześniej: spodziewam się, że przestanie być gorącym tematem — tak jak przestały być IDE, niezależnie od tego, czy to Vim, Neovim, Emacs czy VS Code. Chyba jesteśmy już za garbem, może po drugiej stronie: ludziom będzie się coraz mniej chciało dbać o narzędzie, które otwierają, bo po prostu będą pisać polecenia na Slacku.
Ale ja chcę dobrego ADE. Chcę bardzo mocno. Od grudnia nie daję sobie spokoju, odkąd spróbowałem na własnej skórze tego, co szykował Google w Antigravity: była tam odrobina dobrych rzeczy, a cała reszta — śmietnik. Chciałem czegoś dobrego, otwartego i konfigurowalnego. Dlatego zrobiłem T3 Code — ale nie dlatego, że chciałem robić harness. Nigdy nie chciałem robić harnessu; nigdy też nie będę chciał. Narobiłem mnóstwo atrap do benchmarków — i na tym koniec. Chciałem po prostu narzędzia open source, które steruje moją pracą z AI: czegoś, z czym się stykam, co mogę otworzyć i naprawić. T3 Code jest więc ADE — i podejrzewam, że ADE przestaną mieć znaczenie w niezbyt odległej przyszłości, jak wszystko przed nimi. Na razie jednak mi zależy. Zależy mi bardzo. Zbudowaliśmy najlepsze na rynku — i warto je spróbować. Co masz do stracenia? Darmowe i otwarte. W najgorszym razie okaże się beznadziejne i wyśmiejecie mnie na Twitterze.
Zakończenie: czas zamknąć temat
Chyba powiedziałem wszystko, co miałem. Napisałem o tym zdecydowanie za dużo i narysowałem zdecydowanie za dużo, bo nie chcę więcej rozmawiać o harnessach. A jeśli laboratoria zrobią swoją robotę, to nie będę musiał — harnessy staną się po prostu częścią działania systemów. Jeśli przyjdzie mi jeszcze raz mówić o harnessach, to prawdopodobnie dlatego, że ktoś coś naprawdę schrzanilił. Więc jeśli niedługo zobaczycie film o Antigravity — to nie dlatego, że Google zrobiło coś dobrego. Wydaje mi się, że to wszystko. Szczerze mam nadzieję zdjąć ten temat z agendy raz na zawsze. Dajcie znać, czy się rozjaśniło, czy tylko namąciłem. I błagam: jeśli zobaczycie kogoś, kto upiera się, że T3 Code jest harnessem, albo po prostu ewidentnie nie rozumie, czym jest harness — podrzućcie mu ten film. A jeśli wstyd wam — podrzućcie tekst na t3.gg. Nic na tym nie zarobię; wręcz przeciwnie, będzie mnie to kosztować. Chcę tylko, żeby ludzie zrozumieli, czym jest harness, żebym mógł wreszcie raz na zawsze skończyć z tym tematem. Jestem wykończony. Jeśli i wy jesteście — przepraszam. Powiedziałem wszystko, co miałem. Do zobaczenia następnym razem.