Metoda: najpierw specyfikacja i weryfikacja, potem delegowanie

Metoda, na której stoją wszystkie przepływy pracy w tym serwisie, ma trzy zasady: zanim powstanie kod, każda zmiana trafia do repozytorium jako łańcuch commitowanych artefaktów; zanim agent dostanie więcej autonomii, muszą istnieć kontrole (testy, lintery, bramki typów), które potrafią wykryć błąd; a ludzie oceniają na bramkach intencję, specyfikację i dowody zamiast każdego diffa. Działa tak samo w Claude Code, Codeksie i Cursorze.

Dałeś agentowi zgłoszenie, dostałeś 400 wiarygodnie wyglądających linii i teraz musisz albo przeczytać wszystkie, albo scalić na wiarę. Czytanie każdej linii ogranicza przepustowość do tempa twojego czytania; scalanie na wiarę wypuszcza błąd, którego żaden test nie szukał. Metoda przesuwa twoją uwagę wcześniej, na specyfikację, i później, na dowody.

Jakie są trzy zasady metody?

1. Najpierw specyfikacja, potem generowanie. Każda zmiana przechodzi przez łańcuch artefaktów: intent.md, spec.md, plan.md, diff z wynikami testów i wyniki review. Wskazana osoba akceptuje każdy plik, zanim przeczyta go kolejny etap.
2. Najpierw weryfikacja, potem autonomia. Pozwól agentowi działać dłużej lub bez nadzoru dopiero wtedy, gdy istnieje kontrola, która zaświeci się na czerwono przy złym zachowaniu: test napisany jako pierwszy i niezaliczony, kryteria akceptacji zmapowane na testy oraz wyrocznia, której agent nie może edytować. Jeśli nie potrafisz wskazać takiej kontroli, trzymaj agenta krótko. Jak to zmierzyć, pokazuje strona Jak silna jest twoja wyrocznia?.
3. Oceniaj na bramkach, a nie linia po linii. Ludzie czytają intencję, specyfikację, pakiet dowodów i klasę ryzyka. Kod czyta człowiek tylko w klasach eskalacji wymienionych na stronie Czytanie dowodów zamiast kodu: uwierzytelnianie, pieniądze, schematy, migracje danych, same testy i wszystko, czego nie obejmuje żadna kontrola.

Drabina autonomii opisuje, w którym miejscu tej drogi jest twój zespół, a cykl życia AI-native realizuje te trzy zasady jako sześć etapów w pętli.

Jak każde narzędzie realizuje planowanie, wykonanie i weryfikację?

Dyscyplina jest ta sama; różnią się mechanizmy sterowania.

Claude Code

Planuj w trybie tylko do odczytu: claude --permission-mode plan, /plan lub Shift+Tab. Wykonuj w trybie Manual (zatwierdzasz każdą edycję i polecenie) albo acceptEdits. Od v2.1.283 na kanale latest sesje interaktywne startują w trybie auto, w którym każdą akcję ocenia klasyfikator (z wyjątkiem modeli, których tryb auto nie obsługuje, oraz sesji, w których ustawienia włączają disableAutoMode); tryb zmienisz przez Shift+Tab. Weryfikuj hookiem PostToolUse, który po każdej edycji uruchamia testy, a potem /code-review na gałęzi.

Codex

Planuj przez /plan w interfejsie terminalowym. Wykonuj w profilu uprawnień (beta), na przykład codex --worktree -c default_permissions=":workspace", co dodatkowo izoluje sesję we własnym git worktree. Nie łącz profilu z --sandbox: według OpenAI te dwa systemy się nie składają (sprawdzone na Codex CLI 0.157.1). Weryfikuj, każąc Codeksowi uruchomić testy, a potem /review lokalnie albo @codex review w pull requeście.

Cursor

Planuj w Plan Mode, który pisze plan implementacji, zanim powstanie jakikolwiek kod. Wykonuj w agencie, w osobnym Worktree, gdy uruchamiasz równoległe próby. Weryfikuj poleceniem testów i hookami (Hooks), a pull request niech przejrzy Bugbot na platformie Git.

Pełny zestaw poleceń dla każdego etapu znajdziesz w mapie narzędzi.

Prompty, od których zaczniesz stosować metodę przy następnej zmianie

