Agentowe programowanie zmienia się w tempie bezprecedensowym nawet jak na standardy świata technologicznego. Dostępne tutoriale i materiały online skupiają się głównie na poszczególnych funkcjach w prostych scenariuszach greenfield.

Podczas budowania Boba i pracy z niezliczonymi praktykami z szerokiego spektrum branż wyłonił się zestaw koncepcji, które pomagają zwiększyć skuteczność i komfort pracy z Bobem.

Te koncepcje sprawdzają się również w złożonych projektach wykorzystujących technologie niszowe.

Koncepcja 1: Cykl — eksploracja, planowanie, implementacja, weryfikacja

Cykl eksploracja, planowanie, implementacja, weryfikacja z zewnętrzną pętlą ciągłego doskonalenia przewodników i czujników

Najczęstszym błędem w agentowym inżynierii oprogramowania jest brak struktury. Spójność konwersacji udaje strukturę i kuszeni jesteśmy, by złożyć wszystkie etapy implementacji w jednej rozmowie. Sesje wydają się produktywne, ale koszt ujawnia się dopiero w przeglądzie.

Pisanie kodu ręcznie samo w sobie narzucało strukturę. Implementacja była kosztowna, więc planowanie przed implementacją wydawało się intuicyjnie sensowne. Rozumienie narastało podczas pisania, a błędne założenia miały szansę wyjść na jaw w tym procesie. Agenci AI usunęli to tarcie. Kod jest teraz tani, co zabrało nam też intuicję co do struktury. Struktura, która kiedyś była produktem ubocznym powolności, musi teraz być świadoma.

Stosowanie tego cyklu świadomie może zapewnić tę strukturę:

Eksploracja tworzy rozumienie
Planowanie tworzy decyzje
Implementacja tworzy kod
Weryfikacja tworzy dowody.

Przestrzeganie tego cyklu pomaga zachować skupienie, strukturę i szybciej oraz konsekwentniej osiągać cele.

Pojedyncze przejście przez cykl może zająć dwadzieścia minut lub trzy dni. Przejście może zawierać podcykle, a podział czasu między fazami znacznie różni się w zależności od zadania.

Szczegółowe omówienie cyklu znajdziesz poniżej w sekcji Szczegółowe omówienie: Uruchom cykl.

Koncepcja 2: Okno kontekstu jest zasobem deficytowym

Świadome zarządzanie oknem kontekstu to nawyk przynoszący największy zwrot.

Czym jest okno kontekstu?

Modele są bezstanowe. Czat to nie sesja z pamięcią — każda tura wysyła ponownie wszystkie poprzednie wiadomości i dołącza nową odpowiedź na końcu. Okno kontekstu to maksymalna ilość danych wejściowych, jaką model może przyjąć w jednej turze. W Bob V2 wynosi to 270k tokenów (zarządzanie oknem kontekstu).

Okno wypełnia się jeszcze przed pierwszą wiadomością:

Załadowane z góry: systemowy prompt Boba, opis aktywnego trybu, plik agents.md repozytorium oraz opis każdego podłączonego narzędzia Model Context Protocol (MCP) (MCP w Bobie).
Dodawane podczas sesji, niewidocznie: odczyty plików, wyniki narzędzi, pliki skill ładowane przez Boba, wyjście subagentów.

Okno kontekstu wypełnia się i jest kompaktowane do podsumowania

Gdy okno się zapełni, Bob kompaktuje konwersację. Bob zastępuje dotychczasową rozmowę podsumowaniem i praca jest kontynuowana. Dzięki temu sesja trwa, ale jest to proces stratny z założenia. Bob automatycznie decyduje, które szczegóły przeżyją, a żaden ze straconych nie jest oznaczony. Sesja, która była kompaktowana dwukrotnie, działa na podsumowaniu podsumowania.

Pojedyncze wywołanie MCP może zwrócić dziesiątki tysięcy tokenów, a sekwencja odczytów plików rozcieńcza to, co było omawiane wcześniej w sesji. Opisy trybów, pliki reguł i serwery MCP robią to wolniej i mniej widocznie. Bob dzieli okno na źródła, a to zestawienie warto otworzyć ponownie, gdy konfiguracja rośnie.

Wskaźnik okna kontekstu Boba rozwinięty, pokazujący bieżącą sesję podzieloną według źródeł

