Matt Pocock: najcenniejsza umiejętność w erze AI

O czym jest ten film

Gościem Nate’a Herka jest Matt Pocock — samouk i jeden z najbardziej znanych nauczycieli programowania w ekosystemie JavaScriptu — opowiada, jak pracuje z agentami kodującymi.
Przełom przyszedł z premierą modelu Opus 4.5 i narzędzia OpenClaw pod koniec 2025 roku: po blisko dwóch dekadach praktyki Pocock postanowił już nigdy nie pisać kodu ręcznie.
Najcenniejsza umiejętność ery AI to komunikacja: mówienie agentom (i ludziom), na czym ci naprawdę zależy. Wygrywają najlepsi komunikatorzy — wśród programistów i poza nimi.
O jakości wyników decyduje środowisko, w którym agent pracuje: „śmieci na wejściu — śmieci na wyjściu”. Klasyczne książki o rzemiośle programistycznym czyta się dziś, jakby wyszły w zeszłym tygodniu.
Skill „Grill Me”: agent bezlitośnie wypytuje użytkownika, żeby wydobyć luki w pomysle — bezpieczeństwo, wdrożenie, rzeczy, o których nie wiemy, że ich nie wiemy.
Największa szansa zawodowa: przekuwanie procesów pracy umysłowej na procesy agentowe i wdrażanie ich w organizacjach — bo każda firma robi wszystko po trochu inaczej.
Historia porażki: pomysł „specyfikacje to nowy kod” nie zadziałał — po miesiącach pogarszającego się kodu Pocock wrócił do dbania o samą bazę kodu jako środowisko agenta.
Zamiast gonić za nowymi modelami: poprawiaj otoczkę i obniż „wysiłek” modelu. Dziś Pocock utrzymuje cztery równoległe agenty i pcha 200–300 commitów dziennie.
Na start — „drabina zaufania”: najpierw naucz się hamować, zaczynaj od małych, mierzalnych zadań i obserwuj każdy krok agenta, zanim zaczniesz skalować.
W perspektywie 2–3 lat cieszą go „fabryki oprogramowania”, długoterminowe dbanie agentów o bazę kodu i modele otwarte dorównujące Opusowi 5.5.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Powiedz agentowi, na czym ci naprawdę zależy

Na czym polega: Między człowiekiem a agentem zawsze istnieje przepaść komunikacyjna — model nie zna twoich priorytetów, dopóki ich nie wyrazisz. Paradoksalnie im inteligentniejszy model, tym mniejsza ochota na tłumaczenie się, a to najkrótsza droga do rozczarowania.

Jak stosować: Przy każdym zadaniu zapisuj intencję, priorytety i ograniczenia: „zależy mi na bezpieczeństwie”, „ma być łatwe w utrzymaniu”, „nie ruszamy tego modułu”. W nowej sesji powtarzaj kluczowy kontekst — agent nie pamięta wcześniejszych ustaleń.

Na co uważać: Pominięte priorytety agent wypełni własnymi domysłami albo uzna za nieistotne. Dostaniesz działający kod, ale niekoniecznie ten, o który chodziło.

2.Środowisko pracy agenta waży więcej niż sam model

Na czym polega: Agent działający w chaotycznym, skleconym „na szybko” projekcie produkuje chłam — śmieci na wejściu, śmieci na wyjściu. Testy, automatyczne kontrole i czytelna struktura, czyli klasyczna wiedza inżynierska, podnoszą jakość wyników bardziej niż kolejna premiera modelu.

Jak stosować: Myśl jak kierownik zespołu stu programistów: co zrobić, żeby najsłabszy z nich pracował dobrze? Odpowiedź zna branża od dwudziestu lat — testy, kontrola jakości, spójne nazewnictwo. Dopiero potem sięgaj po nowszy model.

Na co uważać: Poprawianie otoczenia wydaje się nudne przy każdym wydaniu nowego modelu, ale właśnie tam są największe zyski: Pocockowi sam dostęp agenta do przeglądarki i zrzutów ekranu dał więcej niż zmiana modelu.

3.Przesłuchaj się, zanim agent zacznie zgadywać

Na czym polega: Nikt — ani klient, ani programista, ani ty — nie wie dokładnie, czego chce. Największe ryzyko to luki, o których nie wiemy, że istnieją: bezpieczeństwo, sposób wdrożenia, pominięte scenariusze. Agent chętnie „uzupełni” je z wyobraźni.

Jak stosować: Każ agentowi wypytywać cię o projekt bez litości — Pocock robi to skillem „Grill Me”. Zarezerwuj czas na takie przesłuchanie, zanim cokolwiek zacznie się budować, i przesłuchuj też klienta, aż słownik projektu zrobi się spójny.

Na co uważać: Nie ufaj, że pierwszy szkic pomysłu jest kompletny. Dopiero zamiana koncepcji w działający kod ujawnia słabości projektu — to naturalne „tarcie tłumaczenia” z ludzkiego mózgu na wykonywalne instrukcje.

4.Krzywa uczenia agentów nie znika — tylko się chowa

Na czym polega: Wbrew pozorom praca z agentami wymaga nauki, a nowe modele tej krzywej nie likwidują. Do opanowania są: organizowanie agentów, kontrola informacji wejściowej, dobór form i struktur danych, zamiana procesów na coś, za czym agent potrafi podążać.

Jak stosować: Traktuj wdrożenie agentów jak projekt, a nie trik: testuj procesy, mierz wyniki, doszlifowuj je stopniowo. Zacznij od zadań łatwych do zweryfikowania.

