Kui Copilot võib PR-i heaks kiita, otsusta enne millised failid jäävad alati inimesele.

Kui tahad kõige lühemat vastust, siis see on see: kui AI review võib nüüd lugeda päris heakskiiduks, ei ole sinu põhiprobleem enam see, kas mudel on piisavalt tark. Põhiprobleem on see, kas sinu repo ütleb väga selgelt, millistes failides võib AI heakskiit üldse midagi lugeda ja millistes peab viimane jah jääma inimesele.

Kiire vastus tehnoloogiajuhile:

• ära käsitle AI approval'it mugava lisafunktsioonina, vaid uue õiguse tüübina
• määra enne sisse lülitamist failiteed ja PR-klassid, kus inimese review on alati kohustuslik
• veendu, et exclusions ja eelarvereeglid elavad üle tööriista piiri, mitte ainult IDE sees

1. septembril 2026 teatas GitHub, et Copilot code review võib nüüd anda heakskiidu, mis võib arvesse minna repo required approvals reeglis, kui admin selle sisse lülitab. 2. septembril 2026 lisas GitHub ametlikult, et content exclusions kehtivad nüüd ka Copilot appis ja CLI-s, mitte ainult kitsamas editori kontekstis. Samal päeval tuli juurde ka võimalus panna enterprise-managed settings'iga vaikimisi mudel paika kogu ettevõtte või tiimi lõikes. Päev varem tuli veel üks juhtimiskihti tugevdav detail: ajutised individuaalsed eelarve-erandid saavad nüüd ise aeguda.

Kui need neli muudatust ühe lausega kokku võtta, siis tulemus on see: AI kasutus liigub järjest vähem prompti ja järjest rohkem admin policy kätte.

Miks see teema on midagi muud kui juulikuu repo juhtpaneel

Me kirjutasime juulis loos AI coding agent ei vaja veel üht prompti. Ta vajab repo juhtpaneeli., et püsiv repo juhisekiht on olulisem kui järgmine osav prompt. See jutt peab endiselt paika.

Aga 2026. aasta 1.-2. september lükkas fookuse järgmisse punkti. Küsimus ei ole enam ainult selles, mida agent repo sees näeb või kuidas ta käitub. Küsimus on nüüd ka selles, millal võib tema hinnang lugeda päris heakskiiduks.

See muudab required approvals reegli sisuliselt tooteks endaks. Kui seni võis tiim mõelda, et Copilot review on lihtsalt lisakommentaar, siis nüüd on võimalik teha järgmine samm ja lasta sellel teatud olukordades päriselt merge-reeglisse sisse astuda.

Just siin muutub mugavus kiiresti governance'iks.

Mida GitHub tegelikult muutis

GitHubi 1. septembri 2026 changelog ütleb kolm väga olulist asja.

Esiteks: Copilot approval on vaikimisi väljas.

Teiseks: kui see sisse lülitada, võib see lugeda required approvals reegli osaks.

Kolmandaks: seda saab juhtida enterprise, organization ja repository tasemel ning repo tasemel valida, milliseid failiteid Copilot üldse tohib heaks kiita.

See viimane detail on kõige tähtsam. Kui AI approval on ainult suur jah või ei, jääb reegel liiga nüansivabaks. Kui saad piiritleda failiteed, saad sõnastada palju praktilisema lepingu, näiteks nii:

• dokumentatsioon, madala riskiga refactor ja testifailid võivad teatud tingimustel kasutada AI approval'it
• autentimine, õigused, arveldus, turvakriitiline konfiguratsioon ja andmevoogude piirid jäävad alati inimesele
• uued commit'id kustutavad Copiloti approval'i samamoodi nagu inimese oma, seega approval ei ela päriselt muutuse järel edasi

See ei ole enam lihtsalt code-review funktsioon. See on repo policy.

Miks failitee piir on tähtsam kui üldine usaldus AI vastu

Paljud tiimid teevad siin vale pöörde. Nad küsivad liiga abstraktse küsimuse: kas me usaldame AI-d piisavalt.