Bobcoins są naliczane głównie per token. Koszt konwersacji rośnie zatem kwadratowo względem jej długości. Dłuższe konwersacje kosztują znacznie więcej Bobcoins niż krótkie! (dokumentacja Bobcoins)

Pracuj z oknem kontekstu, nie przeciwko niemu

Dziel pracę na osobne konwersacje. Jedno zadanie, jedna sesja. To ta sama logika co zasada pojedynczej odpowiedzialności w kodzie. Konwersacja powinna mieć jeden powód istnienia, np. „narysuj diagram architektury komponentu X" lub „stwórz plan implementacji funkcji Y". Wszystko w oknie kontekstu wpływa na to, co nastąpi później, włącznie z podejściami, które nie zadziałały. Sesja, która utknęła, ma tendencję do tkwienia w miejscu, bo nieudane próby wciąż tam są i model czyta je jako dowód na to, jak wygląda to zadanie (zatruwanie kontekstu).
Cofaj zamiast kłócić się z Bobem. Gdy konwersacja dryfuje w niepożądanym kierunku, cofnij do ostatniej dobrej wiadomości, zmień ją i kontynuuj od tego miejsca. To cofa też wszystkie lokalne zmiany Boba, co utrzymuje okno kontekstu małe i czyste (rollback).
Wszystko, co warto zachować, trzymaj w pliku, nie w czacie. Plany, ustalenia i decyzje powinny trafiać do pliku. Kolega może przejrzeć dokument markdown i przekazać go do nowej sesji; log czatu nie spełnia żadnej z tych funkcji.
Subagenty trzymają masową pracę poza oknem kontekstu. Bob sam decyduje, kiedy uruchomić subagenta, a do kontekstu trafiają tylko ustalenia. Można też zlecić to bezpośrednio, gdy zadanie wyprodukuje wyjście, które nikomu nie jest potrzebne do czytania (subagenty).
Dbaj o to, co trafia do okna kontekstu i czy przynosi wartość. Regularnie sprawdzaj swoje przewodniki i czujniki zgodnie z poniższym tematem i poświęć czas na ich doskonalenie.

Koncepcja 3: Dwa rodzaje elementów składowych — przewodniki i czujniki

W długim projekcie to, czy baza kodu staje się lepsza czy gorsza, zależy mniej od Boba, a bardziej od tego, co kształtuje jego pracę i sprawdza efekty. Dostępnych jest wiele elementów składowych: reguły, skill'e, tryby, hook'i, subagenty, zewnętrzne lintery i agenty recenzujące. Niemal wszystkie wykonują jedno z dwóch zadań.

Przewodniki kierują Bobem przed lub podczas pracy (Feedforward). Reguły, skill'e i tryby to wszystko przewodniki.
Czujniki raportują po tym, jak Bob zadzialał (Feedback). Testy, lintery, type checkery, interaktywne sesje przeglądarki i agenty recenzujące to wszystko czujniki.

Człowiek przy laptopie kieruje strzałkę na Boba, a Bob kieruje strzałkę na kod. Strzałka oznaczona „przewodniki" wchodzi do Boba z góry, opatrzona adnotacjami: reguły, skill'e i tryby. Strzałka oznaczona „czujniki" wraca od kodu do Boba, opatrzona adnotacjami: testy, lintery i agenty recenzujące.

1. Przewodniki

Wszystko, co jest dostarczane Bobowi w celu kierowania pracą, jest przewodnikiem. Istnieją trzy główne elementy składowe, które w tym pomagają, a działają poprzez umieszczanie tekstu w oknie kontekstu dodatkowo do wpisanego przez ciebie prompta. Różnią się kiedy ten tekst dociera i co go wyzwala.

Reguły są zawsze aktywne, tryby aktywuje użytkownik, skill'e aktywuje Bob