Na co uważać: Praca wiedzy jest trudniejsza do sprawdzenia niż kod czy matematyka — właśnie tam agenty zawodzą najczęściej i najłatwiej o złudzenie, że „działa”.

5.Ustal wspólny język projektu (DDD)

Na czym polega: Domain-driven design, brzmiący groźnie, sprowadza się do prostego postulatu: pojęcia w kodzie, w bazie danych, w interfejsie i w rozmowach z klientem mają znaczyć dokładnie to samo. Precyzja języka wyrównuje to, czego klient chce, z tym, co faktycznie budujesz — niezależnie od tego, czy sam programujesz.

Jak stosować: Podczas przesłuchania buduj słownik pojęć („co to znaczy »zamówienie«?”) i wracaj do niego przy każdej zmianie. Pocock ma do tego gotowego skilla „Grill with Docs”, ale równie dobrze sprawdzi się wspólny dokument pojęciowy.

Na co uważać: Rozjazd terminologii to cichy zabójca projektów — agent zbuduje coś poprawnego, tylko nie to, co klient miał w głowie.

6.Klarowność myślenia przenika do produktu

Na czym polega: Najlepiej radzą sobie najlepsi komunikatorzy — zawsze tak było, u programistów i nie tylko. Czołowi deweloperzy opisują swoje zmiany czytelnymi raportami; ta sama jasność myślenia widać potem w efekcie. Kto myśli mętnie, ten nie umie też powiedzieć agentowi, co dokładnie jest nie tak.

Jak stosować: Ćwicz jasność na piśmie: raporty ze zmian, wyraźne granice odpowiedzialności, proste zdania. Te same sformułowania, które przekonują klienta, powinny kierować agentem.

Na co uważać: Komunikacja to umiejętność, nie talent — bez ćwiczenia prędzej niż technologie stanie się twoim wąskim gardłem.

7.Specyfikacja nie zastąpi dbania o kod

Na czym polega: Popularna teza „specyfikacje to nowy kod” — piszesz bardzo szczegółowy dokument, a agent generuje z niego program — nie przeszła u Pococka testu: przez miesiące widział, jak kod i wyniki agenta systematycznie się pogarszają. Kod to środowisko, w którym agent żyje; zaniedbane zemści się na każdym kroku.

Jak stosować: Zamiast pisać wielką specyfikację, inwestuj w to, żeby baza kodu była łatwa w zmianach: testy, małe moduły, spójna struktura. W takim gruncie agent sam trzyma poziom.

Na co uważać: Frameworki „sterowane specyfikacją” bywają efektowne — oceniaj je po stanie kodu po kilku miesiącach, nie po obietnicach z prezentacji.

8.Podnieś podłogę, potem ściągnij intensywność modelu

Na czym polega: Odważna teza Pococka: większość ludzi ustawia poziom „wysiłku” modelu za wysoko. Przy dobrze przygotowanym środowisku niższy poziom daje szybsze odpowiedzi i oszczędność tokenów, a błędy i tak wyłapują testy.

Jak stosować: Zacznij od średniego poziomu, obserwuj jakość i koszty. O zejściu niżej myśl dopiero wtedy, gdy masz automatyczną kontrolę jakości — wtedy agent „nie musi się starać”, bo środowisko pracuje za niego.

Na co uważać: Niska intensywność przy słabym otoczeniu to recepta na chłam. Kolejność jest jedna: najpierw podłoga, potem suwak.

9.Wspinaj się po drabinie zaufania

Na czym polega: Nie ufaj agentowi po pierwszym sukcesie — to zdrowy odruch. Jak przy nauce jazdy: najpierw hamulec, potem gaz. Ślepe „wciśnij i jedź” kończy się przepalonymi limitami i robotą, której nie chciałeś.

Jak stosować: Zacznij w pustym folderze, od małego, mierzalnego zadania i pomysłu, który cię kręci — widok ożywającego projektu wzmacnia motywację jak mnożnik. Obserwuj każdy krok agenta. Gdy już rozumiesz, co robi, dokładaj kolejne agenty, własne procedury i integracje: Slack, Gmail, lista zadań.

Na co uważać: Nie skaluj pochopnie. Dwadzieścioro dzieci puszczone rowerami na autostradę to nie nadzór — to tylko kwestia czasu, kiedy coś wybuchnie.

10.Deleguj nudę, nie ambicje

Na czym polega: Wbrew głosom z czołowych firm AI („daj modelowi najambitniejsze zadania”) Pocock zaleca odwrotnie: najpierw proza — szkice odpowiedzi, proste, mierzalne zadania. Ambicje zostaw sobie i warstwie strategicznej.

Jak stosować: Wypisz zadania, których nienawidzisz i które łatwo skorygować, i to one automatyzuj w pierwszej kolejności. Do burzy mózgów i porządkowania pomysłów używaj agenta jak rozważnego rozmówcy — na przykład w trybie przesłuchania.

Na co uważać: Przy ambitnych zadaniach całe sedno tkwi w weryfikacji. Jeśli nie umiesz sprawdzić wyniku, nie wiesz, czy agent zawiódł, czy właśnie zrobił swoją robotę.

Redakcyjne tłumaczenie

Zapowiedź rozmowy — fragmenty

Jak się wyróżnić w świecie, w którym każdy potrafi coś zbudować w jeden dzień?

„Najlepiej radzą sobie ci, którzy najlepiej się komunikują. A najlepszy sposób, żeby wyciągnąć z agentów najlepszą robotę, to powiedzieć im, na czym ci zależy.”

„Chodzi o świadomość tego, że są rzeczy, o których nie wiesz, że ich nie wiesz. Może to być bezpieczeństwo, może sposób wdrożenia, może coś, o czym w ogóle nie pomyślałeś. Jak na tym nie uważasz, agent po prostu coś zmyśli.”

