Af Kwame Boateng

AI-assisteret kodning beskrives ofte som en hurtigere version af parprogrammering. Den sammenligning er nu for snæver. Når en agent kan inspicere et repository, ændre flere filer, køre værktøjer, generere en forhåndsvisning og oprette en pull request, er det centrale samarbejdsproblem ikke længere blot: »Kan den skrive kode?« Det er: »Kan mennesker se, gennemgå, godkende og senere rekonstruere, hvad der skete?«

Det er derfor, at det vigtigste designskifte i agent-assisterede softwareteams måske er bevægelsen fra private prompts til synlige arbejdsområder. Slack Code beskrives for eksempel som en kombination af projektkanaler med kodningsagenter, revision af kodeforskelle, live-forhåndsvisninger af HTML, arbejdsgange for feedback og godkendelse, automatisk arkivering og revisionslogs. GitHubs Copilot-app har også tilføjet en rude med »Mit arbejde« til organisering af issues og pull requests på tværs af projekter. Disse funktioner peger på et praktisk princip: En agents arbejde bør ligne mindre et uigennemsigtigt svar og mere et ændringssæt, der bevæger sig gennem en kontrolleret produktionsproces.

Chatten er ikke arbejdsloggen

En samtale med en agent kan være nyttig til at udforske en idé, men den er et svagt system of record. Vigtige detaljer kan gemme sig i en lang tråd: hvilke filer der blev ændret, hvilke kommandoer der blev kørt, hvilke antagelser agenten gjorde, hvad en reviewer afviste, og om det endelige resultat adskiller sig fra det første forslag.

Et varigt arbejdsområde gør disse detaljer inspicerbare. Det bør forbinde forespørgslen med et specifikt repository eller projekt, bevare agentens plan, vise værktøjshandlinger og filændringer, linke til tests og forhåndsvisninger og registrere, hvem der godkendte resultatet. Den præcise grænseflade kan variere—en issue-tracker, pull request, samarbejdskanal eller agentkonsol—men oplysningerne bør bestå, efter sessionen er slut.

Det er vigtigt af almindelige tekniske grunde, ikke kun af hensyn til compliance. Hvis der opstår en fejl to uger senere, har et team brug for mere end den endelige diff. Det kan være nødvendigt at kende det oprindelige krav, den genererede plan, testresultaterne, reviewerens kommentarer og om et menneske udtrykkeligt accepterede en risikabel afvejning. En varig log forkorter denne undersøgelse.

Fem lag af synligt arbejde

Teams, der tager kodningsagenter i brug, kan behandle hver ændring som en lille, inspicerbar sagsmappe. Fem lag er særligt nyttige:

  1. Intention: issuet, acceptkriterierne, begrænsningerne og det ønskede omfang.
  2. Plan: agentens foreslåede fremgangsmåde, før den redigerer filer. For en ikke-triviel opgave er dette et godkendelseskontrolpunkt, ikke pynt.
  3. Diff: de præcise tilføjelser, sletninger, afhængighedsændringer, konfigurationsredigeringer og genererede aktiver.
  4. Dokumentation: testresultater, lint-output, sikkerhedstjek, skærmbilleder og en live- eller deployerbar forhåndsvisning, hvor det er relevant.
  5. Beslutningslog: reviewerkommentarer, ønskede ændringer, godkendelse, afvisning, rollback eller opfølgende arbejde.

Pointen er ikke at tvinge enhver ændring gennem et tungt udvalg. En slåfejl og en ændring af betalingsflowet bør ikke have identiske kontroller. Pointen er at gøre graden af kontrol proportional med den potentielle påvirkning.

Godkendelser bør knyttes til handlinger

»Mennesket i løkken« er for vagt til at være en nyttig kontrol. En person kan godkende en plan uden at se den resulterende diff eller godkende en kodeændring uden at opdage, at agenten også ændrede en deploymentfil. Bedre arbejdsgange angiver, hvad en godkendelse giver tilladelse til.

Et team kan for eksempel tillade, at en agent automatisk læser et repository og kører lokale tests, kræve godkendelse, før den skriver uden for en udpeget branch, og kræve en separat godkendelse før merge eller deployment. En agent kan foreslå en databasemigrering, men forbydes at udføre den i produktion. UAEs foreslåede tilgang til at klassificere, hvilke opgaver agenter må fuldføre, og hvilke de blot må anbefale, afspejler dette bredere mønster: Autonomi bør tildeles efter opgave og ikke antages globalt.

Godkendelser skal også have et omfang og en udløbsdato. En godkendelse af »opdater teksten på landingssiden« bør ikke stiltiende autorisere en ny analysepakke. En plan, der blev godkendt i går, bør ikke automatisk dække en væsentligt ændret diff i dag. Grænserne bør være synlige i grænsefladen.

Forhåndsvisninger gør review til inspektion

Code review er ofte lettere, når mennesker kan inspicere resultatet i stedet for at udlede det af kildefilerne. En live-forhåndsvisning af HTML kan afsløre ødelagt afstand, manglende tilstande, utilgængelige kontroller eller en utilsigtet ændring i navigationen, som en reviewer måske overser i en tekstuel diff.

