Udviklingsteam: AI-agenter gennemgår pull requests og sorterer GitHub-sager

I et udviklingsteam er kodegennemgang og sortering af sager to opgaver, som alle finder nyttige, og som ingen finder tid til at gøre grundigt. En pull request venter to dage på, at en ledig person læser den, og de første kommentarer handler ofte om det, et hurtigt blik ville have set: en manglende test, en for bred gren, en glemt hemmelighed. En sag kommer ind uden type og prioritet, nogle gange uden de oplysninger, der skal til for at genskabe fejlen, og venter på, at et menneske kvalificerer den. Det er metodeopgaver med kriterier, som teamet kan skrive ned, og de passer til AI-agenter, så længe deres rettigheder er afgrænsede.

Inspirationen: en første gennemlæsning før menneskerne

Udgangspunktet er en brug, som brugere af Hermes Agent har berettet om, opsummeret i et kort om udviklingsteamet: gennemgå de åbne pull requests og sortere de nye sager. Idéen er ikke at erstatte den menneskelige gennemgang, men at give vedkommende pull requests, der allerede er læst, med punkterne at tjekke øverst på listen, og sager, der allerede er kvalificeret.

Vi beholder to adskilte roller og et forsigtighedsprincip: agenterne kommenterer og mærker, de beslutter intet. Atako anvender idéen med to agenter, hvis GitHub-adgang bevidst er begrænset til at læse, kommentere og mærke.

Hvad de to agenter gør

Scenariet udruller to agenter, begge forbundet til dit GitHub-repository.

PR-gennemgangeren læser de åbne pull requests. For hver enkelt gennemgår den titel, beskrivelse, ændrede filer og commits, åbner de filer, der betyder noget, og sammenligner dem med de konventioner, du har angivet: tests, navngivning, størrelse, commitbeskeder, følsomme områder. Den leder efter fejlrisici, manglende tests, ændringer der berører godkendelse, betaling eller hemmeligheder, og ændringer som intet forklarer. Den efterlader én enkelt kommentar pr. pull request: en linje, der opsummerer ændringen, hvad der er godt, og derefter punkterne at tjekke i rækkefølge efter vigtighed, hver knyttet til en fil og, når det er muligt, en linje, og markeret som blokerende eller som forslag. Den slutter med det, den ikke kunne verificere, for eksempel at køre testene. Den husker den sidste commit, den læste, og kommenterer først igen, når der kommer nye commits, med en kort opfølgning.

Sagssortereren tager sig af nye sager. Den tjekker, at typemærkerne (fejl, funktion, spørgsmål, dokumentation) og prioritetsmærkerne (høj, mellem, lav) findes, og opretter de manglende. For hver sag uden mærke læser den teksten og kommentarerne, leder efter lignende sager, afgør en type og en prioritet efter dine regler, sætter mærkerne på og tilføjer en kommentar: hvad den har forstået, begrundelsen for prioriteten, de sandsynlige dubletter og hvad der mangler for at handle, for eksempel trinnene til at genskabe fejlen eller den berørte version. Når typen eller alvoren er uklar, siger den det, vælger laveste prioritet og stiller spørgsmålet.

Hver runde slutter med et resumé i chatten, der begynder med det, som hurtigt har brug for et menneske.

Hvad agenterne ikke gør

Grænserne er en del af designet. Ingen af agenterne merger, godkender, anmoder formelt om ændringer, lukker en pull request, pusher kode eller opretter en gren. De værktøjer er ikke tildelt dem: det er ikke et løfte i en instruktion, det er en manglende evne. Sortereren lukker, genåbner, låser eller sletter ingen sag og ændrer hverken titel, ansvarlig eller milepæl.