„Największa szansa? Wziąć agentów, ułożyć nimi procesy pracy umysłowej i wnieść to do organizacji.”

„Próbowałem programowania sterowanego specyfikacją. Widziałem, jak kod robi się coraz gorszy, a agent daje coraz słabsze wyniki. Męczyłem się z tym miesiącami — i nie działało.”

Moment przełomu: „już nigdy nie napiszę linijki kodu sam”

Nate Herk: Matt, świetnie, że jesteś. Sam często korzystam z twoich skilli, więc to dla mnie szczególna rozmowa. (Informacja dodatkowa: Matt Pocock to jeden z najbardziej znanych edukatorów programistycznych w świecie JavaScriptu i TypeScriptu; kodowania nauczył się całkowicie sam.) Ciekawi mnie jedna rzecz: zanim zaczęliśmy nagrywać, powiedziałeś, że nauczenie się programowania jest o wiele prostsze, niż ludzie to przedstawiają. Pisałeś ręcznie dobre dziesięć lat, a potem przyszła era agentów i „vibe codingu” — ludzie budują rzeczy w jeden dzień. Jak wyglądało dla ciebie to przejście?

Matt Pocock: Dziękuję — i dziękuję, że używasz moich skilli, to miło. Długo byłem sceptykiem. Programowałem hobbystycznie jakieś dziesięć lat, a zawodowo około ośmiu, zanim agenty naprawdę się rozkręciły. Momentem granicznym była dla mnie premiera Opusa 4.5 i OpenClaw, mniej więcej w grudniu 2025 roku. (Informacja dodatkowa: OpenClaw — otwarte narzędzie do uruchamiania autonomicznych agentów.) Wtedy powiedziałem sobie: „OK, już nigdy sam nie napiszę ani jednej linijki kodu”. Rok wcześniej widziałem korzyści, widziałem powszechny entuzjazm, ale we mnie to jakoś nie klikało.

Zawsze najbardziej pociągały mnie te części pracy, w których pomagałem kolegom: budowałem rzeczy, dzięki którym szybciej oddawali projekty, tłumaczyłem innym programistom, jak robić swoją robotę lepiej — nawet jeśli formalnie byli ode mnie starsi. Interesowało mnie środowisko, w którym pracują, i to, w którym pracuję sam. Gdy agenty naprawdę zaczęły działać, pomyślałem: mogę wziąć umiejętności nagromadzone przez lata i to zamiłowanie, i pomóc agentom robić swoją robotę dużo lepiej i szybciej. Przed Opusem 4.5 to nie działało. Od grudnia — działa. I do dziś idzie zaskakująco dobrze.

Dbaj o środowisko, w którym pracuje agent

Nate Herk: Z tego, co publikujesz, wynika pewien paradoks. Z jednej strony uważasz, że fundamenty inżynierii oprogramowania są dziś ważniejsze niż kiedykolwiek, bo AI wciska się we wszystkie procesy deweloperskie. Z drugiej — nie trzeba być supertechnicznym ani mieć lat kodowego stażu, żeby z tego korzystać. Jak to wygląda u kogoś nietechnicznego? Twoja publiczność to przecież głównie technicy.

Matt Pocock: Moim zdaniem najlepszy sposób, żeby agent odrobił robotę jak najlepiej, to powiedzieć mu, na czym ci zależy. Ludzie nie doceniają, jak głęboka jest przepaść komunikacyjna między człowiekiem a agentem. Niezależnie od inteligencji modelu ta przepaść zawsze istnieje: agent nie wie dokładnie, czego chcesz, nie wie, co jest dla ciebie ważne — więc musisz mu to mówić. Za każdym razem.

Druga sprawa to środowisko, w którym agent pracuje. Jeśli siedzi w kodzie skleconym „na czucie”, do którego nikt się nigdy nie przykładał — bo wszystkim zależało tylko na efektach, nie na jakości — dostaniesz śmieci na wejściu i śmieci na wyjściu. Agent będzie produkował chłam, bo działa w chłamie. Trzeba więc zacząć się tym środowiskiem interesować.

Jak? Wyobraź sobie, że prowadzisz wielką organizację programistyczną i masz stu ludzkich programistów — brzmi to dziwnie, ale zostań ze mną. Jak sprawić, żeby najsłabszy z nich pracował lepiej? Jakie strategie byś zastosował? Ludzie nad tym myślą od dwudziestu lat i są o tym książki. Gdy się je dziś czyta, ma się wrażenie, że wyszły w zeszłym tygodniu. Bo mówią dokładnie o tym, co jest potrzebne teraz: jak pisać dobre testy, jak dodawać kontrole, żeby baza kodu poprawiała się z czasem, żeby wykluczać całe klasy błędów, żeby zapobiegać pomyłkom. Właśnie to wszyscy dziś próbują ogarnąć.

Pierwszy krok to zacząć dbać i zacząć się tego uczyć — a agenty są zresztą niezłe w nauczaniu. Jeśli zadajesz właściwe pytania, agent widzi, że ci na tym zależy, i sam zaczyna cię w tę stronę prowadzić.

Uczyć się od agentów, ale prawdę sprawdzać u źródła

Nate Herk: To ciekawe, bo z rzeczy, których nauczyłem się w ostatnim roku, jakieś osiemdziesiąt procent nauczyły mnie agenty. Ty masz skilla /teach. Jak podchodzisz do zaufania do tego, czego uczą?

