Poproś agenta CLI do kodowania o naprawienie failującego testu, a nie odpowie ci sugestią. Odczyta wynik testu, otworzy plik, zmieni linijkę, uruchomi test ponownie i zgłosi się z powrotem, dopiero gdy przejdzie. Ta pętla jest produktem, nie okno czatu.
Model wewnątrz pętli przyciąga najwięcej uwagi i to też ta część, która zmienia się najszybciej: dostawcy podmieniają go co kilka miesięcy, a wielu agentów pozwala go samemu wybrać. To, co zostaje na miejscu, to harness owinięty wokół modelu — do jakich narzędzi ma dostęp, jak zarządza kontekstem, co może uruchomić bez pytania i gdzie te komendy się wykonują. Dwaj agenci na tym samym modelu mogą zachowywać się zupełnie inaczej właśnie przez to. Harness to jest to, co naprawdę wybierasz.
Jak działa pętla agentowa
Zdejmij branding i każdy agent CLI do kodowania kręci tym samym cyklem:
- Model dostaje twoje polecenie plus cały kontekst, jaki zebrał harness: otwarte pliki, świeży output z shella, instrukcje projektu.
- Zamiast tylko pisać tekst, model może wyemitować wywołanie narzędzia: “uruchom tę komendę shella”, “zapisz te bajty do tego pliku”, “znajdź ten wzorzec”.
- Harness wykonuje to wywołanie naprawdę, na twoim rzeczywistym systemie plików albo w shellu, i wynik wraca do kontekstu modelu.
- Model czyta wynik i decyduje, co zrobić dalej: wywołać kolejne narzędzie albo odpowiedzieć tobie.
To powtarza się, aż model uzna, że zadanie jest skończone. Nie potrzebuje gotowego planu, zanim zacznie działać. Uruchamia komendę, czyta, co się stało, i dostosowuje się — dlatego też agent potrafi zużyć dziesiątki wywołań narzędzi na zadaniu, które finalnie okazało się proste.
Nic z tego nie wymaga nowej architektury modelu. Wymaga modelu, który dobrze wybiera, które narzędzie wywołać i kiedy przestać, oraz harnessu, który daje mu narzędzia warte wywołania.
Jakie narzędzia dostaje agent do kodowania
Wbudowana lista narzędzi jest krótka i nudna: odczyt pliku, zapis albo edycja pliku, uruchomienie komendy shella, przeszukanie kodu po nazwie pliku albo po treści, a w wielu agentach też pobranie adresu URL albo sterowanie przeglądarką. Refaktoring, debugowanie, pisanie testów, czytanie stack trace’a: to wszystko model składa z tych prymitywów, nie jest to osobna funkcja zbudowana przez dostawcę.
Decyzje projektowe, które naprawdę mają znaczenie, siedzą w szczegółach. Czy “edytuj plik” wymaga dokładnego dopasowania stringa do aktualnej zawartości, co jest bezpieczniejsze i łatwiejsze do zrecenzowania, czy model może nadpisać cały plik, co jest szybsze i łatwiej się na tym pomylić? Czy “uruchom komendę shella” wykonuje się bezpośrednio, czy wewnątrz sandboxa, który blokuje dostęp do sieci i zapis poza projektem? Postaw ten sam model za różnymi odpowiedziami na te dwa pytania, a dostaniesz agentów, które nie mają ze sobą nic wspólnego.
Jak agenci do kodowania radzą sobie z kontekstem większym niż okno
Prawdziwy kod nie mieści się w oknie kontekstu, a długa sesja produkuje o wiele więcej outputu z narzędzi, niż ktokolwiek wkleiłby do prompta. Agenci łączą kilka technik, żeby sobie z tym poradzić:
- Selektywne czytanie. Agent szuka konkretnego pliku albo funkcji zamiast
ładować całe repozytorium — ten sam odruch, który masz sam, gdy robisz
grep, zanim zrobiszcat. - Kompakcja. Gdy rozmowa przekroczy pewien próg rozmiaru, harness streszcza wcześniejsze tury do krótszej formy i dalej pracuje z niej, zamieniając szczegóły na miejsce.
- Subagenci. Duże zadanie dzieli się na mniejsze, każde trafia do osobnego wywołania modelu, z samym kontekstem, jakiego potrzebuje. Do głównej rozmowy wraca tylko wynik.
- Retrieval. Część agentów indeksuje kod i używa tego samego wzorca retrievalu, na którym stoi RAG, żeby wciągnąć tylko fragmenty istotne dla aktualnego pytania. Inne pomijają indeks i polegają wyłącznie na wyszukiwaniu.
Kompakcja jest tym elementem, który najbardziej boli. Szczegół z początku sesji, na przykład flaga, o której wspomniałeś raz, może wypaść ze streszczenia. Jeśli agent zaczyna ignorować coś, co powiedziałeś mu godzinę wcześniej, to zwykle właśnie ta przyczyna, a świeża sesja z przypomnianymi kluczowymi faktami to naprawia.
Co agent do kodowania może uruchomić bez pytania
Harness decyduje, jak daleko agent zajdzie, zanim się zatrzyma i zapyta. Na jednym końcu skali każda edycja pliku i każda komenda shella czeka na twoją zgodę. Bezpiecznie, ale wolno: agent nieustannie ci przerywa. Na drugim końcu agent działa w środowisku sandboxowym bez nikogo, kto patrzy, co pasuje do pracy w tle, jak naprawienie niestabilnego testu i otwarcie pull requesta, podczas gdy ty robisz coś innego.
Większość codziennego użycia mieści się gdzieś pośrodku. Akcje tylko do odczytu, jak przeszukiwanie i otwieranie plików, dzieją się automatycznie. Wszystko destrukcyjne albo skierowane na zewnątrz, jak usunięcie pliku albo push do zdalnego repozytorium, czeka na zgodę.
To polityka wymuszana przez harness, nie właściwość modelu. Ten sam model jest ostrożny albo lekkomyślny, zależnie od tego, co wolno mu zrobić bez nadzoru.
Jak MCP daje agentowi nowe narzędzia
Wbudowane narzędzia pokrywają system plików i shell, ale prawdziwa praca często potrzebuje więcej: zapytania do wewnętrznej bazy danych albo otworzenia ticketu w twoim issue trackerze. Model Context Protocol (MCP) to otwarty standard, który daje to bez pisania przez każdego dostawcę agenta osobnej integracji dla każdej usługi.
Serwer MCP opisuje narzędzia, jakie oferuje, i sposób ich wywołania. Każdy
agent kompatybilny z MCP może się połączyć, zobaczyć listę tych narzędzi i
wywołać je dokładnie tak samo jak swoje wbudowane. Agent nie potrzebuje
kodu specyficznego dla usługi: czyta opisy narzędzi i decyduje, kiedy się
przydają, tak samo jak decyduje, kiedy uruchomić grep.
Kosztem jest kontekst. W wielu agentach opisy narzędzi każdego podłączonego serwera zajmują miejsce w oknie przy każdej turze, więc tuzin serwerów, z których rzadko korzystasz, obciąża każde żądanie. Podłączaj te, których projekt naprawdę potrzebuje.
Co robią pliki AGENTS.md i CLAUDE.md
Niemal każdy agent szuka pliku instrukcji w markdown u korzenia repozytorium
i czyta go, zanim zrobi cokolwiek innego. AGENTS.md to konwencja neutralna
wobec dostawcy; niektóre narzędzia używają własnej nazwy, jak CLAUDE.md.
To miejsce, gdzie piszesz to, czego model nie wywnioskuje z samego kodu:
która komenda uruchamia testy i które katalogi są generowane i nie wolno ich
ręcznie edytować. Wszystko, co agent musiałby inaczej zgadywać — i zgadnąć
źle — trafia tutaj.
Wielu agentów czyta też pliki instrukcji w podkatalogach, więc monorepo może mieć plik główny plus bardziej szczegółowy dla każdego pakietu. Czy głębszy plik nadpisuje ten z korzenia, czy się do niego dodaje, zależy od narzędzia — sprawdź dokumentację tego, którego używasz.
Dziesięć linijek w tym pliku oszczędza agentowi odkrywania na nowo twojej komendy do testów przy każdej sesji.
Jak porównywać agentów CLI do kodowania
Gdy pętla i lista narzędzi są wszędzie te same, listy funkcji przestają wiele mówić. Te cztery pytania odróżniają narzędzia w sposób, który realnie wpływa na twój dzień:
| Pytanie | Co to dla ciebie znaczy |
|---|---|
| Gdzie działa: w terminalu, w IDE czy w tle? | Agent terminalowy żyje w twoim shellu i pracuje obok dowolnego edytora. Agent w IDE podpina się pod widok diffów i historię cofania edytora. Agent działający w tle pracuje bez nadzoru na podstawie opisu zadania i oddaje ci pull request, co pasuje do dobrze opisanej pracy z backlogu bardziej niż do interaktywnego debugowania. |
| Harness jest open source czy zamknięty? | Otwarty harness, jak OpenCode albo Aider, można wskazać na dowolny model, do którego masz dostęp przez API, w tym na taki, który uruchomisz lokalnie przez Ollama, i można dokładnie przeczytać, co robi. Zamknięty harness jest zwykle dostrojony pod modele własnego dostawcy i wymaga mniej konfiguracji. |
| Jak płacisz: za token przez API czy w subskrypcji? | Rozliczenie za token śledzi zużycie, więc długie autonomiczne sesje kosztują najwięcej. Subskrypcja ogranicza wydatki, ale dokłada limity użycia i wiąże cię z modelami jednego dostawcy. |
| Jak głęboki jest sandbox? | Część agentów uruchamia komendy bezpośrednio na twojej maszynie; inne zawsze wykonują je w kontenerze albo VM, ten sam rodzaj izolacji, jaki dają kontenery Docker. Bezpośrednie wykonanie nie wymaga konfiguracji i jest ryzykowniejszym wyborem dla wszystkiego, co zostaje puszczone bez nadzoru. |
Klasyfikuj tryb, nie markę. Jeden dostawca często ma narzędzie terminalowe, rozszerzenie do edytora i tryb chmurowy, który otwiera pull requesty; Claude Code i OpenAI Codex działają dokładnie tak. Domyślne ustawienia uprawnień i sandboxa różnią się między tymi trybami, więc oceniaj ten, którego faktycznie będziesz używać.
Jak wybrać agenta CLI do kodowania dla swojego workflow
Pomiń rankingi. Wyniki benchmarków zmieniają się co kilka tygodni i niewiele mówią o twoim repozytorium. Odpowiedz zamiast tego na dwa pytania: czy chcesz agenta w terminalu czy w edytorze, i czy chcesz, żeby pracował bez nadzoru w tle, czy w pętli z twoją akceptacją każdego kroku. Te odpowiedzi zawężają pole do dwóch, trzech kandydatów.
Potem napisz AGENTS.md dla swojego projektu, daj każdemu kandydatowi to
samo prawdziwe zadanie z backlogu i zostaw tego, którego diff scaliłbyś z
najmniejszą liczbą poprawek.