Kui tahad kõige lühemat vastust, siis see on see: kui coding agent kirjutab juba kiiremini, kui sinu tiim jõuab mõelda, siis järgmine võit ei tule uuest mudelist. Ta tuleb sellest, et repo ütleb agendile selgelt, mida ta tohib muuta, mida ta peab testima ja kus inimene hoiab lõpliku otsuse enda käes.
Kiire vastus tehnoloogiajuhile:
- pane püsivad reeglid repo sisse, mitte ainult prompti algusesse
- nõua agendilt enne muudatust failiulatust, teste ja verifitseerimata eelduste märkimist
- ära lase agendil ise oma tööd heaks kiita, isegi siis, kui ta kirjutab korraliku kokkuvõtte
8.-10. juuli 2026 X-signaalides kordusid sama tooniga fraasid: outer loop vs inner loop, boring contract, no self-approval, repo control plane. Jutt ei käi enam ainult sellest, kas agent kirjutab palju koodi. Jutt käib sellest, mille järgi ta üldse repo sees käitub.
See on tähtis just praegu, sest ametlik proof on järele jõudnud. OpenAI Codexi dokumentatsioon ütleb nüüd väga otse, et AGENTS.md on repo taseme juhisekiht coding agentidele. GitHub lisas 18. juunil 2026 AGENTS.md toe Copilot code review'sse ning juba 12. juunil 2026 tõi juurde tugevamad review kontrollid ja exclusions-loogika. Ja Anthropic kirjutas 16. juunil 2026 Claude Code kasutuse uuringus sisuliselt sama allteksti: ekspertteadmine ja orkestreerimine ei kao kuhugi, isegi kui agent aitab rohkem tööd ära teha.
Kui see ühe lausega kokku võtta, siis tulemus on see: hea coding agent ei ela enam ainult promptis. Ta elab repo tööreeglites.
Miks see teema on midagi muud kui lihtsalt review-võlg
Me kirjutasime 24. juunil loos AI kirjutab rohkem koodi, kui review jõuab lugeda, et AI võib muuta review-võla väga kiiresti nähtamatuks kvaliteedikuluks. See lugu läheb järgmise sammu võrra edasi.
Sealne küsimus oli: kas tiim jõuab AI tempot taluda?
Tänane küsimus on: mis paneb agendi üldse sinu reeglite järgi käituma enne, kui review koormus suureks läheb?
Kui vastus on ainult "me kirjutasime hea prompti", siis on vastus liiga nõrk. Prompt kaob sessiooniga. Repo reegel jääb alles, on kontrollitav ja töötab ka siis, kui tööriist vahetub.
Mis on repo juhtpaneel tegelikult
Ma ei pea siin silmas üht maagilist faili, mis kõik mured lahendab. Ma pean silmas väikest, püsivat juhiste kihti, mis teeb coding agendi jaoks nähtavaks vähemalt need asjad:
- millised kaustad või failid on lubatud ja millised mitte
- millised käsud tuleb enne PR-i või diffi käivitada
- milline test on minimaalne kohustus, mitte vabatahtlik soovitus
- kuidas kirjutada muudatuse selgitus nii, et inimene saaks selle kiiresti üle vaadata
- millal agent peab ütlema "ma ei tea" või märkima oletuse, mitte improviseerima edasi
AGENTS.md on siin kõige nähtavam uus standard, aga mõte on laiem kui ühe faili nimi. Sisuline küsimus on see, kas sinu repo annab agendile durable instruction layer'i, mitte ainult lühiajalise vestluskonteksti.
Kui sinu organisatsioon alles valib, kas minna assistendi, coding agendi või oma süsteemi suunas, siis ChatGPT Agent, Custom GPT või oma agent? aitab selle piiri paika panna. Kui agent on aga juba arenduse sees, siis oled sa sellest valikufaasisest küsimusest väljas. Siis on vaja juhtpaneeli.
Kolm asja, mida ma paneksin kohe repo sisse
1. Muudatuse ulatus peab olema enne koodi nähtav
Kõige kasulikum "igav" reegel ei ole stiilijuhis. Kõige kasulikum reegel on see, et agent ütleb enne muutmist:
- milliseid faile ta plaanib puudutada
- mida ta nendes failides muuta tahab
- millise käsuga ta plaanib muudatust kontrollida
See teeb kaks asja korraga. Esiteks piirab see blast radius't. Teiseks teeb see inimese review odavamaks, sest reviewer ei pea kõigepealt aimama, mis siin üldse juhtuma hakkas.
Just siin kordus X-is praktiline fraas boring contract. Hea leping coding agendiga on igav selle parimas mõttes. Ta ei tee sind loovamaks. Ta teeb sind audititavamaks.
2. Testikäsk ei tohi jääda agenti heale tahtele
Kui repo ei ütle otse, milline test on kohustuslik, siis jääb agent arvama. Mõni käivitab liiga palju, mõni liiga vähe ja mõni kirjutab lihtsalt, et "tests were not run".
OpenAI ja GitHubi praegune AGENTS.md / custom instructions suund on siin oluline just sellepärast, et see võimaldab panna build-, lint- ja testikäsklused püsivalt agenti konteksti. Mitte iga sessiooni alguses uuesti käsitsi. Mitte iga arendaja enda mälu peale.
Kui sinu tiimil on juba probleem sellega, et AI-generated muudatus jõuab review'sse enne, kui keegi sai aru, mis test üldse pidi jooksma, siis järgmine investeering ei pruugi olla uus tööriist. Ta võib olla hoopis selgem AI for Developers tööviis ja repo reeglite normaliseerimine.
3. Agent ei tohi olla omaenda viimane reviewer
See kõlab ilmselgelt, aga just siin tekib päriselus palju mugavaid lühiteid. Agent kirjutab diffi, agent teeb kokkuvõtte, agent ütleb, et testid on korras, ja inimene loeb lõpuks ainult tema enda juttu.
8.-10. juuli aruteludes kordus mitu korda sama probleem: summary is not judgment. Hästi kirjutatud kokkuvõte ei ole sõltumatu review. Teine agent ei ole automaatselt sõltumatu review. Ja testiroheline ei ole veel arhitektuurne otsus.
See haakub otse ka looga AI agent tootmisse? Enne rollout'i on vaja kolme asja: piirid, eelarve ja turvakest. Sama piiride loogika kehtib repo sees: kui rollid lähevad segi, muutub kontroll näiliseks.
Kuidas ma sõnastaksin minimaalse lepingu coding agendiga
Kui tahad alustada ühe lihtsa raamiga, siis mina nõuaksin agendilt enne iga sisulist muudatust viit asja:
- Ütle, mida sa kavatsed muuta ja miks.
- Nimeta failid või kaustad, mida sa puudutad.
- Ütle, millise käsuga sa muudatust kontrollid.
- Märgi välja, mis jäi kontrollimata või mille osas sa oletad.
- Ära esita omaenda kokkuvõtet lõpliku kvaliteeditõendina.
See ei tee agendi elu glamuursemaks. Ta teeb selle usaldusväärsemaks.
Kui sa ei tea veel, kas sinu tiim on selleks valmis, siis allpool olev tööriist ongi selleks hetkeks hea:
AI-koodi review valmisoleku kontroll
Märgi viie küsimusega läbi, kas sinu tiim on valmis laskma AI-assisted codingul kiiremini kasvada ilma, et review-võlg ja tootmisrisk samas tempos kaasa tuleks.
Praegu võid lihtsalt kasvatada bugi-, review- ja incidentivõlga. Pane mõõtmine, review-reeglid ja scan'id enne paika.
0/5 kriitilist kontrolli on olemas.
Millal see muutub kiireks probleemiks
Ma liiguks selle teemaga kohe sel nädalal, kui vähemalt üks neist on tõsi:
- AI kirjutatud PR-id tulevad repo sisse kiiremini, kui senior reviewer jõuab neid päriselt lugeda
- eri arendajad annavad agentidele samu korduvaid juhiseid käsitsi, aga repo ise vaikib
- testid jooksevad ebaühtlaselt või nende valik sõltub rohkem sessioonist kui standardist
- agent kirjutab veenvaid kokkuvõtteid, mille taga inimese iseseisev otsus on järjest õhem
Need on kõik märgid, et probleem ei ole enam mudeli võimekuses. Probleem on juhtimiskihis.
Mida ma teeksin järgmise 30 päeva jooksul
Ma ei alustaks sellest, et kirjutaksin 200-realise agenti põhiseaduse. Ma teeksin neli väikest sammu.
- Pane repo juurtasandile lühike
AGENTS.md, kus on build, test, keelatud tsoonid ja diffi selgituse nõue. - Sea reegel, et agent peab enne muudatust nimetama failiulatuse ja pärast muudatust täpse verifitseerimiskäsu.
- Keela vaikimisi muster, kus agent kirjutab, hindab ja sisuliselt ka kiidab ise oma töö heaks.
- Vaata kahe nädala pärast üle, kas see vähendas review-friktsiooni või ainult lõi juurde uut rituaali.
Kui sellest tekib vähem arusaamatusi, kiirem review ja vähem "oota, miks see fail üldse muutus" hetki, siis oled õigel teel. Kui ei teki, siis probleem ei pruugi olla juhiste nappuses, vaid selles, et workflow ise on endiselt liiga udune.
Alumine rida
Juuli 2026 kõige kasulikum coding agenti õppetund ei ole see, et agent vajab veel natuke paremat prompti. Kasulikum õppetund on see: agent vajab püsivat repo juhtpaneeli, mis teeb piirid, testid ja inimese lõpliku otsuse talle nähtavaks.
Kui sa ehitad ainult kiiremat kirjutajat, saad rohkem koodi. Kui sa ehitad juhtpaneeli, saad suurema tõenäosusega rohkem kontrollitavat väärtust.