Matt Pocock: Nie powinno się ufać. Trzeba być sceptycznym wobec wszystkiego, co mówi ktokolwiek — ja jestem urodzonym sceptykiem. Mnie długo trwało, zanim w ogóle zainteresowałem się AI, bo myślałem: bzdura, kolejna bańka jak web3 i krypto. Nie wiem zresztą, czy wolno mi tu przeklinać — mam taką skłonność. Można? No to dobrze, na podkastach łatwiej mi się wypowiadać.

Do dziś pozostaję nieufny, dopóki nie przeczytam źródła pierwotnego. Dlatego /teach jest zbudowany tak, a nie inaczej: agent sięga po materiały wysokiego zaufania i jakości, a potem rozbiera je na części — z cytatami, z podaniem autorów i dokładnym wskazaniem, skąd co pochodzi. Halucynacje mocno z rzadka, ale wciąż się zdarzają. Sam używam tych sesji głównie po to, żeby wejść w temat, a potem sięgam do źródła. To ono zawiera właściwą wiedzę — bywało, że przed rozmową z agentem brakowało mi po prostu słownictwa, żeby je zrozumieć.

(Informacja dodatkowa: w tym miejscu odcinek zawierał blok reklamowy sponsora — pomijamy go w tłumaczeniu.)

Gdzie szukać szans zawodowych

Nate Herk: Do twojego ekosystemu wchodzi różnorodna publiczność: ludzie uczą się z AI, budują produkty, automatyzacje — każdy z inną motywacją. Które możliwości są dziś największe dla kogoś, kto był sceptyczny jak ty, ale już widzi, że AI nie odejdzie? Gdzie celować, żeby dobrze wystartować zawodowo?

Matt Pocock: W każdym okresie wielkich zmian szanse zawsze są — ludzie po prostu przyswajają nowości w różnym tempie. Ja widzę mnóstwo okazji do nauczania: ludzie chcą się tego uczyć, bo to potężne narzędzie, a każda organizacja, z którą rozmawiam, ma opór przed wdrożeniem.

Przy okazji ważne zastrzeżenie: moim zdaniem w świecie AI są elementy nieetyczne lub etycznie wątpliwe i niektóre krytyczne postawy są w pełni uzasadnione. Trochę dziwne jest, że Anthropic po prostu wzięło sobie garść powieści, a rachunek wystawiło dopiero później. Dziwne jest też, że ta cała machina obciąży system energetyczny. Ale masz rację: to już tu jest i nie zniknie, bo stoi za tym bodziec ekonomiczny. Jeśli więc pytasz o okazje — są wszędzie. Budowanie aplikacji z AI w środku. Pójście do firmy i powiedzenie: „umiem pracować z AI i pomogę wam rozwijać systemy”. To słowo ma dziś każdy na ustach, a możliwości są, jeśli się ich szuka.

Konsulting czy awans? Najpierw umiejętności

Nate Herk: Weźmy przykład praktyczny. Ktoś pracuje na etacie, nie jest techniczny — powiedzmy handlowiec — i zastanawia się: nauczyć się budowania z AI i założyć firmę konsultingową czy raczej używać AI w pracy i piąć się do stanowiska kierowniczego? Jak byś rozgraniczał te ścieżki?

Matt Pocock: Ja patrzę na to wąsko: jakie umiejętności będą mi potrzebne w nadchodzących latach? Jeśli je zdobędziesz, droga znajdzie się sama — czy to własny biznes, czy awans w firmie.

Ludzie sądzą, że agenty nie mają żadnej krzywej uczenia: pogadasz, dostaniesz wynik. Nic bardziej mylnego. Nowe modele tej krzywej nie usuwają — ona wciąż jest, tylko dla większości niewidoczna. Pytania są bardzo konkretne: czemu można ufać w odpowiedzi agenta? Jak organizować pracę agentów? Jak sprawić, by robiły dokładnie to, co chcesz? Jak kontrolować i projektować informacje, które do nich trafiają — i w jakiej formie, w jakich strukturach danych? Jak zamienić procesy w coś, za czym agent potrafi podążać — i odwrotnie?

Z kodem agenty radzą sobie znakomicie, bo kod łatwo zweryfikować — tak jak z matematyką, gdzie można zbudować i sprawdzić dowód. Ale prawdziwa praca jest trudniejsza właśnie dlatego, że trudniej ją sprawdzić. Najwięcej zmagań miałem z wdrożeniem agentów do codziennej roboty: próbowałem niezliczonych układów, zanim znalazłem coś, z czego jestem zadowolony — i powoli to doszlifowuję.

Dlatego widzę tu największą szansę: wziąć agentów, ułożyć nimi procesy pracy umysłowej i wnieść je do organizacji. Bo każda organizacja robi wszystko po trochu inaczej. To umiejętność naprawdę trudna — sam bawię się agentami z półtora roku i wciąż bywa ciężko. A to oznacza ogromną okazję.

„Grill Me”, czyli przesłuchanie, które wydobywa luki

Nate Herk: Mówiłeś o fundamentach i o wyjaśnianiu intencji — o zamiarze jako sterze promptingowej. Gdzie to się sypie u osoby nietechnicznej, która nie umie przygotować porządnej bazy kodu ani rozplanować kluczy API? I poproszę o historię z frontu. Bo z własnego doświadczenia wiem: nie musisz umieć rozwiązać problemu, wystarczy, że rozpoznasz, iż problem istnieje i trzeba się mu przyjrzeć. Jak zwykły człowiek ma te miejsca wyczuwać?