Agenterne gætter ikke. Gennemgangeren angiver filen og linjen, markerer det, den ikke kunne verificere, og opfinder ingen funktion og intet testresultat. Hvis den støder på en indchecket hemmelighed eller et token, siger den, hvor det ser ud til at ligge, uden at kopiere det. Sortereren angiver kun sager som dubletter, hvis den faktisk har fundet dem via søgning. Og beslutningen forbliver menneskelig i hvert trin, hvilket er princippet i et design med menneskelig validering.

Sådan sætter du det op i Atako

Fra siden for denne use case sker udrulningen i fire trin.

1. Forbind GitHub. Opret et fine-grained token begrænset til repositoryet med læseadgang til kode og læse- og skriveadgang til sager og pull requests. Forbindelsen kontrolleres, før noget oprettes.
2. Angiv din kontekst. Giv repositoryet i formen ejer/navn, jeres gennemgangskonventioner, hvis I har nogen, og hvad der gør en sag hastende for dig. Uden dem støtter agenterne sig til almindelig god praksis og fejlenes alvor.
3. Udrul. Én handling opretter de to agenter og projektet «Udviklingsteam». Agenterne klargøres og får selv deres første instruktioner.
4. Første resultater, derefter en fast rytme. Gennemgangeren kommenterer de fem nyeste pull requests, sortereren mærker de ti seneste sager uden mærke, og hver opsummerer sin runde i chatten. Derefter planlægger gennemgangeren selv sine runder kl. 9:00 og 14:00 på hverdage og sortereren sin kl. 9:30.

Hvis du endnu ikke har en konto, starter oprettelsen af en din prøveperiode, og scenariet konfigureres lige efter. Hvis din administrator ikke har givet dig lov til at oprette agenter, fortæller udrulningen det og stopper dér.

Hvor du ser resultaterne

Gennemgangskommentarerne læser du i GitHub på hver pull request, og sorteringens mærker og kommentarer på hver sag. Resuméet af hver runde læser du i den enkelte agents chat. I Atako-projektet «Udviklingsteam» finder du siden om, hvordan det virker, og opfølgningen på arbejdet, og på Atako-floor vises de to agenter med deres aktuelle aktivitet.

For at justere adfærden skriver du til agenten i dens chat, for eksempel «tilføj til dine konventioner, at hver databasemigrering skal nævne tilbagerulningsplanen». Den beholder instruktionen i sin hukommelse til de følgende runder.

Værn

Adgangen er bevidst snæver. GitHub-forbindelsen tildeles agenterne med en begrænset liste på tolv værktøjer: læse pull requests, filer og commits, læse og opdatere sager, administrere mærker, tilføje kommentarer. En agent, der ser en kort værktøjsliste, bruger den mere pålideligt end en agent, der farer vild i et katalog med hundredvis, og frem for alt kan det, der ikke er tildelt, ikke ske, selv hvis en tekst forsøger at fremtvinge det. Agenterne behandler titler, beskrivelser, kommentarer og kode som data, der skal analyseres, aldrig som instruktioner.

Det token, du opretter, er dit første værn: begrænset til ét repository og præcise rettigheder afgrænser det den mulige skade, uanset hvad der sker. Det gemmes krypteret, og du kan tilbagekalde det hos GitHub eller fjerne agenternes adgang når som helst.

Den menneskelige validering sidder ved beslutningspunkterne. Du læser gennemgangskommentarerne, beslutter hvad der skal rettes, godkender og merger selv, og du lukker, tildeler og planlægger sagerne.

Hvad du kan forvente

Forvent nyttige kommentarer især på pull requests af rimelig størrelse: ved en meget stor ændring siger gennemgangeren det og koncentrerer sig om de mest følsomme filer i stedet for at foregive at have læst alt. Den kan ikke køre dine tests og siger det i hver kommentar. Sortereren er så præcis, som dine prioritetsregler er; uden dem vælger den forsigtighed og stiller spørgsmål. Værdien kommer af regelmæssigheden: hver pull request får en første gennemlæsning inden for en halv dag, hver sag kommer kvalificeret, og jeres menneskelige gennemgangere bruger tiden på skøn og ikke på at spore fejl.