Ciągła dostawa z pomocą AI

Ciągła dostawa z agentami AI utrzymuje każdą zmianę na tyle małą, by automatyczne kontrole mogły ją udowodnić: jedno zadanie agenta to jeden commit, każdy pull request mieści się w limicie rozmiaru pilnowanym przez CI, a o tym, czy zmiana trafia na produkcję, decyduje pipeline. Agenci zwiększają wolumen zmian, więc rozmiar partii staje się dźwignią, która chroni stabilność.

Spędziłeś cztery godziny, budując funkcjonalność w jednej sesji agenta. Diff ma 1200 linii w 18 plikach, a pierwszy komentarz recenzenta brzmi: „Możesz to podzielić?”. Nie możesz, bo migracja, API i UI są splątane w tych samych commitach. Pull request czeka dwa dni, a gdy nocny build robi się czerwony, najszybszą poprawką agenta jest usunięcie padającego testu.

Ta strona jest dla deweloperów, którzy prowadzą sesje agentów, i dla tech leadów, którzy ustalają zasady merge’owania w zespole. Opisuje samą dyscyplinę dostawy. Sąsiednie strony wchodzą głębiej w dowody, które musi nieść pull request, code review bez czytania każdej linii i bezpieczne wypuszczanie zmian.

Dlaczego małe partie są ważniejsze, gdy kod piszą agenci?

Agenci sprawiają, że duży diff tanio się produkuje i drogo weryfikuje. Trzy niezależne pomiary wskazują ten sam kierunek:

DORA, raport 2025 (Google Cloud, 2025-09-23): „we observe a positive relationship between AI adoption on both software delivery throughput and product performance” oraz „AI adoption does continue to have a negative relationship with software delivery stability”. Raport nazywa mechanizm: „Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability”.
DORA AI Capabilities Model (Google Cloud, Nathen Harvey i Allison Park, 2025-12-10): praca w małych partiach to jedna z siedmiu zdolności, bo „AI can easily generate massive blocks of code, which are hard to review and test”.
DX (Justin Reock, 2026-06-17): mediana rozmiaru pull requesta „nearly doubled, growing from 44 lines to 72 lines per pull request between July 2025 and June 2026”, w raporcie opartym na danych z ponad 400 firm.

Telemetria dostawcy Faros AI (kwiecień 2026, 22 000 deweloperów) pokazuje ten sam kompromis w jednym raporcie: przepustowość zadań na dewelopera wzrosła o 33,7%, rozmiar pull requestów o 51%, a liczba błędów na pull request o 28,7%. Wniosek dla dostawy: rozmiar partii to ustawienie, które kontrolujesz, i musi go pilnować pipeline, bo agent tego nie zrobi.

Co zyskujesz dzięki ciągłej dostawie z agentami

Regułę „commit na zadanie” w CLAUDE.md, AGENTS.md albo w regule Cursora, dzięki której każda sesja zostawia historię nadającą się do przeglądu.
Deterministyczny check w GitHub Actions, który odrzuca pull request ponad limit rozmiaru, bez agenta i bez sekretów w jobie.
Prompty do podziału zbyt dużego diffu na stos pull requestów, do notatek wydania z zakresu commitów i do triage’u czerwonego buildu bez osłabiania testów.
Bramki, które pozwalają wypuścić zmianę na podstawie dowodów zamiast czytania linijka po linijce, oraz miary pokazujące, że dyscyplina działa.

Jak zmienia się ciągła dostawa, gdy kod pisze agent?

Praktyki są te same co zawsze. Zmienia się to, kto je łamie, i która bramka to wyłapuje.

Praktyka	Co robi agent bez reguły	Bramka, która ją utrzymuje
Małe partie	Pracuje do końca całej funkcjonalności i commituje raz	Reguła „commit na zadanie” i check rozmiaru pull requesta w CI
Krótko żyjące gałęzie	Buduje na gałęzi godzinami, a `main` ucieka do przodu	Jedna lista zadań na gałąź, merge tego samego dnia
Każdy commit gotowy do wydania	Zostawia niedokończoną pracę między commitami	Testy, typy i lint przed każdym commitem
Deploy to nie wydanie	Wypuszcza nowe zachowanie od razu do wszystkich	Flagi funkcji i canary (progressive delivery)
Szybka informacja zwrotna	Traktuje czerwony build jak problem do ukrycia	Prompt do triage’u, który zabrania pomijania i luzowania testów
Identyfikowalne wydania	Pisze w wiadomości commita „update files”	Conventional Commits w pliku reguł, notatki wydania z zakresu commitów

Commituj po każdym zadaniu agenta, a nie po całej funkcjonalności

Nawyk, który umożliwia całą resztę, to jedno ukończone zadanie, jeden commit. Jeśli planujesz z łańcuchem artefaktów, każde zadanie z plan.md daje jeden commit, a trzy do pięciu zadań składa się na jeden pull request. Reguła musi mieszkać w pliku instrukcji agenta, bo prompt, o którym zapomnisz, nie jest regułą.

Dodaj regułę commitów do pliku instrukcji, który czyta twoje narzędzie (gdzie, pokazują zakładki poniżej).
Zaczynaj każdą sesję od jednego zadania z planu, nie od całej funkcjonalności.
Gdy kontrole zadania przechodzą, pozwól agentowi zrobić commit i dopiero wtedy zacznij następne zadanie.
Otwieraj pull request, gdy gotowe są zadania jednego kawałka do przeglądu, a nie całej funkcjonalności.

Wpisz regułę do CLAUDE.md w katalogu głównym repozytorium. Od v2.1.277 na kanale wydań latest Claude Code czyta też AGENTS.md, gdy nie ma CLAUDE.md, więc zespół, który dzieli jeden plik z Codexem, może trzymać regułę tam.

## Commits
- Commit after each completed task from plan.md, never after several.
- Before committing, run `npm run typecheck`, `npm run lint` and the tests for the files you changed. Do not commit on a failure.
- Stage only the files that belong to the task. Never stage .env files or generated build output.
- Use Conventional Commits: `type(scope): summary`, one logical change per commit. If the summary needs "and", it is two commits.

Wpisz tę samą regułę do AGENTS.md w katalogu głównym repozytorium; Codex czyta go na początku każdej sesji w zaufanym projekcie; od 0.150.0 AGENTS.md z niezaufanego projektu nie jest wczytywany (/init tworzy plik startowy). Sesje interaktywne uruchamiaj jako codex -s workspace-write -a on-request: rutynowe edycje i testy dzieją się wtedy w sandboksie, a Codex pyta o zgodę przed każdym poleceniem, które musi z niego wyjść.

## Commits
- Commit after each completed task from plan.md, never after several.
- Before committing, run `npm run typecheck`, `npm run lint` and the tests for the files you changed. Do not commit on a failure.
- Stage only the files that belong to the task. Never stage .env files or generated build output.
- Use Conventional Commits: `type(scope): summary`, one logical change per commit.

The task "Add per-client rate limiting to POST /api/orders" from plan.md is done.
Before committing:
1. Run npm run typecheck, npm run lint, and npm test -- src/api/orders.
2. If anything fails, fix the code, not the test, and run the checks again.
3. Run git status and stage only the files this task touched. Do not stage .env, dist/ or lockfile changes you did not intend.
4. Commit with a Conventional Commits message: feat(orders): <summary>, plus a body that says why.
5. Print the commit hash and the output of git show --stat HEAD.
Do not push. Do not start the next task until I confirm.

Wymuś limit rozmiaru pull requesta w CI

Reguła w pliku instrukcji zawodzi po cichu, gdy agent ją zignoruje. Check w CI nie zawodzi. Poniższy workflow liczy zmienione linie względem gałęzi bazowej, pomija lockfile’e i snapshoty testów i kończy się błędem, gdy suma przekroczy limit. Nie uruchamia agenta i nie czyta żadnego sekretu, więc jest bezpieczny dla pull requestów z dowolnej gałęzi.

name: PR size budget
on:
  pull_request:
    types: [opened, synchronize, reopened, labeled, unlabeled]
permissions:
  contents: read
jobs:
  size:
    runs-on: ubuntu-latest
    if: ${{ !contains(github.event.pull_request.labels.*.name, 'size-exception') }}
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
          persist-credentials: false
      - name: Fail when the diff exceeds the budget
        env:
          BASE_REF: ${{ github.base_ref }}
          BUDGET: '400'
        run: |
          set -o pipefail   # a failed git diff must fail the check, not count as 0 lines
          changed=$(git diff --numstat "origin/${BASE_REF}...HEAD" -- . \
            ':(exclude)*.lock' ':(exclude)package-lock.json' ':(exclude)*__snapshots__*' \
            | awk '$1 != "-" { total += $1 + $2 } END { print total + 0 }')
          echo "Changed lines (without lockfiles and snapshots): ${changed} of ${BUDGET}"
          if [ "${changed}" -gt "${BUDGET}" ]; then
            echo "::error::This pull request changes ${changed} lines. Split it into stacked pull requests, or add the size-exception label and explain why in the description."
            exit 1
          fi

Limit 400 linii to punkt wyjścia, a nie próg wynikający z badań. Ustal go na podstawie własnej historii: weź medianę rozmiaru pull requestów zmerge’owanych przez zespół w ostatnim kwartale i zacznij nieco powyżej niej. Etykieta size-exception to furtka dla generowanych migracji i masowych zmian nazw; odpowiada za nią tech lead, a każde jej użycie widać w pull requeście.

Dwa ograniczenia decydują, czy to uczciwa bramka. Przy wyzwalaczu pull_request GitHub uruchamia plik workflow z merge refa pull requesta, więc gałąź może w tym samym diffie podnieść BUDGET albo usunąć check; dodaj /.github/ do CODEOWNERS i wymagaj w ochronie gałęzi recenzji code ownera, żeby zmiana workflow potrzebowała akceptacji tech leada. Poza tym job pominięty przez etykietę liczy się dla wymaganego checku jako zaliczony, a etykietę może dodać każdy z dostępem triage, także autor pull requesta. GitHub nie ma uprawnień do pojedynczych etykiet, więc etykieta to widoczny wyjątek, a nie kontrola: o tym, czy zostaje, decyduje code owner, który recenzuje pull request.

Podziel zbyt duży diff agenta na stos pull requestów

Gdy sesja już wyprodukowała gałąź na 1200 linii, nie proś recenzenta, żeby to przełknął. Niech agent potnie ją na warstwy, z których każda sama przechodzi kontrole. Prompt jest ten sam we wszystkich trzech narzędziach; różni się tylko miejsce uruchomienia. Żeby podział odbył się w osobnym checkoucie, w Codexie zacznij sesję z --worktree, w Claude Code z claude --worktree <nazwa> (-w), a w Cursorze użyj git worktree (agenci w izolowanych worktree).

This branch is too large to review. Split it into stacked branches off main:
1. Run git diff --stat main...HEAD and group the files into layers: database migration and models, API, then UI.
2. Create feature/orders-db with only the first layer. Run the full test suite there. If it fails, move the missing dependency into this layer rather than skipping tests.
3. Create feature/orders-api on top of feature/orders-db, then feature/orders-ui on top of feature/orders-api, running the tests on each.
4. Keep every branch under 400 changed lines, excluding lockfiles and snapshots. If a layer is still larger, propose a further split and stop.
5. For each branch, print the diff stat, the test result, and a two-line pull request summary that names the branch it depends on.
Do not push and do not delete the original branch.

Niech o wydaniu zmiany decyduje pipeline, a nie czytelnik

Małe partie sprawiają, że każdą zmianę da się sprawdzić. Bramki sprawiają, że sprawdzenie jest automatyczne. Zmiana jest gotowa do merge’a, gdy spełnione są cztery warunki, a żaden z nich nie wymaga, by człowiek przeczytał każdą linię:

Deterministyczne kontrole przechodzą: sprawdzanie typów, lint i zestaw testów, w tym nowe testy, które padają na starym kodzie.
Wyrocznia jest nietknięta albo zmiana jest uzasadniona: żadnego usuniętego, pominiętego ani poluzowanego testu bez podanego powodu (ochrona wyroczni).
Agent recenzujący nie znalazł problemu blokującego, uruchomiony na diffie ze spisanymi kryteriami przeglądu.
Pakiet dowodów jest kompletny: link do specyfikacji, wyniki akceptacji, klasa ryzyka i plan wdrożenia, sprawdzane przez CI (pakiet dowodów).

Człowiek zatwierdza zgodnie z klasą ryzyka zadeklarowaną w pakiecie. Zmiany niskiego ryzyka wchodzą po zielonych bramkach; zmiany wysokiego ryzyka (uwierzytelnianie, płatności, migracje, publiczne API) trafiają do wskazanego właściciela, który czyta dowody i oflagowane gorące punkty. Kto czyta co, określa sześciostopniowy triage PR-ów agenta.

Przed pushem uruchom w sesji /code-review, żeby lokalnie przejrzeć gałąź. Dla głębszego przebiegu w chmurze claude ultrareview uruchamia z powłoki wieloagentowy przegląd bieżącej gałęzi i wypisuje znaleziska; na planach Pro i Max po kilku darmowych uruchomieniach płacisz za każde kolejne. Zespoły na planach Team i Enterprise mogą włączyć zarządzane Code Review (research preview) na GitHubie, które czyta plik REVIEW.md w katalogu głównym repozytorium z instrukcjami tylko dla przeglądu. Konfigurację opisuje strona automatyczne przeglądy kodu z Claude Code.

Przed pushem uruchom codex review --base main, żeby nieinteraktywnie przejrzeć gałąź, albo codex review --uncommitted dla pracy, której jeszcze nie zacommitowałeś. Na GitHubie komentarz @codex review pod pull requestem zleca przegląd na miejscu. Konfigurację opisuje strona code review z Codex.

Jeśli chcesz uruchamiać agenta jako job CI na każdym pull requeście, użyj utwardzonej konfiguracji ze strony agenci headless w CI. Job agenta, który pobiera kod kontrybutora, mając klucz API w środowisku, może uruchomić hooki i serwery MCP tego kontrybutora z twoim sekretem, więc skopiuj flagi z tamtej strony zamiast pisać job od zera.

Oddziel deploy od wydania flagami funkcji

Ciągła dostawa oznacza, że main zawsze nadaje się do wdrożenia, a nie że każdy merge trafia do każdego użytkownika. Nowe zachowanie ze zmiany agenta schowaj za flagą funkcji, wdróż je „po ciemku” i najpierw pokaż małej części ruchu. Zmiana, która po merge’u okaże się błędna, kosztuje wtedy przełączenie flagi, a nie revert pod presją. Budżet zasięgu awarii dla każdej klasy ryzyka, analizę canary i automatyczny rollback opisuje strona progressive delivery dla zmian pisanych przez agentów.

Wrap the new per-client rate limiting in POST /api/orders behind a feature flag named orders-rate-limit, default off.
Use the flag client we already use in src/lib/flags; do not add a new dependency.
Add two tests: one proving the old behaviour with the flag off, and one proving the new behaviour with the flag on.
Add a line to the pull request description under "Rollout" naming the flag, its default, and who may turn it on.
Run the tests and show the output.

Pisz notatki wydania z zakresu commitów

Historia „commit na zadanie” w formacie Conventional Commits sprawia, że notatki wydania kosztują niewiele. Daj agentowi zakres i format zamiast polecenia „podsumuj wydanie”.

Generate release notes for git log v1.1.0..v1.2.0.
Group entries under Breaking changes, Features and Fixes, in that order.
For each entry, write one user-facing sentence (not the raw commit subject) and add the pull request number.
Under Breaking changes, list the migration step a user must take.
Skip chore, ci and test commits. Output Markdown only.
If a commit subject does not follow Conventional Commits, list it under "Unclassified" instead of guessing.

Zrób triage czerwonego buildu bez osłabiania testów

Agent dobrze sprawdza się jako pierwsza linia przy padniętym pipeline’ie, pod warunkiem że prompt wyklucza skróty. Zostawiony sam sobie, najszybciej dojdzie do zielonego checka, pomijając test, dodając ponowienia albo luzując asercję.

CI failed on this branch. The log is below.
1. Identify the first real error, not the cascade after it.
2. Classify it: code defect, test defect, flaky test, or CI environment (versions, missing env var, service not ready).
3. For a code defect, fix the code and run the failing test locally to show it passes.
4. For anything else, explain the cause and propose the change, but do not apply it.
Do not skip, delete or loosen any test, and do not add retries. If the only way to green is changing a test, stop and tell me why.

<paste the CI log here>

Skąd wiesz, że ciągła dostawa działa?

Mierz przepływ, a nie aktywność agenta. Śledź te miary w każdym sprincie, na danych z hostingu Gita i narzędzia do wdrożeń, a nie z deklaracji zespołu:

Miara	Co pokazuje	Pożądany kierunek
Mediana zmienionych linii na zmerge’owany pull request	Czy partie pozostają małe	Bez zmian lub w dół
Odsetek pull requestów z etykietą `size-exception`	Czy limit jest prawdziwy	Niski, każdy z uzasadnieniem
Czas realizacji zmiany (lead time) od pierwszego commita do produkcji	Czy małe partie rzeczywiście płyną	W dół
Odsetek nieudanych zmian (change failure rate)	Czy tempo odbywa się kosztem stabilności	Bez zmian lub w dół
Czas przywrócenia po nieudanym wdrożeniu (failed deployment recovery time)	Czy flagi i rollback działają	W dół

Trzy ostatnie to miary dostawy DORA; strona DORA, SPACE, DX Core 4 i pomiar AI definiuje je precyzyjnie i pokazuje, jak je zbierać. Tech lead odpowiada za limit i co sprint przegląda listę wyjątków. Jeśli lead time spada, a change failure rate rośnie, bramki są za słabe na ten wolumen zmian, czyli dokładnie wzorzec opisany w raporcie DORA.

Co się psuje w ciągłej dostawie z AI i jak z tego wyjść

Agent i tak commituje raz, na końcu. Reguła jest w pliku instrukcji, ale długa sesja od niej odpływa. Wyjście: jedna sesja na jedno zadanie, a wynik niech odrzuci check rozmiaru; potem podziel go promptem do stosu gałęzi.
Check rozmiaru staje się formalnością. Każdy duży pull request dostaje etykietę size-exception. Wyjście: wymagaj zdania uzasadnienia w opisie przy każdym wyjątku i przeglądaj listę co sprint; jeśli wyjątki skupiają się w jednym obszarze, zadania w planie są tam za duże.
Zielone checki, osłabione testy. Poprawka agenta przechodzi, bo poluzowano asercję albo pominięto test. Wyjście: dodaj krok CI, który odrzuca usunięte lub pominięte testy, chyba że pull request podaje powód, tak jak opisuje ochrona wyroczni.
Gałęzie ze stosu, które nie budują się samodzielnie. Warstwa bazy danych odwołuje się do modelu, który istnieje dopiero w warstwie API. Wyjście: uruchom pełny zestaw testów na każdej gałęzi stosu, zanim otworzysz jakikolwiek pull request; wymaga tego prompt do podziału.
Agent recenzujący blokuje kolejkę merge’y. Job przeglądu jest wymaganym checkiem, dostawca ma awarię i nic nie wchodzi. Wyjście: daj jobowi timeout i udokumentowane ręczne obejście, a jedyną twardą bramką niech zostaną kontrole deterministyczne.
Wygenerowany YAML workflow odwołuje się do rzeczy, które nie istnieją. Workflow napisany przez agenta przypina starą wersję główną akcji, wymyśla akcję z marketplace’u albo używa secrets.DEPLOY_KEY, którego nikt nie ustawił. Wyjście: wyszukaj w pliku każde odwołanie uses: i secrets., przypinaj akcje do bieżących wersji głównych (actions/checkout@v7 na 2026-09-26), ustaw jawny blok permissions: i uruchom workflow raz na gałęzi do wyrzucenia.
Lokalnie przechodzi, w CI pada. Środowisko agenta różni się od runnera: wersja Node, brakująca zmienna środowiskowa albo usługa, która jeszcze nie wstała. Wyjście: przypnij runtime w repozytorium (na przykład w .node-version) i niech prompt do triage’u sklasyfikuje awarię, zanim ktokolwiek zmieni kod.

Dokąd dalej z ciągłą dostawą

Pakiet dowodów Co musi udowodnić każdy pull request agenta i check CI, który to wymusza.

Code review PR-a agenta Sześciostopniowy triage, który zastępuje czytanie każdej linii.

Progressive delivery Flagi, canary i automatyczny rollback jako siatka pod zmerge’owanymi zmianami agentów.

Automatyzacja pipeline’u z AI Buildy świadome zmian, triage niestabilnych testów i stopniowe wdrożenia w samym pipeline’ie.

Łańcuch artefaktów Plan, którego każde zadanie staje się jednym commitem.

Deploy: bramki przed produkcją Etap cyklu życia, w którym łączą się bramki przeglądu i produkcji.