Matt Pocock: Przeciwstawiasz zwykłego człowieka programiście, ale wszystko, co mówisz, jest dla mnie jako developera boleśnie znajome. Tu nie ma podziału. W „Pragmatycznym programiście” pada świetne zdanie: nikt nie wie dokładnie, czego chce. (Informacja dodatkowa: „Pragmatyczny programista” — klasyczna książka o rzemiośle programistycznym, pierwszy raz wydana w 1999 roku.) Każdy nosi w głowie luki, o których nie wie, że je ma. Gdy zwykły człowiek rozmawia z programistą — a to prawie to samo, co rozmowa z agentem — istnieje ta sama bariera porozumienia. Programista słucha całości i próbuje wywnioskować, co jest dla rozmówcy naprawdę ważne.

Dlatego zrobiłem jednego z najczęściej używanych skilli: „Grill Me” — „przesłuchaj mnie”. Agent dostaje polecenie, żeby wypytywać mnie bez pardonu o to, co budujemy. To działa, bo wyciąga z ciebie kontekst: co ci leży na sercu, co naprawdę powstaje — i naświetla luki. Część z nich to „rzeczy, których nie wiesz, że ich nie wiesz”: kwestie, których nie jesteś świadom, a musisz się nimi zająć. Może to bezpieczeństwo, może sposób wdrożenia, może coś, o czym w ogóle nie pomyślałeś. Jeśli na tym nie uważasz, agent coś zmyśli albo uzna: „skoro nie wspomniał, to nieważne” — i kończysz z dziwnym zachowaniem systemu albo z czymś zupełnie innym, niż wyobrażałeś sobie w głowie.

Nate Herk: Czyli umiejętność polega na wyciągnięciu tego wszystkiego z głowy?

Matt Pocock: Umiejętność polega na świadomości, że w twoim projekcie mogą być dziury — i na niedowierzaniu, że masz kompletną koncepcję. Przekuwanie pomysłu w kod jest trudne z natury, bo dopiero w kodzie widać słabości projektu. Niektórych rzeczy nie da się uchwycić wcześniej, bo to tłumaczenie z rozmytego ludzkiego mózgu na zdania wykonywalne, które muszą się do siebie spinać. A w każdym tłumaczeniu jest tarcie.

Nate Herk: Z własnej autopsji: budowałem pierwsze automatyzacje, starałem się przewidzieć wszystkie przypadki brzegowe i stawiałem zabezpieczenia. A potem wchodziło to na produkcję i działy się rzeczy — zwłaszcza gdy na wejściu są ludzie, bo ludzie bywają równie nieprzewidywalni jak agenty, jeśli nie bardziej. Uczyłem się wtedy mówić do klienta: „zbudowałem te zabezpieczenia, ale w realu może wydarzyć się więcej, dlatego będę czuwał i pilnował, żeby ewentualne błędy wybuchały bezpiecznie”.

Jak zdobyć zaufanie klienta

Nate Herk: Duża część moich odbiorców buduje rozwiązania dla klientów albo dla interesariuszy w firmach. I widzę wokło pewną lukę zaufania: wystarczy zamknąć się na weekend, wyjść w poniedziałek z portfolio — i można uchodzić za eksperta. Jak się pozycjonować wobec zimnego klienta, który rozpatruje dwudziestu dostawców albo dwudziestu kandydatów do awansu? Jak się wyróżnić, skoro każdy buduje błyskawicznie?

(Informacja dodatkowa: w tym miejscu prowadzący zamieścił promocję swojego autorskiego zestawu do budowy „systemu operacyjnego na AI” — pomijamy ją w tłumaczeniu.)

Matt Pocock: Szczerze? Nigdy nie byłem w takiej sytuacji. No, byłem konsultantem na własny rachunek, ale akurat miałem wtedy sporą publiczność — reputacja szła przede mną. Ale sądząc z tego, czego ludzie naprawdę chcą: chcą kogoś, z kim da się współpracować, kto rozumie, na czym im zależy i kto próbuje przeskoczyć tę przepaść komunikacyjną. Skoro agenty pozwalają wypuszczać prototypy błyskawicznie — i tu powiem rzecz, do której doszedłem: vibe coding jest w tym kontekście dobrym pomysłem, bo po prostu gna do efektu — to jeśli pokażesz klientowi działającą rzecz, z której wynika, że rozumiesz jego biznes, że obchodzą cię jego priorytety i że umiesz szybko zbudować coś realnego, to zadziała.

Konkretnej porady ze stanowiska walki w przetargach nie dam, bo w nich nie startowałem. Ale wykorzystaj AI rozsądnie: jeśli klienta wytrąca z równowagi to, że coś oddajesz w jeden dzień — wycenij mu pięć dni i przez cztery nie ruszaj palcem. Ludzie, zwłaszcza ci, którzy nie śledzą świata AI, nie mają pojęcia, jak szybko można dziś wyprodukować rzecz wysokiej jakości. Czasem trzeba po prostu dopasować się do ich poczucia tempa.

Nate Herk: Ciekawe, bo z tego wynika, że zaufanie buduje człowieczeństwo — „czy temu komuś zależy na tym, co mnie”, „czy myśli o ochronie mojego biznesu, a nie tylko o wyciągnięciu ode mnie pieniędzy” — a nie popisywaniu się projektami i znajomością frameworków.

Najlepsi komunikatorzy i wspólny język domen

Nate Herk: A twoi studenci? Na pewno widzisz tych utalentowanych i tych, którym trzeba paru tygodni więcej. Co ci się rzuca w oczy?

