Transformacja przepływu pracy: dostarczanie funkcji przebudowane pod agentów

Poziom 3 Poradnik Zaktualizowano 2026-10-12

Transformacja przepływu pracy pod agentów AI to przebudowa zespołowej pętli od ticketu do merge’a: agenci przygotowują plan, kod i testy, a ludzie decydują o celu zmiany, kryteriach akceptacji i ryzyku. Każdy etap kończy się bramką: zatwierdzonym planem, testami akceptacyjnymi napisanymi przed kodem, pakietem dowodów i code review dopasowanym do ryzyka.

Twój zespół ma licencje na Claude Code, Codex i Cursora, i wszyscy z nich korzystają. A mimo to ticket wciąż czeka dwa dni, aż ktoś go weźmie, pull request wciąż czeka dwa dni na review, i nikt nie potrafi wskazać ani jednego kroku, który agenci usunęli. Narzędzia przyspieszyły pisanie, a pisanie nigdy nie było wąskim gardłem. Ten przewodnik jest dla tech leada, który musi zmienić samą pętlę, a nie edytor.

Zanim zaczniesz, upewnij się, że repozytorium jest gotowe na agentów: zobacz playbook konwersji projektu.

Co zbudujesz dzięki temu przewodnikowi

Prompt audytowy, który czyta ostatnie 30 scalonych pull requestów i pokazuje, gdzie naprawdę ucieka czas.
Mapę etapów: co na każdym etapie przygotowuje agent, o czym decyduje człowiek i jaki dowód zamyka bramkę.
Polecenia do bramki planu i implementacji w Claude Code, Codeksie i Cursorze oraz hook Claude Code, który odsyła agenta do poprawki, gdy testy są czerwone.
Dwa joby code review w CI (Claude Code i Codex) z minimalnymi uprawnieniami oraz tabelę torów ryzyka, która mówi, które pull requesty człowiek nadal czyta linijka po linijce.
Dwutygodniowy pilotaż z czterema miarami i regułą: rozszerzyć, wstrzymać albo wycofać.

Gdzie dziś ucieka czas dostarczania w twoim zespole?

Nie przebudowuj wszystkiego naraz. Wybierz pętlę, która kosztuje najwięcej: w większości zespołów to dostarczanie funkcji, od ticketu do scalonego pull requesta. Zmierz ją, zanim ją zmienisz, bo wąskie gardło rzadko leży tam, gdzie ludzie zgadują. Uruchom poniższy prompt w dowolnym z trzech narzędzi z katalogu głównego repozytorium, z zalogowanym GitHub CLI (gh).

Use `gh pr list --state merged --limit 30 --json number,title,createdAt,mergedAt,additions,deletions,reviews,comments`
and `gh pr view <number> --json commits,reviews,closingIssuesReferences`
and `gh issue view <issue> --json createdAt` for the linked issue to study the last 30 merged pull requests.

For each pull request, estimate the elapsed time in these stages:
1. ticket clarified (first commit minus ticket creation, if the PR links an issue)
2. first commit to PR opened
3. PR opened to first review
4. review rounds (count them, and list the reasons for each change request)
5. last approval to merge

Then produce:
- a table of the median and the worst quartile for each stage
- the three most common reasons for change requests, with PR numbers as evidence
- the two stages that are slowest AND most mechanical, and for each one, what an agent
  could draft and what a person must still decide

Cite PR numbers for every claim. Do not give generic advice. Do not modify any files.

Jeśli twój zespół ma już skonfigurowany serwer GitHub MCP, może on zastąpić gh w tym audycie i w późniejszych krokach review. Serwer działa we wszystkich trzech narzędziach, na przykład claude mcp add --scope project --transport http github https://api.githubcopilot.com/mcp/ -H 'Authorization: Bearer ${GITHUB_PAT}' w Claude Code albo codex mcp add github --url https://api.githubcopilot.com/mcp/ --bearer-token-env-var GITHUB_PAT w Codeksie (flagi sprawdzone w Claude Code 2.1.283 i Codex CLI 0.157.1). --scope project zapisuje wpis w .mcp.json, gdzie Claude Code rozwija ${GITHUB_PAT}, więc zespół współdzieli konfigurację bez commitowania tokena. Prompt zostaw bez zmian i poproś o odpowiednie narzędzia MCP zamiast poleceń gh.

