AI w CI/CD — agent na ścieżce każdego commit

Q13 · Bramki jakości Czy agenci AI są częścią samego CI/CD (poza tym, że developerzy uruchamiają ich lokalnie)?

Odpowiedź na maks: “Pełny pipeline: agent generuje, agent recenzuje, agent testuje, agent deployuje — z twardymi bramkami.”

Dlaczego to ważne: Agenci tylko lokalni to historia o produktywności; agenci w pipeline to historia o organizacji inżynierskiej. Kumulujące się zyski zaczynają się dopiero wtedy, gdy AI jest na ścieżce każdego commit.

Dlaczego to ważne w 2026

W 2026 każda poważna organizacja inżynierska ma agentów na laptopach developerów. Ta część jest załatwiona. To, co odróżnia organizację Coordinated od Strategic Leader na Q13, to czy ci agenci żyją także po stronie serwera — uruchamiani na push, pull_request, schedule, workflow_dispatch, na alertach Sentry, na cronie, na triggerach CodeRabbita. AI Engineering Report 2026 (telemetria 22 000 developerów z 4 000 zespołów) ustalił, że mediana czasu w PR review podskoczyła o 441% rok do roku. Powód: lokalne agenty czterokrotnie podbiły przepustowość PR-ów, a CI zostało takie samo. Wąskie gardło przesunęło się z “pisania kodu” na “wszystko, co dzieje się między pushem a mergem”. Agenci w pipeline to jedyna rzecz, która skaluje także tę stronę.

Pod liczbą o przepustowości kryje się historia kumulacji. Gdy AI jest tylko na laptopie, organizacja dostaje N × zysk_per_dev. Gdy AI jest w pipeline, dostaje N × zysk_per_dev + zysk_pipeline — a zysk_pipeline nie zależy od tego, czy konkretny dev pamiętał, by uruchomić agenta. Dokumentacja jest zsynchronizowana, bo workflow aktualizuje ją na każdym merge’u. Dług lintowy nie narasta, bo job na schedule naprawia go nocą. PR-y dependency są mergowane przez agenta, który zweryfikował upgrade. Ta kumulacja na poziomie organizacji jest tym, co mierzy poziom Strategic Leader.

Asymetria lokalne-vs-pipeline kształtuje też sposób, w jaki zespoły compliance i bezpieczeństwa patrzą na AI. Lokalny agent jest dla nich niewidzialny — każda zmiana pochodzi z konta developera, ślad audytowy wygląda jak w 2020. Agent w pipeline jest odwrotnością: każda akcja to workflow run z zalogowanym triggerem, scope tokena, diffem i wynikiem. To jest ta wersja AI, którą Twój zespół bezpieczeństwa może realnie zatwierdzić.

Jak naprawdę wygląda maksymalny wynik (pipeline w 4 fazach)

Drabina dojrzałości pipeline’owej ma cztery fazy. Poziom Strategic Leader na Q13 robi wszystkie cztery — i robi je pod twardymi bramkami, które blokują merge albo deploy na realnych failurach.

Faza 1 — Generuje. Agenci tworzą kod wewnątrz pipeline’u, nie tylko go recenzują. Przykłady: job workflow_dispatch, który bierze ID z Lineara i otwiera draft PR; job schedule, który nocą ciągnie tickety ai-eligible; workflow triggerowany przez Sentry otwierający fix-PR, gdy issue odpala się na produkcji; PR Renovate’a dorzeźbiony przez agenta robiącego zmiany w call-site’ach. Output to normalny PR — branch, commity, body, etykiety — który płynie przez pipeline jak każda inna zmiana.

Faza 2 — Recenzuje. Agenci recenzują każdy PR (pisany przez człowieka czy agenta), zanim zerknie na niego człowiek. Wzorzec warstwowy z Q9: CodeRabbit / Greptile na statyczny; Claude Code Action / Codex Cloud / Cursor Cloud na architektura-i-intencja; Sentry Seer na ryzyko regresji. Żaden sam nie blokuje merge’a — od tego są twarde bramki — ale razem pokrywają ~70% powierzchni review linijka po linijce.