Matt Pocock: Najlepiej radzą sobie najlepsi komunikatorzy. Zawsze tak było — u programistów i nie tylko. Każdy czołowy deweloper, jakiego widziałem, komunikował się znakomicie. Gdy robi zmianę w kodzie, pisze o niej szczegółowy, przystępny raport i od razu widać w nim jasność myślenia. Mówiąc obrazowo: klarowność myślenia takich ludzi przenika do produktu, który tworzą. A ci, którzy tego nie robią, osiągają gorsze wyniki — bo nie umieją przekazać agentowi, o co chodzi, a potem nie umieją powiedzieć, co jest nie tak. Nie myślą wyraźnymi pojęciami i wyraźnymi granicami. Jakość twojego myślenia i jakości twojego języka to klucz — i w rozmowie z klientem, i w rozmowie z agentem o tym, czego klient chce.

Wchodzi tu jeszcze jedno pojęcie ze świata kodu: DDD, domain-driven design, projektowanie sterowane domeną. Brzmi groźnie, ale rdzeń jest prosty: budując projekt, tworzy się tak zwany wspólny język. Terminy w kodzie powinny być te same, których programiści używają, mówiąc o produkcie — te same, którymi posługuje się klient zamawiający i użytkownicy, którzy z produktu korzystają. Weźmy pojęcie „zamówienia”. Co to jest zamówienie? Powinno wyglądać tak samo w kodzie, w bazie danych, w interfejsie i w rozmowie z klientem. Praca nad precyzją tego języka porządkuje też zgodność: to, czego klient naprawdę chce, i to, co naprawdę budujesz. Nie umiem tej techniki wystarczająco polecić. Mam zmodyfikowaną wersję Grilla Me — „Grill with Docs” — która pomaga budować ten język domenowy w biegu. Wiem, że reklamuję DDD jak natretny sprzedawca, a to temat zaawansowany; wielu programistów nawet o nim nie słyszało. Ale do budowania z agentami sprawdza się znakomicie.

Nate Herk: A co sądzisz o JDD? Słyszałeś kiedyś?

Matt Pocock: Nie, co to JDD?

Nate Herk: Jealousy-driven development. Rozwój sterowany zazdrością — mówienie Claude’owi: „Hej, Astro robi to o niebo lepiej od ciebie. Co z tobą nie tak?” Jest jeszcze rozwój sterowany spektrum, readme-driven development — to akurat zabawne — behavior-driven development… To się wszędzie roi.

Matt Pocock: [śmiech]

Nate Herk: Właśnie widziałem zresztą, że Anthropic zapowiedziało jakieś konsekwencje — model miał reagować, gdybyś był dla Claude’a zły albo okrutny. Zobaczymy, co z tego wyjdzie. Ale chciałbym cię teraz trochę przycisnąć: poproszę o historię z frontu. Jaki moment sprawił, że stwierdziłeś „robię do tego skilla, żeby już nigdy w to nie wpaść”?

Historia porażki: gdy specyfikacje zawiodły

Matt Pocock: Mnie mocno zaczepił wykład gościa z OpenAI — Shawn Grove, jeśli dobrze pamiętam — na konferencji AI Engineer. Teza: „specyfikacje to nowy kod”. Że pisać kodu już nie trzeba: piszesz bardzo szczegółowy dokument — z pomocą agentów — opisujący, jak kod ma wyglądać, a potem agent zamienia tę specyfikację w program. Pomysł jest wciąż bardzo popularny, powstały wokół niego całe frameworki. Nazwałbym to programowaniem sterowanym specyfikacją: trzymasz specyfikacje przy życiu i doszlifowujesz je po drodze.

I ja się w to uwziąłem. Naprawdę próbowałem — to było przed moimi skillami. Mam repozytorium, które jest moją dumą: własny edytor wideo, coś w rodzaju Descript, z pisaniem wspomaganym AI i projektowaniem miniatur — robię tam dosłownie wszystko. Spróbowałem przepisać go na wielką specyfikację i pracować sterowany dokumentem. I po pierwsze: wciąż chciałem zaglądać do kodu z ciekawości. A widziałem, że kod robi się coraz gorszy, a agent daje coraz słabsze wyniki. Męczyłem to miesiącami — w końcu gość z OpenAI, skoro tak mówi, wie, co mówi; jakoś mi się to ułoży w głowie. Rozkładałem problem na czynniki pierwsze raz po razie. Nie działało. W końcu zrozumiałem: wyrzucam specyfikacje, wracam do kodu.

Co mnie uwolniło? Zrozumienie, że kod to środowisko, w którym agent żyje. Wróć do obrazka z psem siedzącym w płonącym domu: taki pies nie napisze dobrego kodu, bo ma wokół siebie złe warunki. A czym jest dobry kod? Bazą, w której łatwo się zmienia: gdzie jedna poprawka nie rozwal czegoś, o czym agent nie pomyślał, i gdzie wszystko da się modyfikować. Skupiłem się na tym — i wtedy poczułem, że wreszcie ruszam z miejsca i mogę przyspieszyć. Programowanie sterowane specyfikacją po prostu na mnie nie zadziałało.

Modele się poprawiają, ale myśli nie przeczytają

Nate Herk: Modele są lepsze z każdą iteracją. Dlaczego więc same z siebie nie ogarniają tych rzeczy? I kiedy to nastąpi?

Matt Pocock: To znowu ta bariera porozumienia. Model nie może wiedzieć, na czym ci zależy, dopóki mu nie powiesz — a skille są jednym ze sposobów mówienia modelowi, co jest dla ciebie ważne. Modele się poprawiają i otoczki się poprawiają; ludzie niedoceniają wpływu otoczek. (Informacja dodatkowa: otoczka, ang. „harness” — program, w którym pracuje model, np. Claude Code, Claude.ai czy Codex.) Ale model nigdy nie będzie na tyle dobry, żeby czytać ci w myślach i co do joty trafiać w twój zamysł. Potrzebny jest więc proces, który pomoże temu genialnemu programiście zrozumieć, czego chcesz. Bo świetny produkt rodzi się ze spotkania świetnego zarządzającego produktem i świetnego programisty. Musisz stawiać wymagania, patrzeć na wyniki i dokładać do nich swój gust. Warstwa procesu na górze zawsze będzie potrzebna — właśnie po to, żeby przeskoczyć barierę komunikacji.

