Operator agentów AI: czego nauczył mnie podcast z Theo Browne'em

Ten wpis jest inny niż większość na aikreacja.pl. Jest dłuższy i bardziej techniczny. Napisałem go przede wszystkim dla siebie, bo to miejsce, do którego wracam po inspirację. Jeśli budujesz własnego asystenta albo cały zespół asystentów, znajdziesz tu sporo do przemyślenia.

Theo Browne prowadzi jeden z największych kanałów dla programistów na YouTube i buduje T3 Code - otwartą apkę do sterowania agentami AI, które piszą kod (Claude Code, Codex i podobne). W październiku rozmawiał z Joelem Hooksem na kanale MEGA DEV.

Od wykonawcy do operatora

Najważniejsze zdanie tego podcastu pada pod koniec godziny. Theo mówi do programistów:

“Twoją pracą nie jest już bycie czarną skrzynką, do której wchodzi kontekst, a wychodzi kod. Twoją pracą jest przygotowanie tej skrzynki tak, żeby odniosła jak największy sukces.”

To jest sedno zmiany. Programista przestaje być tym, kto robi. Staje się operatorem: tym, kto przygotowuje warunki, w których agent zrobi dobrą robotę.

Theo podaje prosty sposób, żeby zrozumieć, czego agent potrzebuje. Przypomnij sobie zadanie, które poszło Ci najlepiej w życiu. Takie, przy którym praca “sama się wylewała”. Zadaj sobie pytania:

• Kto dał Ci to zadanie i jak je opisał?
• Co wiedziałeś o ludziach, dla których to robisz?
• Jakie narzędzia miałeś pod ręką?
• Jak mogłeś sprawdzić, że zmiana działa?
• Jakie uwagi dostałeś po pierwszej wersji?

Wszystko, co wtedy pomogło Tobie, pomoże też agentowi. Twoim zadaniem jest dać mu to samo, tylko zapisane tak, żeby mógł z tego korzystać bez Ciebie.

Theo mówi też wprost, że agenci już dziś zamykają zadania, jeśli są dobrze opisane. “Jeśli myślisz inaczej, oszukujesz sam siebie” - dodaje.

Co w takim razie zostaje człowiekowi? Według Theo przede wszystkim ludzie, dla których pracujesz. Każdy w zespole musi dziś dobrze wiedzieć, kto korzysta z jego pracy i czego potrzebuje. Kiedyś to pomagało. Dziś jest konieczne, bo samo wykonanie zadania przechodzi na agentów. Dobry opis zadania bierze się z rozumienia potrzeb, a tego agent sam nie zdobędzie.

Kompas, który udawał kompas

Theo tłumaczy obecny etap AI przez historię iPhone’a. W iOS 6 kalendarz wyglądał jak papierowy kalendarz, a kompas jak prawdziwy kompas na drewnianym stole, ze złotym brzegiem. Apple robił to celowo (nazywano to skeuomorfizmem). Ludzie mieli uwierzyć, że telefon zastąpi przedmioty, których używali całe życie.

Z czasem większość ludzi nigdy nie miała papierowego kalendarza ani kompasu. W iOS 7 Apple przestał więc udawać rzeczywistość i zaczął projektować to, co najlepiej działa. Apki zrobiły się prostsze, a z czasem mogły robić znacznie więcej.

Według Theo z AI jesteśmy dziś w epoce iOS 6. Trzymamy się form, które znamy z pracy ludzi:

• Tryb planowania. Agent najpierw pisze plan, czeka na zgodę, dopiero potem działa. Miało to sens, gdy modele były słabsze i trzeba je było ograniczać. Dziś model sam planuje w trakcie pracy.
• Rozbudowane “fabryki” agentów. Ludzie budowali systemy z dwudziestoma rodzajami podagentów, etapami i pętlami recenzji. Theo mówi, że dziś wystarczy napisać agentowi: “rozdziel tę pracę na podagentów, a kolejnych użyj do sprawdzenia”. Efekt jest prawie taki sam.
• Przekonanie, że trzeba przeczytać każdą linijkę kodu. Inaczej “nie wiem, co się dzieje”.

Theo sam nie pisze już własnych definicji podagentów. Wyjątkiem był jeden błąd w narzędziu, który musiał obejść. Mówi agentowi, czego chce, i ufa, że model sobie poradzi, o ile ma potrzebne narzędzia.

Ważne: Theo nie mówi, że te formy były złe. Były potrzebne na swój czas. Problem zaczyna się wtedy, gdy trzymamy się ich z przyzwyczajenia.

Całe produkty stają się plikami tekstowymi