Mina küsiksin hoopis: millistes failides on eksimus nii kallis, et viimane otsus peab jääma inimesele sõltumata sellest, kui veenev AI review välja näeb?

See on palju parem juhtimisküsimus, sest see ei nõua religioosset usku ega täielikku keeldu. See nõuab klassifitseerimist.

Sarnane loogika jooksis läbi ka eilse ja tänase X-momentum'i. Kõige kasulikumad reaktsioonid ei vaielnud selle üle, kas Copilot on tark või rumal. Need ütlesid sisuliselt sama asja eri sõnadega: käsitle approval'it privileegina, mitte checkbox'ina, ja otsusta enne ära, mis klassi pull request'ides võib masin üldse midagi allkirjastada.

Kui sul seda klassi mõtlemist ei ole, siis ei päästa sind ka hea mudel. Siis on sul lihtsalt uus tee, kuidas näiliselt turvaline merge tegelikult liiga odavaks muutub.

Exclusions peavad elama üle tööriista piiri

2. septembri 2026 teine oluline muudatus oli see, et GitHubi content exclusions kehtivad nüüd ametlikult ka Copilot appis ja CLI-s.

See kõlab väikse detailina ainult seni, kuni mõtled päris töövoole. Kui exclusions töötavad ainult IDE sees, aga agent võib sama repo osa lugeda mujalt kanalist, siis ei ole sul tegelikult policy't. Sul on kasutajaliidese eripära.

GitHubi docs lähevad siin veel praktilisemaks. Excluded content:

• ei toida inline suggestion'eid
• ei toida Copiloti vastuseid
• ei lähe Copilot code review sisendiks

See on oluline just nüüd, sest AI-toega arendus ei ela enam ainult editoris. Ta liigub appi, CLI-sse ja teistesse agentsetesse pindadesse. Kui sinu piirid ei liigu kaasa, siis jääb reegel maha esimesest mugavast kõrvalteest.

See on ka põhjus, miks AI kirjutab rohkem koodi, kui review jõuab lugeda ei olnud ainult review-võla lugu. Review-võlg kasvab eriti kiiresti seal, kus lubatud ja keelatud tsoonid muutuvad tööriistade vahel uduseks.

Ajutine erand ei tohi jääda püsivaks lihtsalt sellepärast, et kellelgi pole aega koristada

Sama juhtimismuster tuli välja ka GitHubi 1. septembri eelarveuuenduses. Individuaalne kasutajaeelarve võib nüüd ise aeguda ja kukkuda tagasi järgmisele üldisele reeglile.

See ei ole ainult billing detail. See on sama kontrolliloogika teine külg.

Ajutine erand on hea siis, kui:

• tiim testib uut workflow'd
• üks arendaja vajab lühiajaliselt suuremat mahtu
• konkreetne sprint õigustab kõrgemat kulu

Ajutine erand muutub halvaks siis, kui see jääb süsteemi sisse lihtsalt seepärast, et keegi peab selle kunagi hiljem käsitsi maha võtma.

Kui sinu rollout toetub käsitsi koristamisele, siis ei ole see päris rollout. See on halduse võlg.

Sellepärast mulle meeldib, et sama septembri signaalipakk õpetab korraga kahte asja: õigused peavad olema piiratud ja erandid peavad olema isetaastuvad.

See haakub väga hästi ka looga AI kasutus ei ole adoption, kui override, cleanup ja krediidikulu jäävad mõõtmata. Kui override jääb nähtamatuks või ajutine muutub püsivaks, ei mõõda sa enam adoption'it. Sa mõõdad kontrolli kadu.

Kolm failiklassi, mida ma hoiaksin alati inimese käes

Kui peaksin seda nädalalõpuks ühe juhina lihtsustama, jagaksin repo kolmeks.

1. Alati inimesele jäävad failid

Siia paneksin:

• autentimise ja õiguste loogika
• maksete, arvelduse või limiitide loogika
• infrastruktuuri ja turvakonfiguratsiooni võtmekihid
• andmevoolu või retention'i reeglid
• kõik failid, mille viga võib tekitada reaalse turva-, raha- või vastutusriski