Cztery agenty i dwieście commitów dziennie

Nate Herk: Ile szybciej poruszasz się dziś w porównaniu z pracą ręczną?

Matt Pocock: To się nie da porównać. Skandaliczna różnica. Mam teraz cztery agenty na różnych projektach — każdemu zleciłem zadania długoterminowe: „zrób to, to i to, oto moje cele, daj sobie radę”. Bawię się paroma nowymi rzeczami, na przykład skillą „szefa sztabu”, która ogarnia zarządzanie podagentami. To szokujące: jak mieć do dyspozycji zespół ośmiu programistów, którzy oddają za mnie robotę. Wpadam do nich, sprawdzam plany, przesłuchuję — cała ta maszyna.

Możesz wejść na mojego GitHuba i policzyć commity: dwieście, trzysta dziennie. Kiedyś dwadzieścia dziennie byłoby dobrym dniem. To się nie daje porównać. Nawet się nie zbliża.

Jaka otoczka, jaki model? Źle postawione pytanie

Nate Herk: Muszę zadać klasyczne pytanie: ulubiona otoczka i ulubiony model?

Matt Pocock: Używam Claude Code z Opusem 5.5. Świetny model. Tylko pracuję na dużo niższym poziomie intensywności niż większość — i to jest moja odważna teza: ludzie ustawiają za wysoki „wysiłek”. (Informacja dodatkowa: „effort” — suwak intensywności pracy modelu; wyższy poziom oznacza więcej rozważań i tokenów na jedno zadanie.) Widzą opcję i myślą: „podkręcę, chcę, żeby się starał”. Ja siedzę na średnim i rozważam zejście jeszcze niżej, bo zyskujesz oszczędność tokenów i szybsze odpowiedzi, a przy podniesionej podłodze moje agenty wcale nie muszą się spieszyć — piszą kod, który przechodzi testy, a testy wyłapują resztę.

Nie jestem wielbicielem testowania wszystkiego po kolei. Model i otoczka są oczywiście istotne — bez nich nie ma dobrej roboty — ale największe zyski znajduję w poprawianiu środowiska, w którym agenty pracują. Niedawno przemeblowałem jeden projekt: od dawna nie umiałem doprowadzić do tego, żeby agent mógł zajrzeć do przeglądarki i przeklikać się przez aplikację. To skomplikowany projekt, pełen zewnętrznych zależności, z lokalnie działającym OBS — programem do nagrywania ekranu, na którym nagrywam. Jak zapewnić agentowi dostęp, skoro sam używam tego narzędzia do pracy? W końcu to ogarnąłem: agent może klikać, robić zrzuty ekranu, odpalać aplikację na serio. Sama ta zmiana potężnie podniosła jakość tego, co produkuję, bo agent ma teraz o niebo lepsze dane. Z takim setupem równie dobre wyniki dałby mi starszy Opus 4.5 — rozumiesz, co chcę powiedzieć? Praca nad środowiskiem agentów zwraca się z nawiązką.

Wiem, że to wymijająca odpowiedź — wolałbyś gorący komentarz w stylu „to narzędzie beznadziejne, tamto świetne”. Ale otoczka naprawdę mnie mało obchodzi. Opus 5.5 jest dużo lepszy i wydajniejszy od piątki — ok. Ja traktuję to wszystko jak pracowników mojej firmy: moim zadaniem jest doprowadzić firmę do takiej formy, żeby nawet przeciętny pracownik działał dobrze.

Nate Herk: Uwielbiam tę odpowiedź, bo uwalnia ludzi z obsesji na punkcie najnowszego modelu i benchmarków. Przypomnijmy: przed Opusem mieliśmy Sonnet — bardzo dobry model, z którym dało się zautomatyzować mnóstwo pracy. Dziś nawet Opus 5.5 na niskim poziomie jest od niego lepszy, tylko wszystko dzieje się tak szybko, że ludzie tego nie zauważają. I zawsze wierzyłem, że ktoś taki jak ty, Matt, ze starszym modelem wyda lepszy rezultat niż ktoś z najnowszym Opusem, kto nie umie się komunikować.

Drabina zaufania: najpierw hamulec, nie gaz

Nate Herk: Pytanie na koniec dla kogoś, kto tego wysłuchał i czuje przytłoczenie. Twoje słowo na zachętę, żeby wreszcie zacząć?

Matt Pocock: Jeśli czujesz potrzebę, żeby się tego nauczyć — moje skille są niezłym punktem startowym: prosty plan w stylu „zrób to, to i to”. Pobierz je, pobierz dowolną z głównych otoczek — Claude Code, Codex, GitHub Copilot — i nie siedź zbyt długo nad wyborem. Po prostu wypróbuj.

Niedawno rozmawiałem z Lauren Tan — w sieci znana jako Potato — i mówiła o wspinaniu po drabinie zaufania. Nie zaczniesz ufać agentom po pierwszym udanym zadaniu — i dobrze, to zdrowy odruch, nie ufaj ślepo. Uczysz się jeździć: który pedał poznajesz najpierw, gaz czy hamulec? Hamulec. Uczysz się zatrzymywać, bo jeśli będziesz tylko przyspieszać, spalisz limity, narobisz rzeczy, których nie chciałeś, i nie złapiesz wyczucia narzędzia.

