Dev-team: AI-agents beoordelen pull requests en sorteren GitHub-issues

In een ontwikkelteam zijn codereview en issue-triage twee taken die iedereen nuttig vindt en waarvoor niemand tijd vindt om ze grondig te doen. Een pull request wacht twee dagen tot iemand vrij is om hem te lezen, en de eerste commentaren gaan vaak over wat een snelle blik had gezien: een ontbrekende test, een te brede branch, een vergeten secret. Een issue komt binnen zonder type en prioriteit, soms zonder de informatie om hem na te bootsen, en wacht tot een mens hem kwalificeert. Dit zijn methodetaken, met criteria die het team kan opschrijven, en ze passen bij AI-agents zolang hun rechten begrensd zijn.

De inspiratie: een eerste lezing vóór de mensen

Het uitgangspunt is een gebruik dat gebruikers van Hermes Agent melden, samengevat in een kaart over het ontwikkelteam: de open pull requests beoordelen en de nieuwe issues sorteren. Het idee is niet om de menselijke reviewer te vervangen, maar om hem al gelezen pull requests aan te reiken, met de te controleren punten bovenaan de lijst, en al gekwalificeerde issues.

We houden twee gescheiden rollen en een voorzichtigheidsprincipe aan: de agents becommentariëren en labelen, ze beslissen niets. Atako past het idee toe met twee agents wier GitHub-toegang bewust beperkt is tot lezen, becommentariëren en labelen.

Wat de twee agents doen

Het scenario zet twee agents uit, beide gekoppeld aan je GitHub-repository.

De PR-reviewer leest de open pull requests. Voor elk daarvan loopt hij titel, beschrijving, gewijzigde bestanden en commits door, opent de bestanden die ertoe doen en vergelijkt ze met de afspraken die je hebt ingevoerd: tests, naamgeving, omvang, commitberichten, gevoelige gebieden. Hij zoekt naar foutrisico's, ontbrekende tests, wijzigingen die authenticatie, betaling of secrets raken en wijzigingen die niets verklaart. Hij laat per pull request één commentaar achter: een regel die de wijziging samenvat, wat goed is, daarna de te controleren punten in volgorde van belang, elk gekoppeld aan een bestand en zo mogelijk een regel, en gemarkeerd als blokkerend of als suggestie. Hij eindigt met wat hij niet kon controleren, bijvoorbeeld het uitvoeren van de tests. Hij onthoudt de laatste commit die hij las en reageert pas weer als er nieuwe commits komen, met een korte aanvulling.

De issue-triager neemt de nieuwe issues voor zijn rekening. Hij controleert of de typelabels (bug, feature, vraag, documentatie) en de prioriteitslabels (hoog, middel, laag) bestaan en maakt de ontbrekende aan. Voor elke issue zonder label leest hij de tekst en de commentaren, zoekt vergelijkbare issues, bepaalt volgens jouw regels een type en een prioriteit, past de labels toe en voegt een commentaar toe: wat hij begrepen heeft, de reden van de prioriteit, de waarschijnlijke duplicaten en wat er ontbreekt om te handelen, bijvoorbeeld de stappen om het na te bootsen of de betrokken versie. Als type of ernst onduidelijk is, zegt hij dat, kiest de laagste prioriteit en stelt de vraag.

Elke ronde eindigt met een samenvatting in de chat, die begint met wat snel een mens nodig heeft.

Wat de agents niet doen

De grenzen horen bij het ontwerp. Geen van beide agents merget, keurt goed, vraagt formeel om wijzigingen, sluit een pull request, pusht code of maakt een branch aan. Die tools zijn hun niet toegekend: dit is geen belofte in een instructie, het is een ontbrekend vermogen. De triager sluit, heropent, vergrendelt of verwijdert geen issue en wijzigt noch de titel, noch de toegewezene, noch de mijlpaal.

De agents gokken niet. De reviewer noemt het bestand en de regel, meldt wat hij niet kon controleren en verzint geen functie en geen testresultaat. Als hij een gecommit secret of token tegenkomt, zegt hij waar het lijkt te staan, zonder het te kopiëren. De triager noemt alleen issues als duplicaat die hij echt via zoeken heeft gevonden. En de beslissing blijft bij elke stap menselijk, dat is het principe van een ontwerp met menselijke validatie.