Nendes failides võib AI review aidata, aga mitte olla viimane jah.

2. Tingimuslikult AI approval'iga failid

Siia võivad minna:

• madala riskiga refactor'id
• testifailid
• sisemine dokumentatsioon
• UI või copy muudatused, millel on väike blast radius

Ka siin ainult siis, kui test, branch protection ja diffi ülevaade on paigas.

3. AI approval'it mitte vajavad, vaid lihtsalt kiirendust saavad failid

Mõne koha puhul ei ole üldse vaja masinlikku heakskiitu rolli suurendada. Piisab sellest, et AI aitab mustandit või esimest ülevaadet teha, aga required approvals jäävad täielikult inimese kätte.

Kui su tiim ei oska neid kolme klassi sõnastada, siis ära lülita approval't veel sisse. See ei tähenda, et sa oled AI vastu. See tähendab, et sa pole veel policy valmis.

Kuidas ma selle otsuse järgmise 30 päeva jooksul teeksin

Mina ei teeks seda suure manifestina. Ma teeksin viis väikest sammu.

1. Kaardista repos failid ja kaustad, mille eksimuse hind on kõrge.
2. Otsusta, millistes teedes ei tohi AI approval kunagi required approvals reeglit täita.
3. Kontrolli, et content exclusions kehtivad samade tundlike tsoonide jaoks ka väljaspool IDE-d.
4. Sea ajutistele AI eelarve- või õiguseeranditele lõppkuupäev, mitte ainult hea lootus.
5. Testi AI approval't kõigepealt ühes madala riskiga repos, mitte kogu organisatsiooni vaikereeglina.

Kui sul on tunne, et see on liiga palju tööd ühe mugava funktsiooni jaoks, siis just see ongi õige tunne. See tähendab, et sa käsitled seda õigesti: mitte kui mänguasja, vaid kui uut merge-õiguse vormi.

Kui sinu arendustiim on juba selles faasis, siis AI for Developers on palju loomulikum järgmine samm kui järjekordne üldine AI-demo. Kui küsimus on kitsamalt Microsofti või GitHubi tööriistade admini- ja standardiloogikas, siis Microsoft Copilot koolitus aitab sama vestluse viia tööriista tasemest juhtimistasemele.

Millal ma liiguksin kiiremini just nüüd

Ma liiguksin selle teemaga kohe sel nädalal, kui vähemalt üks neist on tõsi:

• tiim kasutab juba Copilot review'd või muid coding agente, aga required approvals reegel on sisuliselt vana maailm
• repo sisaldab tundlikke tsoone, kuid exclusions ei ole läbi mõeldud üle appi ja CLI piiri
• ajutisi AI kulu- või õiguseerandeid jagatakse käsitsi ja nende lõppu keegi ei halda
• juhtkond küsib juba AI tootlikkust, kuid ei küsi veel, milline kood peab jääma inimese nimele

Need on märgid, et probleem ei ole enam mudeli võimekuses. Probleem on selles, et uus õigus tekkis kiiremini kui sinu policy.

Alumine rida

1. ja 2. september 2026 ei toonud lihtsalt järjekordset Copiloti funktsiooni. Need tegid nähtavaks, et AI-toega arenduses muutub päris otsustuskohaks nüüd see, millises failis võib masina hinnang lugeda heakskiiduks ja millises mitte.

Kui sa jätad selle otsuse harjumuse, mitte policy hooleks, siis saad rohkem mugavust. Kui sa teed sellest teadliku repo reegli, saad suurema tõenäosusega rohkem kontrollitavat kiirust.

Allikad

• GitHub Changelog: Copilot code review can now approve pull requests
• GitHub Changelog: Content exclusions generally available in Copilot app and CLI
• GitHub Changelog: Set an expiration date for individual user budgets
• GitHub Changelog: Enterprise-managed settings support any default model
• GitHub Docs: Content exclusion for GitHub Copilot
• GitHub Docs: Configuring code review by GitHub Copilot
• Microsoft Learn: Understand Local Agents in Microsoft 365 admin center
• European Commission: AI Act overview