Prompt do skopiowania: plan zgodny ze specyfikacją, z dowodami

Stay in plan mode and do not edit files. Read spec.md and the files it names. Write plan.md: a numbered task list where each task names the files it changes and the exact command that proves it (a test name, a lint rule, a build step). Add a Proof section mapping every acceptance criterion in spec.md to one check. List any criterion you cannot map as UNCOVERED, and any assumption as CONFIRMED or GUESS. Stop for my review.

Prompt do skopiowania: dowody zamiast diffa do czytania

Before I review this branch, produce an evidence summary. For each acceptance criterion in spec.md, name the test that covers it, show its result, and state whether it failed before your change. List every file you changed outside plan.md, every test you modified or deleted, and any dependency you added. Flag anything touching auth, payments, schemas, migrations, tests or CI config as NEEDS HUMAN READ.

Test, który nie padał przed zmianą, niczego nie dowodzi, a zmieniony test to pierwsze miejsce, w które warto zajrzeć.

Gdzie pomaga każda część sekcji „Metoda i przepływy pracy”

Podgrupa	Zacznij od	Sięgnij po nią, gdy…
Cykl życia	Cykl życia AI-native	chcesz poznać sześć etapów, ich artefakty i to, kto podpisuje każdy z nich
Zasady	Zasady	potrzebujesz reguł niezależnych od narzędzia: planowanie tylko do odczytu, najpierw testy, małe partie
Kontekst	Zarządzanie kontekstem	agent ignoruje konwencje albo kończy mu się kontekst
Harness	Harness	ustawiasz uprawnienia, hooki, skille i sandboksy
Planowanie i specyfikacja	Planowanie i specyfikacja	zamieniasz zgłoszenie w specyfikację z wykonywalnymi kryteriami akceptacji
Budowanie	Wzorce budowania	baza kodu jest duża, to monorepo albo zestaw usług
Testowanie i weryfikacja	Testowanie z agentami	potrzebujesz testów na tyle mocnych, by im ufać bez czytania kodu
Code review i wdrożenie	Przegląd i wdrożenie	pull request potrzebuje pakietu dowodów i bramki produkcyjnej
Eksploatacja i uczenie się	Eksploatacja	sygnały z produkcji mają zasilać kolejny intent.md
Automatyzacja	Automatyzacja	praca ma przechodzić od zgłoszenia do pull requesta bez nadzoru

Pełną listę wspólnych przepływów pracy dla wszystkich narzędzi znajdziesz na stronie Przepływy: wszystkie narzędzia.

Metody zewnętrznych autorów, takie jak Superpowers, Spec Kit i BMAD, opisujemy w porównaniu frameworków agentowych. Klucz odpowiedzi do Developer Scorecard przypisuje każdemu pytaniu stronę, która poprawia wynik.

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

• Artefakty pisane po kodzie. spec.md wygenerowany z gotowego diffa opisuje to, co zbudowano, a nie to, czego chciano. Naprawa: żadna sesja w trybie planowania nie startuje, dopóki spec.md nie zostanie zaakceptowany, a pull request linkuje zaakceptowany commit.
• Autonomia przed testami. Agent działa bez nadzoru, a testy, które sam napisał, przechodzą mimo zepsutego kodu. Naprawa: celowo zepsuj implementację i sprawdź, czy test robi się czerwony; przenieś chronione testy poza ścieżki, do których agent ma zapis.
• Bramki, które stały się pieczątką. Po dziesięciu zielonych pull requestach nikt już nie otwiera dowodów. Naprawa: klasy eskalacji zostają obowiązkowe, a raz w tygodniu jeden rutynowy pull request czytasz w całości.
• Dryf planu w długich sesjach. Agent odpływa od plan.md. Naprawa: każde zadanie w nowej sesji, z numerem zadania i poleceniem, które je dowodzi.

Dokąd dalej z metodą

Zacznij od Drabiny autonomii, żeby umiejscowić swój obecny przepływ pracy, a potem przeczytaj o cyklu życia AI-native i łańcuchu artefaktów, gdzie jest cała procedura. Tech leadzi, którzy wdrażają to w całym repozytorium, przechodzą dalej do mapy adopcji dla jednego repozytorium oraz strony Governance i autonomia.