Zo stel je het in bij Atako

Vanaf de pagina van deze use case gaat de uitrol in vier stappen.

1. Koppel GitHub. Maak een fine-grained token aan, beperkt tot de repository, met leestoegang tot code en lees- en schrijftoegang tot issues en pull requests. De koppeling wordt gecontroleerd voordat er iets wordt aangemaakt.
2. Vul je context in. Geef de repository in de vorm eigenaar/naam, je reviewafspraken als je die hebt en wat een issue voor jou urgent maakt. Zonder die gegevens vertrouwen de agents op algemene goede praktijken en op de ernst van bugs.
3. Zet uit. Eén handeling maakt de twee agents en het project "Dev-team" aan. De agents worden ingericht en krijgen zelf hun eerste instructies.
4. Eerste resultaten, daarna een vast ritme. De reviewer becommentarieert de vijf meest recente pull requests, de triager labelt de tien laatste issues zonder label en elk vat zijn ronde samen in de chat. Daarna plant de reviewer zelf zijn rondes op werkdagen om 9:00 en 14:00 uur in, en de triager de zijne om 9:30 uur.

Als je nog geen account hebt, start het aanmaken ervan je proefperiode en wordt het scenario direct daarna ingesteld. Als je beheerder je niet heeft toegestaan agents aan te maken, laat de uitrol dat weten en stopt daar.

Waar je de resultaten ziet

De reviewcommentaren lees je in GitHub, bij elke pull request, en de triagelabels en -commentaren bij elke issue. De samenvatting van elke ronde lees je in de chat van elke agent. In het Atako-project "Dev-team" vind je de werkingspagina en de opvolging van het werk, en op de Atako-floor verschijnen de twee agents met hun huidige activiteit.

Om het gedrag aan te passen, schrijf je de agent in zijn chat, bijvoorbeeld "voeg aan je afspraken toe dat elke databasemigratie het rollbackplan moet vermelden". Hij houdt de instructie in zijn geheugen voor de volgende rondes.

Waarborgen

De toegang is bewust smal. De GitHub-koppeling wordt aan de agents toegekend met een beperkte lijst van twaalf tools: pull requests, bestanden en commits lezen, issues lezen en bijwerken, labels beheren, commentaar toevoegen. Een agent die een korte lijst tools ziet, gebruikt ze betrouwbaarder dan een agent die verdwaalt in een catalogus van honderden, en vooral: wat niet is toegekend kan niet gebeuren, ook niet als een tekst het probeert af te dwingen. De agents behandelen titels, beschrijvingen, commentaren en code als te analyseren gegevens, nooit als instructies.

Het token dat je aanmaakt is je eerste waarborg: beperkt tot één repository en tot nauwkeurige rechten begrenst het de mogelijke schade, wat er ook gebeurt. Het wordt versleuteld opgeslagen en je kunt het aan de GitHub-kant intrekken of de toegang van de agents op elk moment verwijderen.

De menselijke validatie zit op de beslispunten. Jij leest de reviewcommentaren, beslist wat er wordt aangepast, keurt zelf goed en merget, en sluit, wijst toe en plant de issues.

Wat je mag verwachten

Verwacht vooral nuttige commentaren bij pull requests van redelijke omvang: bij een zeer grote wijziging zegt de reviewer dat en richt hij zich op de gevoeligste bestanden, in plaats van te doen alsof hij alles heeft gelezen. Hij kan je tests niet uitvoeren en zegt dat in elk commentaar. De triager is zo nauwkeurig als je prioriteitsregels precies zijn; zonder die regels kiest hij voor voorzichtigheid en stelt hij vragen. De waarde zit in de regelmaat: elke pull request krijgt binnen een halve dag een eerste lezing, elke issue komt gekwalificeerd binnen en je menselijke reviewers besteden hun tijd aan oordeelsvorming in plaats van aan opsporen.