Czytaj wynik krytycznie: agent szacuje granice etapów na podstawie znaczników czasu, więc traktuj liczby jak ranking, a nie pomiar. Jeśli twój audyt wygląda jak większość, czekanie (na doprecyzowanie i na review) zajmuje więcej niż pisanie, więc przebudowa musi objąć etapy wokół kodu, a nie tylko sam kod.

Które decyzje zostają przy ludziach, a jaka praca przechodzi na agenta?

Przebudowana pętla zachowuje sześć etapów. Zmienia się to, kto wytwarza każdy artefakt i co zamyka każdą bramkę. Reguła stojąca za tabelą: człowiek decyduje o wszystkim, co drogo kosztuje w razie pomyłki albo trudno to odwrócić, a agent przygotowuje wszystko, co da się potem sprawdzić testem, kontrolą typów albo review.

Etap	Agent przygotowuje	Człowiek decyduje	Dowód, który zamyka bramkę
Cel	Pytania o niejasności w tickecie	Po co jest zmiana i co jest poza zakresem	Ticket z kryteriami akceptacji podpisanymi przez autora
Akceptacja	Scenariusze Given/When/Then i czerwone testy	Czy testy oddają wymaganie	Czerwone testy w repozytorium przed kodem produkcyjnym
Plan	Pliki do zmiany, podejście, lista testów, otwarte pytania	Podejście, kompromisy, odpowiedzi na otwarte pytania	Plan zatwierdzony w sesji albo w tickecie
Implementacja	Kod i dodatkowe testy, jeśli plan ich wymaga	Nic, chyba że agent zatrzyma się na otwartym pytaniu	Diff ograniczony do zatwierdzonego planu
Weryfikacja	Poprawki, aż cały zestaw testów przejdzie	Nic, chyba że któraś bramka uparcie nie przechodzi	Testy, typy, lint i build zielone w CI
Code review	Pierwsze przejście review w CI	Zatwierdzić, odesłać albo eskalować, według toru ryzyka	Pakiet dowodów plus review wymagane przez tor

Większość wartości niosą dwa wiersze. Wiersz akceptacji przesuwa ludzki osąd przed powstanie kodu, gdzie jest tani; pełną technikę opisuje strona o wykonywalnych kryteriach akceptacji. Wiersz code review sprawia, że nie każdy pull request dostaje takie samo czytanie linijka po linijce, a to właśnie ta kolejka niemal na pewno wyszła w twoim audycie. Zespół DORA z Google mówi to samo o wielkości partii: „AI can easily generate massive blocks of code, which are hard to review and test. Enforcing the discipline of small batches counteracts this risk” (blog Google Cloud, 2025-12-10).

Przeprowadź jeden ticket przez nową pętlę

Zanim napiszesz jakąkolwiek politykę, przeprowadź jeden prawdziwy ticket przez pętlę razem z zespołem. Kroki są takie same w każdym narzędziu; różni się mechanika.

Zapisz kryteria akceptacji jako czerwone testy. Poproś agenta, żeby zamienił kryteria z ticketu na testy, przeczytaj testy (nie kod) i zatwierdź je w repozytorium (commit), póki nie przechodzą. Od tej chwili testy są specyfikacją, którą agent musi spełnić, i nie wolno mu ich zmieniać bez pytania.
Uzyskaj plan i zatwierdź go. Agent czyta ticket i testy, a potem proponuje pliki, podejście i otwarte pytania, nie pisząc kodu. Poprawka planu kosztuje jedno zdanie; poprawka gotowej implementacji kosztuje całe popołudnie.
Implementuj zgodnie z planem przy włączonych bramkach. Agent pisze kod i po każdym logicznym kroku uruchamia testy. Jeśli spróbuje skończyć przy czerwonych testach, hook raz odeśle go do poprawki, a jeśli testy nadal będą czerwone, CI zablokuje merge.
Zbierz dowody. Pull request podaje wyniki testów akceptacyjnych, uruchomione kontrole i wszystko, co zmieniło się poza planem. Pełny kontrakt i sprawdzenie w CI, które go wymusza, opisuje pakiet dowodów.
Zrób review według toru ryzyka. Pierwsze przejście robi reviewer w CI. Potem człowiek sprawdza to, czego wymaga tor, czyli w większości zmian dowody i testy, a nie każdą linię.

