Utvecklingsteam: AI-agenter granskar pull requests och sorterar GitHub-ärenden

I ett utvecklingsteam är kodgranskning och ärendesortering två uppgifter som alla tycker är nyttiga och som ingen hittar tid att göra ordentligt. En pull request väntar två dagar på att någon ledig ska läsa den, och de första kommentarerna handlar ofta om vad en snabb genomläsning hade sett: ett saknat test, en alltför bred gren, en bortglömd hemlighet. Ett ärende kommer in utan typ och prioritet, ibland utan information för att återskapa felet, och väntar på att en människa ska kvalificera det. Det är metoduppgifter, med kriterier som teamet kan skriva ner, och de passar AI-agenter så länge deras rättigheter är avgränsade.

Inspirationen: en första genomläsning före människorna

Utgångspunkten är ett användningsområde som användare av Hermes Agent har berättat om, sammanfattat i ett kort om utvecklingsteamet: granska de öppna pull requests och sortera de nya ärendena. Tanken är inte att ersätta den mänskliga granskaren, utan att ge hen pull requests som redan är lästa, med punkterna att kontrollera överst i listan, och ärenden som redan är kvalificerade.

Vi behåller två skilda roller och en försiktighetsprincip: agenterna kommenterar och etiketterar, de bestämmer ingenting. Atako tillämpar idén med två agenter vars GitHub-åtkomst medvetet är begränsad till att läsa, kommentera och etikettera.

Vad de två agenterna gör

Scenariot driftsätter två agenter, båda kopplade till ditt GitHub-repo.

PR-granskaren läser de öppna pull requests. För var och en går den igenom titel, beskrivning, ändrade filer och commits, öppnar de filer som spelar roll och jämför dem med de konventioner du har angett: tester, namngivning, storlek, commitmeddelanden, känsliga områden. Den letar efter felrisker, saknade tester, ändringar som rör autentisering, betalning eller hemligheter och ändringar som ingenting förklarar. Den lämnar en enda kommentar per pull request: en rad som sammanfattar ändringen, vad som är bra och sedan punkterna att kontrollera i viktighetsordning, var och en knuten till en fil och när det går en rad, och markerad som blockerande eller som förslag. Den avslutar med vad den inte kunde verifiera, till exempel att köra testerna. Den minns den senaste commit den läste och kommenterar igen först när nya commits kommer, med en kort uppföljning.

Ärendesorteraren tar hand om nya ärenden. Den kontrollerar att typetiketterna (bugg, funktion, fråga, dokumentation) och prioritetsetiketterna (hög, medel, låg) finns och skapar de som saknas. För varje ärende utan etikett läser den texten och kommentarerna, letar efter liknande ärenden, bestämmer en typ och en prioritet enligt dina regler, sätter etiketterna och lägger till en kommentar: vad den har förstått, skälet till prioriteten, de sannolika dubbletterna och vad som saknas för att agera, till exempel stegen för att återskapa eller berörd version. När typ eller allvarlighetsgrad är oklar säger den det, väljer lägsta prioritet och ställer frågan.

Varje omgång avslutas med en sammanfattning i chatten som börjar med det som snabbt behöver en människa.

Vad agenterna inte gör

Gränserna är en del av utformningen. Ingen av agenterna mergar, godkänner, begär formellt ändringar, stänger en pull request, pushar kod eller skapar en gren. De verktygen är inte beviljade: det är inget löfte i en instruktion, det är en förmåga som saknas. Sorteraren stänger, öppnar igen, låser eller raderar inget ärende och ändrar varken titel, tilldelad person eller milstolpe.

Agenterna gissar inte. Granskaren anger fil och rad, flaggar vad den inte kunde verifiera och hittar inte på någon funktion eller något testresultat. Om den stöter på en incheckad hemlighet eller token säger den var den verkar finnas, utan att kopiera den. Sorteraren anger som dubbletter bara ärenden den faktiskt hittat via sökning. Och beslutet förblir mänskligt i varje steg, vilket är principen bakom en design med mänskligt godkännande.

Så ställer du in det i Atako

Från sidan för det här användningsfallet sker driftsättningen i fyra steg.

1. Koppla GitHub. Skapa en fine-grained-token begränsad till repot, med läsåtkomst till kod och läs- och skrivåtkomst till ärenden och pull requests. Kopplingen kontrolleras innan något skapas.
2. Ange ditt sammanhang. Ange repot i formen ägare/namn, era granskningskonventioner om ni har några och vad som gör ett ärende brådskande för dig. Utan dem lutar sig agenterna mot allmänna goda rutiner och buggars allvarlighetsgrad.
3. Driftsätt. En enda åtgärd skapar de två agenterna och projektet "Utvecklingsteam". Agenterna förbereds och får sina första instruktioner på egen hand.
4. Första resultat, sedan en jämn rytm. Granskaren kommenterar de fem senaste pull requests, sorteraren etiketterar de tio senaste ärendena utan etikett och var och en sammanfattar sin omgång i chatten. Därefter schemalägger granskaren själv sina omgångar kl. 9:00 och 14:00 på vardagar och sorteraren sin kl. 9:30.

Om du ännu inte har ett konto startar skapandet av ett din provperiod, och scenariot konfigureras direkt efteråt. Om din administratör inte har tillåtit dig att skapa agenter meddelar driftsättningen det och stannar där.

Var du ser resultaten

Granskningskommentarerna läser du i GitHub, på varje pull request, och sorteringens etiketter och kommentarer på varje ärende. Sammanfattningen av varje omgång läser du i respektive agents chatt. I Atako-projektet "Utvecklingsteam" hittar du sidan om hur det fungerar och uppföljningen av arbetet, och på Atako-floor visas de två agenterna med sin pågående aktivitet.

För att justera beteendet skriver du till agenten i dess chatt, till exempel "lägg till i dina konventioner att varje databasmigrering måste ange planen för återställning". Den behåller instruktionen i sitt minne för kommande omgångar.

Skyddsräcken

Åtkomsten är medvetet smal. GitHub-kopplingen beviljas agenterna med en begränsad lista på tolv verktyg: läsa pull requests, filer och commits, läsa och uppdatera ärenden, hantera etiketter, lägga till kommentarer. En agent som ser en kort verktygslista använder den mer pålitligt än en agent som går vilse i en katalog på hundratals, och framför allt kan det som inte är beviljat inte hända, även om en text försöker tvinga fram det. Agenterna behandlar titlar, beskrivningar, kommentarer och kod som data att analysera, aldrig som instruktioner.

Den token du skapar är ditt första skyddsräcke: begränsad till ett repo och till precisa rättigheter avgränsar den den möjliga skadan, vad som än händer. Den lagras krypterad, och du kan återkalla den på GitHub-sidan eller ta bort agenternas åtkomst när som helst.

Det mänskliga godkännandet sitter vid beslutspunkterna. Du läser granskningskommentarerna, bestämmer vad som ska rättas, godkänner och mergar själv, och du stänger, tilldelar och planerar ärendena.

Vad du kan förvänta dig

Räkna med användbara kommentarer främst på pull requests av rimlig storlek: vid en mycket stor ändring säger granskaren det och koncentrerar sig på de känsligaste filerna i stället för att låtsas ha läst allt. Den kan inte köra dina tester och säger det i varje kommentar. Sorteraren är så träffsäker som dina prioritetsregler är precisa; utan dem väljer den försiktighet och ställer frågor. Värdet kommer av regelbundenheten: varje pull request får en första genomläsning inom en halv dag, varje ärende kommer kvalificerat och era mänskliga granskare lägger sin tid på bedömning och inte på att leta.