GitHub se v průběhu posledního roku proměnil z úložiště kódu v AI platformu. AI agenti mohou samostatně opravovat nahlášené chyby, reagovat na komentáře v PR a průběžně udržovat kvalitu repozitáře. Nejnovějším přístupem je Github Agentic Workflow, existuje ale celá řada přístupů od třetích stran. Jak tedy nechat váš kód opravovat AI?
Takže pro představu. Vedle nativních nástrojů GitHubu existuje rostoucí ekosystém třetích stran, od open source řešení jako SWE-agent (spíše orientační) a OpenCode po komerční platformy jako Devin nebo CodeRabbit. Tento článek mapuje dostupné vrstvy automatizace, srovnává je a ukazuje, jak je prakticky nastavit, včetně toho, kde jsou limity a co zatím nefunguje tak hladce, jak by si marketingové materiály přály (a my s nimi)…
Copilot Autofix: automatické opravy bezpečnostních chyb
Nejjednodušší vrstvou automatizace je Copilot Autofix, součást GitHub Advanced Security. Funguje tak, že při každém pull requestu skenuje kód pomocí CodeQL, identifikuje bezpečnostní zranitelnosti a přímo v PR nabídne opravu jako návrh, který lze jedním kliknutím commitnout.
Copilot Autofix podporuje jazyky C#, C/C++, Go, Java/Kotlin, Swift, JavaScript/TypeScript, Python, Ruby a Rust. Pro open source projekty je zdarma, pro soukromé repozitáře vyžaduje licenci Advanced Security. Ve výchozím stavu je povolený pro každý repozitář využívající CodeQL, takže nastavení spočívá v zapnutí Code Scanning.
Zásadní omezení: Copilot Autofix řeší výhradně bezpečnostní zranitelnosti detekované CodeQL. Neřeší obecné chyby logiky, datové problémy ani UI bugy. GitHub sám upozorňuje, že opravy fungují na principu nejlepšího úsilí a nejsou zaručeny na 100 %. Vývojář musí každý návrh projít a ověřit, že zachovává zamýšlené chování aplikace. Berte to tedy spíše jako drobnou pomoc, než strukturální změnu.
Copilot Coding Agent: přiřaďte issue agentovi
Druhá vrstva je podstatně ambicióznější. Copilot Coding Agent je autonomní agent, kterému přiřadíte GitHub issue a on na pozadí samostatně analyzuje problém, napíše kód a otevře draft pull request. Od léta 2025 je obecně dostupný pro všechny placené plány Copilot (Pro, Pro+, Business, Enterprise).
Pracovní cyklus vypadá takto: přiřadíte @copilot jako assignee na issue (nebo zmíníte @copilot v komentáři existujícího PR, klidně můžete delegovat ze svého vývojového prostředí či třeba Slacku). Agent analyzuje popis issue a strukturu repozitáře, pracuje v izolovaném prostředí napojeném na GitHub Actions, kde může prozkoumávat kód, provádět změny, spouštět testy a lintery. Když dokončí práci, agent otevře draft PR a požádá vás o review. Na základě vašich komentářů může iterovat.
Nastavení je přímočaré: v nastavení organizace nebo repozitáře povolíte Copilot Coding Agent v sekci Policies. Pro Business a Enterprise plány to musí udělat administrátor. Účtování probíhá přes GitHub Actions minuty a prémiové požadavky (premium requests), což u intenzivního používání může být nezanedbatelná položka.
Copilot Coding Agent při práci automaticky prohání kód přes GitHub secret protection, code security a supply chain security nástroje, takže základní bezpečnostní kontrola je součástí procesu. Agent ale není omezen na bezpečnostní opravy – lze mu zadat libovolné issue, od opravy datové chyby po refaktoring nebo implementaci nové funkce.
GitHub Agentic Workflows: průběžná automatizace repozitáře
Třetí a nejnovější vrstvou jsou GitHub Agentic Workflows, dostupné od února 2026 v technické preview. Jde o systém, kde automatizaci popisujete v Markdownu a ta běží jako GitHub Actions workflow s AI agentem.
Princip je odlišný od předchozích dvou vrstev. Místo jednorázového přiřazení issue agentovi definujete průběžné automatizace, které se spouštějí na základě triggerů (nový issue, schedule, CI selhání). Soubor .github/workflows/nazev.md obsahuje YAML frontmatter s konfigurací (trigger, oprávnění, povolené výstupy, nástroje) a Markdown instrukce v přirozeném jazyce popisující, co má agent dělat.
GitHub tyto automatizace sdružuje pod pojem „Continuous AI” a definuje šest základních kategorií:
- průběžný triage issues (automatické označování směrování a sumarizace nových issues)
- průběžná údržba dokumentace (synchronizace README a dokumentace se změnami v kódu)
- průběžné zjednodušování kódu (identifikace zlepšení a otevírání PR)
- průběžné zlepšování testů (hodnocení pokrytí a přidávání testů)
- průběžná kontrola kvality (analýza CI selhání a návrhy oprav)
- průběžný reporting (zprávy o stavu repozitáře).
Bezpečnostní model je navržen konzervativně. Workflow běží s read-only oprávněními ve výchozím stavu. Zápisy vyžadují explicitní schválení přes takzvané „safe outputs”, což jsou předem definované a revidovatelné GitHub operace (vytvoření PR, komentář k issue). Prostředí je sandboxované se seznamy povolených nástrojů a izolací od sítě. Jako LLM lze nakonfigurovat Copilot CLI, Claude Code nebo OpenAI Codex.
Nastavení vyžaduje instalaci rozšíření gh-aw pro GitHub CLI, vytvoření .md workflow souboru, jeho kompilaci do lock souboru příkazem gh aw compile a commit do repozitáře. Alternativně lze workflow vytvořit interaktivně s pomocí kódovacího agenta. GitHub doporučuje začít s výstupy s nízkým rizikem (komentáře, reporty, drafty) a teprve postupně přecházet k vytváření PR.
Agentic Workflows jsou navrženy jako doplněk k existujícímu CI/CD, ne jako náhrada. Nepřebírají build, test ani release pipeline. Jejich přidaná hodnota je v úlohách, které vyžadují uvažování a které tradiční YAML workflow nedokáže vyjádřit.
Je ovšem nutné připomenout, že tato funkcionalita v Githubu je zatím technické preview, můžete narazit na obtíže a především malou zkušenost s touto funkcionalitou v komunitě. Nicméně vyzkoušejte dokumentaci - a přikažte Claude Code, aby si ji prošlo a navrhlo vám konkrétní využití pro váš projekt. Proč byste si implementaci měli vymýšlet sami…😎
Nástroje třetích stran: kdo umí opravit kód
Mimo ekosystém GitHubu existuje řada nástrojů, které dokáží převzít nahlášené issue a vytvořit PR s opravou. Liší se mírou integrace, cenou a tím, zda jsou open source.
Devin AI a samoopravující se PR
Devin AI od firmy Cognition přistupuje k problému z jiného úhlu. Místo toho, aby agent jen reagoval na issue, zavádí koncept „Self-Healing PR” – samoopravujícího se pull requestu. Smyčka funguje tak, že Devin napíše kód a vytvoří PR, review bot (linter, bezpečnostní skener, SonarQube, Codacy nebo vlastní Devin Review) okomentuje nalezené problémy, Devin přečte komentář a pushne opravu, CI běží znovu a pokud se objeví další problém, cyklus se opakuje.
Klíčový detail: ve výchozím stavu Devin ignoruje všechny komentáře od botů. Konkrétní boty, na které má reagovat, přidáváte do allowlistu. Komentáře o selhání linteru se zpracovávají vždy bez ohledu na nastavení, protože jde o nejčastější mechanickou opravu s nejnižším rizikem nekonečné smyčky.
Devin je komerční platforma mimo GitHub ekosystém. Oproti nativním GitHub nástrojům nabízí propracovanější smyčku agent-reviewer, ale za cenu vendor lock-in a samostatného účtování. Cena začíná u 20$ měsíčně a skáče podle reálně využitého času agenta.
OpenCode: open source agent s otevřenými modely
OpenCode je open source kódovací AI agent, který se instaluje jako GitHub App a reaguje na příkaz /oc nebo /opencode v komentáři u issue nebo PR. Umí vytvořit PR z issue, opravit kód na základě review komentářů a automaticky triagovat nové issues. Běží v GitHub Actions runnerech, takže nevyžaduje vlastní infrastrukturu.
Zajímavá je podpora otevřených modelů přes Hugging Face Inference Providers. Místo závislosti na OpenAI nebo Anthropic API lze použít modely jako DeepSeek, GLM-4.5 nebo Kimi K2. To snižuje náklady a eliminuje vendor lock-in na straně poskytovatele LLM.
Nastavení probíhá příkazem opencode setup github, který provede instalaci GitHub App, vytvoření workflow souboru a konfiguraci secrets. Na veřejných repozitářích je třeba počítat s tím, že kdokoli může spustit bota komentářem /oc, což může vést k nečekaným nákladům na inference.
SWE-agent: výzkumný nástroj z Princetonu
SWE-agent je open source projekt z Princeton University, publikovaný na NeurIPS 2024. Vezme GitHub issue a pokusí se ho automaticky opravit pomocí zvoleného jazykového modelu (GPT-4o, Claude Sonnet a další). Minimalistická varianta mini-swe-agent o zhruba 100 řádcích kódu dosahuje přes 74 % na benchmarku SWE-bench verified.
SWE-agent je primárně výzkumný nástroj a benchmark. Nemá nativní GitHub App integraci jako OpenCode nebo Copilot, takže jeho nasazení do produkčního workflow vyžaduje vlastní orchestraci. Je ale cenný jako referenční bod pro hodnocení kvality ostatních nástrojů a jako základ pro vlastní řešení.
Ellipsis: review i oprava v jednom
Ellipsis je komerční nástroj (YC startup), který nejen recenzuje PR, ale umí nalezené chyby sám opravit. Označení @ellipsis-dev v komentáři spustí vícekrokový proces: agent přečte kód, detekuje chyby, vygeneruje opravu a ověří, že prochází kompilací a testy. Oproti čistě review nástrojům tak pokrývá celý cyklus od nalezení po opravu.
Aider + GitHub Actions: open source alternativa
Aider je open source kódovací asistent, pro který existuje komunitní GitHub Action. Po přiřazení labelu aider k issue se automaticky spustí akce, která vytvoří branch s opravou a otevře PR. Aider optimalizuje náklady tím, že pracuje s diffy místo celých souborů a posílá mapu projektu místo kompletního obsahu. Díky tomu jsou náklady na API volání relativně nízké i na větších kódových základnách.
AIPR: minimalistická GitHub Action
AIPR je jednoduchá akce z GitHub Marketplace, která na label „AIPR” zavolá OpenAI API a vytvoří PR s řešením. Zásadní omezení: pracuje jen s jedním souborem, takže se hodí výhradně pro triviální opravy. Pro cokoli komplexnějšího je nepoužitelná.
Nástroje pro review PR
Samostatnou kategorii tvoří nástroje, které PR neupravují, ale recenzují. Jejich role je odlišná, ale komplementární k opravným agentům.
CodeRabbit je nejrozšířenější AI review bot s více než milionem připojených repozitářů. Automaticky recenzuje každý PR inline komentáři, souhrny a bezpečnostním skenováním. Pro open source je zdarma. V nezávislém benchmarku z ledna 2026 zachytil všechny skryté chyby, ale dosáhl jen 1/5 na úplnost, což znamená, že zachytí povrchové problémy, ale uniknou mu architektonické a systémové chyby.
Greptile se odlišuje tím, že buduje graf celého repozitáře a recenzuje PR s plným kontextem kódové báze, ne jen diffu. Detekuje chyby napříč soubory, například nesoulad mezi změnou v rozhraní a serializátorem v jiném souboru. Učí se z reakcí týmu (palec nahoru/dolů na komentářích) a po dvou až třech týdnech přestane komentovat věci, které tým nepovažuje za důležité. Cena začíná na 30 USD za vývojáře měsíčně.
Qodo (dříve CodiumAI) nabízí 15+ agentních workflow pro review a zaměřuje se na vynucování bezpečnostních a compliance politik v enterprise prostředí.
Greptile ve svém blogovém příspěvku z února 2026 upozorňuje na důležitý princip: kódovací agent by neměl recenzovat vlastní kód. Nezávislost review od generování je klíčová pro důvěryhodnost celého procesu. Auditor nepřipravuje účetní knihy a student si neznámkuje vlastní zkoušku. Tento argument hovoří pro oddělení nástrojů pro generování kódu a pro jeho review.
Srovnávací přehled
| Nástroj | Typ | Opravuje kód? | Spouštění | Open source | Cena |
|---|---|---|---|---|---|
| Copilot Autofix | bezpečnostní opravy | ano (návrhy) | automaticky při PR | ne | Advanced Security / zdarma OSS |
| Copilot Coding Agent | issue → PR | ano | přiřazení issue | ne | Copilot Pro/Pro+/Business/Enterprise |
| Agentic Workflows | průběžná automatizace | ano | trigger/schedule | ne | preview, premium requests |
| Devin AI | self-healing PR | ano | automaticky při review | ne | komerční platforma |
| OpenCode | issue → PR, review | ano | /oc příkaz | ano | zdarma (+ náklady na modely) |
| SWE-agent | issue → oprava | ano | CLI | ano | zdarma (+ náklady na modely) |
| Ellipsis | review + oprava | ano | @ellipsis-dev | ne | komerční |
| Aider | issue → PR | ano | label na issue | ano | zdarma (+ náklady na modely) |
| CodeRabbit | review PR | ne (jen návrhy) | automaticky při PR | ne | zdarma OSS / 15 USD/vývojář |
| Greptile | review PR | ne (jen návrhy) | automaticky při PR | ne | 30 USD/vývojář |
| Qodo | review PR | ne (jen návrhy) | automaticky při PR | ne | komerční |
Proč jednorázové volání LLM nestačí: iterativní smyčky
Jeden z klíčových problémů, který marketingové materiály většiny nástrojů přecházejí, je spolehlivost jednorázové opravy. Ve skutečnosti se AI agent při prvním pokusu málokdy trefí do správného řešení, které projde kompilací, testy i code review. Reálná oprava vyžaduje iterativní smyčku.
Princip je analogický tomu, jak pracuje lidský vývojář: napíše opravu, spustí testy, zjistí, že něco rozbil, opraví to, spustí testy znovu. Rozdíl je v tom, že LLM tuto smyčku potřebuje explicitně navrženou v orchestrační vrstvě. Jednotlivé nástroje ji řeší různě.
Copilot Coding Agent pracuje v izolovaném GitHub Actions prostředí, kde může opakovaně spouštět testy a lintery a reagovat na jejich výsledky. Devin AI má tu smyčku jako svůj hlavní prodejní argument – agent reaguje na komentáře review botů a opakovaně opravuje, dokud PR neprojde. OpenCode reaguje na CI výsledky a komentáře v PR. Aider v kombinaci s GitHub Actions spouští testy po každé úpravě.
S iterativní smyčkou souvisejí tři praktické problémy:
Prvním je riziko nekonečné smyčky. Agent opraví jednu věc, tím rozbije druhou, opraví druhou, rozbije třetí. Devin to řeší allowlistem botů a omezením počtu iterací. Copilot má interní limity na délku session. U vlastních řešení je nutné explicitně nastavit maximální počet průchodů.
Druhým problémem jsou náklady. Každá iterace znamená další volání LLM API, další spotřebu GitHub Actions minut, další premium requests. U složitějších oprav, kde agent potřebuje pět až deset průchodů, mohou náklady na jednu opravu dosáhnout jednotek dolarů. To je stále výrazně levnější než čas vývojáře, ale je třeba s tím počítat při plánování rozpočtu.
Třetím problémem je kvalita kontextu. S každou iterací roste objem konverzace mezi agentem a nástroji (testy, linter, CI logy). Pokud kontextové okno LLM přeteče, agent ztrácí přehled o tom, co se dělo na začátku, a začne dělat protichůdné změny. Pokročilejší nástroje řeší problém sumarizací předchozích kroků nebo selektivním výběrem relevantního kontextu.
V praxi to znamená, že jednoduchý workflow „při novém issue zavolej LLM a commitni výsledek” bude fungovat pouze pro triviální opravy (překlep v textu, chybějící import). Pro cokoli složitějšího potřebujete orchestraci, která zahrnuje spuštění opravy, ověření testy a CI, vyhodnocení výsledku, případnou další iteraci a nastavení bezpečnostních limitů proti zacyklení.
Vlastní řešení přes GitHub Actions
Všechny výše popsané nástroje lze nahradit nebo doplnit vlastním workflow postaveným na GitHub Actions. Základní myšlenka je jednoduchá: GitHub Action reagující na event issues: [opened, labeled] spustí kódovacího agenta, který issue analyzuje a vytvoří PR.
V praxi takové řešení typicky vypadá jako kombinace Bug Report widgetu na webu (tlačítko „Nahlásit chybu”, které přes API vytvoří GitHub Issue s labelem bug-report a automaticky sebranými technickými údaji), GitHub Action, která při novém issue s příslušným labelem spustí agenta (Claude Code, Aider nebo vlastní skript volající LLM API), a samotného agenta, který přes gh CLI načte detail issue, analyzuje kód, vytvoří branch, provede opravu, spustí testy a otevře PR.
Takové řešení běží na repozitáři tangero/stredniskoly, webové aplikaci pro přijímací řízení na střední školy. Bug reporty od uživatelů automaticky vytváří GitHub Issues. Zpracování zatím probíhá poloautomaticky přes Claude Code v terminálu – vývojář zadá příkaz typu „analyzuj issue #3 a oprav problém”, Claude přes gh CLI načte detail, najde související soubory, navrhne opravu a commitne s referencí Fix #3, která issue automaticky zavře. Důvod je jednoduchý: v Claude Code se chyby vyřeší podstatně lépe a v kontextu celého projektu, přitom se jim vývojář může věnovat na pozadí jiné práce a pouze učiní rozhodnutí, zda a jak pokračovat, pokud je to třeba.
Tento přístup ilustruje stav, kde se dnes nachází většina malých projektů: sběr chyb je automatizovaný, ale zpracování vyžaduje lidskou iniciaci. Plná automatizace by vyžadovala doplnění GitHub Action, která při novém issue automaticky přiřadí Copilot jako assignee nebo spustí OpenCode:
on:
issues:
types: [labeled]
jobs:
auto-assign:
if: github.event.label.name == 'bug-report'
runs-on: ubuntu-latest
steps:
- uses: actions/github-script@v7
with:
script: |
await github.rest.issues.addAssignees({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
assignees: ['copilot']
})
Výhoda vlastního řešení je plná kontrola nad procesem a možnost přizpůsobení konkrétním potřebám projektu. Nevýhoda je nutnost údržby a absence propracovaných bezpečnostních guardrails, které nabízejí komerční nástroje.
Praktická doporučení
Pro většinu týmů dává smysl začít od nejjednodušší vrstvy a postupně rozšiřovat. Copilot Autofix nevyžaduje žádnou konfiguraci nad rámec zapnutí Code Scanning a okamžitě pokrývá bezpečnostní zranitelnosti. Přidání review bota (CodeRabbit pro open source zdarma, Greptile pro týmy s rozpočtem) zajistí, že každý PR projde alespoň základní AI kontrolou.
Dalším krokem je Copilot Coding Agent nebo OpenCode pro zpracování backlogu issues. Copilot má výhodu nativní integrace a jednoduchého nastavení, OpenCode nabízí flexibilitu ve výběru modelu a je zdarma. Pro pokročilejší použití jsou GitHub Agentic Workflows nebo Devin, které umožňují průběžnou automatizaci celého repozitáře.
Důležitý princip, na který upozorňuje Greptile: kódovací agent by neměl recenzovat vlastní kód. Pokud používáte Copilot Coding Agent na generování PR, měl by je recenzovat nezávislý nástroj, ne Copilot code review nad vlastním výstupem. Nezávislost review od generování je základ důvěryhodného procesu.
Žádný z popsaných nástrojů automaticky nemerguje PR. Lidská kontrola zůstává povinná ve všech případech. GitHub Agentic Workflows to mají explicitně v architektuře – PR se nikdy nemergují automaticky. To je v současné fázi vývoje rozumné omezení. Otázka, zda a kdy bude AI důvěryhodná natolik, aby mergovala sama, zůstává otevřená. Greptile předpokládá, že k tomu dojde, a právě proto argumentuje pro nezávislost review agenta od kódovacího agenta – pokud agent schvaluje kód, měl by to být jiný agent než ten, který ho napsal.
Trend je zřejmý: vývojář se posouvá z role opraváře chyb do role recenzenta a architekta. Dnes je možné nastavit pipeline, kde nahlášené issue automaticky zpracuje agent, výsledný PR projde nezávislým AI review a člověk vyhodnotí výstupy a rozhodne jen o finálním merge. Nástroje na to existují. Otázka je, jak rychle se jim bude dát důvěřovat natolik, aby ta poslední lidská kontrola přestala být nutná.