Reguły są zawsze aktywne. agents.md w katalogu głównym repozytorium to główna z nich, a główna rada dotycząca tego pliku to: trzymaj go krótko. Każda linia konkuruje o uwagę przy każdej pojedynczej turze, więc długi plik reguł sprawia, że Bob gorzej stosuje każdą z poszczególnych reguł (reguły).
Tryby są aktywowane przez użytkownika. Wbudowane tryby to: Ask jest tylko do odczytu. Plan przeprowadza przez proces planowania i przekazuje wynik do Agent, który podejmuje działanie. Niestandardowe tryby można łatwo dodawać (tryby, dodawanie niestandardowego trybu).
Skill'e Bob aktywuje, gdy uzna je za istotne. Zawsze aktywny jest tylko krótki opis skill'a. Główna treść skill'a ładowana jest do kontekstu tylko na żądanie. Dzięki temu skill'e są bardzo oszczędne tokenowo (skill'e).

Wszystko w pliku reguł zużywa tokeny przy każdej turze, niezależnie od tego, czy ta tura tego wymagała — więc trzymaj go minimalnym i pozwól reszcie czekać, aż będzie potrzebna.

2. Czujniki

Wszystko, co dostarcza Bobowi informacji zwrotnej o wyprodukowanej pracy, jest czujnikiem. Które sygnały są przydatne, zależy od bazy kodu i stosu, więc zestaw wart posiadania różni się od projektu do projektu i wymaga prawdziwego wysiłku w assemblerze. Najcenniejsze czujniki są uruchamialne maszynowo i wykonywane przez Boba podczas fazy implementacji. Czujniki można podzielić na dwie różne kategorie.

Czujniki obliczeniowe są deterministyczne: testy, lintery, type checkery, kompilatory. Werdykty są dokładne i powtarzalne, wystarczająco tanie, by Bob uruchamiał je często. Pokrycie jest ograniczone przez systemy, które zespół zbudował i utrzymuje.
Czujniki oparte na AI są elastyczne i niedeterministyczne. Agent recenzujący czyta pod kątem intencji i rzeczy, dla których linter nie ma reguły. Wyjściem jest ocena, a nie pomiar. Różni się między uruchomieniami, a koszt i czas ograniczają częstotliwość użycia (recenzje kodu).

Podłączenie ich ma kilka opcji, w przybliżonym porządku od najmniejszego tarcia:

Hook'i to deterministyczna opcja o najmniejszym tarciu. Sprawdzenie uruchamia się w stałym punkcie, za każdym razem, niezależnie od tego, czy Bob uznał to za istotne. Zobacz dokumentację hook'ów.
Skill'e są często używane jako przewodniki, ale skill uruchamiający recenzję jest czujnikiem i to najprostszy sposób na dodanie niedeterministycznego sprawdzenia. Zobacz dokumentację skill'ów.
Continuous integration (CI) umieszcza agenta recenzującego w pipeline'ie, przy każdym pull request, dla całego zespołu, a nie tylko jednego dewelopera. Zobacz agenta recenzującego PR w akcji.

Szczegółowe omówienie: Uruchom cykl

Granice faz są też granicami kontekstu, co jest praktycznym powodem, by je rozróżniać: gadanina eksploracyjna nie ma czego szukać w konwersacji, gdzie pisany jest kod.

1. Eksploracja

Eksploracja różni się znacznie w zależności od roli i zadania. Może oznaczać onboarding do nowej bazy kodu lub szacowanie zasięgu zmian przy poważnym refaktoringu. Kilka przykładów:

Poproś Boba o diagram architektury istniejącego systemu przed wprowadzeniem jakichkolwiek zmian. Zobacz tutorial generowania diagramów architektury lub to samo na wideo.
Poproś o spersonalizowany przewodnik wprowadzający z dwóch perspektyw — raz jako użytkownik poruszający się przez produkt i raz jako deweloper poruszający się przez kod. Podanie informacji o swoim doświadczeniu i zadaniu pomaga dostosować dokument (inspekcja bazy kodu).
Na IBM Z i IBM i skorzystaj z opcji specyficznych dla platformy. Problem eksploracji na tych systemach jest inny i bardzo korzysta ze specjalistycznych narzędzi dostępnych w pakietach premium. Zobacz Premium Package for Z (docs) oraz Premium Package for IBM i (docs).

Eksploracja może obejmować też budowanie rzeczy, które zamierzasz usunąć. Implementacja jest teraz tania, więc wąski prototyp to najszybszy sposób na sprawdzenie, czy podejście przetrwa kontakt z bazą kodu. Kent Beck nazwał to spike implementation dwadzieścia pięć lat temu, a dyscyplina jest ta sama: buduj, żeby się czegoś nauczyć, zachowaj naukę, wyrzuć kod.

Tania implementacja podnosi wartość architektury i jakości kodu, a nie ją obniża. Teraz łatwo wyprodukować dużą ilość kodu, który działa i jest błędny.

2. Planowanie

Faza planowania to miejsce największej dźwigni. Wszystko, co plan zrobi dobrze, opłaci się dwa razy: raz podczas implementacji i ponownie, gdy zmiana opuści ręce autora i kolega będzie musiał ją przejrzeć.

Czego potrzebuje dobry plan:

Krótki i precyzyjny, jednocześnie. Plany muszą być czytelne.
Jasno określający zamierzony wynik, włącznie z niepewnymi częściami. Wiedza o tym, co jest nieznane, to większość pracy, a odkrycie tego — reszta.
W pliku. Plany nie powinny żyć w sesji czatu.

Jest wiele sposobów na stworzenie planu, ale zintegrowany tryb Plan jest najłatwiejszym miejscem do rozpoczęcia (jak w tym tutorialu). Tryb Plan jest zbudowany tak, by być ugodowy i ma tendencję do wypełniania luk. Choć umożliwia to szybkie iteracje w wielu przypadkach, czasem potrzebna jest większa rygorystyczność. Może zbudować kompetentny plan wokół błędnego założenia bez kwestionowania tego założenia. Dedykowany skill kłócący się z planem — grill-me autorstwa Matta Pocka na przykład — to najtańszy sposób na uzyskanie weryfikacji przed zamianą założenia w kod.

O spec-driven development (SDD). Termin obejmuje wiele obszarów i wciąż ewoluuje. Ludzie traktują go jako decyzję zero-jedynkową, ale bliżej mu do spektrum:

Spec-first: plan poprzedza implementację. To prawie bezwarunkowo konieczne.
Spec-anchored: spec pozostaje po implementacji, jako dokumentacja i standard, któremu implementacje muszą odpowiadać.
Spec-as-source: spec jest plikiem źródłowym. Człowiek edytuje spec; człowiek nie edytuje kodu.

Odpowiedni poziom zależy od zespołu, krytyczności/dojrzałości bazy kodu i branży. Narzut wyższy poziomów SDD może być bolesny przy szybkich iteracjach. W branży motoryzacyjnej, gdzie spec-driven development poprzedza AI o dekady, SDD dobrze wpasowuje się w istniejące praktyki.

3. Implementacja

Implementacja to prosta faza i Bob radzi sobie z prawie całą jej częścią.

Obserwowanie pracy Boba i przerywanie w celu doprecyzowania jest opcjonalne i często przydatne. Traktuj częstotliwość jako sygnał: ciągłe przerywanie oznacza, że problem leży w planie, a rozwiązaniem jest cofnięcie się, a nie ciągłe poprawianie.

Nie wahaj się wyrzucić całej implementacji i wrócić do trybu Plan. Kod jest tą tanią częścią.

4. Weryfikacja

Weryfikacja dzieli się na dwie odrębne kategorie: weryfikację automatyczną i weryfikację ręczną.

Weryfikacja automatyczna jest napędzana przez czujniki dostępne Bobowi lub egzekwowane przez hook'i. Są wykonywane często podczas fazy implementacji bez interwencji człowieka. Główne kategorie z przykładami:

Poprawność: Czy kompiluje się, przechodzi type check, parsuje?
- Mierzone: pass/fail, pokrycie typów
- Narzędzia: tsc, mypy, cargo check, javac
Zachowanie: Czy robi to, co powinno?
- Mierzone: wskaźnik pass rate, pokrycie gałęzi
- Testy jednostkowe, integracyjne, end-to-end
- Narzędzia: pytest, Jest, Playwright, Stryker
Utrzymywalność: Czy ten kod warto zachować?
- Mierzone: złożoność, duplikacja, naruszenia granic
- Narzędzia: ESLint, Ruff, Lizard, ArchUnit
Bezpieczeństwo: Czy ten kod jest bezpieczny?
- Mierzone: znaleziska według wagi, CVEs
- Narzędzia: Semgrep, CodeQL, gitleaks, npm audit

Pozwalają Bobowi wychwytywać własne błędy i poprawiać jakość podczas fazy implementacji. Dobre pokrycie testami to zasadnicza ochrona przed regresją: zapewnia, że Bob niczego nie popsuł.

W tym cyklu weryfikacja jest wymieniona jako osobna faza na końcu pętli, co odnosi się głównie do weryfikacji ręcznej. Weryfikacja ręczna zaczyna się od uruchomienia zmiany i porównania obserwowanego zachowania z zachowaniem opisanym w planie. Niezgodność zazwyczaj sprowadza się do jednej z dwóch przyczyn:

Implementacja odeszła od planu. Naprawa jest w kodzie.
Plan nie odzwierciedla tego, co zamierzałeś zbudować. Plan wymaga doprecyzowania. To jest znacznie częstsze.

Ręczna inspekcja testuje więc plan i implementację jednocześnie.

Dodatkowa weryfikacja powinna odbywać się w pipeline'ach CI/CD. To ugruntowana praktyka w inżynierii oprogramowania, którą można udoskonalić przez użycie headless coding agentów. Jeden przykład: automatyczna recenzja przy każdym pull request, uruchomiona przez Bob Shell, uzupełnia recenzentów-ludzi zamiast ich zastępować. Zobacz wideo agenta recenzującego PR w akcji oraz dokumentację uruchamiania Bob Shell nieinteraktywnie.

Praca w zespole

Wszystko opisane w poprzednich sekcjach dotyczy wewnętrznej pętli jednego dewelopera. Zewnętrzna pętla zaczyna się, gdy zmiany trafiają do kolejki recenzji. Każdy diff teraz dociera szybciej i z mniejszą ilością dołączonego rozumowania, podczas gdy recenzent ma więcej do przeczytania i mniej kontekstu, w którym to czyta.

Dowody muszą podróżować razem z pracą. Dlaczego ma teraz większe znaczenie niż jak, ponieważ jak nie jest już kosztowną częścią do wyprodukowania.

W praktyce oznacza to, że plan podróżuje razem ze zmianą: zespoły dołączają go do pull request lub dodają z powrotem do oryginalnego zgłoszenia obok recenzji. Mechanizm zależy od narzędzi.

To, co zewnętrzna pętla robi z procesem zespołu, to temat sam w sobie i będzie przedmiotem późniejszego wpisu.

Kilka przemyśleń na temat promptowania

W ostatnich latach duży nacisk kładziono na właściwe promptowanie LLM-ów, z czego wyłoniła się nawet cała kategoria stanowisk „prompt engineer". Obecnie duża część promptowania jest obsługiwana wewnątrz harnessu. Znaczenie wyspecjalizowanych technik promptowania zmalało na rzecz podejścia metodologicznego. Oto kilka wskazówek:

Iterowanie bije promptowanie. Gdy Bob robi coś innego niż prosiłeś, cofnij i przepisz wiadomość, która to spowodowała. Poprawianie do przodu zostawia błędną odpowiedź, skargę na nią i ponowną próbę — wszystko w oknie.
Metodologia bije promptowanie. Prompt jest ograniczony do jednej sesji. Plik reguł lub sprawdzenie, które Bob może uruchomić sam, działa w każdej sesji po tej, która je stworzyła, a to jedyny rodzaj inwestycji, która się tu akumuluje.
Daj Bobowi brief, który dostałby starszy inżynier. Kompetentny kolega otrzymawszy niejasne zadanie zapyta, co oznacza „gotowe" i czego może dotykać; Bob nie zapyta, więc umieść oboje w wiadomości.
Mów, co robić, nie czego nie robić. „Nie używaj komponentów klasowych" wyklucza jedną opcję i zostawia resztę przestrzeni otwartą, więc Bob wybiera spośród tego, co zostało — czyli kolejne zgadywanie. Podanie celu zamiast — komponenty funkcyjne z hooks — zamyka to w jednej turze.
Każda instrukcja powtórzona więcej niż dwa razy należy do pliku. Do tego służą agents.md i skill'e.
Bardziej szczegółowe instrukcje promptowania można znaleźć w tutorialu pisania skutecznych promptów.

Kluczowe wnioski

Brak struktury to największy problem. Przestrzeganie cyklu Eksploracja → Planowanie → Implementacja → Weryfikacja pomaga zachować skupienie i szybciej oraz konsekwentniej osiągać cele.
Kontekst jest zasobem deficytowym, a fazy są granicami kontekstu. Nie przenoś eksploracyjnej gadaniny do implementacji.
Plan jest artefaktem recenzji. Przeglądanie planu bije przeglądanie diffa — dla autora i dla recenzenta.
Wszystko warte zachowania opuszcza czat. Plany, decyzje i ustalenia należą do pliku. Plik można diffować, recenzować, wersjonować i przekazać innemu agentowi.
Weryfikacja powinna być uruchamialna maszynowo, co oznacza, że musisz ją zaprojektować podczas planowania, a nie odkrywać po fakcie.

Źródła i dalsze lektury

Simon Willison, Agentic engineering patterns
Birgitta Böckeler, Harness engineering

Dokumentacja i tutoriale IBM Bob: