Ciagla dostawa z pomoca AI

Spedziles cztery godziny budujac funkcjonalnosc w pojedynczej sesji AI. Diff ma 1200 linii w 18 plikach. Otwierasz PR, a pierwszy komentarz recenzenta brzmi “Czy mozesz rozdzielic to na mniejsze PR-y?” Nie mozesz, bo zmiany sa ze soba splatane. Testy przechodza lokalnie, ale nie w CI, bo zapomniałes dodac nowa zmienna srodowiskowa. Teraz debugujesz CI, podczas gdy twoja funkcjonalnosc tkwi w limbo przegladow.

Ciagla dostawa jest antidotum na wielkie feature branche. Zasada jest prosta: dostarczaj male, zweryfikowane zmiany tak czesto, jak to mozliwe. AI sprawia, ze jest to latwiejsze, nie trudniejsze, poniewaz moze automatyzowac powtarzalne czesci pipeline’u dostawy — pisanie wiadomosci commitow, generowanie opisow PR-ow, uruchamianie kontroli przed scaleniem, a nawet dzielenie duzych zmian na przegladalne fragmenty.

Czego sie nauczysz

Przeplyw pracy do commitowania i dostarczania zmian generowanych przez AI przyrostowo
Prompty do automatycznych wiadomosci commitow, opisow PR-ow i wpisow w changelogu
Strategie integracji AI z twoim pipeline’em CI/CD
Techniki dzielenia duzych diffow generowanych przez AI na przegladalne PR-y

Dyscyplina przyrostowego commitowania

Pojedynczy najbardziej wplywowy nawyk dla ciaglej dostawy z AI: commituj po kazdym udanym zadaniu, a nie po calej funkcjonalnosci. Jesli stosujesz metodologie PRD-Plan-Todo, kazdy element listy zadan powinien skutkowac jednym commitem.

Po kazdym ukonczonym zadaniu popros Cursor o commit z sensowna wiadomoscia:

The rate limiter implementation passes all tests. Commit this change
with a descriptive commit message following our conventional commits
format (feat/fix/chore). Include what changed and why.

Cursor moze uruchomiac git add i git commit bezposrednio z trybu Agent. Dla jeszcze szybszego przepływu wlacz Background Agent do obslugi commitow, podczas gdy ty przechodzisz do nastepnego zadania.

Claude Code doskonale radzi sobie z przeplywami pracy git. Po kazdym zadaniu:

All tests pass. Commit this change with a conventional commit message.
Stage only the files related to the rate limiter task. Do not stage
unrelated changes.

Dla bezobslugowej integracji CI, Claude Code moze commitowac automatycznie:

claude -p "Run the linter and tests. If they pass, commit with a descriptive message."

Claude Code obsluguje rowniez hooki, ktore moga automatycznie formatowac kod przed kazdym commitem, zapewniajac spojny styl bez recznej interwencji.

Codex moze commitowac i nawet tworzyc PR-y bezposrednio:

All tests pass for the rate limiter. Commit the changes with a
conventional commit message. Then create a draft PR with a
summary of what changed and how to test it.

Integracja Codex z GitHub swietnie sie tu sprawdza. Z poziomu aplikacji mozesz wypchnac commit, utworzyc PR i nawet poprosic o przeglad w jednym prompcie. Watki cloudowe moga obsluzyc tworzenie PR, podczas gdy ty kontynuujesz prace lokalnie.

I've completed [TASK DESCRIPTION]. Before committing:

1. Run the linter (npm run lint)
2. Run the type checker (npm run type-check)
3. Run relevant tests (npm test -- --testPathPattern=[PATTERN])
4. If all pass, stage only the relevant files (not node_modules, .env, etc.)
5. Commit with a conventional commit message: type(scope): description
6. Show me the commit hash and summary

Do not push yet. I want to review the commit before pushing.

Automatyzacja tworzenia PR-ow

Pull requesty to miejsce, gdzie odbywa sie przeglad kodu. Im szybciej mozesz utworzyc dobrze udokumentowany PR, tym szybciej twoj kod zostanie przegladniety i scalony. AI moze generowac opisy PR-ow, ktore naprawde pomagaja recenzentom zrozumiec zmiane.

Po wypchnięciu brancha popros Cursor o utworzenie PR:

Push the current branch and create a PR against main.

For the PR description:
1. Summarize what this PR does and why
2. List the key files changed with a brief explanation of each
3. Include testing instructions
4. Mention any deployment considerations (new env vars, migrations)

Use our PR template format.

Cursor moze uzywac CLI gh do tworzenia PR-ow bezposrednio z trybu Agent.

Przeplyw PR w Claude Code jest sprawdzony w boju:

Push this branch and create a PR against main using gh.

Write the PR description covering:
- Summary of changes
- Key decisions and trade-offs
- Testing done (include test output)
- Deployment notes (migrations, env vars, feature flags)

