– Min nye produktsjef er en lærende agent

Mandag 6. juli lå jeg på plattingen på Kvamskogen og hadde ferie. 

Klokka 09:32 startet produktsjefen min ukas selvrefleksjon, og fire minutter senere hadde den åpnet en pull request. Jeg kunne ligge i sola mens den forbedret seg selv.

Produktsjefen heter crema-agent og er en GitHub-app jeg har lært opp til å jobbe i backloggen til CReMa, det interne CRM-systemet til Kodemaker. 

Den leser nye saker, prioriterer dem, graver i hva som egentlig blir bedt om, og skriver utkast til spesifikasjoner. Enkle fikser koder den også. Alt den lager kommer som pull requests.

Produkteieren jeg aldri hadde

CReMa drifter jeg stort sett alene, ved siden av kundeoppdrag. Ingen produkteier prioriterer for meg, ingen makker tenker høyt med meg. 

Det vanskelige er ikke selve byggingen, men å vite at jeg løser riktig problem, og ikke bare bygger det som er lettest å bygge.

Treffsikkerheten er lavere enn de fleste liker å tro. Hos Microsoft, som måler ideene sine med kontrollerte eksperimenter, forbedrer bare rundt en tredjedel av ideene det de skal forbedre. Det er ideer fra hele produktteam, med produktsjefer og alt. 

Alene treffer jeg neppe bedre. Så det var rollen jeg ga agenten: den som leser hver sak grundig, skiller symptom fra årsak og tar førsteutkastet.

Den mektigste knappen er en etikett

Det er lite magi i opplegget, og det er selve poenget. Statusen til en sak ligger i etikettene (labels) på GitHub, og hver av dem er satt av et menneske.

Kommer det en ny sak, triagerer agenten den på ett til tre minutter: type, prioritet, størrelse, rett i backloggen. Setter jeg på agent:spec, ligger et utkast til spesifikasjon klart som pull request fem til åtte minutter senere. Godkjenner jeg med agent:ready og legger på agent:implement, koder den løsningen, kjører testene og åpner en pull request som lukker saken. Review-boten vår har lest gjennom endringen før jeg rekker å åpne den.

Etikettene er knappene, Kanban-tavla er bare et speil av dem så jeg har oversikt. Regelen som gjør at dette går an i praksis: mennesket trykker på hver eneste knapp. Agenten kan gjøre arbeidet i ett steg, men den kan aldri sende seg selv videre til neste.

Fra ønske til spec-utkast på ti minutter

En kollega ønsket seg en ny funksjon: e-poster skal kunne knyttes til leads. Tre minutter etter at saken fikk triage-etiketten, svarte agenten. Type: forbedring. Prioritet: P1, fordi «e-post er ofte den naturlige inngangen til en lead». Størrelse: medium.

Jeg la på agent:spec. Sju minutter senere lå førsteutkastet klart som pull request: 157 linjer, med problembeskrivelsen forankret i kollegaenes egne kommentarer og de åpne spørsmålene samlet nederst.

«E-post er ofte den naturlige inngangen til en lead» er produktresonnering, forarbeidet en god produktsjef ville brukt timer på, servert før jeg rakk å hente kaffe. Agenten bruker minutter der jeg ville trengt alt fra en halvtime til to dager, og jeg bruker kvarteret mitt på å finpusse.

Prislappen? En triage koster rundt én dollar, et spec-utkast to, og en hel sak fra triage til ferdig pull request lander typisk på seks dollar i modellbruk. Det er implementeringen som varierer mest: de dyreste kjøringene koster to til tre ganger det vanlige. 

Sett opp mot timene et spec-utkast sparer meg for, er det regnestykket fort gjort. Tallene er listepris, altså det tokenene ville kostet om jeg kjøpte dem løst. I praksis betaler jeg ingenting ekstra, siden agenten går på Claude-abonnementet jeg allerede har.

Stripe gjør det samme, bare større

Er dette et leketøy for ett lite internsystem? Stripe mener nei. De har bygget sine egne kodeagenter, kalt minions, og skriver åpent om hvordan de fungerer. Hos dem merges over 1300 pull requests i uka helt uten menneskeskrevet kode. Styringsmodellen er den samme som i vårt lille CRM: agenten produserer, mennesket godkjenner.

Lisens til å triagere, ikke til å merge

crema-agent er registrert som GitHub-app med egen bot-identitet, ikke som en ansatt med adgangskort. Bare slik kan systemet skille menneske fra bot. Hvert steg får dessuten så lite tilgang som mulig: triage-steget kan bare sortere og sette etiketter. Skulle nøkkelen lekke, er det verste en angriper får til å stokke om på noen gule lapper.

Den mest omtalte trusselen heter prompt injection: en sak er tekst, og teksten kan prøve å kuppe agenten. Derfor blandes tekst fra saker aldri inn i agentens egne instrukser. Alt i en sak behandles som upålitelige data, og oppdager agenten et forsøk på å vri den av sporet, stopper den og merker saken agent:blocked. Alt agenten gjør ender som et forslag. Hele historikken blir liggende igjen som kommentarer og pull requests.

Første oppdrag gikk skeis

Agenten fikk en liten bug som sin første ekte sak, og tre interessante ting gikk galt.

Den kjørte, meldte «ferdig» med grønt flagg, og hadde gjort ingenting. Den hadde brukt hele kjøringen på å bli nektet tilgang til sin egen oppskrift: 25 avslag på 34 forsøk, og så avsluttet den «vellykket». Lærdom nummer én: grønt er ikke det samme som gjort.

I neste forsøk skrev den at den «manglet tilgang til prosjektet». Det stemte ikke: den hadde bare skrevet kommandoen på en måte tilgangslista ikke godtok, og diktet opp en troverdig forklaring i stedet for å melde fra om den ekte feilen. Lærdom nummer to: be den rapportere det den faktisk ser, ikke det som høres sannsynlig ut.

Den tredje feilen var vanskeligst: tavla ville fortsatt ikke oppdatere seg. Årsaken var uventet: saken var full av agentens egne mislykkede kommentarer, og den nye kjøringen leste dem, trodde på dem og gjentok «mangler tilgang» som om det var fersk informasjon. Lærdom nummer tre: stol på det du måler nå, ikke på arkivet.

Alle tre ble fikset med små endringer. Et slikt oppsett må testes i ekte bruk, som et hvilket som helst produkt.

Agenten som lærer av rettelsene våre

Så tilbake til plattingen. Hver mandag morgen kjører en jobb der agenten ser tilbake på uka: Hvor gjorde vi om på triagen? Hva var vi uenige i? 

Den leser rettelsene våre som tilbakemelding og foreslår justeringer i sin egen oppskrift, ikke i koden til CRM-systemet. Ideen er lånt fra Warp, som kjører lignende selvforbedrings-løkker. Agenten får foreslå forbedringer av seg selv, men aldri gjennomføre dem på egen hånd.

Agenten foreslår, mennesket bestemmer

Målet er ikke å erstatte utviklere med en bot. For meg var det nesten motsatt. 

Jeg liker å bygge, men å drifte alene er vanskelig, og jeg har savnet en som prioriterer, stiller spørsmål og tar førsteutkastet sammen med meg. 

Den rollen fyller agenten nå, og den strekker oppmerksomheten min som utvikler lenger. Grunnregelen ligger fast: den mektigste knappen i arbeidsflyten vår er fortsatt en etikett, og det er et menneske som trykker på den.

Hvilke oppgaver hos dere er modne for en agent, og hvilke rammer ville du gitt den?