Copilot umí schválit pull request: nastav AI review tak, abys neztratil kontrolu nad kódem

Code review je nejběžnější úzké hrdlo vývojového týmu. Ne kvůli tomu, že by lidé neuměli číst kód, ale proto, že schvalování čeká ve frontě za meetings, hotfixy a dovolenou. GitHub to od začátku září 2026 mění: Copilot code review nejen komentuje pull requesty, ale umí je i oficiálně schválit — a to schválení se počítá do branch protection pravidel stejně jako podpis člověka.

Přesně v tento okamžik se polovina tech leadů zastaví: „AI schvaluje produkční kód? To ne." Rozumná reakce — ale funkce je postavená tak, že kontrolu držíš pořád ty. V tomto návodu ti ukážu, jak approval assessments fungují, kde je zapneš, jak omezit Copilota jen na bezpečné části repa a jak celé schvalování nastavit, aby ti ušetřilo hodiny, ale nepustilo roboty k bezpečnostně kritickému kódu.

Co se přesně změnilo

Dvě odlišné věci, které GitHub v changelogu oznámil 1. září — a stojí za to je nerozmíchat:

1. Approval assessment v každém review. Každé Copilot review teď obsahuje v přehledovém komentáři hodnocení, jestli považuje pull request připravený ke schválení. Získáš tak rychlý signal „v pohodě / ještě ne" vedle detailních komentářů. Důležité: tohle hodnocení samo o sobě se do merge požadavků nepočítá. Je to informace pro tebe, ne hlas.

2. Skutečné schvalování. Administrátoři můžou Copilota autorizovat k podpisu schválení. Jakmile to zapneš, Copilotovo approval se počítá do pravidla o povinných schváleních (required approvals) úplně stejně jako lidské. A funguje i ochrana proti zastaráni: když po schválení někdo pushne nové commity, schválení se zruší úplně stejně jako u lidského reviewera. Můžeš si vyžádat nové review a dostat čerstvý verdikt.

Celé to je veřejný preview pro Copilot Pro, Pro+, Max, Business a Enterprise. Schvalování je standardně vypnuté — bez explicitního zásahu administrátora se nic nemění.

Kde approval zapneš

Nastavení existuje na třech úrovních a řetězí se shora dolů:

• Enterprise: administrátor může nechat schvalování vypnuté pro celou firmu, nebo přenechat rozhodnutí organizacím.
• Organizace: zapneš org-wide, přenecháš adminům jednotlivých repozitářů, povolíš jen pro vybraná repa, nebo zakážeš úplně.
• Repozitář: administrátor repa zapne nebo vypne a — tohle je klíčové — určí, které cesty (file paths) smí Copilot schvalovat.