Ta myśl zrobiła na mnie największe wrażenie. Theo porównuje agentów do Node.js. Kiedyś JavaScript działał tylko w przeglądarce. Node sprawił, że ten sam język mógł sterować całym komputerem.

Agenci robią to samo z językiem naturalnym. Piszesz w zwykłym pliku tekstowym (Markdown), co ma się stać, przekazujesz go agentowi i to się dzieje.

Przykład Theo: codziennie o 10:00 agent przegląda wszystkie zmiany czekające na zatwierdzenie w jego projektach. Na tej podstawie nadpisuje prostą stronę HTML. Theo zaczyna dzień od gotowego podglądu. Bez programu, bez bazy danych, bez serwera. Jest tylko plik z opisem i harmonogram, który go uruchamia.

Theo stawia też granicę. Nie piszesz serwera w Markdownie, tak jak nie przepisujesz ffmpeg (programu do obróbki wideo) w JavaScripcie. Ale wiele drobnych narzędzi, które kiedyś trzeba było budować i utrzymywać, dziś jest jednym plikiem, który nie wymaga żadnej opieki.

Skille: pamięć procesu, która ma swoje słabe strony

Joel pyta wprost: czy skille (zapisane procedury, które agent wczytuje do konkretnego zadania) przetrwają? Theo odpowiada ostrożnie. Uważa, że idea powtarzalnego procesu zostanie. Nie wie, w jakiej formie.

Dlaczego zostanie? Bo modele są wrażliwe na słowa, którymi je prowadzisz. Jeśli trzy osoby w zespole opiszą to samo zadanie inaczej, agent zachowa się na trzy różne sposoby. Wspólny plik z procedurą sprawia, że zespół dostaje ten sam wynik.

Gdzie jest słaby punkt? Ten sam skill działa różnie u różnych ludzi. Zależy od innych plików z instrukcjami i od modelu. Theo podaje własny przykład. Ma w instrukcjach zasadę: “traktuj pytania jako tylko do odczytu, dopóki nie potwierdzę, że chcę zmian”. Przy modelach Claude to prawie konieczne, bo inaczej od razu zmieniają pliki. Przy innych modelach ta sama zasada przeszkadza. Pytasz, czy uwagi są warte poprawy, model mówi “tak” i nic nie robi.

Theo widzi też kierunek rozwoju. Część skilli zamieni się w proste usługi w chmurze. Ktoś z zespołu klika przycisk i dostaje raport, bez mieszania w swojej bieżącej pracy z agentem.

List do genialnego inżyniera z dniem świstaka

To moje ulubione porównanie z całego podcastu:

“Agenci to niesamowicie utalentowani inżynierowie, którzy przeżywają najgorszy dzień świstaka. Za każdym razem, gdy dajesz im zadanie, ich mózg się resetuje i zapominają wszystko, czego się nauczyli.”

Co z tego wynika? Wyobraź sobie list, który taki inżynier czyta każdego ranka. Zna się na swojej robocie i sam znajdzie wszystko w plikach. Nie wie tylko, od czego zacząć, kim jesteś i co jest jego zadaniem.

Tym właśnie ma być plik z instrukcjami dla agenta (CLAUDE.md albo AGENTS.md). Ma być krótkim listem na start, a nie encyklopedią firmy.

Co zostaje: skrzynia biegów

Joel pyta, czy zabezpieczenia w kodzie nie stają się teatrem. Mowa o testach, sprawdzaniu typów danych, automatycznej kontroli przy każdej zmianie. Theo odpowiada pytaniem: czy samochody z automatyczną skrzynią mają biegi?

Mają. Kierowca ich nie widzi i o nich nie myśli, ale biegi dalej chronią silnik. Tak samo jest z zabezpieczeniami. Człowiek może ich nie dotykać, ale agent korzysta z nich cały czas.

Theo zauważa, że okno kontekstu agenta (ile tekstu model ogarnia naraz) jest mniejsze niż większość dużych projektów. Dlatego najważniejsze pytanie nie brzmi “ile agent może wiedzieć”. Brzmi “ile agent może zrobić bez wiedzy o całości, i to z pewnością, że niczego nie zepsuł”.

Co więc zostaje i zyskuje na znaczeniu:

Element	Po co agentowi
Sprawdzanie typów danych	Zmienisz nazwę pola w bazie i od razu widzisz każde miejsce, które się przez to sypie
Testy	Automatyczna odpowiedź, czy zmiana działa
Kontrola przy każdej zmianie	Zewnętrzny sędzia, zanim cokolwiek trafi do ludzi
Wersja podglądowa	Każda zmiana dostaje własną kopię strony do kliknięcia, bez konfiguracji
Kontrola w języku naturalnym	Lista zasad zapisana zwykłymi słowami, którą osobny agent sprawdza przy każdej zmianie

