Ciągła dostawa z pomocą AI

Spędziłeś cztery godziny budując funkcjonalność w pojedynczej sesji AI. Diff ma 1200 linii w 18 plikach. Otwierasz PR, a pierwszy komentarz recenzenta brzmi “Czy możesz rozdzielić to na mniejsze PR-y?” Nie możesz, bo zmiany są ze sobą splątane. Testy przechodzą lokalnie, ale nie w CI, bo zapomniałeś dodać nową zmienną środowiskową. Teraz debugujesz CI, podczas gdy twoja funkcjonalność tkwi w limbo przeglądów.

Ciągła dostawa jest antidotum na wielkie feature branche. Zasada jest prosta: dostarczaj małe, zweryfikowane zmiany tak często, jak to możliwe. AI sprawia, że jest to łatwiejsze, nie trudniejsze, ponieważ może automatyzować powtarzalne części pipeline’u dostawy — pisanie wiadomości commitów, generowanie opisów PR-ów, uruchamianie kontroli przed scaleniem, a nawet dzielenie dużych zmian na przeglądalne fragmenty.

Czego się nauczysz

Przepływ pracy do commitowania i dostarczania zmian generowanych przez AI przyrostowo
Prompty do automatycznych wiadomości commitów, opisów PR-ów i wpisów w changelogu
Strategie integracji AI z twoim pipeline’em CI/CD
Techniki dzielenia dużych diffów generowanych przez AI na przeglądalne PR-y

Dyscyplina przyrostowego commitowania

Pojedynczy najbardziej wpływowy nawyk dla ciągłej dostawy z AI: commituj po każdym udanym zadaniu, a nie po całej funkcjonalności. Jeśli stosujesz metodologię PRD-Plan-Todo, każdy element listy zadań powinien skutkować jednym commitem.

Po każdym ukończonym zadaniu poproś Cursor o commit z sensowną wiadomością:

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 może uruchamiać git add i git commit bezpośrednio z trybu Agent. Dla jeszcze szybszego przepływu włącz Background Agent do obsługi commitów, podczas gdy ty przechodzisz do następnego zadania.

Claude Code doskonale radzi sobie z przepływami pracy git. Po każdym 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 bezobsługowej integracji CI, Claude Code może commitować automatycznie:

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

Claude Code obsługuje również hooki, które mogą automatycznie formatować kod przed każdym commitem, zapewniając spójny styl bez ręcznej interwencji.

Codex może commitować i nawet tworzyć PR-y bezpośrednio:

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 świetnie się tu sprawdza. Z poziomu aplikacji możesz wypchnąć commit, utworzyć PR i nawet poprosić o przegląd w jednym prompcie. Wątki cloudowe mogą obsłużyć tworzenie PR, podczas gdy ty kontynuujesz pracę 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-ów

Pull requesty to miejsce, gdzie odbywa się przegląd kodu. Im szybciej możesz utworzyć dobrze udokumentowany PR, tym szybciej twój kod zostanie przejrzany i scalony. AI może generować opisy PR-ów, które naprawdę pomagają recenzentom zrozumieć zmianę.

Po wypchnięciu brancha poproś 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 może używać CLI gh do tworzenia PR-ów bezpośrednio z trybu Agent.

Przepływ 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 może działać w trybie bezobsługowym jako część twojego pipeline’u:

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

Codex ma natywną integrację z GitHub dla przepływów 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 może być również uruchamiany ze Slack lub Linear do tworzenia PR-ów z opisów zadań, zamykając pętlę między zarządzaniem projektem a dostawą 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 dużych zmian

Czasami sesja AI produkuje dużą zmianę, która powinna być wieloma PR-ami. Zamiast próbować ręcznie rozplątać historię git, poproś 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.

Obsługa worktree w Codex sprawia, że jest to szczególnie płynne — każdy PR może być rozwijany i testowany we własnym worktree bez przełączania branchów.

Integracja z pipeline’em CI

AI nie służy tylko do pisania kodu. Może pomóc ci utrzymywać i debugować 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 działa

Commity są zbyt granularne. Commitowanie po każdej pojedynczej zmianie linii tworzy szum. Odpowiednia granularność to jedna logiczna zmiana na commit — pojedynczy element listy zadań, naprawa błędu, refaktoryzacja. Jeśli wiadomość commita wymaga “i” do opisania, co się zmieniło, to prawdopodobnie jest za duży.

PR-y są automatycznie scalane bez przeglądów. AI może tworzyć PR-y szybko, ale szybkość nie jest zamiennikiem ludzkiego przeglądu. Każdy PR powinien być przejrzany przez człowieka przed scaleniem na produkcję. Używaj draft PR-ów dla pracy w toku.

CI przechodzi lokalnie, ale nie w CI. Najczęstsza przyczyna to różnice środowiskowe. Upewnij się, że twoje środowisko CI odpowiada lokalnemu (wersja Node, zmienne środowiskowe, stan bazy danych). Dodaj krok “sprawdzenie środowiska CI” do swojego pipeline’u.

AI generuje niepoprawne wiadomości commitów. Wiadomości commitów generowane przez AI mogą być zbyt ogólnikowe (“update files”) lub zbyt rozwlekłe. Umieść konwencje wiadomości commitów swojego zespołu w CLAUDE.md, .cursor/rules lub AGENTS.md, aby AI stosował twój format.

Co dalej

Od PRD przez plan do listy zadań Metodologia planowania, która produkuje czyste, przyrostowe listy zadań dla ciągłej dostawy.

Człowiek w pętli Jak efektywnie przeglądać PR-y generowane przez AI bez stawania się wąskim gardłem.

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