O czym jest ten film
- Autor wprowadza ramę „poziomu operacyjnego” pracy z agentami: drabinę pięter od pojedynczych linii kodu, przez tabele w bazie danych, skrypty i aplikację, aż po plany, dokumentację, przepływy deweloperskie z AI i fabrykę oprogramowania.
- Każde piętro to inny układ korzyści: im wyżej, tym większa dźwignia i szybkość; im niżej, tym więcej kontroli i rozumienia systemu.
- Sedno przekazu: wyżej nie znaczy lepiej — liczy się zakres zdolności i umiejętność poruszania się w obie strony, zależnie od zadania.
- Położenie na drabinie pokazuje możliwy zakres: vibe coder widzi tylko aplikację, pracownik wiedzy — dokumentację i plany, analityk danych — tabele i skrypty, inżynier — pełny stos.
- Większość inżynierów z przyzwyczajenia krąży między planem, aplikacją i pojedynczymi plikami; samo oglądanie aplikacji to „podłoga”, nie sufit umiejętności.
- Konkretne zalecenia: bogata medialnie dokumentacja generowana przez agentów, pilnowanie tabel bazy danych (kluczowe przy danych osobowych użytkowników), znajomość struktury katalogów, typów i funkcji jako praktycznego „dna”.
- Dźwignię wybiera się, gdy: rozumie się domenę, praca jest znajoma i powtarzalna („trzy razy to wzorzec”), powstaje wiele wytworów, ma się surowe umiejętności agentowe.
- Schodzi się w dół, gdy: wchodzi się w nową domenę lub bazę kodu, stawka jest wysoka (rakiety, budownictwo, biomedycyna), dowody zostawiane przez agenta niczego nie dowodzą, a także gdy liczą się wydajność i detal (np. identyczne, klepane na hurra interfejsy).
- Osobny wątek: zadania „poza rozkładem” modelu — czego model nie wie albo co robi wbrew tobie — i sposoby poszerzania jego możliwości: inżynieria kontekstu, fine-tuning, łączenie wielu modeli.
- Na koniec zapowiedzi: poziomy ponad fabryką oprogramowania („dark factory”, RSI) oraz trzecia faza kursu Tactical Agentic Coding.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zacznij od audytu: na jakim piętrze spędzasz czas z agentem
Na czym polega: Autor definiuje „poziom operacyjny” jako piętro, na którym ty i twój agent kierujecie uwagę: od linii kodu, przez tabele i CLI, po plany i fabryki oprogramowania. Większość inżynierów robi to nieświadomie.
Jak stosować: Przez tydzień notuj, na co faktycznie patrzysz w pracy: na aplikację? plan? pliki? tabele? Na tej podstawie porównaj faktyczny poziom z tym, jakiego wymaga zadanie.
Na co uważać: Nie myl poziomu z prestiżem — wyższy nie znaczy lepszy, a wygodne „samo patrzenie na aplikację” to najniższy możliwy zakres.
2.Dźwignia i kontrola to dwa końce jednej osi
Na czym polega: Wspinanie się daje zasięg i szybkość kosztem rozumienia szczegółów; zejście daje kontrolę i wiedzę kosztem tempa. Autor porównuje to do awansu na lidera zespołu: większy wpływ, mniej bezpośredniego dostępu do kodu.
Jak stosować: Przy każdym większym zadaniu zdecyduj świadomie: potrzebuję teraz skali (idę w górę) czy pewności (schodzę). To decyzja, nie nawyk.
Na co uważać: Nie da się mieć jednocześnie wszystkiego — czas i uwaga są ograniczone, a każdy ruch w dół kosztuje czas.
3.Czego nie rozumiesz, tego nie przeskalujesz
Na czym polega: Budowanie fabryk oprogramowania i rozbudowanych przepływów agentowych bez znajomości produktu, tabel i struktury kodu kończy się źle. Dźwignia bez zrozumienia systemu jest bezwartościowa.
Jak stosować: Zanim zautomatyzujesz obszar, zejdź w nim niżej: obejrzyj tabele, typy, układ katalogów. Dopiero potem podnoś poziom i dokładaj agentów.
Na co uważać: Zasada działa też przy zmianie branży — doświadczony inżynier oprogramowania wchodzący w robotykę czy piekarnictwo ma wąski zakres i musi zaczynać od dołu.
4.Trzy razy to wzorzec — czas automatyzować
Na czym polega: Znajoma, powtarzalna praca to najczystszy sygnał do automatyzacji. Trzecie powtórzenie tego samego powinno zapalać „czerwoną lampkę”.
Jak stosować: Zacznij od małej umiejętności, zbuduj agenta wielokrotnego użytku, a gdy zechcesz oszczędzać i skalować — przełóż to na przepływ deweloperski z AI (ADW).
Na co uważać: Automatyzuj tylko to, co potrafisz ocenić; inaczej mnożysz błędy zamiast oszczędności.
5.Poznaj sygnały, że trzeba zejść do detali
Na czym polega: Schodź niżej, gdy: wchodzisz w nową domenę lub nową bazę kodu; stawka jest wysoka (rakiety, budownictwo, biomedycyna); ślady, które zostawia agent, nie są dowodem sukcesu ani porażki; liczy się wydajność lub gust (wszystkie interfejsy zaczynają wyglądać tak samo).
Jak stosować: Zdefiniuj sobie funkcję oceny: jakie dane wejściowe mają dawać jakie wyniki. Jeśli nie umiesz odróżnić dobrego efektu od złego — zejdź do typów, tabel, w ostateczności do linii.
Na co uważać: Schodzisz wraz z agentem, a nie zamiast niego; ręczne pisanie kodu to dziś margines (mikrooptymalizacje w C i asemblerze).
6.Tabele bazy danych to umowa całego systemu
Na czym polega: Baza i jej tabele stanowią kontrakt, na którym opiera się reszta kodu. W średnio- i długoterminowych projektach pilnowanie ich to warunek zaufania do agenta — zwłaszcza gdy mowa o danych osobowych użytkowników. Produkt to dziś przede wszystkim dane.
Jak stosować: Projektuj tabele sam i weryfikuj, jak agent „wyobraża sobie” strukturę, zanim cokolwiek dotykającego danych użytkowników trafi na produkcję.
Na co uważać: Przy krótkoterminowych prototypach ten poziom można świadomie odpuścić — ale nie przenoś tego luzu do systemów produkcyjnych.
7.Dokumentacja pełna obrazów zamiast czytania kodu
Na czym polega: Kod pozostaje ostateczną prawdą o systemie, ale jego czytanie jest wolne. Autor każe agentom kompresować stan prac w obrazy, SVG, nagrania audio i krótkie wideo — czytelne dla niego, zespołu i innych agentów.
Jak stosować: Niech każdy plan i każdy zamknięty etap kończy się wygenerowanym przez agenta podsumowaniem wizualnym; traktuj je jako warstwę orientacyjną nad kodem.
Na co uważać: To warstwa nawigacyjna, nie zastępstwo prawdy — gdy liczy się detal, weryfikuj w kodzie, nie na obrazku.
8.Typy i funkcje jako rozsądne dno
Na czym polega: Znajomość układu katalogów daje rozumienie bez schodzenia za nisko; typy „opowiadają historię” danych płynących przez produkt; funkcje to sensowna dolna granica. Same linie — tylko wyjątkowo.
Jak stosować: Przeglądając pracę agenta, sprawdzaj najpierw typy i sygnatury funkcji; do pojedynczych instrukcji zaglądaj punktowo.
Na co uważać: Wielu inżynierów nie wie, jakie typy żyją w ich systemie, i nie interesuje się generowanymi funkcjami — to ryzykowne wygodnictwo w każdym produkcie, który ma przetrwać dłużej niż prototyp.
9.Rozpoznawaj zadania poza rozkładem modelu
Na czym polega: „Poza rozkładem” to nie tylko to, czego model nie wie, ale też to, czego robić odmawia albo co robi wbrew tobie. W takich obszarach twoja wiedza realnie poszerza możliwości modelu — uczysz go nowej domeny.
Jak stosować: Gdy agent nie rozumie twojej dziedziny, zejdź w dół i dostarcz kontekst: klasyczna inżynieria kontekstu, uczenie w kontekście, w trudniejszych wypadkach fine-tuning lub łączenie kilku modeli tak, by uzupełniały swoje luki.
Na co uważać: Nie współpracuj „na ślepo” z modelem, który nie wie, co próbujesz osiągnąć — najpierw go naucz albo zrób pracę sam.
10.Buduj system, który buduje system — i zachowaj ruch w obie strony
Na czym polega: Docelowo przestajesz pracować na aplikacji i zajmujesz się warstwą agentową, która robi to za ciebie; z planów przechodzisz do szablonów, a agenta opisujesz przez „wielką czwórkę”: kontekst, model, prompt, narzędzia. Warunek: zachowana zdolność schodzenia — dźwignia bez kontroli i zrozumienia nic nie znaczy.
Jak stosować: Po opanowaniu niskich pięter inwestuj w umiejętności czysto agentowe: orkiestracja wielu agentów, łączenie modeli zamiast ich wybierania, własne środowiska uruchomieniowe — i składaj z nich coraz większe przepływy.
Na co uważać: Największa pułapka to zamarnięcie na jednym piętrze; rama ma być dynamiczna — w górę, gdy potrzebujesz zasięgu, w dół, gdy potrzebujesz pewności.
Redakcyjne tłumaczenie
Wstęp: pytanie, które porządkuje całą pracę
Cześć, inżynierowie! Najlepsi z nas nie są najlepsi dlatego, że harują ciężej i dłużej. Są najlepsi dlatego, że gdy przychodzi czas na skalowanie oddziaływania, zajmują się tym, co daje największy mnożnik — a kiedy detale stają się krytyczne, zwalniają i schodzą do nich. Kiedy nam idzie słabo, bywa to kwestia braku umiejętności. Znacznie częściej jednak skierowaliśmy uwagę na niewłaściwe miejsce.
Przez ponad piętnaście lat pracy w inżynierii wypracowałem ramę, która w epoce agentów pozwoliła mi bardzo szybko się rozwijać — i chcę się nią podzielić. Jej siła polega na tym, że porządkuje pracę wokół najcenniejszych zasobów: czasu, skupienia i uwagi.
W czasach AI zmieniło się miejsce, w którym inżynier spędza swój czas. Nie mówię tu o inżynierii promptów czy kontekstu, ani o dostrajaniu środowisk, w których działają agenty. Mówię o poziomie, na którym pracujesz, żeby razem z agentami wytwarzać wartościowe oprogramowanie. Pozwól, że zadam jedno kluczowe pytanie: na jakim poziomie operacyjnym pracujesz ze swoimi agentami — od pojedynczych linii kodu aż po fabrykę oprogramowania?
Czym jest poziom operacyjny pracy z agentami
Definicja jest prosta: poziom operacyjny zmusza cię do odpowiedzi na pytanie, dokąd trafia twoja uwaga. Na czym się w tej chwili skupiasz. I zawsze mówimy o duecie — ty sterujesz agentem, a wy obaj patrzycie na konkretne piętro systemu. Na samej górze drabiny stoi fabryka oprogramowania, gdzie mnożnik systemowy jest największy. Na samym dole masz pełną kontrolę. I od razu kluczowa myśl: nie chodzi o żaden pojedynczy szczebel ani o to, by ciągle piąć się wyżej. Czasem zejście niżej przyniesie więcej wartości — zależnie od problemu, który akurat rozwiązujesz.
Patrząc na tę drabinę, zwróć uwagę, gdzie spędzasz najwięcej czasu. Najprawdopodobniej przy planach. Może przy samej aplikacji. Czasem schodzisz do pojedynczego pliku. Zapamiętaj to, bo za chwilę użyjemy drabiny jako kompasu do kilku naprawdę ważnych decyzji. Plan wypadu: plusy i minusy każdego poziomu, wybór między dźwignią a kontrolą, typowy rozkład dla przeciętnego inżyniera, rola wiedzy domenowej i sposób jej budowania (to punkt szczególnie ważny dla vibe coderów) oraz odpowiedź na pytanie, na jakim poziomie powinnaś albo powinieneś pracować. Choć rama pasuje do każdej dziedziny, ten kanał jest i będzie dla inżynierów oprogramowania — konkretnie osób na poziomie od średniozaawansowanego po seniora wzwyż, które budują wartościowe produkty i wdrażają je na produkcję.
Fundamenty: linie, bloki, funkcje, typy, klasy
Zacznijmy od fundamentów — od tego, gdzie inżynierowie kiedyś spędzali cały czas: od pisania kodu, pojedynczych instrukcji, aż po klasy. Największym zyskiem na tym piętrze jest bezpośrednia kontrola. Oprogramowanie to w gruncie rzeczy zbiór linii; można zejść jeszcze niżej, ale nie ma to dla nas znaczenia. Ruszamy od linii i bloków, przez funkcje i typy, po klasy. Już samo spojrzenie na klasę mówi bardzo dużo: typy, definicja funkcji, argumenty, zwracana wartość, blok kodu, wreszcie pojedyncze instrukcje.
I pamiętaj: zawsze mówimy o tobie plus agent. Nie namawiam, byś sam siadał i pisał te linie. Jeśli na tym poziomie kierujesz uwagę na instrukcje, bloki, funkcje, typy i klasy — masz nad systemem największą kontrolę. Ale, jak zaraz zobaczymy, coś za coś.
Struktura kodu: pliki, moduły, katalogi
Piętro wyżej to struktura kodu — to, jak zorganizowany jest twój projekt. Porozumiewając się z agentami, odwołujesz się do nazw plików, modułów i katalogów. Budując nową funkcjonalność, możesz na przykład określić, jak pliki mają być poukładane i jak się nazywają, a potem wskazywać je agentowi z nazwy. Zyskujesz nieco więcej dźwigni, ale — zauważ — tracisz kontrolę i rozdzielczość, bo niskopoziomowe szczegóły bierze na siebie agent.
Dane i wykonanie: bazy i tabele
Dalej robi się bardzo abstrakcyjnie. Na poziomie danych i wykonania zajmujesz się bazami danych i pojedynczymi tabelami — i nie tylko produkcyjną: także stagingową, deweloperską, całą rodziną baz, które obsługuje twój produkt. Baza i jej tabele to umowa, którą ty i twoi agenci zawieracie z resztą systemu: z modułami, kodem, pojedynczymi liniami. Abstrakcji przybywa.
Skrypty i wiersz poleceń
Kolejne dwa ciekawe piętra to skrypty i CLI. To sposób sterowania systemem na poziomie czysto inżynierskim: poruszasz się bardzo szybko, uruchamiasz wąski, konkretny fragment logiki, budujesz wielokrotnego użytku ścieżki dla siebie i agentów — a na tym wszystkich nakłada się warstwa skryptów. Znów: im wyżej, tym większa dźwignia. Wyznaczasz struktury ważne przez cały czas życia budowanych aplikacji i produktów, ale nie zaglądasz już ani do plików, ani do katalogów, ani do linii.
Dostarczanie i intencje: aplikacja, repozytorium, plan, dokumentacja
Trend się utrzymuje. Piętro wyżej: dostarczanie i intencje. U wielu inżynierów właśnie teraz powinny zapalić się lampki. Część sprytnych ludzi dokumentuje już swoją pracę dla agentów, ale trafia tu na poziom szczególny: poziom samej aplikacji — piętro numer 13 na drabinie, czyli poziom vibe codingu. Wielu nieinżynierów pracuje wyłącznie tutaj.
(Informacja dodatkowa: vibe coding — styl pracy, w którym oprogramowanie powstaje głównie w rozmowie z modelem AI, bez wchodzenia w kod; termin spopularyzował Andrej Karpathy.)
Zauważ, jak dużo kontroli tracimy już na poziomie samej aplikacji. I to jest punkt rozdziału: jeśli potrafisz patrzeć wyłącznie na aplikację — nie umiesz spojrzeć ani wyżej, ani niżej — będziesz bardzo ograniczony: w rodzajach efektów, które potrafisz wytworzyć, w skali oddziaływania i w zdolności naprawiania tego, co pójdzie nie tak. Ograniczeń jest tu mnóstwo. Można jednak wznieść się ponad aplikację, na poziom repozytorium. Inżynier pracujący tam może zrobić coś naprawdę mocnego — na przykład utrzymywać katalog apps z wieloma aplikacjami. To wzorzec, który bardzo lubię, bo produkt to nie jedna aplikacja ani nawet jedno repozytorium; bywa, że wiele. Na tym piętrze ty i agent operujecie na bardzo wysokiej abstrakcji.
Porozmawiajmy o intencjach. Planowanie to dziś bardzo mocne miejsce dla każdego inżyniera, bo stamtąd widzisz cały system pod sobą i część tego, co nad tobą. Możesz opisać, co ma się wydarzyć dalej i co się wydarzyło dotąd. Poziom planu jest bardzo ważny — ale zauważ, ile informacji przepada. Możesz pisać naturalnym językiem i nie mieć rozeznania w tym, co dzieje się niżej. Ktoś może na przykład nie umieć otworzyć aplikacji i nanieść w niej zmiany. Brzmi absurdalnie — i jest absurdem — ale takie przypadki się zdarzają. Nad planem jest jeszcze dokumentacja: po prostu konkretne utrwalanie tego, co się stało. Mocna rzecz z oczywistych powodów. Wielu inżynierów powie, że dokumentacją powinien być sam kod. Nie zgadzam się — to bardzo niski poziom operowania. Ma swoje plusy, ma i minusy; do nich wrócimy.
System agentowy: agent, przepływ deweloperski z AI, fabryka oprogramowania
Na samym szczycie jest poziom systemu agentowego. Mówimy tu o agencie, o przepływach deweloperskich z AI (AI Developer Workflow, ADW) — czyli agentach połączonych z kodem tak, by taki duet bił każdy z elementów z osobna — i wreszcie o fabryce oprogramowania, jednym z najwyższych mnożników, jakie inżynier może dziś osiągnąć. Kto prowadzi fabrykę, porusza się prawdopodobnie rząd wielkości szybciej niż pozostali. To samo dotyczy ADW, bo z wielu takich przepływów składa się fabryka. Samo uruchamianie sekwencji plan–buduj–testuj–wdroż to jeszcze nie fabryka; to jeden przepływ deweloperski z AI. Rozgryziliśmy go dokładnie w materiale „forget loop engineering”, który poszedł wiralowo — i był ważny, bo odsunęliśmy w nim pojęcie „loop engineering” na bok i pokazaliśmy, czym to naprawdę jest. Nie chodzi o pętlę. Chodzi o to, by umieć budować dowolne przepływy deweloperskie dla swojej pracy inżynierskiej i swoich produktów.
Najwyższe piętra oznaczają, że praktycznie straciliśmy kontrolę nad wszystkim. Patrzenie na finalny produkt daje bardzo mało możliwości sterowania. Praca z agentami wewnątrz produktu — podobnie. To samo z ADW. I tu trafiamy na sedno całej ramy: jeśli chcesz większej dźwigni i pracy na tych wysokościach, najpierw musisz zejść w dół. Musisz rozumieć system. Nie przeskalujesz czegoś, czego nie rozumiesz.
Wyżej nie znaczy lepiej
Powiedzmy to wprost: wyżej nie znaczy lepiej. Sama dźwignia bez zrozumienia nie zadziała. Kierowanie całej uwagi na fabryki oprogramowania i przepływy agentowe, gdy nie wiesz, co robi twoja aplikacja, jaka jest wizja produktu, jakie tabele są w bazie, jak dane układają się w typy i jaka jest struktura kodu — skończy się bardzo źle. Tę ramę rozwijam od dawna właśnie po to, by pomóc sobie i innym ustalić, gdzie w epoce agentów kierować czas, uwagę i skupienie, bo dziś wcale nie jest to oczywiste.
Jeśli znasz kanał, wiesz, że hiperfiksujemy się na szczycie drabiny. Ale to dlatego, że mówię do inżynierów oprogramowania — a wy te niższe piętra już znacie: warunki, bloki, pętle, struktury danych, algorytmy, tabele, SQL i NoSQL, kompromisy projektowe, architektura, load balancery — całe to pozornie „nudne” inżynierskie zaplecze, dzięki któremu produkty w ogóle działają. Przynajmniej większość moich widzów je rozumie.
Więc jeszcze raz: wyżej nie znaczy lepiej — ale kiedy już rozumiesz niskie poziomy swojej dziedziny, zdecydowanie powinieneś się wspinać. Po co robić osobiście to, co agent zrobi za ciebie? Nie ma po co. Wiem, że wielu inżynierów wciąż to robi — i spora część cotygodniowych odcinków tego kanału służy właśnie temu, by z tego wyjść.
Nie szukamy jednego punktu, tylko zakresu zdolności. To on wyznacza, jak daleko zajdziesz, jak duże rzeczy zbudujesz i jak udana będzie twoja praca. Chcesz operować we właściwym zakresie we właściwym momencie. W samej podłodze jest vibe coder: jedyny wytwór, jaki potrafi obejrzeć, to aplikacja. Piętro wyżej — pracownik wiedzy: rozumie dokumentację, plan, może produkt. Dalej analityk danych: zna tabele, uruchamia skrypty, rozumie więcej warstwy programistycznej — szersze rozeznanie, większe możliwości. A inżynier oprogramowania otwiera drzwi na oścież: wszystkie prymitywy kodu, cała struktura — i wolna droga w górę.
Najlepsza średnia i wyższa grupa inżynierów bardzo dużo myśli o produkcie, nie tylko o niskopoziomowych detalach. Pamiętam własny skok w karierze — około 2018, 2019 roku: zacząłem planować całą pracę, dokumentować wszystko, co zrobiłem, i myśleć przez pryzmat produktu oraz ludzi, którzy z niego korzystają. Nie o kierowniku, nie o szefie — o samym produkcie. Właśnie ten przeskok — zapomnij na chwilę o agentach, mówię o czystej inżynierii — przenosi na poziom senior, a nawet principal. Planujesz, dokumentujesz, myślisz o produkcie i rozumiesz, że sprawa jest większa niż jedna aplikacja czy jedno repozytorium. A im wyżej, tym większa dźwignia.
Dla porządku: kolejność elementów można lekko przestawiać i dopisywać własne — ja pokazuję największe kalibry. Produkt mógłby na przykład leżeć niżej; nieistotne. Chodzi o ideę. Ostatnim właściwym poziomem jest poziom agentowy — i to tu naprawdę zaczyna się inżynieria agentowa: inżynieria oprogramowania z autonomicznym oprogramowaniem, które podejmuje działania w twoim imieniu. Link do wpisu, w którym rozbieram to pojęcie na części, zostawiam w opisie.
Co kupujesz, idąc w górę — i co oddajesz
Wspinaczka daje dźwignię i szybkość, ale nic nie jest za darmo. Każdy inżynier z głową na karku zauważył, że dzieje się coś szalonego: tracimy rozumienie niższych poziomów i mamy mniejszą kontrolę nad tym, co się dzieje, niż kiedykolwiek. Tak właśnie działa technologia — coś daje i coś odbiera. Pytanie nie brzmi, czy tak będzie; pytanie brzmi, jakie kompromisy wybierasz dziś.
Układ ten zna każdy lider, manager czy CTO na poziomie staff: im większy wpływ, tym częściej trafiasz w role, w których masz mniej bezpośredniej kontroli i mniej rozumienia szczegółów. Ale co dostajesz w zamian? Dźwignię. Ludzie pracują z tobą i dla ciebie, masz zespół, jesteś szybszy, robisz rzeczy niemożliwe dla pojedynckiej osoby. Dokładnie ten sam mechanizm działa na stosie dźwigni w epoce agentów: twoje doświadczenie inżynierskie plus twój system agentowy — niezależnie od środowiska uruchomieniowego i modeli, na których pracujesz. Im wyżej, tym więcej dźwigni i szybkości, tym mniej bezpośredniej kontroli i rozumienia.
W dół jest odwrotnie: zyskujesz kontrolę i rozumienie. Czego nie dostajesz? Prędkości. I tu trzeba nazwać rzeczy po imieniu, bo inżynieria oprogramowania to sztuka kompromisów: zbudować najlepszy system w odpowiedniej cenie, w odpowiednim tempie, z odpowiednią wydajnością — i świadomie coś w zamian oddać. Nie da się pilnować wszystkiego; uwaga, czas i zasoby są ograniczone.
I znów podkreślam: mówię o tobie i twoim agencie pracującym na niższym piętrze. Absolutnie nie namawiam do robienia rzeczy ręcznie. Ten rozdział się skończył. Ostateczne ostrzeżenie: inżynier piszący linie kodu ręcznie nie ma dziś czego szukać — nie wygra w rywalizacji. Zostawiam furtkę, i to ułamek promila, dla pracy skrajnie precyzyjnej: aktualizowania instrukcji w C i asemblerze pod mikrooptymalizacje w systemach algorytmicznego handlu wysokiej częstotliwości. Naprawdę ciasne rzeczy. Ale i tam obstawiam, że wejście agenta pomnoży twoje możliwości.
Gdzie siedzi większość — i co autor poleca
Jak można się domyślić, najpopularniejsze poziomy wynikają z lenistwa. Podłogą jest vibe coding. Sufitem — inżynieria agentowa: traktowanie tej pracy jak nowego rzemiosła i nowej umiejętności. Bo inżynieria agentowa to nowe rzemiosło. Obraz, który chcę utrwalić: na dole tradycyjna inżynieria (z produktem w zestawie), a wyżej — mocno skompresowane piętra. Fani kanału wiedzą, że pod agentem, ADW i fabryką kryje się wiele podpoziomów; tu je skracam, ale idea jest jasna: umiejętności do opanowania jest teraz mnóstwo. Inżynieria promptów, kontekstu i środowisk agentowych to te najłatwiejsze do wskazania.
Wielu ludzi skupia się na samym agencie — bardzo dobrze. Jeszcze więcej na planie, bo czymże jest plan? Promptem w dużej skali. Umiejętność pisania takich dokumentów i przekazywania ich coraz mocniejszym agentom, zasilanym coraz mocniejszymi modelami, to kompetencja kluczowa — inżynierowie to rozumieją i w to wchodzą. A aplikacja? Wielu ludzi, w tym cała rzesza vibe coderów, tylko na nią patrzy: wyszło to, czego chciałem? Nie? To promptuję od nowa. Maksymalne oparcie się na jednym poziomie. Niektórzy pilnują CLI i narzędzi agenta — dziś często w postaci „skillsów”. I wreszcie poziom plików: pracujesz z agentem nad pojedynczymi plikami, coś stroisz, coś dostrajasz. Zabawnie to nazywać szczególną uważnością, ale takie mamy czasy.
Co polecam? Trochę więcej niż to. Zasada na szczycie: zdobywaj dźwignię w systemach, które rozumiesz. Kiedy schodzić, a kiedy się wspinać — zaraz do tego dojdziemy. Najważniejsze zalecenia:
- Dokumentacja — pisana z agentami i dla agentów, ale też dla ciebie. Moje plany i dokumenty są dziś bogate medialnie: generuję obrazy i SVG, żeby ja, moi agenci i zespoły błyskawicznie rozumieli, co zostało zrobione. Kod pozostaje ostateczną prawdą — każdy inżynier wie, gdzie iść, żeby sprawdzić. Ale to wolne, a agent i tak wykona sporo tej niskopoziomowej roboty. Więc przyspieszamy: agenty podsumowują, kompresują, sklejają informacje w zwięzłe obrazy, nagrania audio i krótkie widea. Na poziomie dokumentacji da się zrobić bardzo dużo.
- Tabele bazy danych. Przy krótkoterminowych prototypach — nieważne. Ale w każdym średnio- i długoterminowym projekcie nie wyobrażam sobie, jak można ufać agentowi i wdrażać dane osobowe użytkowników, nie pilnując tego piętra. Projektowanie tabel, wiedza o tym, jak agent wyobraża sobie strukturę — brzmi banalnie po dziesięciu, piętnastu latach w branży, ale produkt to dane, i nigdy nie było to prawdziwsze niż dziś. Najcenniejsze, co budujesz w produkcie, to relacja z użytkownikami. W jakiej formie? W danych.
- Struktura katalogów i pliki — chyba najbardziej kontrowersyjne poziomy, obok typów i funkcji. Wielu inżynierów nie ma pojęcia, jakie typy żyją w ich projekcie, i nie interesuje się tym, jakie funkcje się generują, dlaczego i kiedy. Im więcej kontroli potrzebujesz, tym niżej schodź. Przynajmniej miej ogólne rozeznanie. Vibe coding jest w porządku — chyba że budujesz prawdziwe produkcyjne oprogramowanie, które ma być rentowne w długim terminie. Wtedy zakazałbym go ostatecznie. Znajomość układu katalogów i plików daje rozumienie bez schodzenia za nisko. Polecam też rozumieć typy — typy opowiadają historię danych płynących przez produkt. Funkcje to z pewnością poziom, na którym zatrzymałbym się jako na dolnej granicy. Co jakiś czas warto zajrzeć do samych linii, ale to rzadkość. I pamiętaj: schodzenie kosztuje czas.
Kiedy wybierać dźwignię
Wszystko, co robimy, to zakresy — i jest ich wiele. Jeśli zmieniasz domenę — nie jesteś piekarzem, a budujesz automatyzację piekarni dla robotów — twój zakres jest wąski. I jeśli myślisz, że od razu zbudujesz fabrykę oprogramowania, oszukujesz sam siebie. Będziesz potrzebował wiedzy domenowej. Nie chodzi więc tylko o surowe umiejętności inżynierskie i agentowe, ale też o to, w jakiej branży pracujesz. Wybieraj dźwignię, gdy rozumiesz domenę — bo wtedy wiesz, co jest dobre, a co złe. Gdy praca jest znajoma i powtarzalna — to oczywisty sygnał do automatyzacji. Trzy powtórzenia to już wzorzec; za trzecim razem powinna ci się zapalić czerwona lampka: zautomatyzuję to, rzucę na to agentów i kod, zbuduję przepływ deweloperski z AI. Zacznij od umiejętności, od czegoś prostego; zbuduj agenta wielokrotnego użytku; przenieś do ADW, gdy zechcesz oszczędzać i skalować. Wybieraj dźwignię, gdy dowody przemawiają za automatyzacją — jeśli robiisz coś po raz trzeci, powinieneś mocno kwestionować swoje działanie, bo najpewniej tracisz czas.
I rzecz oczywista: nie wzniesiesz się bez surowych umiejętności inżynierii agentowej. Najwyższy blok jest dla ciebie całkowicie niedostępny, jeśli nie ogarniasz inżynierii promptów, kontekstu i środowisk agentowych, orkiestracji wielu agentów, doboru modelu pod zadanie i pod cenę, budowy własnego harnessu i łączenia agentów z kodem tak, by duet bił każdy element z osobna. Jest tego mnóstwo — w tym fuzja modeli, o której mówiliśmy zeszłego tygodnia przy okazji V2 fusion harness (link w opisie). Potrzebujesz surowej wiedzy — nie tylko inżynierskiej, nie tylko domenowej, ale właśnie agentowej.
Kiedy wybierać kontrolę
Bo to nie jest ruch w jedną stronę. Czasem trzeba i w górę, i w dół — gdy tego wymaga problem i rozwiązanie. To zakres, nie kierunek; rzeczywistość jest zbyt złożona na proste reguły.
- Mało rozumiesz w danej dziedzinie — musisz zejść. To fakt. Skoro nie wiesz, co robią twoi agenci, jak ocenisz, czy robią dobrze? Ja właśnie teraz, próbując zbudować małego fizycznego robota, nie mam tam żadnej wiedzy — więc schodzę do samego dołu, do linii kodu, która zapala diodę w tym robocie. Taki „hello world” inżynierii sprzętowej.
- System jest ci obcy. Nowa firma, nowa baza kodu, nowy projekt — nie podnoś poziomu operacyjnego, skoro nie wiesz, co jest pod tobą.
- Wysokie ryzyko i wielki wpływ. Wysyłasz rakiety w kosmos? Lepiej nie vibe coduj. Projektujesz konstrukcje, w których będą mieszkać ludzie? Robisz biomedycynę? To wszystko są poważne argumenty za kontrolą. Brzmi oczywście — ale zdziwiłbyś się.
- Słabe dowody z debugowania. Patrzysz na ślady, które zostawia agent, i myślisz: ta walidacja nie ma sensu, to nie wygląda na dowód sukcesu ani porażki? Musisz zejść. Musisz wiedzieć, kiedy coś działa. Potrzebujesz jakiejś funkcji oceny — znaku sukcesu lub porażki. Na tym w większości polega wiedza ekspercka: znasz dane wejściowe i wiesz, jakie wyjścia powinien wygenerować system. Jeśli nie potrafisz oddzielić dobrych wyników od złych — schodź. Do klas, do typów, do tabel, w razie potrzeby do linii.
- Wydajność i detal. I coś, co zaczyna i mnie irytować: wszystkie interfejsy zaczynają wyglądać tak samo. Dlaczego? Bo wszyscy klepią je na hurra, z/modulem AI, bez zdania i bez smaku. A szczegóły mają znaczenie. Widać to — nie tylko inżynierowie; zwykli ludzie też potrafią rozpoznać produkt „wypluty” bez namysłu. Ma swój podpis: te same szablony, te same komponenty, wszędzie identyczne pulpity. Gdy liczy się detal i gust — wchodzisz w głąb. Wydajność jest jeszcze ostrzejsza: budujesz algorytm handlu wysokiej częstotliwości i nie wiesz, która linia kodu kosztuje cię pięć milisekund? Twoja konkurencja cię zje. Gdy liczy się wydajność, wybierasz kontrolę. I znów: to ty i twój agent schodzicie razem — ty, twoje środowisko, twoja orkiestracja, twoja drużyna agentów, twój fusion harness. Schodzicie zespołowo.
Poza rozkładem: granice tego, co model wie
Jeszcze jedna rzecz, naprawdę ważna: gdy to, co robisz, jest poza rozkładem modelu. Koncepcja jest prosta — to, co model zna, kontra to, czego nie zna; albo to, o czym ty wiesz, że on nie wie. Mnóstwo rzeczy znają wszystkie modele — od solidnych „roboczych koni” w górę: zbudują ci API, zaprojektują bazę w Postgresie, zrobią zwyczajny, przeciętny interfejs, czasem nawet ładny. A potem jest to, co poza rozkładem: czego model nie umie, o czym nie wie, albo czego aktywnie odmawia — bo w treningu wpajano mu, by o tym nie mówił i tego nie robił. Nie będę podawać konkretnych przykładów; sam je znasz. Chodzi o przypadki, gdy agent robi rzeczy, których nie chcesz. Poza rozkładem to więc nie tylko niewiedza, ale też obszary, z którymi musisz walczyć.
Koncepcja jest kluczowa: jeśli model nie ma informacji i działa źle, musisz wkroczyć. Twoja wiedza inżynierska i domenowa realnie poszerza rozkład — realnie zwiększa to, co model potrafi. W efekcie uczysz go nowych umiejętności. Technik jest wiele i wiele omawialiśmy na kanale: klasyczna inżynieria kontekstu, uczenie w kontekście, a w trudniejszych przypadkach fine-tuning czy fusion harness — łączenie modeli, zbieranie wielu opinii i planów, współpraca agentów uzupełniających wzajemnie swoje luki. Zasada jest prosta: nie współpracuj z kimś, kto nie wie, co próbujesz zrobić. A jeśli musisz — albo jeśli jest pomocny w innych, bocznych obszarach — naucz go. Zastosuj swoją wiedzę, by wypełnić jego białe plamy. Gdy model nie ma pojęcia, o czym mówisz, schodzisz w dół stosu.
Nie ma zamiennika dla surowej wiedzy
Jak więc budować wiedzę ekspercką — dla vibe coderów, dla każdego, kto chce podnieść umiejętności, i dla inżynierów wchodzących w nowe dziedziny? Bardzo prosto: musisz ją zbudować. Musisz zdobyć doświadczenie. Wiem, że brzmi to banalnie, ale ktoś musi to powiedzieć: jeśli chcesz być w czymś dobry, rób to od atomów. A atomami inżynierii oprogramowania są linie, bloki, funkcje, typy, klasy, plik, moduł. Musisz przez to przejść. Nie da się przeskalować czegoś, czego nie rozumiesz. Inżynieria agentowa nie ma sensu, jeśli na żadnym poziomie nie rozumiesz tego, co usiłujesz „agentować”.
Jak głęboko zejść, zależy od wszystkiego, o czym rozmawialiśmy: twojego poziomu wiedzy, ryzyka, tego, ile wie agent. Możesz spierać się o to, jak nisko trzeba — ale nie ma zamiennika dla surowej wiedzy eksperckiej. Po prostu nie ma. Każdy inżynier, od debiutanta po seniora, rozumie, że nie ma skrótu dla procesu, który go tu doprowadził. To czysty czas: musisz obijać się głową o komputer — albo o cokolwiek innego w twojej dziedzinie. I dopiero wtedy możesz wskazać agentom wysokie piętra i właściwie nimi sterować, z ekstremalną dźwignią i ekstremalną prędkością.
A przełomy, które dzieją się teraz — u inżynierów budujących z modelami całe systemy agentowe — będą absurdalne. Przeskok z jednego agenta do wielu jest ogromny. Z jednego modelu do wielu modeli w promptach — też ogromny. Z fiksacji na agentach do łączenia agentów z kodem w pracy produktowej i inżynierskiej — wręcz wykładniczy. A fabryka oprogramowania to zupełnie inna planeta.
Poziomy ponad fabryką i to, co dalej
Są poziomy ponad fabryką oprogramowania — i tu robi się naprawdę ekscytująco. Agent to dziś standard branżowy: jeśli używasz tylko agenta, dostajesz przeciętne wyniki. ADW daje kolejny stopień mocy, bo pozwala budować na cyklu życia oprogramowania — na dowolnym przepływie, który kiedyś przechodziłeś ręcznie — i mnożyć go agentami (stąd to „AI” w nazwie). Nie chodzi o pętlę; chodzi o powtarzalny przepływ pozwalający przechodzić przez pracę z prędkością światła, kodem i agentami używanymi we właściwym momencie. Co się dzieje, gdy takie przepływy zaczynasz łączyć? Powstaje fabryka oprogramowania. A fabryka to nie tylko cykl rozwojowy: to hot-fix, prototyp, burza pomysłów, wdrożenie na staging do przetestowania, próba kolejnej permutacji, ticket supportu, który właśnie przyszedł. To system, który zaczyna działać bez ciebie.
Krótkie ogłoszenie: aktywnie pracuję nad trzecią fazą następcy kursu Tactical Agentic Coding (link w opisie). Krótki pitch: to moje podejście do skalowania daleko poza AI coding i vibe coding — z inżynierią agentową tak mocną, że baza kodu zaczyna sama siebie prowadzić. Skorzystały z niego tysiące inżynierów, także z firm, które znasz z nazwy. To kurs dla ludzi wdrażających na produkcję — dla czołowych 20% — dla tych, którzy wiedzą, że to nie modele, nie narzędzia i nie agenty są już wąskim gardłem, tylko oni sami. Druga faza jest dostępna od prawie roku i wciąż aktualna. Dlaczego? Bo nie skupiam się na modelach, narzędziach ani frameworkach, tylko na ideach i twardych taktykach agentic coding przechodzących w inżynierię agentową. Konkretnie: buduj system, który buduje system. To zmiana przekonań co do tego, gdzie spędzać czas — przestajesz pracować na aplikacji i zajmujesz się warstwą agentową, która robi to za ciebie; przestajesz kodować, odchodzisz od planów i zaczynasz szablonować. Do tego skalujemy „wielką czwórkę” agenta: kontekst, model, prompt, narzędzia. Drobiazg dla wytrwałych: członkowie kursu dostaną zniżkę na to, co nadchodzi.
Zateasuję jeszcze dwa wielkie pomysły latające po internecie: dark factory i RSI.
(Informacja dodatkowa: RSI, recursive self-improvement — hipotetyczny system AI zdolny usprawniać sam siebie; „dark factory” to zapożyczona z przemysłu metafora fabryki działającej całkowicie bez ludzi.)
RSI to na dziś praktycznie nieistniejąca granica stanu wiedzy — nikt tego jeszcze nie robi; próbują liderzy wielkich laboratoriów, przede wszystkim OpenAI i Anthropic. Ale to dwa kolejne namacalne poziomy do osiągnięcia. I jak zawsze: nie przeskoczysz od razu ani do RSI, ani do dark factory, ani do fabryki oprogramowania. Zaczynasz nisko, rozumiesz, co się dzieje, a potem skalujesz i łączysz. Misja kanału i agenticengineer.com jest jedna: budujemy żywe oprogramowanie, które działa, gdy śpimy.
Finał: na jakim poziomie jesteś ty?
Więc — na jakim poziomie operacyjnym pracujesz? Już powinieneś mieć o wiele lepsze rozeznanie, gdzie na drabinie siedzisz. Gdzie ty i twoi agenci spędzacie najwięcej czasu? Jakie wytwory powstają waszą ręką? I dokąd chcesz się przesunąć? Może trzeba zejść — bo utrzymujesz się za wysoko, a potrzebujesz detalu, żeby potem zrobić skok w górę? Bądź ze sobą szczery i szukaj ulepszeń. Przestań myśleć o tym, jak wyglądasz na tle innych — zacznij doprowadzać sprawy do końca, uczyć się i ewoluować. Czasem, w niektórych domenach i bazach kodu, oznacza to zejście. Innym razem wspinaczkę. Jeśli wiesz, co robisz — wspinaj się. Opanuj przepływy deweloperskie z AI, opanuj inżynierię promptów, kontekstu i środowisk agentowych. Weź SDK agentowe, weź jedno środowisko zamknięte i jedno otwarte. Używaj modeli razem i łącz moce obliczeniowe zamiast je wybierać. To wszystko — o czym rozmawiamy na kanale co tydzień — składa się potem w górę: w ADW i fabryki oprogramowania, gdzie powstaje to dziwnie żywe oprogramowanie, które działa za ciebie — i gdy jesteś przy biurku, i gdy cię nie ma.
Wielka puenta: dźwignia bez kontroli i zrozumienia nic nie znaczy. Ruszaj w górę, gdy potrzebujesz zasięgu i prędkości; schodź, gdy potrzebujesz kontroli i rozumienia. Wybieraj poziom pod problem, który masz przed sobą, i zachowaj zdolność ruchu w obie strony. Szukasz zakresu — i dynamiki w jego obrębie. Linki w opisie. Widzimy się w każdy poniedziałek. Trzymaj skupienie i buduj dalej.