Zasady pracy z agentami programistycznymi

Zasady z tej sekcji to niezależne od narzędzia reguły budowania oprogramowania z agentami AI: agent pracuje w trybie tylko do odczytu, dopóki plan nie zostanie zaakceptowany, „gotowe” definiuje nieprzechodzący test, każdy błąd staje się kolejną specyfikacją, zmiany idą partiami na tyle małymi, by CI mogło je udowodnić, a ocena człowieka działa na czterech bramkach zamiast w każdym diffie.

Ten przegląd jest dla programistów, którzy codziennie uruchamiają agentów, i dla tech leadów, którzy ustalają domyślne zasady zespołu. Sytuacja, na którą odpowiada: agent oddaje ci 1200 zielonych linii w 18 plikach, a jedyne opcje wydają się dwie — „przeczytać wszystko” albo „zaufać”. Flagi i modele zmieniają się z każdym wydaniem; te reguły nie, a każda z nich usuwa jeden powód, by czytać cały diff.

Która zasada rozwiązuje twój problem?

Zacznij od objawu, nie od listy stron.

Objaw, który znasz	Zasada	Strona
Agent zmienił kod, choć tylko zadałeś pytanie	Tylko odczyt, dopóki plan nie zostanie zaakceptowany	Tryb agenta czy tryb zapytań
Wynik „wygląda dobrze”, ale nic nie mówi, co znaczy „poprawnie”	Najpierw nieprzechodzący test	Programowanie sterowane testami
Kolejne próby naprawy krążą wokół tego samego błędu	Każdy błąd to następna specyfikacja, w ograniczonej pętli	Programowanie sterowane błędami
Pull requesty są za duże, by je przejrzeć lub podzielić	Jedno zadanie na commit, limit rozmiaru pilnowany przez CI	Ciągła dostawa
Code review to wąskie gardło albo akceptacje są odruchowe	Ocena człowieka na czterech bramkach: intencja, specyfikacja, dowody, klasa ryzyka	Człowiek w pętli
Czterdzieści PR-ów od agentów tygodniowo i dwóch recenzentów	Autonomię zdobywa się pętla po pętli, w granicach zaufanej wyroczni	Fabryki oprogramowania
Agent wciąż wybiera rozwiązania, których nigdy byś nie wdrożył	Ograniczenia, przykład, plan przed wykonaniem	Techniki promptowania

Pliki, które powstają dzięki tym zasadom (intent.md, spec.md, plan.md), są zdefiniowane w jednym miejscu: w łańcuchu artefaktów.

Zastosuj zasady w następnym zadaniu dla agenta

Zacznij w trybie tylko do odczytu i poproś o plan, który wymienia pliki, kolejność pracy i testy dowodzące każdego kroku.
Uruchom claude --permission-mode plan albo wpisz /plan w trwającej sesji.

Wpisz /plan w terminalowym interfejsie Codeksa, zanim opiszesz zmianę.

Przełącz agenta na Plan Mode, zanim opiszesz zmianę.
Pozostałe kroki wyglądają tak samo w Claude Code, Codeksie i Cursorze.
Zaakceptuj plan, a potem każ agentowi najpierw napisać testy i pokazać, że nie przechodzą z właściwego powodu.
Daj agentowi jedno polecenie sprawdzające, na przykład npm run typecheck && npm run lint && npm test, i wymagaj jego wyniku, zanim zgłosi koniec pracy.
Commituj po każdym zadaniu z planu i zakończ sesję, gdy diff dojdzie do limitu rozmiaru przyjętego w zespole.
Otwórz pull request z dołączonymi dowodami i ustaw klasę ryzyka, która decyduje, czy ktoś czyta kod.

Stay read-only until I approve a plan. First, write a plan that lists
the files you will change, the order of work, and the tests that prove
each step. After I approve it: write the tests first and show me they
fail for the reason the plan predicts; then implement one step at a time,
run `npm run typecheck && npm run lint && npm test` after each step, and
commit each passing step separately. If the same check fails three times
in a row, stop and report the error instead of editing tests or config.

Audit this repository for how it constrains coding agents. For each rule
below, report the file, hook or CI job that enforces it, or "not enforced":
1. Agents plan before they edit (instructions file, permission settings).
2. New behaviour arrives with a test that failed first.
3. One check command exists and runs in CI.
4. Pull request size is limited by a CI check.
5. Changes to auth, payments, schema or migrations route to a named
   reviewer (CODEOWNERS, branch protection).