Faza 3 — Testuje. Agenci uruchamiają testy, nie tylko je piszą. Generują brakujące unit testy. Uruchamiają E2E (Playwright, browser-use, Cypress) i diagnozują failures czytając trace. Uruchamiają skany bezpieczeństwa (Semgrep, CodeQL, Trivy) i albo naprawiają w tym PR, albo otwierają osobny hardeningowy. Uruchamiają budżety wydajnościowe (Lighthouse, k6) i wystawiają regresje z repro. Sedno: agent triażuje failure.

Faza 4 — Deployuje. Agenci są właścicielami ostatniej mili: merge, deploy, weryfikacja po-deploy, rollback na regresji. gh pr merge --squash --delete-branch --auto kolejkuje merge, gdy przejdą wymagane checki; workflow deploy go wypycha; job po-deployowy wali w canary, obserwuje error rate i latency, i albo promuje do 100%, albo robi rollback. Nadzorujący agent czyta Sentry, PostHog i metryki canary. Na regresji robi rollback i otwiera incident PR z kontekstem.

Cokolwiek słabszego — “agenci recenzują PR-y, ale nikt nie uruchamia ich w CI”, “workflow Claude Code odpala się tylko na @-mention”, “agent pisze kod, ale człowiek zawsze mergeuje” — cap-uje Q13 na mid-tier.

Aktualny krajobraz (zweryfikowany przez web search)

Claude Code GitHub Action

Claude Code GitHub Actions to oficjalna akcja Anthropic (code.claude.com/docs/en/github-actions) wpinająca Claude’a w workflow jako pełnoprawnego agenta CI. Wywoływana przez @claude w komentarzach PR/issue, przez etykiety (needs-fix, ai-review) albo przez workflow_dispatch na harmonogramie. Pod spodem to samo Claude Code CLI, którego używasz lokalnie — to samo CLAUDE.md, te same skille i hooki — w trybie headless z -p, więc lokalny kontekst podąża za agentem do pipeline’u. Build 2026 wspiera prompt caching między workflow runs (≈90% redukcji na drugim runie), równoległe sub-agenty przez Claude Agent SDK i zarządzany model uprawnień, gdzie token GitHuba ogranicza, czego agent może dotknąć.

Poważne sklepy hardują akcję przez harden-runner od StepSecurity — firewall egressowy, logi audytu runtime, wykrywanie tamperingu. Sam Claude Code działa bez restrykcji sieciowych out-of-the-box, dlatego firewall jest niezbędny.

Codex Cloud (scheduled + on-trigger)

OpenAI Codex Cloud uruchamia własne sandboxowe środowisko cloud, zamiast wpinać się w Twoje CI. Zlecasz zadania z ChatGPT, Codex CLI albo rozszerzenia IDE; Codex odbija branche, commituje, uruchamia testy w sandboxie i otwiera PR do GitHuba. Build 2026 (codex remote-control, multi-environment view_image, auth Bedrock AWS) dodał schedule (cron) i on-trigger (webhook — alert Sentry, zdarzenie GitHuba). Raportowany success rate na dobrze zazakresowanych ticketach fix-z-jasną-repro to pasmo 85–90% — pasmo, w którym realnie możesz puścić go nocą na wybrany backlog bez cmentarza popsutych PR-ów rano.

Cursor Cloud Agents

Cloud agent Cursora (IDE-owy odpowiednik Codex Cloud) rozciąga lokalnego agenta Cursora na background runs: wybierasz ticket, wysyłasz go do chmury, otwiera PR. W 2026 Cursor, Codex i Claude Code coraz bardziej interoperują — Cursor MCP w Codeksie przez Composio, Claude Code z Cursora, i na odwrót. Implikacja dla CTO: nie musisz wybierać jednego i zapinać całego pipeline’u — uruchamiaj różne fazy na różnych agentach, a PR niech będzie powierzchnią integracji.

Twarde bramki (skan bezpieczeństwa, budżet wydajności, cap kosztu)

Agenci w pipeline bez twardych bramek to sposób, by dowieźć incident w kształcie --no-verify na produkcji. Trzy bramki są nienegocjowalne:

