Przejdź do głównej zawartości
AI Developer Toolkit

Ciągła dostawa z pomocą AI

Ciągła dostawa z pomocą AI oznacza dostarczanie małych, zweryfikowanych zmian w sposób ciągły i oddanie agentowi klejącej roboty wokół potoku: wiadomości commitów, opisów PR-ów, przeglądu diffów, YAML-a workflow, bramek wdrożeniowych i notatek wydania. Dyscypliną, która to umożliwia, jest commitowanie po każdym ukończonym zadaniu, a nie po całej funkcjonalności.

Spędziłeś cztery godziny, budując funkcjonalność w pojedynczej sesji AI. Diff ma 1200 linii w 18 plikach. Pierwszy komentarz recenzenta brzmi „czy możesz rozdzielić to na mniejsze PR-y?”, a nie możesz, bo zmiany są ze sobą splątane. Potem PR leży dwa dni, czekając na recenzenta, wdrożenie wymaga trzech ręcznych zatwierdzeń w dwóch kanałach Slacka, notatki wydania wciąż są TODO, a w noc, gdy CI zrobiło się czerwone, nikt nie zrobił triage’u aż do standupu.

Ciągła dostawa jest antidotum na wielkie feature branche, a jej zasada jest prosta: dostarczaj małe, zweryfikowane zmiany tak często, jak to możliwe. Zespoły tego nie robią, bo klejąca robota między scalonym PR-em a produkcją — przeglądy, YAML, bramki, changelog, triage awarii — to dokładnie ta mordęga, której nikt nie chce brać na siebie.

I właśnie na tej klejącej robocie asystent AI zarabia na siebie. Nie „AI pisze twoją aplikację”, tylko AI jako niestrudzony recenzent, autor wiadomości commitów, generator YAML-a i pierwszy reagujący, wpięty prosto w potok.

Co daje ciągła dostawa z pomocą AI

Dział zatytułowany „Co daje ciągła dostawa z pomocą AI”
  • Dyscyplinę przyrostowego commitowania, która utrzymuje diffy od AI w stanie nadającym się do przeglądu
  • Prompty do wiadomości commitów, opisów PR-ów, notatek wydania i wpisów do changelogu
  • Prawdziwy krok GitHub Actions uruchamiający Claude Code headless na diffie każdego PR-a
  • Gotowe prompty do generowania YAML-a potoku, blokowania wdrożenia i triage’u czerwonego buildu — po jednym na narzędzie
  • Podział Cursor / Claude Code / Codex: gdzie każde narzędzie pasuje w potoku
  • Tryby awarii, które potoki generowane przez AI trafiają na produkcji, i kontrole, które je wyłapują

Commituj po każdym zadaniu, a nie po każdej funkcjonalności

Dział zatytułowany „Commituj po każdym zadaniu, a nie po każdej funkcjonalności”

Pojedynczy najbardziej wpływowy nawyk: commituj po każdym udanym zadaniu, a nie po całej funkcjonalności. Jeśli stosujesz metodologię od PRD przez plan do listy zadań, każdy element listy powinien skutkować jednym commitem. To właśnie robi różnicę między splątanym diffem na 1200 linii a stosem zmian, który recenzent faktycznie przeczyta.

Po każdym ukończonym zadaniu poproś Cursora 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 uruchamia git add i git commit bezpośrednio z trybu Agent. Dla szybszego przepływu oddaj commity agentowi Cloud Agent (dawniej Background Agent), a sam przejdź do kolejnego zadania.

Zamiana gałęzi w PR do przejrzenia

Dział zatytułowany „Zamiana gałęzi w PR do przejrzenia”

Pull requesty to miejsce, gdzie odbywa się przegląd, a dobrze udokumentowany PR jest przeglądany szybciej niż goły. Agent ma diff, więc może napisać opis, który naprawdę pomoże recenzentowi.

Po wypchnięciu gałęzi poproś Cursora o otwarcie PR-a — z trybu Agent steruje CLI gh:

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.

Dzielenie zbyt dużego diffa na PR-y w stosie

Dział zatytułowany „Dzielenie zbyt dużego diffa na PR-y w stosie”

Czasem sesja produkuje zmianę, która powinna być trzema PR-ami. Zamiast ręcznie rozplątywać historię gita, zleć tę operację agentowi.

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.

Recenzent na każdym PR-ze

Dział zatytułowany „Recenzent na każdym PR-ze”

Automatyczny przegląd PR-ów to miejsce o najwyższej dźwigni, od którego warto zacząć automatyzację samego potoku: jest niskiego ryzyka (tylko komentarze, żadnych wdrożeń) i zwraca się już pierwszego dnia. Te trzy narzędzia zajmują tu różne powierzchnie, więc wybieraj na podstawie tego, gdzie twój zespół już mieszka.

BugBot Cursora przegląda PR-y automatycznie po włączeniu na repozytorium i wystawia komentarze inline na temat prawdopodobnych błędów. Ponów przegląd na żądanie, komentując bugbot run w PR-ze. Gdy coś oznaczy, Autofix (GA od lutego 2026) potrafi uruchomić w tle agenta Cloud Agent, który otwiera kolejny PR z proponowaną poprawką — tak że recenzent zatwierdza diff, zamiast go pisać. Od maja 2026 BugBot rozlicza się za przegląd (mniej więcej $1.20 za przebieg o domyślnym wysiłku, więcej przy dużych diffach) w planach Teams i Individual, zamiast dawnej stałej opłaty za stanowisko.

Używaj Cursora, gdy twój zespół przegląda w interfejsie GitHuba i chce, by poprawki były proponowane jako PR-y, które można obejrzeć.

Oto prawdziwy, minimalny krok GitHub Actions, który uruchamia Claude Code w trybie headless na diffie PR-a. Flagi są tu częścią nośną: --allowedTools (nie --allow-tools) ogranicza to, czego agent może dotknąć, a --output-format json (nie --json) sprawia, że wynik da się sparsować w dalszych krokach.

.github/workflows/ai-review.yml
name: AI PR Review
on: pull_request
permissions:
  contents: read
  pull-requests: write
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0
      - name: Run Claude Code review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > /tmp/pr.diff
          npx -y @anthropic-ai/claude-code -p \
            "Review the diff in /tmp/pr.diff for security issues, logic bugs, and missing error handling. Be specific and cite file:line. Skip style nits." \
            --allowedTools "Read,Grep,Bash(git diff:*)" \
            --output-format json > review.json

Cała rzecz polega na odwróceniu: nie wklejasz diffa do okna czatu. To potok podaje diff agentowi i przechwytuje ustrukturyzowane wyjście, które możesz wystawić jako komentarz albo na którym możesz wywalić joba.

Generuj potok, zamiast pisać go ręcznie

Dział zatytułowany „Generuj potok, zamiast pisać go ręcznie”

Nikt nie powinien pisać YAML-a CI z pustego pliku. Opisz potok zwykłym językiem, pozwól agentowi go wyemitować, a potem przejrzyj wynik względem swojego prawdziwego runnera i nazw sekretów.

W trybie Agent agent może odczytać twój package.json i istniejące .github/workflows, więc dopasuje się do prawdziwych skryptów i wersji Node zamiast zgadywać:

Create .github/workflows/ci.yml. Read package.json first to use the real
script names and Node version. The workflow should: install deps with
npm ci, run npm run lint, run npm run test (Vitest), then build a Docker
image only on pushes to main. Use actions/checkout@v6 and
actions/setup-node@v6. Cache npm. Do not invent scripts that aren't
in package.json.

Bramka wdrożenia z człowiekiem w pętli

Dział zatytułowany „Bramka wdrożenia z człowiekiem w pętli”

Pełne automatyczne wdrożenie to ostatnia rzecz, którą się przyjmuje, nie pierwsza. Zacznij od tego, że agent przygotowuje wdrożenie i uruchamia kontrole przed startem, a potem przekazuje człowiekowi ostateczne „tak”. Zatwierdzenie może żyć w Slacku, w regule ochrony środowiska GitHuba albo w czacie z samym agentem.

Przy notatkach wydania daj agentowi zakres commitów i format, a nie ogólnikowe „podsumuj”:

Triage czerwonego buildu

Dział zatytułowany „Triage czerwonego buildu”

Agent przydaje się też na samym potoku, a czerwony build o drugiej w nocy to przypadek, w którym pierwszy reagujący, który nigdy nie śpi, naprawdę pomaga. Ograniczenie w prompcie znaczy tu więcej niż sama diagnoza: bez niego najszybszą drogą do zielonego ptaszka jest skasowanie testu.

Gdzie ciągła dostawa z pomocą AI zawodzi

Dział zatytułowany „Gdzie ciągła dostawa z pomocą AI zawodzi”

Dokąd pójść dalej z ciągłą dostawą

Dział zatytułowany „Dokąd pójść dalej z ciągłą dostawą”
Potoki CI/CD Głębsze wzorce budowania samego potoku.
Reagowanie na incydenty Gdy wdrożenie pójdzie nie tak i potrzebujesz agenta do triage'u.
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.

Autor:

Zobacz co nowego na platformie.

Polityka prywatności Regulamin Ustawienia cookie