/ ZMIANA
Kod przestał być pracą
Przez osiemnaście lat moja praca opisywała się jednym zdaniem: „napisać kod". Osiemnaście miesięcy temu to się skończyło. Dzisiaj robota polega na sprecyzowaniu, co ma się stać, podaniu modelowi wystarczającego kontekstu i obejrzeniu, co zrobił. Kod jest produktem ubocznym.
Brzmi jak drobiazg. Nie jest. To przesuwa, które umiejętności kapitalizują się w czasie. Seniorzy, których znam, a którzy odmówili zrobienia tej zmiany, są dziś wolniejsi od midów, którzy ją zaakceptowali. Ci, którzy zrobili przeskok, prowadzą firmy, które do niedawna wymagały zespołów. Linia podziału nie idzie po talencie. Idzie po tym, jak bardzo byłeś gotów nauczyć się nowego rzemiosła od zera w wieku, w którym większość ludzi przestaje się uczyć nowych rzeczy.
To nowe rzemiosło ma już nazwę. Mówię na nie agentic engineering: dyscyplina sprawiania, żeby agentowe systemy AI wykonywały pracę o wysokiej dźwigni w sposób niezawodny, powtarzalny, w punkcie koszt-jakość, który bije ludzką alternatywę.
/ CO ZNACZY AGENTIC
„Agentic" nie znaczy „autonomiczny"
Słowo agentic ludzie rzucają jako synonim „w pełni autonomiczny". Nie jest. System agentowy to taki, który może wykonać wielokrokową akcję samodzielnie, ale niezawodne systemy agentowe to te, w których ty zdecydowałeś, które kroki może wykonać, w jakich kontekstach, z jakim mechanizmem rollback i przeglądu. Autonomia to gałka, którą podkręcasz, kiedy zabezpieczenia już działają. Nie jest celem samym w sobie.
Model mentalny, którego używam: agent to nieprawdopodobnie szybki junior, który się nie męczy, przeczytał każdy publiczny kod, jaki kiedykolwiek powstał, i ma najgorszą możliwą pamięć do kontekstu twojego konkretnego projektu. Twoja rola to być seniorem, który dostarcza kontekst, ustawia ograniczenia i przegląda diff. Każdy, kto kiedykolwiek prowadził juniorów, rozpozna ten wzorzec od razu. Kto nigdy nie prowadził, pomyli prędkość z umiejętnością i zapłaci za to podatek.
/ CZTERY WARSTWY
Działający stack agentowy ma cztery warstwy
Jeśli odejmiesz marketing, niemal każda produkcyjna konfiguracja agentowa rozkłada się na cztery warstwy. Świadomość, w której z nich w danym momencie działasz, oszczędza ogromne ilości czasu przy debugowaniu.
- Rozmowa. Model, który bierze naturalny język i zwraca pracę. Tu większość ludzi zaczyna. Tu też się zatrzymuje, bo to już wydaje się cudem w porównaniu z narzędziami sprzed roku.
- Narzędzia. Ten sam model plus możliwość czytania plików, uruchamiania komend, przeszukiwania webu, dzwonienia po API. W momencie, w którym model może odpalić komendę i zobaczyć wynik, przekraczasz granicę między „mądrym autouzupełnianiem" a „agentem". Niemal wszystko interesujące dzieje się poniżej tej granicy.
- Orkiestracja. Wiele pętli agentowych współpracujących ze sobą. Jeden agent specyfikuje, drugi implementuje, trzeci recenzuje, czwarty deployuje. Każda pętla ma własne okno kontekstu, własny model, własne uprawnienia. Tutaj naprawdę żyją agentowe firmy, i to właśnie o tej warstwie tutoriale milczą najczęściej.
- Pamięć. Trwały stan między sesjami. Pliki, które agent czyta co turę („rozszerzenia system promptu"), bieżące notatki, które agent aktualizuje między rozmowami, retrieval po starej pracy. Pamięć to to, co sprawia, że poniedziałek przestaje być poniedziałkiem zero.
Wielki błąd w każdej warstwie jest ten sam: mylenie technologii z systemem. Lepszy model nie uratuje cię przed niedbałą orkiestracją. Lepsza orkiestracja nie uratuje cię przed braku pamięci. Lepsza pamięć nie uratuje cię przed niejasną rozmową. Warstwy się ułożone w stos, a najsłabsza limituje resztę.
/ DZIENNA PĘTLA
Jak dziś naprawdę wygląda dzień przy klawiaturze
Sześć miesięcy temu mój dzień to było osiem godzin pisania. Dziś to osiem godzin czytania, decydowania i interweniowania. Czas spędzony na pisaniu schodzi do dziewięćdziesięciu minut, a większość z tego to krótkie poprawki, nie oryginalny kod. Reszta (sześć i pół godziny) idzie na specyfikację, review i priorytetyzację.
Typowy blok wygląda tak: otwieram rozmowę, wklejam jeden problem, odpowiednie pliki i kryteria sukcesu. Model proponuje plan. Czytam, dopycham dwa punkty, trzeci akceptuję. Model implementuje. Czytam diff, podczas gdy on uruchamia testy. Testy padają. Model czyta błąd, proponuje poprawkę. Albo mu pozwalam, albo widzę, że źródło problemu leży tam, gdzie on nigdy nie zajrzy, i interweniuję. Tak przez dziewięćdziesiąt minut. Output jest tym, co juniorowi zajęłoby cały dzień, a ja nie napisałem ani jednej sygnatury funkcji.
Co kluczowe, na tym poziomie ziarnistości nie łączę agentów w łańcuch. Pokusa, żeby ustawić „agent A woła agenta B, który woła agenta C", jest ogromna i prawie zawsze błędna na tym poziomie. Łańcuchowanie ma sens dopiero wtedy, gdy już udowodniłeś, że praca jest powtarzalna, wejścia są czyste, a tryby awarii są zlokalizowane. Przez większość dnia jedna rozmowa z jednym agentem pod twoim nadzorem bije każdy schemat orkiestracji, jaki możesz wymyślić.
/ KIEDY ORKIESTROWAĆ
Test orkiestracji
Najlepszy test, jaki znam dla pytania „czy to powinno być orkiestrowane, czy nadal w rozmowie", to test powtarzalności. Jeśli wykonałem ten sam kawałek pracy trzy razy w ten sam sposób i wynik za każdym razem był akceptowalny, zasługuje na orkiestrowany pipeline. Wszystko zrobione mniej razy jest wciąż pytaniem badawczym, a zamiana pytania badawczego w pipeline daje ci kruchy, drogi, trudny do debugowania system, który produkuje błędne odpowiedzi z wysoką prędkością.
Kawałek biznesu, który stoi za tą stroną, jest orkiestrowany end-to-end: research niszy → propozycja produktu → review → napisanie treści → krytyka → render PDF → wygenerowanie okładki → publikacja na cztery platformy → kolejka postów social. Cały pipeline chodzi bez nadzoru, a ja klikam pojedynczy guzik, żeby produkt przeszedł do następnego etapu. To działa, bo każdy krok został najpierw zrobiony konwersacyjnie piętnaście czy dwadzieścia razy, aż tryby awarii były znane, a ograniczenia ostre. Dopiero wtedy podniosłem go do orkiestracji.
Większość ludzi robi to odwrotnie. Zaczyna od budowania orkiestracji, a komponenty debuguje potem. Ta kolejność produkuje system, który pada w dwudziestu miejscach naraz, bez jasnej drogi do izolacji, który komponent jest zły. To najdroższy sposób, jaki znam, na nauczenie się tych samych lekcji dwa razy.
/ ZABEZPIECZENIA
Dźwignia bierze się z zabezpieczeń
Nieprzeszkoleni operatorzy martwią się, którego modelu używać. Doświadczeni operatorzy martwią się zabezpieczeniami. Model jest wymienny. Zabezpieczenia nie.
Zabezpieczenie to wszystko, co łapie pewną klasę błędów, zanim trafi do produkcji. Może być programatycznym sprawdzeniem („jeśli wynik ma więcej niż trzy myślniki em-dash, model wszedł w purpurową prozę, retry"), regułą strukturalną („każdy endpoint API musi odpowiedzieć w ciągu dziesięciu sekund, inaczej caller traktuje to jako awarię") albo bramką workflow („potrzebna manualna akceptacja przed publikacją na Etsy"). To jest nudne. To jest żmudne do zaprojektowania. To jest największa różnica między systemem agentowym, który wytrzymuje obciążenie, a tym, który pada w trzeci wtorek.
Framework zabezpieczeń, który stosuję, ma trzy linie obrony. Prewencja: sam prompt mówi, czego nie robić. Detekcja: programatyczne sprawdzenia po wyjściu modelu łapią to, co się prześlizgnęło przez prompt. Naprawa: małe procedury auto-fix łatają znane odzyskiwalne błędy bez ponownego wołania modelu. Każda kolejna warstwa jest droższa od poprzedniej, a złożenie trzech to dokładnie różnica między „dziewięćdziesiąt procent akceptowalne" a „dziewięćdziesiąt dziewięć procent akceptowalne", co brzmi jak mała przepaść, a w praktyce jest przepaścią między systemem, który możesz zostawić chodzącego na noc, a takim, którego nie możesz.
/ PAMIĘĆ
Pamięć to cichy mnożnik
Domyślna konfiguracja agentowa ma pamięć złotej rybki. Każdy poniedziałek jest poniedziałkiem zero: agent nie pamięta, czego nauczył się w zeszłym tygodniu, nie pamięta decyzji, które razem podjęliście, nie pamięta, które podejście padło ostatnim razem. Koszt manifestuje się wszędzie, ale na tyle cicho, że większość operatorów nigdy go nie nazywa.
Liczą się trzy formy pamięci. Pamięć projektu: zwersjonowany plik w repo, który agent czyta przy każdej turze (CLAUDE.md to kanoniczny przykład). Pamięć operatora: trwałe notatki, które agent prowadzi o tobie, twoich preferencjach, twoim wcześniejszym feedbacku. Ciągłość rozmowy: możliwość kontynuowania starej rozmowy zamiast zaczynania od zera. Pierwsze dwa są dziś głównie pod twoją kontrolą; trzecie jest tym, co dostawcy narzędzi ścigają się zbudować.
Jeśli masz w tym kwartale czas tylko na jedno, zainwestuj w pamięć projektu. Dobrze nastrojony CLAUDE.md (lub jego odpowiednik) ratuje więcej czasu modelu niż jakakolwiek inna interwencja, jaką znam. Napisałem o tym osobny field manual. W skrócie: traktuj go jak część system promptu, nie jak README, i przycinaj raz w miesiącu.
/ WYMIAR KOSZTU
Koszt to ograniczenie, które kształtuje wszystko
Każdy trzeci wtorek miesiąca siadam z rachunkami z API i prowadzę linię od wydatków z powrotem do konkretnych operacji. Prawie zawsze jest jeden krok pipeline'u odpowiedzialny za połowę kosztu i jedną trzecią awarii. Napraw go, a system w jednym patchu staje się tańszy i bardziej niezawodny.
Kilka wzorców, które wielokrotnie zwróciły się z nawiązką. Dopasuj model do zadania: tani model robi klasyfikację i ekstrakcję, średni pisze, drogi planuje i edytuje. Routing po typie zadania często ścina wydatki o sześćdziesiąt do osiemdziesięciu procent bez straty jakości. Limituj retry z intencją: pętla retry, która przy każdej próbie strzela droższym modelem, to powolna eksplozja rachunku; pętla, która schodzi na tańszy model i akceptuje słabszy wynik, to system, który sam siebie hamuje. Tnij na granicy: poproś model o miękki limit powyżej twojego twardego, a potem przytnij programatycznie. Próby trafiania w dokładną długość przez sam prompt nigdy nie działają niezawodnie i pożerają retry.
/ CO NIE DZIAŁA
Rzeczy, które świetnie wyglądają w demo i gniją w produkcji
Krótka lista wzorców, przed którymi ostrzegłbym każdego, kogo widziałem, jak żre na nich godziny.
- Debata wielu agentów. Dwóch agentów kłócących się, żeby wyprodukować lepszą odpowiedź. Przekonująco brzmiące papiery, prawie żadnych wygranych w realu. Kosztuje trzy do pięciu razy więcej, jakość rzadko rośnie, a powierzchnię awarii podwoiłeś. Odpuść, dopóki ktoś nie udowodni inaczej.
- Frameworki „autonomicznych agentów", które obiecują wszystko. Ogólna lekcja: każdy framework, którego pitch brzmi „powiedz mu cel i odejdź", sprzedaje ci demo. Cała interesująca praca dzieje się tam, gdzie demo nie pokazuje.
- Bazy wektorowe jako pierwszy odruch. Często właściwą odpowiedzią jest grep po repo, nie embedowanie wszystkiego do vector store i modlitwa. Szukanie wektorowe jest świetne do mglistej podobieństwowej w skali; jest przesadą do „gdzie ta funkcja jest wywoływana" i gorsze niż grep w tym konkretnym pytaniu.
- Spekulacyjne równoległościowanie. Uruchomienie dziesięciu wariantów równolegle i wybór najlepszego brzmi mądrze, a zwykle produkuje dziesięć średnich wyników kosztujących dziesięć razy budżet. Jakość bierze się z iteracji ze feedbackiem, nie z amplifikacji słabego sygnału na dziesięć sposobów.
/ NOWE UMIEJĘTNOŚCI
W czym faktycznie musisz być dobry
Umiejętności, które kapitalizują się w agentic engineering, nie są tymi, które kapitalizowały się w klasycznym programowaniu. Jest pokrycie, ale kształt codziennej eksperckości jest inny.
- Specyfikacja. Umiejętność opisania efektu na tyle precyzyjnie, żeby szybki, chętny, ale ubogi kontekstowo współpracownik mógł w niego trafić. To jest bliżej pisania produktowego niż pisania kodu. Wydaj godzinę na spec, a zaoszczędzisz pięć na implementacji.
- Czytanie diffów z lotu ptaka. Kiedy agent dowozi piętnaście zmian plików w minutę, nie da się przeczytać każdej dokładnie. Potrzebujesz wykalibrowanego radaru: „to typ edycji, której ufam" kontra „to typ, którego zawsze potem żałuję". Ten radar buduje się na powtarzaniach review, nie na powtarzaniach pisania.
- Wybór właściwej wysokości interwencji. Kiedy agent zjeżdża z torów: poprawiasz prompt, restartujesz rozmowę, naprawiasz leżący niżej spec czy zmieniasz orkiestrację? Każda z tych opcji ma inny koszt czasu, a wybór złej jest najczęstszym sposobem, w jaki operatorzy tracą godziny.
- Wiedza, kiedy przestać. Działający system agentowy kusi cię, żeby dodawać funkcje w nieskończoność. Dobrzy wiedzą, które funkcje zarabiają na swoje miejsce, a które dodają powierzchnię bez przychodu. To ta sama umiejętność, której zawsze potrzebowali product managerowie. Z tym że teraz nie masz komu jej oddelegować.
/ DLA KOGO TO JEST
Ta zmiana dzieje się, czy ci się podoba, czy nie
Wielu seniorów, których szanuję, przeczekuje to z założeniem, że to hype i przejdzie. Nie sądzę, żeby przeszło. Sądzę, że to już nieodwracalnie zmieniło ekonomię małych firm softwareowych, a inżynierowie, którzy nadal czekają, zobaczą, jak ich klasyczne umiejętności zostają wycenione w dół w tempie, którego nie zabudżetowali.
Dobra wiadomość, jeśli jesteś jednym z nich: krzywa przejścia jest krótsza, niż się spodziewasz. Sześć tygodni poważnego codziennego używania stawia cię przed dziewięćdziesięcioma procentami ludzi, którzy mówią, że używają narzędzi AI do kodu. Sześć miesięcy stawia cię przed niemal wszystkimi. To nie jest pięcioletnie przekwalifikowanie. To sześciomiesięczne przerouting tego, jak spędzasz dzień roboczy.
Jeśli nie wywodzisz się z inżynierii w ogóle (produktowy, founder, operator), stoisz na innej linii startu, ale na tej samej krzywej. Nie potrzebujesz już zatrudnić inżynierów, żeby dowieźć software. Potrzebujesz nauczyć się specyfikować, recenzować i orkiestrować. Umiejętności, które się przeklejają z nie-inżynierskich tła (pisanie precyzyjnie, ocenianie jakości, rozumienie, czego użytkownicy naprawdę chcą) to dokładnie umiejętności, które agentic engineering nagradza.
/ NA KONIEC
Dwie części, jedno rzemiosło
Playbook PDF, który stoi za tym wpisem, jest dwuczęściowy z założenia. Część pierwsza to model mentalny: co się zmieniło, dlaczego i w co zainwestować, żeby wylądować po właściwej stronie tej zmiany. Część druga to dzienna mechanika: pętla, zabezpieczenia, zasady orkiestracji, dyscyplina kosztowa. Można czytać każdą osobno, ale zestaw to to, co większość czytelników chce, bo model mentalny uzasadnia praktykę, a praktyka sprawia, że model mentalny ląduje.
Jeden operator może dziś dowieźć tyle, co pięciu. Dyscyplina, która to urzeczywistnia, jest mała, do nauczenia i niemal w całości polega na powściągliwości: wiedząc, co delegować, co sprecyzować, a co zostawić w spokoju. To jest cały playbook. Reszta to powtórzenia.