Use only what exists in the repository and git history. End with the one
unenforced rule whose fix is smallest, and propose that fix as a diff.

Jak udowodnić, że zasady są przestrzegane?

Zasada, która żyje tylko na wiki, nie zmienia zachowania agenta. Każda zyskuje zaufanie dopiero wtedy, gdy sprawdza ją maszyna, a za wyjątki odpowiada konkretna osoba:

Najpierw testy: CI pokazuje, że nowy test nie przechodzi na commicie bazowym i przechodzi na gałęzi; ochrona wyroczni nie pozwala agentowi edytować testów, którymi jest oceniany.
Małe partie: job w CI odrzuca każdy pull request powyżej limitu rozmiaru.
Dowody zamiast czytania: każdy pull request agenta zawiera manifest z pakietu dowodów: zmianę w specyfikacji, wyniki kryteriów akceptacji, wynik sprawdzeń i klasę ryzyka.
Akceptacja człowieka: tech lead akceptuje specyfikację, wskazany recenzent scala zmianę, a czytanie kodu zostaje dla klas eskalacji opisanych w czytaniu dowodów zamiast kodu.

Co się psuje, gdy zespół wdraża te zasady?

Zasady zostają prozą. Agent nie czyta twojej wiki. Jak naprawić: zapisz reguły w CLAUDE.md, AGENTS.md albo w regułach Cursora i podeprzyj każdą hookiem lub sprawdzeniem w CI.
Agent przechodzi testy, osłabiając je. Czerwony build robi się zielony, bo zniknęła asercja. Jak naprawić: gdy zaakceptujesz nieprzechodzące testy, zablokuj agentowi zapis w tych plikach, wymagaj akceptacji z CODEOWNERS i uruchamiaj decydujące sprawdzenie w CI na testach z gałęzi bazowej. W Claude Code blokadą jest reguła permissions.deny albo hook PreToolUse, a wpis w CODEOWNERS działa niezależnie od narzędzia; blokady dla Codeksa i Cursora opisuje strona o ochronie wyroczni. Na co uważać, pokazuje lista wzorców osłabiania testów na stronie o TDD.
Autonomię się ogłasza, zamiast ją zdobywać. Zespół przełącza wszystkie repozytoria naraz na przebiegi bez nadzoru. Jak naprawić: podnoś autonomię pętla po pętli i tylko tam, gdzie wyrocznia jest mocna, tak jak opisują to fabryki oprogramowania.
Bramki stają się pieczątką. Akceptacje przychodzą w kilka sekund. Jak naprawić: każda bramka sprawdza konkretny dowód, a stopniowe przekazanie zaufania opisuje strona Jak pomóc zespołowi przestać czytać każdy diff.

Strony zasad, po jednej na regułę

Fabryki oprogramowania Odmierzaj autonomię pętla po pętli, zamiast ogłaszać ją dla całej fabryki.

Człowiek w pętli Cztery bramki dla ludzkiej oceny; czytanie kodu dla klas eskalacji.

Programowanie sterowane testami Nieprzechodzący test jako cel, którego agent nie obejdzie.

Programowanie sterowane błędami Ograniczona pętla błąd–poprawka–ponowne uruchomienie i dowód, że doprowadziła do zielonego wyniku.

Ciągła dostawa Jedno zadanie na commit, limit rozmiaru PR, flagi funkcji (feature flags) między wdrożeniem a udostępnieniem.

Tryb agenta czy tryb zapytań Kiedy zostać przy odczycie, kiedy dać prawo zapisu, kiedy puścić agenta bez nadzoru.

Techniki promptowania Ograniczenia, przykłady i prompty „najpierw plan”, które sterują agentem.

Dokąd dalej z zasadami

Dopiero zaczynasz? Zacznij od przeglądu metody. Żeby zobaczyć zasady w działaniu jako jeden proces, przeczytaj o cyklu życia oprogramowania AI-native i przeprowadź zmianę przez łańcuch artefaktów. Żeby umiejscowić obecną praktykę zespołu, skorzystaj z jednej mapy. Gotową metodykę innego autora, zbudowaną na tych samych ideach, opisuje strona o compound engineering.