Bramka bezpieczeństwa. Semgrep + CodeQL na każdym PR; workflow failuje na nowych znaleziskach high-severity. Trivy (albo Snyk) na każdym buildzie kontenera; build failuje na nowych depach z high-CVE. Agenci jeżdżą pod tymi bramkami, nie obok.
Bramka wydajności. Lighthouse CI na każdym preview deploy z ciasnymi budżetami (np. LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1). Dla backendu k6 z budżetami latency p95. Failujący budżet blokuje merge.
Bramka kosztu. Cap kosztu AI — workflows Claude Code Action mają per-run budżet tokenowy, który failuje run po przekroczeniu. Cap kosztu runtime — zmiany w infrze idą przez workflow, który szacuje nowy miesięczny rachunek (requesty Workersów, ready D1, egress R2, operacje KV) i failuje bez etykiety --accept-cost-increase.

Agent generuje dokumentację (auto-update README z zmian kodu)

Workflow Phase 1 o najwyższej dźwigni, gdy pipeline jest na miejscu: na każdym merge’u zmieniającym sygnaturę funkcji, publiczny endpoint, env var, flagę CLI albo schemat, workflow ponownie czyta dotknięte pliki i regeneruje odpowiednie sekcje docsów — README, MIGRATIONS, OpenAPI, CLAUDE.md, strony Starlight. Commit bezpośrednio do main albo follow-up PR. Half-life “docsy lekko nieaktualne” spada z kwartałów do godzin.

Agent naprawia PR-y lint / dependency (Renovate + AI fix)

Renovate-plus-agent to drugi najbardziej dźwigniowy workflow Phase 1. Renovate otwiera PR-y dependency (masz to od lat). Nowość 2026: wepnij workflow Claude Code / Codeksa, który uzupełnia te PR-y — gdy Renovate postuje bump, agent uruchamia suite, czyta failures, robi zmiany w call-site’ach, commituje na branch Renovate’a i dopiero wtedy zazielenia PR. Ten sam wzorzec dla reguł ESLint / Ruff / Prettier. Dług lintowy i dependency przestają narastać, bo naprawianie jest mechaniczne.

Krok po kroku: budowanie workflowu AI-w-pipeline