Forhåndsvisninger er ikke bevis på korrekthed. De bør stå ved siden af, ikke erstatte, tests og kildekodereview. Men de skaber et fælles objekt for diskussion: En reviewer kan pege på en bestemt skærm, tilstand eller interaktion og knytte feedback til den foreslåede ændring.

Det er særligt værdifuldt, når ikke-specialister deltager i reviewet. En product manager kan måske ikke vurdere en frameworkændring, men kan være den rette person til at bekræfte, at arbejdsgangen svarer til kravet. En designer kan validere en visuel regression. En sikkerhedsspecialist kan fokusere på tilladelser og datahåndtering. Det agent-assisterede arbejdsområde kan sende hvert spørgsmål videre til den person, der er bedst placeret til at besvare det.

Diffs har brug for kontekst, ikke kun farve

En velkendt rød-og-grøn diff er stadig vigtig, men agentgenererede ændringer kan være omfattende nok til at overvælde en reviewer. Teams bør bede agenter om at holde commits eller ændringsgrupper afgrænsede, forklare, hvorfor hver væsentlig fil blev ændret, og identificere genererede filer eller leverandørfiler særskilt.

Nyttige spørgsmål til gennemgang omfatter:

  • Hvilken bruger­synlig adfærd er ændret?
  • Hvilke filer blev kun ændret for at understøtte implementeringen?
  • Hvilke antagelser gjorde agenten om den eksisterende adfærd?
  • Hvilke tests blev tilføjet, ændret eller ikke kørt?
  • Kan denne ændring påvirke tilladelser, dataopbevaring, fakturering eller eksterne API'er?

Disse spørgsmål gør gennemgangen til en gentagelig undersøgelse i stedet for en vag anmodning om at »se det her igennem«. De hjælper også med at afdække en almindelig fejltilstand: en plausibel funktion ledsaget af en ufuldstændig opdatering af tests eller en utilsigtet konfigurationsændring.

Arkivér den relevante argumentation

Det er ikke automatisk nyttigt at bevare hvert eneste token fra hver modelsamtale. Lange historikker kan være dyre at gemme og vanskelige at søge i, mens forskning i kontekstkomprimering advarer om, at opsummeringer kan miste vigtig information. Et praktisk revisionsspor bør derfor bevare beslutningsrelevante artefakter frem for ukritisk at gemme alt.

Som minimum skal anmodningen, den godkendte plan, den endelige diff, resultaterne fra værktøjer og tests, referencen til forhåndsvisningen eller udrulningen, beslutninger truffet af gennemgåere samt eventuelle godkendte undtagelser bevares. Hvis en agent brugte eksterne kilder eller hentede interne dokumenter, skal de relevante kildereferencer og det tidspunkt, hvor de bidrog til ændringen, registreres. For arbejde med høj risiko kan det være berettiget at bevare den fuldstændige interaktions- og udførelseslog.

Gør registreringer manipulationssikre, når indsatsen kræver det, og fastlæg regler for opbevaring, før en krise opstår. Et revisionsspor, der forsvinder, når en kanal arkiveres — eller som ikke kan skelne et ændret resultat fra originalen — vil ikke understøtte en seriøs undersøgelse.

Hvad dette ændrer for karrierer inden for software

Den nye kompetence er ikke blot at skrive bedre prompts. Det handler om at designe arbejde, som en anden person kan inspicere og have tillid til. Udviklere skal være fortrolige med at specificere acceptkriterier, opdele opgaver, gennemgå diffs i stor skala, opbygge meningsfulde tests og afgøre, hvornår en agent skal stoppe og spørge.

Folk inden for produkt og design får en større rolle i gennemgangen af forhåndsvisninger og præciseringen af intentioner. QA-ingeniører kan hjælpe med at definere godkendelsesporte og fejlsituationer. Engineering managers skal måle gennemløb uden at belønne usynlig risikotagning. Tekniske skribenter og driftsspecialister kan bidrage ved at gøre beslutninger, undtagelser og runbooks varige.

En nyttig øvelse er at tage en rutinefunktion og kortlægge dens evidenskæde: anmodning, plan, branch, diff, tests, forhåndsvisning, godkendelse, release og rollback. Spørg derefter, hvor en fremtidig kollega ville være tvunget til at gætte. Hvert gæt er en kandidat til et bedre arbejdsområde, en tydeligere tilladelse eller en mere holdbar registrering.

En enkel arbejdsregel

Lad agenter bevæge sig hurtigt inden for en synlig og reversibel ramme. Giv dem et afgrænset arbejdsområde, begræns følsomme handlinger, kræv godkendelse ved meningsfulde grænser, knyt evidens til ændringen, og bevar den endelige beslutning. Målet er ikke at sænke automatiseringen, indtil den ligner manuel kodning. Det er at gøre hastighed forenelig med ansvarlighed.

I agentassisteret udvikling er den bedste samarbejdspartner ikke det system, der isoleret set producerer mest kode. Det er det system, hvis arbejde kan forstås, udfordres, godkendes, fortrydes og bruges til at lære af.