Read the ticket below and the failing tests in tests/acceptance/ that encode it.
Before you write any production code, produce a plan with:
1. the exact files you will create or modify, and why each one
2. the approach in three to five sentences, naming any existing module you will reuse
3. any test you want to add beyond tests/acceptance/, and the case it covers
4. every assumption you are making, and every question where the ticket is ambiguous
   about error handling, limits, permissions or data migration

Stop after the plan. Do not write code and do not modify tests/acceptance/ until I approve.
If an acceptance test looks wrong, say so in the plan instead of changing it.

Ticket:
<paste the ticket here>

Polecenia planu i implementacji w każdym narzędziu

Zacznij od domyślnego modelu narzędzia i zanim zmienisz model, podnieś poziom wysiłku (effort); aktualne ustawienia domyślne i ceny są w przeglądzie modeli.

Planuj interaktywnie w trybie planowania (/plan albo Shift+Tab, który przełącza tryby) lub bez interfejsu, w skryptowanym pipeline. W terminalu:

# Stage 2: plan only; plan mode cannot edit files
claude -p "Read docs/tickets/TICKET-482.md and the failing tests in tests/acceptance/. \
Produce an implementation plan: files, approach, extra tests, open questions. No code." \
  --permission-mode plan

# Stage 3: implement the approved plan; claude -p starts in Manual mode
# (auto mode on third-party providers or with telemetry off, v2.1.285+),
# so allow exactly the commands the loop needs
claude -p "Implement the approved plan in docs/plans/TICKET-482.md. Run npm test after \
each logical step and fix failures before continuing. Do not edit tests/acceptance/." \
  --permission-mode acceptEdits \
  --allowedTools "Bash(npm test:*),Bash(npm run lint:*),Bash(npm run typecheck:*)"

Regułę „nie kończ na czerwono” wymuś mechanicznie hookiem Stop. Kod wyjścia 2 z hooka Stop nie pozwala Claude’owi zakończyć pracy i pokazuje mu twój komunikat. Zapisz ten skrypt jako .claude/hooks/tests-green.sh i nadaj mu prawo wykonywania (wymaga jq w PATH):

#!/usr/bin/env bash
# Stop hook: send Claude back once if the suite is red.
input=$(cat)
# CI jobs (such as the review job below) have their own gates; skip there.
[ -n "$GITHUB_ACTIONS" ] && exit 0
# Plan-mode sessions write no code, and the acceptance tests are red by design.
[ "$(printf '%s' "$input" | jq -r '.permission_mode // ""')" = "plan" ] && exit 0
# stop_hook_active is true when this hook already forced a continuation;
# let the session end then, and rely on CI to block the merge.
if [ "$(printf '%s' "$input" | jq -r '.stop_hook_active // false')" = "true" ]; then
  exit 0
fi
# Nothing changed since the last commit; skip.
[ -z "$(git status --porcelain)" ] && exit 0
log=$(mktemp)
trap 'rm -f "$log"' EXIT
if ! npm test --silent > "$log" 2>&1; then
  echo "Tests are failing. Fix them before you finish. Last lines:" >&2
  tail -n 40 "$log" >&2
  exit 2
fi

Warunek z git status --porcelain sprawia, że pytanie zadane po commicie nie uruchamia testów od nowa. Jeśli pełny zestaw testów działa wolno, skieruj hook tylko na testy jednostkowe, a resztę zostaw CI. Zarejestruj go w .claude/settings.json, który trafia do repozytorium, więc dostaje go cały zespół:

{
  "hooks": {
    "Stop": [
      { "hooks": [ { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/tests-green.sh" } ] }
    ]
  }
}

Dwa pierwsze warunki (sprawdzenie GITHUB_ACTIONS i sprawdzenie trybu planowania) sprawiają, że hook nie działa w sesjach, w których czerwone testy są zamierzone. Tryb planowania (krok 2) nie pisze kodu, a job review w CI nie ma zainstalowanych zależności, więc oba warunki kończą działanie hooka od razu. W kroku 1 zatwierdzone testy akceptacyjne są czerwone z założenia, więc albo uruchom sesję piszącą testy bez hooka (sesja osobista albo --setting-sources user), albo każ hookowi uruchamiać zestaw bez testów akceptacyjnych, na przykład npm test -- --exclude 'tests/acceptance/**' z Vitestem, którego --exclude przyjmuje glob plików (w cudzysłowie, żeby powłoka go nie rozwinęła), a nie samą nazwę katalogu.

Hook Stop pasuje tu lepiej niż hook PostToolUse przy każdej edycji: pełny zestaw testów po każdej zmianie pliku jest wolny, a hook PostToolUse i tak nie cofnie edycji, bo narzędzie już się wykonało. Testy fixture dla takich hooków opisuje strona Hooki Claude Code.

Planuj w profilu uprawnień tylko do odczytu, a implementuj z prawem zapisu w katalogu roboczym. Profile uprawnień są w wersji beta i OpenAI zaleca je zamiast starszej flagi --sandbox. W terminalu (flagi sprawdzone w codex --help, codex exec --help i codex review --help, v0.157.1):

# Stage 2: plan only; the read-only profile cannot change files
codex exec -c default_permissions=":read-only" \
  "Read docs/tickets/TICKET-482.md and the failing tests in tests/acceptance/. \
   Output an implementation plan: files, approach, extra tests, open questions. No code."

# Stage 3: implement interactively with workspace write access
codex -c default_permissions=":workspace" \
  "Implement the approved plan in docs/plans/TICKET-482.md. Run npm test after each \
   logical step and fix failures before finishing. Do not edit tests/acceptance/."

# Before you push: a local review of the branch against main
codex review --base main

W wersji 0.157.1 codex review odrzuca --base razem z własnymi instrukcjami („cannot be used with ‘[PROMPT]’”), więc review gałęzi działa na wbudowanych instrukcjach Codeksa.

Wpisz polecenia testów, lintu i kontroli typów do AGENTS.md, żeby każda sesja Codeksa, lokalna czy w chmurze, uruchamiała te same bramki bez przypominania. Codex też ma hooki (handlery typu command; hooki wymagają utrwalonego zaufania), jeśli chcesz regułę zielonych testów wymusić, a nie tylko o nią prosić. Przy pracy równoległej zadanie w Codex cloud albo sesja z --worktree implementuje ticket A, a ty w tym czasie zatwierdzasz plan dla ticketu B.

Jak zweryfikować wynik bez czytania każdej linii?

Czytanie linijka po linijce nie skaluje się, gdy większość pull requestów otwierają agenci, a kolejka code review staje się nowym wąskim gardłem. Zastąp je warstwami dowodów, z których każda łapie inną klasę błędów:

Testy akceptacyjne napisane przed kodem dowodzą zachowania, o które prosił ticket. Zablokuj je: zmiana w tests/acceptance/ w tym samym pull requeście co implementacja wymaga osobnego zatwierdzenia. Zobacz ochronę wyroczni.
Bramki mechaniczne (testy, typy, lint, build) działają w CI przy każdym pushu, a czerwona bramka blokuje merge.
Reviewer w CI wyszukuje nieobsłużone błędy, brakujące przypadki brzegowe i podejrzane miejsca pod kątem bezpieczeństwa, żeby nie musiał tego robić człowiek.
Człowiek robi review według toru ryzyka, zgodnie z tabelą poniżej.

Dodaj reviewera AI do CI

Oba joby poniżej uruchamiają się na pull_request, więc przy pull requestach z forków sekret jest pusty i job kończy się błędem, zamiast go ujawnić; pull requesty z forków przeglądaj ręcznie albo workflowem uruchamianym przez maintainera, który pobiera kod forka tylko do odczytu. Nie przełączaj ich na pull_request_target, żeby dostarczyć sekrety do kodu z forka. Przy pull requestach z gałęzi we własnym repozytorium klucz jest dostępny, a job uruchamia plik workflow z tej gałęzi, jej hooki z .claude/settings.json, .mcp.json i AGENTS.md. Dlatego obejmij /.github/, .claude/, .codex/, .mcp.json i AGENTS.md plikiem CODEOWNERS z wymaganą recenzją właściciela kodu, bo inaczej pull request (także napisany przez agenta) może zmienić to, co działa obok klucza. Przegląd jest dowodem pomocniczym, a nie bramką scalania.

Na podstawie przykładu automatycznego review z anthropics/claude-code-action:

name: AI PR review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 1
          persist-credentials: false
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}
            Review this pull request. Report only unhandled errors, missing edge cases,
            security issues, and changes to tests/acceptance/. Skip style.
            Use `gh pr comment` for a summary and inline comments for specific lines.
          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

openai/codex-action@v1 uruchamia codex exec i zwraca jego końcową odpowiedź jako wyjście final-message; publikuje ją w pull requeście osobny job post, który jako jedyny ma token pull-requests: write i nie uruchamia agenta. README akcji zaleca permission-profile zamiast starszego wejścia sandbox:

name: AI PR review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    # The agent's job gets no write scope.
    permissions:
      contents: read
    outputs:
      review: ${{ steps.codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
          persist-credentials: false
      - id: codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          permission-profile: ":read-only"
          prompt: |
            Review the changes between origin/${{ github.base_ref }} and HEAD.
            Report only unhandled errors, missing edge cases, security issues,
            and changes to tests/acceptance/. Skip style.
  # No checkout and no agent: this job only posts the text the review job returned.
  post:
    needs: review
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - name: Post the review
        env:
          GH_TOKEN: ${{ github.token }}
          GH_REPO: ${{ github.repository }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
          REVIEW: ${{ needs.review.outputs.review }}
        run: gh pr comment "$PR_NUMBER" --body "$REVIEW"

Które pull requesty człowiek nadal czyta linijka po linijce?

Ustal tory raz, wpisz je do AGENTS.md i do szablonu pull requesta, i niech decydują ścieżki plików. Reviewer zatwierdza dowody wymagane przez tor; tech lead jest właścicielem polityki torów i zmienia ją tylko na podstawie błędów, które przeszły na produkcję.

Tor	Typowe ścieżki	Review człowieka
Tylko dowody	Teksty w UI, narzędzia wewnętrzne, testy, dokumentacja, kod za feature flagą	Przeczytaj pakiet dowodów i testy akceptacyjne; zatwierdź, jeśli są zielone
Próbkowanie	Zwykły kod produktowy	Dowody plus czytanie linijka po linijce najbardziej ryzykownego pliku albo co piątego pull requesta
Pełne czytanie	Uwierzytelnianie, płatności, migracje danych, kontrakty publicznego API, infrastruktura	Review linijka po linijce przez właściciela kodu, niezależnie od dowodów

Przesunięcie pętli z pełnego czytania w stronę samych dowodów to osobna, etapowa zmiana; review cieniowe, próbkowanie i regułę wycofania opisuje transfer zaufania.

Przykład: endpoint eksportu z limitem zapytań

Oto pętla na jednym tickecie: dodaj POST /api/exports do serwisu Express, z limitem pięciu zapytań na użytkownika na minutę.

Akceptacja. Agent pisze trzy czerwone testy: eksport się udaje, niepoprawne body zwraca 400, a szóste zapytanie w ciągu minuty zwraca 429. Reviewer czyta testy i dodaje czwarty: limit jest na użytkownika, a nie globalny. Testy trafiają do repozytorium jako czerwone.
Plan. Agent proponuje trasę w src/routes/exports.ts, schemat Zod i limiter w pamięci. Reviewer odrzuca limiter w pamięci, bo serwis działa na kilku instancjach, i wskazuje istniejącego klienta Redisa. Koszt: jedno zdanie.
Implementacja i weryfikacja. Agent pisze trasę, schemat i limiter na Redisie. Test 429 jest wciąż czerwony, gdy agent próbuje zakończyć pracę (middleware zwraca 503), więc hook Stop raz odsyła go do poprawki i agent zmienia kod statusu; gdyby test został czerwony, CI zablokowałoby merge.
Code review. Reviewer Claude Code w CI zauważa, że limiter przy niedostępnym Redisie odrzuca zapytania, więc awaria Redisa blokuje każdy eksport. To decyzja produktowa, więc osoba robiąca review eskaluje ją do product ownera; product owner wybiera przepuszczanie zapytań przy awarii (fail-open) dla eksportów, a decyzja trafia do opisu pull requesta. Ścieżka należy do toru próbkowania, więc reviewer czyta linijka po linijce plik limitera, a resztę sprawdza przez dowody.

Każdą decyzję wymagającą osądu (limit na użytkownika, Redis zamiast pamięci, fail-open) podjął człowiek. Żadna z nich nie wymagała czytania wygenerowanego handlera trasy.

Zapisz pętlę tak, by każdy inżynier uruchamiał tę samą

Przepływ pracy, który żyje w głowie jednego tech leada, u każdego inżyniera działa inaczej. Umieść go w repozytorium: reguły etapów w AGENTS.md (Claude Code czyta CLAUDE.md, a AGENTS.md wtedy, gdy nie ma CLAUDE.md, od v2.1.277; Cursor czyta też AGENTS.md i CLAUDE.md i używa Rules), hook Stop w .claude/settings.json, listę dowodów w .github/pull_request_template.md, a tory w CODEOWNERS i szablonie. Jeden plik bazowy z cienkimi adapterami dla każdego narzędzia opisuje strona Wspólne reguły agentów.

Add a section called "Delivery workflow" to AGENTS.md (create the file if it is missing).
Read package.json, the CI workflows in .github/workflows/ and CODEOWNERS first, and use
the real commands and paths you find there. The section must say, in imperative sentences:

1. Before production code: turn the ticket's acceptance criteria into failing tests under
   tests/acceptance/ and stop for approval.
2. Before implementation: produce a plan (files, approach, extra tests, open questions)
   and stop for approval.
3. During implementation: run the exact test, lint and type-check commands after each
   logical step; never finish while any of them fails; never edit tests/acceptance/
   without asking.
4. In the pull request: fill in every section of .github/pull_request_template.md.
5. Risk lanes: list the paths that need a full human read (auth, payments, migrations,
   public API, infrastructure), taken from CODEOWNERS where possible.

Keep the section under 40 lines. Show me the diff and do not commit.

Wygenerowaną sekcję sprawdź tak jak kod: każde polecenie musi istnieć, każda ścieżka musi się rozwiązywać. Błędne polecenie testów w AGENTS.md jest gorsze niż żadne, bo każda sesja agenta uruchomi je z pełnym przekonaniem.

Pilotuj nowy przepływ przez dwa tygodnie, potem zdecyduj

Przez dwa tygodnie prowadź pętlę w jednym zespole i jednym repozytorium, a wszystkie tickety funkcjonalne przepuszczaj przez nią. Porównaj te cztery miary z wynikiem audytu:

Miara	Jak ją policzyć	Jak wygląda dobry wynik
Czas od ticketu do merge’a	Mediana, od statusu „gotowy” do merge’a	Spada, głównie przez krótsze czekanie na review
Rundy review na pull request	Review z prośbą o zmiany na jeden scalony pull request	Spadają, bo plany są poprawiane przed kodem
Kompletność dowodów	Odsetek pull requestów z wypełnionymi wszystkimi sekcjami szablonu	Niemal każdy pull request w drugim tygodniu
Błędy po merge’u	Błędy przypisane do pull requestów z pilotażu	Nie więcej niż w punkcie odniesienia

Pełne definicje metryk opisuje strona DORA, SPACE, DX Core 4 i pomiar AI.

Potem zdecyduj. Rozszerz pilotaż na kolejny zespół, gdy spadł czas dostarczenia albo liczba rund review, a błędów po merge’u nie przybyło. Wstrzymaj i napraw najsłabszą bramkę, gdy liczby stoją w miejscu. Wycofaj tory do pełnego czytania, gdy błędów po merge’u przybyło, i zanim spróbujesz ponownie, znajdź bramkę, która przepuściła błąd. Kolejne pętle układa mapa adopcji, a sposób mierzenia skutecznego użycia w zespole definiuje strona Adopcja w zespole.

Raport DORA 2025 dobrze tu ostrzega: „AI doesn’t fix a team; it amplifies what’s already there” (blog Google Cloud, 2025-09-23). Pilotaż w zespole z niestabilnymi testami i niejasnymi ticketami najpierw wzmocni właśnie te problemy, więc napraw bramki, zanim obwinisz agentów.

Kiedy nowy przepływ dostarczania się sypie

Agent pewnie buduje nie to, co trzeba. Bramka planu została pominięta albo stała się pieczątką. Wyjście: wyrzuć gałąź zamiast ją łatać, uruchom ponownie prompt planu i przez najbliższe dwa tygodnie wymagaj przy każdym planie jednej pisemnej poprawki albo wyraźnej notatki „bez zmian”.

Testy przechodzą, ale zachowanie jest złe. Agent napisał testy, które potwierdzają jego własną implementację, albo poprawił testy akceptacyjne, żeby przechodziły. Wyjście: dodaj w CI sprawdzenie, które nie przechodzi, gdy tests/acceptance/ zmienia się w tym samym pull requeście co src/ bez wskazanego zatwierdzającego, i przenieś testy akceptacyjne przed plan, jak w kroku 1. Jak sprawdzić, czy testy złapałyby prawdziwy błąd, pokazuje strona o sile wyroczni.

Kolejka review rośnie szybciej niż wcześniej. Agenci otwierają więcej i większych pull requestów, niż reviewerzy są w stanie przyjąć. Wyjście: ustal budżet rozmiaru pull requesta i limit pracy w toku na reviewera, jak w artykule o kolejce code review, i przenieś ścieżki niskiego ryzyka do toru „tylko dowody”.

Pętla jest wolniejsza niż samodzielne napisanie zmiany. Tak jest przy jednolinijkowej zmianie konfiguracji. Wyjście: dodaj do polityki tor „trywialny” (bez bramki planu; testy i CI nadal obowiązkowe), a pełną pętlę zostaw dla zmian dotykających kilku plików albo nieznanego obszaru.

Długie sesje przeczą wcześniejszym decyzjom. Kontekst się zapełnił i agent zgubił zatwierdzony plan. Wyjście: zapisz zatwierdzony plan w docs/plans/, ogranicz jedną sesję do jednego planu i zamiast ciągnąć długą sesję, zacznij nową, która czyta plik planu.

Każdy inżynier dostaje inne wyniki. Przepływ żyje w promptach poszczególnych ludzi. Wyjście: dodaj do repozytorium sekcję AGENTS.md, hook i szablon pull requesta z poprzedniej sekcji i zmieniaj je przez review, tak jak kod.

Następne kroki

Łańcuch artefaktów Strona dewelopera w tej pętli: cel, specyfikacja, plan, diff i wyniki review jako artefakty w repozytorium.

Code review PR-a agenta bez czytania każdej linii Sześciokrokowy triaż pull requestów agenta, który zastępuje czytanie linijka po linijce.

Jak przygotować backlog dla agentów Które tickety przechodzą przez pętlę agenta i szablon ticketu z wbudowanymi kryteriami akceptacji.

Playbook konwersji projektu Najpierw przygotuj repozytorium: jeden AGENTS.md oparty na prawdziwym kodzie, adaptery i kontrole w CI.

Książki · w Toolkicie Książki · w twoim Toolkicie 08 tytułów · PL + EN Twoje

Przeczytaj ścieżkę tech leada jako książkę. Pobierz ścieżkę tech leada jako książkę.

Przewodniki dla zespołu w kolejności, której potrzebuje lider: drabina, harness, projektowanie weryfikacji i code review jako kolejka.

Przewodniki dla zespołu w kolejności, której potrzebuje lider: drabina, harness, projektowanie weryfikacji i code review jako kolejka. Masz ją w Toolkicie, a pobrany plik zostaje u ciebie.

16 Kroków
EPUB·PDF Formaty
PL·EN Wydania

Zobacz wszystkie osiem książek Jedna z 8 książek w Toolkicie · 249,99 zł jednorazowo

Pobierz książkę Zobacz wszystkie osiem

Ścieżka czytania Okładka książki Inżynieria agentowa dla tech leadów

Grzbiety według liczby stron

Masz wszystkie osiem PL + EN