Use conventional PR title format.

Dla integracji CI, Claude Code moze dzialac w trybie bezobslugowym jako czesc twojego pipeline’u:

claude -p "Review the current diff against main. Generate a PR description." --output-format json

Codex ma natywna integracje z GitHub dla przeplywow PR:

Create a pull request for the current branch against main.

Include:
- Summary of what changed and why
- Files changed with explanations
- Test coverage information
- Any breaking changes or deployment requirements

Add relevant labels and request review from the team.

Codex moze byc rowniez uruchamiany ze Slack lub Linear do tworzenia PR-ow z opisow zadan, zamykajac petle miedzy zarzadzaniem projektem a dostawa kodu.

Generate a PR description for the current branch. Run git diff main...HEAD
to see all changes. Structure the description as:

## Summary
[1-2 sentence overview of the change]

## Changes
[Bulleted list of key changes with file names]

## Testing
[How this was tested, include relevant test commands]

## Deployment
[Any deployment considerations: new env vars, migrations, feature flags]

## Screenshots
[If UI changes, note that screenshots should be added]

Dzielenie duzych zmian

Czasami sesja AI produkuje duza zmiane, ktora powinna byc wieloma PR-ami. Zamiast probowac reczenie rozplatac historie git, popros AI o pomoc w podziale.

The current branch has changes across the database layer, API layer,
and frontend. Help me split this into three separate PRs that can
be reviewed and merged independently:

1. PR 1: Database migration and model changes
2. PR 2: API endpoint changes (depends on PR 1)
3. PR 3: Frontend changes (depends on PR 2)

Create a new branch for PR 1 with only the database changes.

The current diff is too large for a single PR. Help me split it:

1. Run git diff --stat to see all changed files
2. Group files by layer (db, api, frontend)
3. Create branch feature/rate-limiter-db with only database changes
4. Create branch feature/rate-limiter-api with API changes
5. Create branch feature/rate-limiter-ui with frontend changes

Each branch should be independently testable. Start with the
database branch.

The diff on this branch is too large. Split it into stacked PRs:

1. Database layer changes (first to merge)
2. API layer changes (stacks on database PR)
3. Frontend changes (stacks on API PR)

Create separate branches for each. Make sure each branch's tests
pass independently. Create draft PRs with dependencies noted.

Obsluga worktree w Codex sprawia, ze jest to szczegolnie plynne — kazdy PR moze byc rozwijany i testowany we wlasnym worktree bez przelaczania branchow.

Integracja z pipeline’em CI

AI nie sluzy tylko do pisania kodu. Moze pomoc ci utrzymywac i debugowac sam pipeline CI.

Our CI pipeline failed on this PR. Here is the error output:
[paste CI log]

1. Identify the root cause of the failure
2. Determine if this is a code issue or a CI configuration issue
3. If code: fix it and push
4. If CI config: explain what needs to change in the pipeline
5. If flaky test: identify why it's flaky and propose a fix

Do not skip failing tests or add retry logic as a band-aid.

Kiedy to nie dziala

Commity sa zbyt granularne. Commitowanie po kazdej pojedynczej zmianie linii tworzy szum. Odpowiednia granularnosc to jedna logiczna zmiana na commit — pojedynczy element listy zadan, naprawa bledu, refaktoryzacja. Jesli wiadomosc commita wymaga “i” do opisania, co sie zmienilo, to prawdopodobnie jest za duzy.

PR-y sa automatycznie scalane bez przegladow. AI moze tworzyc PR-y szybko, ale szybkosc nie jest zamiennikiem ludzkiego przeglądu. Kazdy PR powinien byc przegladniety przez czlowieka przed scaleniem na produkcje. Uzywaj draft PR-ow dla pracy w toku.

CI przechodzi lokalnie, ale nie w CI. Najczestsza przyczyna to roznice srodowiskowe. Upewnij sie, ze twoje srodowisko CI odpowiada lokalnemu (wersja Node, zmienne srodowiskowe, stan bazy danych). Dodaj krok “sprawdzenie srodowiska CI” do swojego pipeline’u.

AI generuje niepoprawne wiadomosci commitow. Wiadomosci commitow generowane przez AI moga byc zbyt ogolnikowe (“update files”) lub zbyt rozwlekle. Umiesc konwencje wiadomosci commitow swojego zespolu w CLAUDE.md, .cursor/rules lub AGENTS.md, aby AI stosowal twoj format.

Co dalej

Od PRD przez plan do listy zadan Metodologia planowania, ktora produkuje czyste, przyrostowe listy zadan dla ciaglej dostawy.

Czlowiek w petli Jak efektywnie przegladac PR-y generowane przez AI bez stawania sie waskim gardlem.

Koszt kontekstu Zrozum implikacje kosztowe uruchamiania AI w twoim pipeline CI.