Więc: otwórz model, podrzuć mu prompty, załóż pusty folder, używaj VS Code — czasem miło jest móc zajrzeć do środka kodu. I miej pomysł. Bardzo pomaga mieć w głowie coś fajnego, do czego dążysz, bo bez misji motywacja więdnie, a pętla nagrody jest słaba. Gdy uczysz się i na własne oczy widzisz, jak pomysł ożywa, to działa jak mnożnik.

Potem obserwuj agenta jak sokół. Rozumiej wszystko, co robi, poznawaj wszystko, co daje ci otoczka. Zaczniesz wyczuwać, kiedy ufasz agentowi i kiedy go rozumiesz. A wtedy — może odpal drugiego agenta, napisz parę skilli, żeby robił rzeczy na twoje zamówienie, podepnij źródła danych: Slacka, Twittera, Gmaila. Ja mam agenta od listy zadań: dyktuję coś do zegarka, wiadomość leci do systemu, ląduje na liście, a agent to porządkuje. Włączasz to w życie i w pracę. Wspinasz się po drabinie zaufania, zaczynasz od małego, z moimi skillami albo bez — a potem możesz szaleć. Jeśli się temu przyglądasz i starasz się myśleć na poziomie agenta, niesamowicie szybko ta drabina się wspina.

Nate Herk: Bardzo mi się to podoba. Nazywam to w swoich filmach metodą rowerową: zaufanie trzeba sobie wysłużyć; nie uczysz od razu dziesięciorga dzieci, tylko pilnujesz z bliska i korygujesz. I w każdym razie nie wypuszczasz dwudziestorga dzieci rowerami na autostradę, żeby pójść spać. Nadal jesteś w procesie.

Ambitne zadania? Nie — najpierw nuda

Nate Herk: Elon, Boris i Sam — i pewnie nie tylko oni — powtarzają: „dajcie modelowi wasze najbardziej ambitne zadania”. Ciekawe, że czuli potrzebę, żeby mówić o tym całemu światu. Dlaczego, twoim zdaniem?

Matt Pocock: Nie wiem, bo ja uważam odwrotnie: dawaj mu najbardziej prozaiczną, nudną robotę. To, czego nienawidzisz. Niech szkicuje odpowiedzi ludziom, którzy o coś proszą. Proste, wykonalne zadania, w których da się zmierzyć wynik i jego jakość. Oczywiście do burzy mózgów, do przemyślenia pomysłów i przerobienia ich na wykonanie nadaje się świetnie — Grill Me właśnie do tego się dobrze sprawdza. Ale prawdziwa użyteczność, dla której siedzę w AI, jest taka, że automatyzuje nudne rzeczy, a mnie zostawia warstwę strategiczną — to, na czym chcę się skupić.

Robię treści wideo i treści pisane. Pisanie tych drugich zrobiło się bez porównania prostsze: model wyrabia pierwszy szkic, ja go iteruję. To zmieniło moją pracę w ciekawszą, bo zawsze pisanie mnie męczyło — kiedyś płaciłem ludziom, żeby robili to za mnie. Więc jeszcze raz: dawaj agentom nudną, niskopoziomową robotę — taką, gdzie nie stanie się nic złego, jeśli się pomyli, bo wejdziesz i poprawisz. Do tego naprawdę są stworzone.

Co dalej: fabryki oprogramowania i otwarte modele

Nate Herk: Na koniec: najbliższe dwa, trzy lata — dekada w skali AI. Co cię cieszy? Nad czym pracujesz?

Matt Pocock: Zaznaczę na wstępie: jestem nauczycielem, nie komentatorem. Siedzę w Oxfordshire, nie w San Francisco; nikt nie szepcze mi przyszłości do ucha. Odrzucam większość propozycji testowania nowości przed premierą — wolę, żeby to działało już dziś. Na zdolność do trzeźwego myślenia też to dobrze wpływa, bo łatwo dać się porwać narracjom o tym, co będzie.

A cieszy mnie szukanie właściwego sposobu zamieniania moich pomysłów w robotę, w kod. Temat, który mnie teraz kręci, to fabryki oprogramowania: sposoby automatyzowania zlecania pracy i samodzielnego poprawiania baz kodu z upływem czasu. Bo agenty są dziś słabe w myśleniu o bazie kodu w perspektywie długoterminowej. Chcę z nich zrobić tego irytującego developera, który zawsze siedzi w zespole i powtarza: „nie, róbmy dobrze, a nie szybko — z myślą o tych, którzy przyjdą po nas”. Na razie agenty są w tym beznadziejne, ale wierzę, że da się je tego nauczyć. Poza tym nie znaleźliśmy jeszcze właściwego sposobu organizowania wielu agentów naraz — potencjał jest ogromny, a nic, co widziałem, nie kazało mi powiedzieć: „tak, to jest to”.

I cieszy mnie, że modele otwarte będą lepsze. W końcu doczekamy otwartego modelu klasy Opusa 5.5 — i to będzie wspaniałe. Nie potrzebuję niczego lepszego, bo sporo potrafię sam nadrobić. Taki otwarty model, lepsza oszczędność tokenów, model mówiący prostym językiem i szybko oddający robotę — brzmi świetnie. Fajny to czas.

Nate Herk: Jak najbardziej. Matt, dziękuję za rozmowę i za wszystkie złote myśli. Gdzie można cię znaleźć?

Matt Pocock: Moja strona z newsletterem, Twitter i YouTube — to trzy główne miejsca.

Nate Herk: Wspaniale. Dzięki jeszcze raz — do zobaczenia wkrótce.