Wybierz najpierw triggery generujące. Zanim wpniesz agenta w CI, zdecyduj, które zdarzenia tworzące PR mają obsługiwać agenci. Minimum: PR-y dependency od Renovate, fix-PR-y triggerowane przez Sentry, schedule’owany nocny run backlogu ciągnący tickety ai-eligible z Lineara, manualny pas workflow_dispatch. Cokolwiek więcej to bonus.
Wpnij Claude Code GitHub Action dla pasów review/fix. Dodaj anthropics/claude-code-action do .github/workflows/claude.yml. Trigger na pull_request, na issue_comment z @claude i na etykietach typu needs-fix/ai-review. Przekaż CLAUDE.md do kontekstu, ustaw per-run budżet tokenowy i zhardenuj runnera przez harden-runner od StepSecurity przed krokiem Claude.
Dodaj Codex Cloud dla pasa nocnej generacji. Skonfiguruj środowisko Codex Cloud na to samo repo. Ustaw schedule (noc, weekend) i webhook on-trigger z Sentry. Taguj tickety Linear ai-eligible. Zdefiniuj per-task budżet tokenowy i timeout sandboxa, żeby zatkany task nie chodził 6 godzin.
Warstwuj boty review przed agentem. CodeRabbit (albo Greptile) na każdym PR na przebieg statyczny. Claude Code Action review na przebieg architektoniczny. Sentry Seer na PR-y dotykające niedawno oflagowanych powierzchni błędu. Kolejność: tanie szybkie boty pierwsze, drogi architektoniczny agent drugi.
Zainstaluj twarde bramki. Semgrep + CodeQL failujące na nowych znaleziskach high-severity. Lighthouse CI na każdym preview z jawnymi budżetami Core Web Vitals. Trivy na każdym buildzie kontenera. Per-run budżet tokenowy w każdym workflow agenta. Wszystkie cztery jako required checks w branch protection.
Auto-merge z --auto. Gdy pętla recheck na PR uspokoi się bez actionable komentarzy, a wymagane checki przejdą, zakolejkuj gh pr merge --squash --delete-branch --auto. --auto czeka na pending checki; nie nadpisuje branch protection. Nigdy nie wciskaj --admin-override z workflowu. Na failu/żądaniu zmian wystaw blocker i zatrzymaj się.
Dodaj weryfikację po-deployową. Na każdym deployu prod follow-up workflow wali w URL-e canary, obserwuje API release Sentry w pierwszych 10 minutach, obserwuje PostHog pod kątem regresji w lejku, robi rollback przez wrangler rollback na regresji. Rollback otwiera incident PR z kontekstem.
Dodaj workflow synchronizacji docsów. Workflow filtrowany paths, odpalający się na merge’ach dotykających powierzchni API (np. src/pages/api/**, src/lib/db/schema.ts). Claude (headless) regeneruje odpowiednie sekcje i commituje z powrotem.
Dodaj workflow Renovate-plus-agent. Workflow odpalający się, gdy Renovate otwiera PR dependency, uruchamiający suite, a na failu wywołujący Claude Code na branchu Renovate’a, by naprawił call-site’y. PR Renovate’a jest zielony, zanim popatrzy na niego człowiek.
Obserwuj wszystko. Wlej telemetrię workflow runów do panelu metryk AI (Q22): spend tokenowy per workflow, success/failure rate, time-to-first-comment, time-to-merge, % PR-ów dotkniętych przez agenta, % PR-ów dotkniętych przez agenta, które się zmergowały. Bez tego nie udowodnisz ROI swojemu CFO na koniec roku.

Częste pułapki

Brak twardych bramek. Dodawanie agentów do pipeline bez bramek bezpieczeństwa, wydajności i kosztu to sposób, by dowieźć incident w stylu --no-verify na skali. Bez Semgrep, CodeQL, Lighthouse i capa tokenowego na każdym workflow agenta nie masz maksymalnego Q13.
Rozbiegani agenci. Workflow bez per-run budżetu tokenowego może spalić $400 tokenów na jednym PR. Ustaw cap tokenowy na każdym kroku, timeout sandboxa na każdym zadaniu Codex Cloud, cap concurrency workflowu, by scheduled run nie zakolejkował dwudziestu swoich kopii.
Brak observability. Jeśli nie potrafisz powiedzieć, ile PR-ów dotknął agent w zeszłym tygodniu, co wydał i ile się zmergowało, agent jest niewidzialny. Wepnij telemetrię workflow w panel metryk AI od pierwszego dnia.
Agent mergeujący do main bez checków. gh pr merge --auto to dobry ruch; gh pr merge --admin nigdy nie jest dobrym ruchem z automatycznego workflowu. Cały sens --auto to czekanie na wymagane checki.
Mieszanie generacji i review w jednym workflow. Gdy ten sam workflow otwiera i recenzuje PR, review jest strukturalnie skompromitowane. Rozdziel pasy; nie dziel stanu poza samym PR-em.
Brak fallbacku na failure agenta. Gdy workflow Claude Code Action failuje (rate limit, awaria, crash), skonfiguruj continue-on-error: true na kroku agenta tam, gdzie właściwe, posttuj jasny komentarz “agent nie zadziałał, wymagany human review” i blokuj merge na twardych bramkach, a nie na nieobecności agenta.
Pipeline agenty tylko na jednym repo. Zbuduj workflowy raz, podaj je do każdego repo przez template w stylu dotfiles. Inaczej wyniki dziko rozjeżdżają się per projekt.
Brak opt-outu. Etykieta skip-ai albo marker [skip-ai] omijający workflowy agenta (ale nie twarde bramki) jest niezbędny — bez niego agenci stają się tarciem zamiast dźwignią.

Jak zweryfikować, że tam jesteś

Do dalszej lektury

Q9 · Automatyzacja PR review w zespole Wzorzec warstwowego review stojący przed każdym merge'em — CodeRabbit / Greptile + Claude Code Action / Codex / Sentry Seer + ultrareview.

Q12 · Polityka E2E Jak agenci sami uruchamiają testy przeglądarkowe przed mergem — testowa połowa historii o agentach w pipeline.

Q15 · Tier 3 nocne runy Pas scheduled-generation: wybrany backlog 'AI eligible', scheduled runy, review-on-arrival rano.

CTO Scorecard 25 pytań, ~12 minut. Ocena tieru + plan 30/60/90 + rejestr ryzyk.