Úroveň repozitáře je to nejdůležitější nastavení v celém příběhu. Path restriction znamená, že můžeš povolit schvalování pro docs/**, testy nebo interní tooling, a zakázat pro src/**, infrastrukturu nebo cokoli, co se dotýká plateb a autentizace. Detaily najdeš v oficiální dokumentaci code review.

Praktická rada pro první nasazení: zapni schvalování nejdřív v jednom repu s nízkým rizikem, nech běžet dva týdny a sleduj, kolik Copilotových schválení se pak v merge konfliktu s lidským verdiktem ukázalo jako předčasných. Až pak šiř dál.

Než approval povolíš: nastav automatické review

Schvalování dává smysl jen v kombinaci s tím, že Copilot review dostává vůbec. Od minulého roku to řeší branch rulesety:

1. Otevři Settings → Rules → Rulesets → New branch ruleset v daném repu.
2. Zamiř na pravidlo Require a pull request before merging.
3. Zaškrtni Automatically request Copilot code review.
4. Rozhodni o dvou volbách:
   • Review new pushes — Copilot reviewuje znovu při každém pushi (doporučuji, jinak review zastará hned po prvním doplňkovém commitu).
   • Review draft pull requests — review běží i v draftu, což dává smysl pro ranou zpětnou vazbu, ale pozor na spotřebu premium requestů u placených tarifů.

Ruleset cílí na konkrétní větve — typicky main plus vzory jako release/*. Díky tomu se Copilot stává reviewerem automaticky, nikdo ho nemusí ručně přidávat a merge se bez něj (nebo bez lidského schvalovatele) neprojde.

Jednorázově můžeš review vyžádat i ručně — v pravém panelu pull requestu vyber Copilota jako reviewera, nebo z terminálu přes GitHub CLI příkazem review na konkrétní PR. To se hodí, když chceš verdikt ad hoc bez rulesetu.

Nauč Copilota vaše standardy

Syrové Copilot review komentuje obecně. Když chceš, aby reagovalo na to, jak váš tým skutečně píše kód, vytvoř soubor .github/copilot-instructions.md s přirozenými instrukcemi — například „vždy kontroluj SQL injection v doctrine repoziářích", „preferuj readonly proměnné", „kontroluj, zda se mění migrace a jestli jsou reverzibilní".

Jedna technická drobnost, která tě ušetří hodinu debugování: Copilot čte instrukce z head branch (větve s tvými změnami), ne ze základní větve. Když tedy do instructions přidáš nové pravidlo, musíš ho dostat do větve, kterou reviewuješ — nejen do main. U nových rules to znamená: nejdřív merge update instructions, pak otevřít feature branch.

Kde AI schválení (ne)patří

Ať je model sebechytřejší, schválení je akt důvěry, ne jen technická kontrola. Pár hranic, které bych si nastavil já:

Nech Copilota schvalovat:

• dokumentaci a změny v docs/**,
• testy a fixture data,
• interní tooling, build skripty, CI konfiguraci bez secretů,
• rutinní refaktoring bez změny chování (rename, extrakce metod, formátování).

Vyžaduj lidský podpis:

• autentizaci, autorizaci a cokoli s security v názvu adresáře,
• platební toky a práci s osobními údaji,
• databázové migrace produkce,
• změny v infrastruktuře a správě secretů,
• cokoli, co ovlivní zákazníka pod SLO smlouvou.

Mechanismus je přitom stejný: path restriction na úrovni repa plus klasická CODEOWNERS pravidla, kde kritické cesty vlastní konkrétní lidé. Dismissal nastavení („dismiss stale pull request approvals when new commits are pushed") nech zapnuté — Copilot tu funguje stejně jako člověk a nové commity mu schválení zruší.

A jedno varování na závěr této sekce: approval assessment v komentáři je názor modelu, ne záruka. Když ti Copilot napíše „ready to approve" a ty vidíš, že se změna dotýká něčeho citlivého, lidský verdikt má vždy přednost. Model nezná kontext obchodu, poslední incident ani to, co zákazník slíbil. Ty ano.

Kdy se ti vrátí investice času

Konkrétní scénář, kde to celé vyniká: menší tým, který denně otevírá 5–10 pull requestů, z toho většina jsou drobné změny — copy, styly, testy, malé bugfixy. Dnes review čeká hodiny až dní. S rulesetem a path-restricted approval Copilot odfiltruje triviální PRs během minut a lidské reviewery nechá jen těm změnám, kde rozhodnutí skutečně potřebuje kontext.

Větší organizace s dostupným Enterprise tarifem navíc získá centrální kontrolu — schvalování můžou povolit jen vybraným organizacím a zbytek nechat na lidských reviewerech, takže rollout je postupný a auditovatelný.

Shrnutí

Copilot code review se posunul z komentátora na schvalovatele — ale jen tam, kde to administrátor explicitně povolí. Klíčové kroky pro tebe:

1. Zapni approval assessments implicitně (běží v každém review) a sleduj, jestli ti signal sedí s vlastním úsudkem.
2. Přidej ruleset s automatickým Copilot review na hlavní větve.
3. Pověs schvalování na path restrictions — bezpečné cesty ano, kritické ne.
4. Doplň .github/copilot-instructions.md a pamatuj, že se čte z head branch.
5. Nech zapnuté dismissal při nových commitech a drž CODEOWNERS na citlivých souborech.

AI review nezastaví lidi v hodnotě — přesune je tam, kde jsou potřeba. A to je přesně ten důvod, proč tuhle funkci zapnout dnes, ne až ji bude mít konkurence jako standard.

Zajímá tě, jak AI dotáhnout celý pull request od začátku do konce? Mrkni na návod na VS Code Agent Merge, který řeší druhou polovinu příběhu — automatické dokončení merge.