Ostatni punkt jest nowy. Theo ma w projekcie zapisane po angielsku zasady, np. “używaj gotowych elementów z naszego systemu projektowego, nie buduj własnych”. Agent sprawdza je przy każdej zmianie, zanim zajmie się nią człowiek. Theo porównuje to do listy kontrolnej pilota. Takiej reguły nie napiszesz w zwykłym programie sprawdzającym, a agent ją rozumie.

Pewność zamiast czytania każdej linijki

Tu jest liczba, która porządkuje całe myślenie. Theo pyta: jaką masz pewność, że zmiana, która przeszła wszystkie kontrole, naprawdę jest dobra? 40%? 60%? 85%?

Każdy punkt w górę zmienia skalę tego, co możesz zrobić. Przy 85% możesz wypuścić setki agentów na zaległe zadania. Przy 95% i łatwym cofaniu zmian możesz zatwierdzać prawie w ciemno.

Theo mówi, że poprzedniego wieczoru przed snem zatwierdził 28 zmian. Było to możliwe tylko dlatego, że zanim do niego trafiły, system je już sprawdził.

Kolejna praktyczna zasada: jeśli Ty nie możesz pracować nad trzema rzeczami naraz bez gubienia się, agenci też nie będą mogli. Projekt, który wymaga jednego konkretnego ustawienia komputera albo pozwala uruchomić tylko jedną kopię, blokuje pracę równoległą. Theo napisał kiedyś 3 tysiące linijek kodu tylko po to, żeby wygodnie testować zmiany zdalnie. Kiedyś przy małym zespole by się to nie opłacało. Przy setkach agentów zwraca się wielokrotnie.

Jak Theo sprawdza nowy model

Theo testuje nowy model jak kandydata na rozmowie o pracę. Najpierw każe mu przejrzeć swoje środowisko i projekt. Potem dopytuje:

• Dlaczego użyłeś tego narzędzia?
• Dlaczego wczytałeś tę procedurę?
• Co myślisz o tym, jak ten projekt jest poukładany?
• Czy masz wszystko, żeby robić zmiany z pewnością?

Dopiero potem daje prawdziwe zadania. Zaczyna od “napraw ten błąd, jest mniej więcej tutaj”. Kończy na “przebuduj tę sześcioletnią apkę na zupełnie innej technologii”. Szuka odpowiedzi na dwa pytania: na jak samodzielną pracę może temu modelowi pozwolić i na ile może mu wtedy zaufać.

Otwarte narzędzia w czasach małego zaufania

Theo mówi, że wchodzimy w erę coraz mniejszego zaufania. Dlatego chce, żeby narzędzie, w którym pracuje codziennie, było otwarte. Może je zmienić, naprawić albo pójść własną drogą, jeśli twórcy skręcą w złą stronę.

Jego zdanie: “Zawsze możesz zaufać kodowi, który sam możesz zmienić. Nie wiem, czy możesz zaufać czemukolwiek innemu.”

To dobrze się łączy z tym, o czym pisałem w czterech narzędziach AI, z których korzystam: niezależność od jednego dostawcy jest dla mnie warunkiem, a nie dodatkiem.

Mali mogą więcej niż duzi

Duże firmy mają stare sposoby pracy zapisane w procesach. Kto się do nich nie stosuje, ryzykuje zwolnienie. Mały zespół zmienia sposób pracy razem z technologią.

Theo zauważa, że dziś technologia zmienia się dużo szybciej niż procesy w firmach. Ta różnica nigdy nie była tak duża. Dlatego zmotywowany mały zespół z dobrze przygotowanym środowiskiem może dziś dogonić dużych.

Joel dopowiada coś, co dobrze znam. Przez lata prowadzenia firmy nie miał czasu ani głowy na takie systemy. Teraz może o nich myśleć, bo agenci dają skalę, na którą wcześniej stać było tylko gigantów.

Solo founder? Theo odradza, ja widzę to inaczej

Theo mówi wprost, że nie warto być solo founderem. Sam był nim tylko trzy miesiące i do dziś wspomina ten czas ze stresem. Według niego niewielu odnosi sukces, a prawie wszyscy kończą bardzo przygnębieni.

Prowadzę firmę sam i rozumiem, o czym mówi. Mierzenie się z trudnościami w pojedynkę jest emocjonalnie ciężkie. Nie chcę jednak nikogo zniechęcać. Uważam, że AI może tu dużo pomóc. Przejmuje część pracy, a ja odzyskuję czas na wartościowe spotkania z innymi ludźmi i na wymianę doświadczeń.

