O czym jest ten film
- Viralowe repozytorium „Reverse Engineer Anything” pozwala agentom rekonstruować dowolne aplikacje i robi wrażenie — to zasługa dobrze zaprojektowanej otoczki wokół agenta.
- Część internetu wyciąga z tego wnioski na wyrost: „skoro agenty dają radę z czymś tak trudnym, programowanie jest rozwiązane”.
- Autor wyjaśnia, dlaczego to zadanie działa wyjątkowo dobrze: rekonstruowana aplikacja sama jest intencją — idealny wzorzec, z którym agent może porównywać własną pracę w każdej chwili.
- Duże modele językowe nie czytają w myślach. Autor od ponad roku nie pisze kodu, ale mocno uczestniczy w planowaniu na starcie i weryfikacji na końcu.
- „Meat proxy” — przepuszczanie zgłoszeń przez agenta bez własnego namysłu — nie wnosi żadnej wartości, a odpowiedzialność za kod i tak zostaje przy człowieku.
- Gdy nie ma gotowego wzorca, trzeba go stworzyć: PRD, plan, dokumentacja. Przykłady to najmocniejsze narzędzie pracy z modelami, niezależnie od ich mocy.
- Przykład z praktyki: „fabryka oprogramowania” autora zbudowała grę — 2D zamiast zamierzonego 3D, bo nie udało się przekazać intencji. Dopiero wzorzec graficzny z „Zeldy” rozwiązał problem.
- Prosty test umiejętności: jeśli następny model będzie dwa razy lepszy, ta umiejętność zyskuje na znaczeniu czy traci?
- Traci: sztuczki promptowe, ręczne pętli rozumowania, gigantyczne pliki reguł, uczenie modeli ogólnych zasad inżynierii.
- Zyskuje: planowanie przed napisaniem kodu, walidacja po nim i cała inżynieria otoczki — nowa rola to „inżynier otoczki, nie bazy kodu”. W środku filmu segment sponsora: Firecrawl i biblioteka Alexandria.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Rekonstruowana aplikacja to gotowa specyfikacja
Na czym polega: „Reverse Engineer Anything” działa tak dobrze nie dlatego, że agenty „umiają wszystko”, ale dlatego, że odtwarzana aplikacja jest kompletnym wzorcem: produkt końcowy już istnieje, więc agent może w pełni wiarygodnie sam sprawdzać, czy to, co buduje, zgadza się z oryginałem.
Jak stosować: Zawsze, gdy to możliwe, dawaj agentowi punkt odniesienia — istniejącą aplikację, ekran, plik, zachowanie. Ustaw porównywanie efektu z wzorcem w pętli, najlepiej automatycznie.
Na co uważać: Nie wyciągaj z takich demonstracji wniosku, że „programowanie jest rozwiązane”. To przypadek szczególny: idealna referencja istnieje tu z samej definicji zadania.
2.Komunikowanie intencji to umiejętność pierwszego rzędu
Na czym polega: Niezależnie od mocy modelu agent dostaje tylko to, co mu przekażesz. Autor od roku nie pisze kodu, ale planuje na starcie i weryfikuje efekt na końcu; błąd agenta traktuje przede wszystkim jako swoją porażkę w zakomunikowaniu zamiaru.
Jak stosować: Buduj procesy i otoczkę, które wymuszają doprecyzowanie intencji, zanim ruszy implementacja — na przykład zasypujące cię pytaniami — oraz weryfikację wyniku wobec zamiaru.
Na co uważać: Im sprawniejszy model, tym większa pokusa oddelegowania również myślenia. Ta umiejętność rośnie najbardziej na wartości — nie odpuszczaj jej.
3.Nie zostawaj „żywym przekaźnikiem”
Na czym polega: „Meat proxy” (dosłownie „mięsne proxy”) to człowiek, który zgłoszenie z Jiry wkleja agentowi, a odpowiedź agenta odsyła na Slacka albo do pull requesta. W całym łańcuchu nie wnosi żadnej wartości — zgłaszający równie dobrze mógł pójść do agenta bezpośrednio.
Jak stosować: Zanim cokolwiek przekażesz agentowi, przetwórz zgłoszenie własnym rozumem: doprecyzuj kontekst, ograniczenia i kryteria ukończenia.
Na co uważać: „Claude powiedział, że…” wklejone koledze do przeglądu to najczystsza forma przekaźnictwa — i najkrótsza droga do utraty zaufania zespołu.
4.Odpowiedzialność za kod zostaje przy człowieku
Na czym polega: Nawet jeśli nie dołożysz ani grama własnego myślenia, za efekt odpowiadasz ty, nie agent. Bez przekazanych niuansów agent wyprodukuje dobry kod, który trafia obok tego, czego potrzebujesz.
Jak stosować: Traktuj każdą delegację jak kontrakt: co dokładnie ma powstać, po czym poznam, że jest gotowe, kto akceptuje.
Na co uważać: Jakość kodu bywa myląca — brak błędów nie oznacza zgodności z intencją.
5.Gdy nie ma wzorca, stwórz go
Na czym polega: Większość projektów zaczyna się od pomysłu w głowie albo zadania zleconego przez kogoś — bez gotowej aplikacji jako odniesienia. Wtedy trzeba wytworzyć referencję samemu: PRD, plan, dokument, który agent potraktuje jak wzorzec.
Jak stosować: Pozwól agentowi zasypywać cię pytaniami na etapie planowania i utrwalaj odpowiedzi w dokumentach; wracaj do nich przy walidacji.
Na co uważać: Dokument pisany „do szuflady” nic nie da — musi być częścią pętli pracy agenta, a nie załącznikiem.
6.Przykłady działają najmocniej
Na czym polega: Od lat — powtarza autor — przykłady są najskuteczniejszym sposobem pokazania modelowi, czego chcemy. Nie zależy to od mocy modelu.
Jak stosować: Zamiast opisywać styl „na słowa”, podaj konkretną grę czy aplikację o pożądanej estetyce i każ agentowi porównywać wynik bok w bok, dopasowując się z czasem.
Na co uważać: Źle dobrany wzorzec zdominuje projekt — wybieraj referencje świadomie (autor celowo prosił o grafikę „odrobinę mniej zabawkową” niż w oryginale).
7.Test: co z tą umiejętnością, gdy model będzie dwa razy lepszy?
Na czym polega: Prosty filtr priorytetów: jeśli przy dwukrotnie mocniejszym modelu umiejętność zachowuje albo rośnie znaczenie — warto ją ćwiczyć; jeśli traci — odpuść.
Jak stosować: Przejrzyj to, czego się uczysz, i oceń każdy element tym jednym pytaniem; powtarzaj przegląd np. co kwartał, bo odpowiedzi będą się zmieniać.
Na co uważać: Test mówi o kierunku, nie o zero-jedynce — umiejętność tracąca znaczenie może być jeszcze przejściowo potrzebna.
8.Sztuczki promptowe i wielkie pliki reguł tracą opłacalność
Na czym polega: Triki, które kiedyś podnosiły jakość odpowiedzi, przestają dawać przewagę; modele same prowadzą się przez kolejne kroki; bardzo długie pliki reguł częściej obciążają agenta balastem, niż pomagają; zasad inżynierii oprogramowania modeli nie trzeba już uczyć.
Jak stosować: Skracaj pliki reguł do niezbędnego minimum, a uwalnianą energię przenoś do konstrukcji systemu: subagentów, hooków, punktów kontrolnych.
Na co uważać: Nie myl „mniej promptowania” z „mniej myślenia” — zaoszczędzony czas przeznacz na planowanie i walidację, nie na bezrefleksyjność.
9.Wąskie gardło to planowanie przed i walidacja po
Na czym polega: Środek procesu — samo pisanie kodu — jest zautomatyzowany. Wartość człowieka przesuwa się na początek (precyzyjny zamiar) i koniec (ocena, czy agent trafił).
Jak stosować: Chroń w kalendarzu czas na oba etapy; nie pozwalaj, by presja terminów zjadała planowanie i przegląd efektu.
Na co uważać: Skracanie planowania „bo agent szybko zrobi” to fałszywa oszczędność — poprawki kosztują więcej niż dopracowany dokument.
10.Zostań inżynierem otoczki, nie bazy kodu
Na czym polega: Nowa rola według autora: przestajemy być inżynierami bazy kodu — to zleciliśmy agentowi — i stajemy się inżynierami otoczki, która przygotowuje agentowi grunt. Każdy błąd agenta to materiał na ulepszenie systemu.
Jak stosować: Prowadź rejestr porażek agenta i zamieniaj je w reguły, hooki, subagentów — buduj koło zamachowe, dzięki któremu pracujesz coraz sprawniej.
Na co uważać: Budowanie otoczek nie każdemu leży. Jeśli kochasz samo kodowanie, autor uczciwie przyznaje, że nowa rola może być mniej satysfakcjonująca — warto to sobie szczerze nazwać.
Redakcyjne tłumaczenie
Wirusowe repozytorium i wnioski na wyrost
Zacznijmy od „Reverse Engineer Anything” — najświeższego hitu na GitHubie, który szczerze mówiąc robi wrażenie. Dobrze pokazuje, co potrafią agenty, gdy zbuduje się wokół nich porządnie zaprojektowaną otoczkę — harness, czyli zestaw reguł, narzędzi i punktów kontrolnych, w których model wykonuje pracę. Problem w tym, że internet wyciąga z tego wnioski grubo na wyrost: skoro agenty dają radę z czymś tak trudnym, to podobno programowanie i inżynieria zostały całkowicie „załatwione” i nie musimy już angażować własnych głów — albo ten moment nadchodzi lada dzień.
Tymczasem agenty radzą sobie z tym konkretnym zadaniem z bardzo konkretnego powodu — i właśnie o tym chcę opowiedzieć. To wpisuje się w szerszą rozmowę, do której zmierzam: co w ogóle jest się jeszcze sens uczyć, skoro AI przejmuje coraz trudniejsze rzeczy? Rozumiem ten nastrój. Przy całym hype wokół AI i czarnowidztwie w branży inżynierskiej — jak tamten viralowy tweet z zeszłego miesiąca — można naprawdę dojść do wniosku, że im sprawniejsze modele, tym mniej opłaca się inwestować w umiejętność budowania, a my wszyscy staniemy się „mięsnym proxy”: agentom po prostu zdejmiemy z głowy cały krytyczny osąd.
To droga donikąd. Jestem głęboko przekonany, że pewne umiejętności zyskują na znaczeniu właśnie dlatego, że agenty stają się zdolniejsze. Bo nie wszystko jest inżynierią wsteczną. Są zadania, w których agenty są znakomite — ale z tego faktu nie wynika, że rozwiążą wszystko.
Zatrzymajcie to repozytorium w pamięci, bo do niego wrócę. Najpierw jednak sedno.
Model nie czyta w myślach
Pytanie, które od początku podsuwam, brzmi: czy cokolwiek jest wciąż warte nauki? Odpowiedź brzmi: tak, jak najbardziej. Główny powód jest prosty — duży model językowy nie czyta ci w myślach. Niezależnie od tego, jak będzie potężny, wokół agenta musi istnieć otoczka, która pozwala należycie przekazać twoją intencję. To właśnie ta zmiana dokonuje się dziś w inżynierii oprogramowania.
Agenty rzeczywiście piszą cały kod. Sam nie napisałem ani jednej linijki od ponad roku. Deleguję kodowanie, ale jestem mocno zaangażowany w planowanie na starcie i weryfikację na końcu. Nawet gdybym miał bardzo rozbudowany harness z pierwszorzędnym modelem, któremu ufałbym, że pisze czysty kod, wciąż musiałbym się upewniać, że dostaję to, czego naprawdę chcę. Jeśli agent się pomyli, to w gruncie rzeczy bardziej moja wina: nie przekazałem zamiaru tak, jak trzeba. Dlatego potrzebuję otoczki, która już na początku zasypuje mnie pytaniami, doprowadza nas do wspólnego rozumienia, a na końcu weryfikuje efekt wobec intencji. To nigdy nie zniknie. Umiejętność komunikowania intencji — i budowania wokół agenta systemu, który to umożliwia — będzie tylko zyskiwać, im trudniejsze zadania będziemy agentom zlecać.
Pułapka „mięsnego proxy”
Kłopot w tym, że właśnie dlatego, iż agenty są tak dobre w środkowym etapie pracy, kusi, by stać się wspomnianym „mięsnym proxy” — człowiekiem sprowadzonym do roli przekaźnika. Znam to z autopsji. Dostajesz zgłoszenie — tiket w Jirze albo prośbę od kolegi z zespołu — i wklejasz je do agenta programistycznego bez planowania, bez własnego namysłu. To, co agent zwróci, ląduje z powrotem na Slacku albo w pull requeście. W takim układzie osoba, która wysłała pierwotną prośbę, równie dobrze mogła pójść do agenta sama — w całym procesie nie wniosłeś żadnej wartości.
A odpowiedzialność za kod i tak zostaje przy tobie. Jako inżynier odpowiadasz za efekt, nawet jeśli nie dołożyłeś do niego ani grama własnego myślenia. Tym bardziej zadbaj o to, by intencja była przekazana należycie. Bo jeśli naprawdę jesteś tylko przekaźnikiem, gwarantuję: w większości zadań agent nie zrobi tego, czego faktycznie potrzebujesz, bo nie zna niuansów — jak dokładnie ma być naprawiony błąd albo jak ma działać budowana funkcja. Konkretnie: nie bądź osobą, która na pytanie na Slacku przepuszcza odpowiedź przez agenta i odsyła kolejkę zaczynającą się od „Claude powiedział, że…” plus wielki blok tekstu od AI, który teraz druga strona musi sama przeanalizować. To najczystsza forma bycia przekaźnikiem.
Dlaczego inżynieria wsteczna to przypadek szczególny
Dobrze — ale skoro przekazywanie intencji jest takie ważne, skoro potrzebna jest cała ta otoczka, to jak wytłumaczyć istnienie „Reverse Engineer Anything”? Spójrzcie do readme, do szybkiego startu: to bardzo prosta prośba o odtworzenie dowolnej aplikacji. Repozytorium eksplodowało właśnie dlatego, że z tym narzędziem rekonstrukcja czegokolwiek jest niesamowicie prosta.
I tu wracamy do powodu, o którym mówiłem na początku. Zastanów się: to działa tak dobrze, ponieważ aplikacja, którą odtwarzasz, sama jest intencją. Nie potrzeba niczego więcej, żeby dokładnie określić, jak ma wyglądać produkt końcowy — bo on już istnieje. Agent może przez cały czas, w pełni wiarygodnie, sprawdzać własną pracę: to, co buduje, zgadza się z funkcjami i zachowaniem aplikacji wzorcowej, czy nie? Dlatego proces działa tak znakomicie. Do tego dochodzi bardzo przemyślany harness, więc i on ma swój udział. Ale w zwykłych warunkach, nawet z dobrą otoczką, pracy nad intencją jest dużo więcej. Tu tej pracy nie ma — bo wzorzec stoi gotowy.
Dlatego uważam, że ludzie się mylą, twierdząc, iż to repozytorium dowodzi, że agenty wkrótce zbudują cokolwiek. To nieuczciwy przykład, bo ma znakomite odniesienie. Owszem — przy wielu rzeczach, które budujemy, możemy agentowi taki wzorzec dać i róbcie to zawsze, gdy się da. Ale większość projektów zaczyna się od pomysłu w twojej głowie albo od zadania, które ktoś ci zleca. I wtedy nadal twoją sprawą jest zakomunikowanie intencji. Jeśli podasz mglistą ideę, jeśli będziesz tylko przekaźnikiem, dostaniesz dobry kod — bo duże modele piszą dobry kod — ale nie ten, który chciałeś zbudować.
Skoro nie masz jasnego przykładu, musisz go w istocie stworzyć. Tu jako budowniczowie wciąż mocno pracujemy własną głową: agent zasypuje nas pytaniami, my odpowiadamy na nie z namysłem — i budujemy wzorzec w postaci dokumentacji: PRD-a, planu, czegokolwiek, co spełni tę rolę. (Informacja dodatkowa: PRD, product requirements document — dokument opisujący wymagania wobec produktu, zanim ruszy implementacja.) Chodzi o to, żeby agent miał punkt odniesienia i naprawdę rozumiał, co ma wyjść na końcu.
Podsumowując: najważniejsza umiejętność, w którą dziś warto inwestować, to budowanie otoczek służących przekazywaniu intencji — dawanie agentowi wzorców tam, gdzie się da, umożliwianie mu ich samodzielnego znajdowania, a tam, gdzie się nie da, przechodzenie przez proces tworzenia własnego. Wielu ludzi nazywa to „inżynierią intencji”. Nazwa nie jest najważniejsza; liczy się to, byś umiał ocenić — własnym krytycznym myśleniem — kiedy możesz dać przykłady, a kiedy musisz wytworzyć ich substytut. Od lat powtarzam: przykłady są najpotężniejszym narzędziem pracy z dużymi modelami. Nieistotne, jak mocny jest model — nadal ich potrzebuje, by wiedzieć, czego naprawdę chcesz.
Sponsor: Firecrawl i biblioteka Alexandria
Sponsorem tego odcinka jest Firecrawl — firma, która nazywa siebie „kontekstowym API dla agentów AI”. Kilka tygodni temu pokazywałem ich wyszukiwarkę; dziś chciałbym pokazać Alexandrię, którą właśnie uruchomili. To biblioteka wiedzy: ogromny katalog ponad stu dostawców danych, z których twoje agenty mogą czerpać bezpośrednio — benchmarki, dane o firmach, portale z ofertami pracy, podcasty oraz własne indeksy Firecrawl z pracami naukowymi i dokumentacją dla programistów. (Informacja dodatkowa: dostęp odbywa się przez MCP, otwarty protokół pozwalający agentom korzystać z zewnętrznych narzędzi i źródeł danych.)
Do Alexandrii mogę sięgać bezpośrednio z moich agentów programistycznych, na przykład z Claude Code, przez serwer MCP Firecrawl. Poprosiłem o wykorzystanie Alexandrii do odpowiedzi na pytanie, który model o otwartych wagach daje dziś najwięcej inteligencji za dolara w agentach kodujących — szczerze mnie to ciekawi. Agent najpierw odpytał Alexandrię, by znaleźć właściwego dostawcę danych; za darmo sprawdził koszt przeszukiwania; a potem jednym zapytaniem pobrał całą tabelę rankingową i podał odpowiedź. Kiedy już znalazłem model, chciałem podpiąć go do Claude Code. Tu z pomocą przyszedł indeks deweloperski Firecrawl: szybko przeszukał issues i pull requesty na GitHubie, readme i dokumentację, błyskawicznie znalazł sposób integracji, a nawet wyłapał pułapki z listy zgłoszeń w repozytorium Claude Code. Firecrawl jest darmowy na start — z miesięczną pulą kredytów — a przeglądanie wszystkiego w Alexandrii nie kosztuje nic. Link zostawiam w opisie.
Z praktyki: gra, która miała być trójwymiarowa
Nie wszystko jest inżynierią wsteczną z idealnym wzorcem. Ale przy wielu rzeczach możesz wzorzec dać — albo stworzyć — przynajmniej dla części swojej intencji. Pokażę przykład z własnej pracy, a film zakończę testem pomagającym ocenić, czy dana umiejętność jest wciąż warta nauki, gdy modele będą coraz zdolniejsze. Bo intencja, choć jest dziś głównym tematem, nie wyczerpuje sprawy.
Ostatnio dużo pracuję nad moją „fabryką oprogramowania” napędzaną AI i buduję na niej różne aplikacje, żeby ją wypróbować — szeroko omawiałem ją na kanale i podlinkuję odpowiedni film. Idea jest taka: podajesz fabryce PRD, w którym zrobiłeś planowanie i — rzecz jasna — zakomunikowałeś intencję, a fabryka samodzielnie rozbija go na zadania i wykonuje je jedno po drugim, aż powstanie cała aplikacja. Bardzo autonomicznie, ale ty nadal mocno uczestniczysz, tworząc ten wstępny dokument.
Eksperymentuję z tym przez cały rok i działa to już naprawdę dobrze. Oto gra, którą zbudowałem z pomocą fabryki: dałem jej przejść może tuzin rund, żeby powstał wstępny dowód koncepcji. To dobra gra — nie na tyle, żebym publikował ją dziś na Steamie, ale solidny punkt wyjścia, na którym można budować. Jest tylko jeden problem: właściwa gra nie miała być dwuwymiarowa. Chciałem 3D. A ja nie jestem grafikiem ani artystą w żadnym wydaniu i miałem spory kłopot z tym, jak w PRD zakomunikować agentowi, że gra ma być trójwymiarowa. Bez wzorca naprawdę trudno było mi zmusić go, żeby zrobił 3D dobrze. Skończyło się na wersji 2D. Działa ładnie, ale nie o to chodziło — bo nie udało mi się przekazać intencji. I wiem, że to nie wina agenta. Zaraz pokażę, skąd ta pewność.
Wzorzec z „Zeldy”
Poszedłem w ślady „Reverse Engineer Anything”: zamiast drobiazgowo opisywać grafikę 3D i dokładny wygląd, dałem agentowi wzorzec, do którego ma dążyć, i tak ustawiłem przepływ pracy w PRD, by budował w jego kierunku i na bieżąco porównywał efekty bok w bok. A skąd wzorzec? Od lat uwielbiam grafikę pewnej gry z serii „The Legend of Zelda”. Jest wyjątkowa: nie jest w pełni trójwymiarowa jak „Super Mario Galaxy” czy strzelanki pierwszoosobowe, ale też nie jest czysto „z góry” jak Pokémony. Po prostu ją kocham. Pomyślałem: co, jeśli przekażę to agentowi? Zaplanowałem z nim na starcie: „oto gra, której grafikę chcemy naśladować — może odrobinę mniej zabawkową — a ty będziesz stale porównywał wynik z tym wzorcem i z czasem go wyrównywał”.
Działało to znakomicie. Oto pierwszy dowód koncepcji gry zbudowanej w fabryce z „Zeldą” jako odniesieniem graficznym. Próbowałem wersji 3D tej gry już pięć, może sześć razy — i to pierwszy raz, kiedy efekt wygląda zbliżenie do tego, co chciałem. A to zasługa całej otoczki walidującej względem grafiki gry, którą świadomie wybrałem. Włożyłem w to sporo planowania i projektowania, sporo własnego myślenia — mimo że korzystam z bardzo autonomicznej formy kodowania z AI. I to dopiero początek: fabryka pracuje nad tą aplikacją dzień, może dwa, a już wygląda naprawdę dobrze. Dla zabawy pokazuję, jak wygląda walka — podobnie jak w wersji 2D. Do wyregulowania zostały drobiazgi, jak to dziwne koło pojawiające się od czasu do czasu, ale rozgrywka jest zaskakująco płynna. Gra jest po prostu świetna.
Najważniejsze jest co innego: każdą nieudaną wersję gry 3D budowałem z najmocniejszym dostępnym modelem — Opusem 5.5 — w bardzo rozbudowanej otoczce, jaką jest moja fabryka. I nadal muszę poświęcać dużo czasu na zakomunikowanie intencji, bo bez tego agent napisze dobry kod, który chybia sedna. Dlatego to umiejętność numer jeden — i nic tego nie zmieni, o ile jeszcze wzrosną możliwości modeli.
Test podwajania mocy modelu
Prowadzi to idealnie do zapowiadanego testu. Komunikowanie intencji jest umiejętnością najważniejszą, ale nie jedyną. Pytanie, które warto sobie zadawać, brzmi: jeśli następny model będzie dwa razy lepszy, ta konkretna umiejętność nabędzie większego czy mniejszego znaczenia? Jeśli znaczenie pozostanie takie samo — nadal warto w nią inwestować. A sporo rzeczy to znaczenie traci.
Gdy modele stają się zdolniejsze, mniej zajmujemy się inżynierią promptów: sztuczki, które kiedyś poprawiały wyniki, przestają być przewagą. Nie musimy już ręcznie pisać własnych pętli rozumowania — modele same prowadzą się przez proces. W samych otoczkach mamy wbudowane mechanizmy typu /goal. A wielkie pliki reguł? W ostatnich miesiącach przekonaliśmy się, że bardzo długie pliki opisujące wszystkie nasze ograniczenia i konwencje czasem bardziej obciążają agenta balastem, niż pomagają. Modeli nie trzeba też już uczyć ogólnych zasad inżynierii oprogramowania, jak dwa lata temu. I to jest dopiero zmiana: rok–dwa lata temu te rzeczy wiele znaczyły — dobry prompt, dopracowany plik reguł. Dziś to nie jest miejsce na twoją inwestycję.
Wąskie gardło: planowanie przed, walidacja po
Inwestuj tam, gdzie wąskie gardło: w planowanie, które robisz przed napisaniem kodu, i w weryfikację po nim. Zwłaszcza w komunikowanie intencji, ale ogólnie w całą inżynierię otoczki — budowanie umiejętności, podagentów, hooków i składanie tego w spójniejszy system dla twojego agenta. Jak moja fabryka; jak to, co skonstruował autor „Reverse Engineer Anything”. Za każdym potężnym systemem stoi ktoś, kto włożył w niego mnóstwo krytycznego myślenia, żeby przygotować agentowi grunt. Bo im mocniejsze modele, tym trudniejsze zadania będemy im zlecać — a konwencje i przepływy pracy muszą być wbudowane w system.
Tak, nie będziemy już poświęcać godzin plikom reguł jak kiedyś. Ale poziom wyżej — sam system — pozostaje krytyczny. Zawsze powtarzam programistom: przestaliśmy być inżynierami bazy kodu, bo to zleciliśmy agentowi. Jesteśmy teraz inżynierami otoczki dla agenta: przygotowujemy mu grunt, a każdy błąd traktujemy jako okazję, żeby naszego agenta ulepszyć.
Czy ta nowa rola może cieszyć?
Części inżynierów to nie leży. Może lubisz pisać kod, a nie lubisz budować otoczek — rozumiem, nie każdemu to pasuje. Jeśli to ty, szczerze mi przykro: wiem, że taka rola może być mniej satysfakcjonująca. Ale przynajmniej dla mnie — i mam nadzieję, że też dla ciebie — budowanie tych systemów daje dużo spełnienia. Robotę w bazie kodu załatwiasz, tylko inną drogą. A obserwowanie, jak twoja otoczka robi się coraz lepsza, to czysta przyjemność: to koło zamachowe, dzięki któremu pracujesz coraz sprawniej — o ile włożysz w nie własne myślenie, dbasz o komunikowanie intencji i pozostajesz częścią procesu.
Na tym tyle. Mam nadzieję, że test się przyda — pomoże ci przemyśleć, w jakie umiejętności warto dalej inwestować, bo jest ich naprawdę sporo, nawet przy tak zdolnych modelach. Zwłaszcza ta najważniejsza: zawsze musimy komunikować intencję i mieć w otoczce miejsce, gdzie się to dzieje. Jeśli czekasz na więcej materiałów o inżynierii agentycznej i „inżynierii intencji”, polubienie i subskrypcja bardzo pomogą. Do zobaczenia w następnym odcinku.