Przestań pisać prompty ręcznie. Jak zamienić agentów AI w autonomiczną linię produkcyjną
Szef rozwoju Claude Code w Anthropic, Boris Cherni, przyznał kiedyś, że nie pisze już prompty ręcznie. Zamiast tego uruchamia automatyczne pętle, które tworzą zadania dla Claude, uruchamiają go i weryfikują wyniki samodzielnie. Napisanie prompta raz nie jest problemem. Ale jeśli codziennie przekazujesz te same instrukcje asystentowi AI — czy to sprawdzając CI, czy sortując błędy — wykonujesz rutynową pracę.
Developer Kobus Greyling opublikował projekt o nazwie loop-engineering na GitHubie, który proponuje zmianę podejścia. Przestań być operatorem czatu i zostań projektantem autonomicznych systemów. Projekt zdobył ponad 10 000 gwiazdek i jest tu naprawdę nad czym się zastanowić.
Od jednorazowych sesji do zamkniętych pętli
Główny problem typowych interakcji z agentami kodującymi takimi jak Claude Code, Grok czy Cursor tkwi w kontekście. Otwierasz dialog, wyjaśniasz strukturę projektu, dajesz zadanie i czekasz na wynik. Sesja się zamyka — kontekst jest tracony. Następnego dnia wszystko zaczyna się od nowa.
Koncepcja Loop Engineering proponuje zamknięcie procesu w nieskończoną pętlę. Agent działa według harmonogramu, odczytuje stan repozytorium z specjalnego pliku, wykonuje pracę w izolowanej gałęzi, uruchamia testy i aktualizuje statusy.
flowchart LR
A[Schedule / Automation] --> B[Triage Skill]
B --> C[Read + Write STATE / Memory]
C --> D[Isolated Worktree]
D --> E[Implementer Sub-agent]
E --> F[Verifier Sub-agent]
F --> G[MCP / Git / Tickets]
Nie musisz pisać złożonych frameworków Pythona. Architektura pętli składa się z kilku zrozumiałych elementów:
- Zaplanowane wykonanie przez cron, GitHub Actions lub systemd.
- Stan projektu w zwykłym pliku Markdown
STATE.md, który znajduje się w korzeniu repozytorium i przetrwa każde ponowne uruchomienie agenta. - Izolowane gałęzie Git worktree, aby zmiany agenta nie psuły bieżącej kopii roboczej.
- Rozdzielenie agentów na wykonawcę i sprawdzającego (Maker / Checker). Jeden pisze kod, drugi uruchamia testy i sprawdza lintery.
Co jest w środku repozytorium
Projekt składa się z zestawu narzędzi CLI opublikowanych w npm oraz katalogu gotowych scenariuszy. Wszystkie narzędzia są połączone w jednym pakiecie, więc nic nie trzeba klonować.
Możesz wdrożyć szablon do istniejącego projektu jednym poleceniem:
npx @cobusgreyling/loop init . --pattern daily-triage --tool grok
Po inicjalizacji narzędzie tworzy pliki umiejętności, strukturę przechowywania stanu i wyświetla wskaźnik gotowości projektu — wynik Loop Ready.
Aby sprawdzić kondycję powstałego systemu, użyj polecenia doctor:
npx @cobusgreyling/loop doctor .
To polecenie znajduje problemy z konfiguracją i wyświetla trzy główne kroki poprawy. Na przykład zasugeruje dodanie limitów budżetu tokenów lub skonfigurowanie ścieżek zabronionych do edycji.
Zestaw narzędzi zawiera również funkcje loop-cost do szacowania kosztów tokenów, loop-sync do wyszukiwania rozbieżności między opisem pętli a plikiem stanu oraz loop-worktree do bezpiecznego tworzenia oddzielnych gałęzi dla każdej próby naprawy.
Siedem gotowych szablonów
Repozytorium zawiera szablony typowych zadań deweloperskich.
Każdy wzorzec jest opisany z podziałem kosztów tokenów i zalecanym trybem implementacji:
- Codzienna segregacja. Raz dziennie skanuje repozytorium, zbiera problemy i aktualizuje
STATE.md. - Opiekun PR. Monitoruje otwarte pull requesty, sprawdza statusy testów i zostawia wskazówki dla autorów.
- Zamiatacz CI. Przechwytuje nieudane buildy CI i próbuje naprawić nieudane testy w oddzielnej gałęzi.
- Zamiatacz zależności. Aktualizuje zależne biblioteki i weryfikuje, że projekt się buduje.
- Szkicownik changeloga. Zbiera szkic changeloga przed nowym wydaniem.
- Sprzątanie po merge. Usuwa przestarzałe gałęzie i pliki tymczasowe po scaleniu.
- Segregacja issue. Przegląda nowe zgłoszenia w trackerze i sugeruje etykiety lub wstępne odpowiedzi.
Autor zaleca implementację pętli stopniowo. Najpierw uruchom agenta w trybie tylko do odczytu (L1), gdzie generuje tylko raporty. Gdy będziesz pewny dokładności jego wniosków, możesz przejść do trybu potwierdzania (L2), a dopiero potem powierzyć drobne rutyny pełnej autonomii (L3).
Mroczna strona autonomii
Kobus Greyling szczerze analizuje ryzyka autonomicznych agentów. Jeśli uruchomisz pętlę z sub-agentami bez ograniczeń, rachunek za LLM API będzie zaskakująco nieprzyjemny. Powtarzające się żądania w nieskończonej pętli mogą spalić setki dolarów w ciągu kilku godzin.
Drugie ryzyko nazywa się długiem zrozumienia. Jeśli agent sam pisze patche, sam uruchamia testy i sam scala kod do main, zespół szybko traci kontrolę nad architekturą. Projekt staje się czarną skrzynką.
Ponadto cała weryfikacja pozostaje twoją odpowiedzialnością. Agent nie ma zdrowego rozsądku i spróbuje zamknąć test za wszelką cenę, nawet jeśli oznacza to usunięcie samego testu.
Kto powinien spróbować
Repozytorium będzie przydatne dla zespołów, które aktywnie korzystają z narzędzi AI wiersza poleceń, takich jak Claude Code czy Grok, i szukają sposobu na systematyczną integrację z CI/CD.
Zacznij mało. Zainstaluj loop init, wybierz scenariusz daily-triage i pozwól agentowi przez tydzień tylko pisać dzienne raporty do STATE.md. To bezpieczny sposób, aby zrozumieć, jak dobrze koncepcja pasuje do twojego projektu, nie ryzykując stabilności twojego kodu.
Powiązane projekty