Najpierw zrozum, potem automatyzuj

Na koniec Theo mówi to, co uważam za najważniejszą przestrogę całego podcastu:

“Ludzie nie używają AI, żeby automatyzować to, co rozumieją. Używają jej, żeby uniknąć budowania tego zrozumienia. Jeśli tak jej używasz, szykujesz sobie porażkę.”

I dalej: “Jeśli najpierw naprawdę zadbasz o daną rzecz i ustawisz ją tak, żeby działała dobrze, a dopiero potem wpuścisz agentów, osiągniesz dużo więcej.”

Theo podaje przykłady złego podejścia. “Nie chce mi się uczyć frontendu, niech AI to zrobi.” “Nie lubię zarządzać serwerami, niech AI się tym zajmie.” “Nie lubię przeglądać kodu, niech AI to robi.” Jego rada jest inna: używaj AI, żeby pozbyć się nielubianych części pracy, na której Ci naprawdę zależy. Żeby dobrze zautomatyzować coś, czego nie lubisz, musisz to najpierw dobrze znać.

Co z tego biorę do AI-Exec

AI-Exec to mój zespół asystentów AI: role od strategii, sprzedaży, marketingu, procesów i technologii, wspólna pamięć firmy i zasada, że to, co wychodzi na zewnątrz, zatwierdzam ja. Opisałem go we wpisie AI-Exec: zespół asystentów AI. Przyłożyłem do niego tezy Theo.

Teza Theo	Jak jest u mnie dziś	Kierunek
Tryb planowania to kompas z iOS 6	Każda treść zewnętrzna przychodzi do mnie jako szkic do zatwierdzenia	Zatwierdzanie zostaje przy rzeczach zewnętrznych. Przy pracy wewnętrznej coraz mniej pytań o zgodę
Role jak w ludzkim zespole to forma przejściowa	Asystenci mają role jak w firmie: CEO, CMO, COO	Role pomagają mi zaufać i porządkują wiedzę. Mogą się z czasem uprościć
Markdown jest wykonywalny	Procedury dnia i tygodnia, skille i rutyny w tle to pliki tekstowe	Więcej drobnych usług jako plik z opisem i harmonogram zamiast osobnych narzędzi
Skill to pamięć procesu, ale różnie działa na różnych modelach	Każdy skill ma znacznik wersji i źródła, bo żyje w kilku środowiskach	Testować skille na każdym modelu, którego używam
List do inżyniera z dniem świstaka	Główny plik instrukcji, który każdy asystent czyta na start	Pilnować, żeby był krótkim listem, a nie encyklopedią
Agent jest tak dobry, jak informacja zwrotna, którą dostaje	Narzędzie do publikacji zwróciło kiedyś fałszywe “zaplanowane”. Asystent w to uwierzył	Każdy ważny krok kończy się sprawdzeniem prawdziwego wyniku, a nie odpowiedzi narzędzia
Najpierw zrozum, potem automatyzuj	Buduję mniejsze systemy i wiem, jak działają	Wchodzić w większą złożoność dopiero wtedy, gdy rozumiem, jak system sam sobą zarządza

Jestem otwarty na to, żeby budować AI-Exec bardziej pod agentów, a mniej kopiować ograniczenia świata ludzi. Widzę, że wiodące modele pracują coraz lepiej, nawet na zwykłych poleceniach. Z czasem agenci będą konsultować zmiany między sobą i sami ulepszać system. Moją rolą będzie nadzór. Dokładnie taki operator, o jakim mówi Theo.

Obejrzyj cały podcast

Jeśli budujesz własnego asystenta, prowadzisz zespół albo zastanawiasz się, co oddać agentom AI - obejrzyj go w całości. Jest po angielsku i trwa nieco ponad godzinę.

Whole products can now be prompts - Theo Browne, kanał MEGA DEV

Najważniejsze fragmenty:

• 30:30 - iOS 6, kompas i koniec trybu planowania
• 35:36 - całe produkty jako pliki tekstowe, podagenci
• 37:38 - czy skille przetrwają
• 40:42 - skrzynia biegów, czyli po co zabezpieczenia
• 43:44 - inżynier z dniem świstaka
• 46:48 - Markdown, który się wykonuje
• 52:55 - od czarnej skrzynki do operatora
• 64:09 - najpierw zrozum, potem automatyzuj

Jeśli chcesz zacząć od jednego asystenta, który zna Twoją firmę, zajrzyj do przewodnika Zbuduj swojego asystenta.