Av Kwame Boateng
AI-assistert koding beskrives ofte som en raskere versjon av parprogrammering. Den sammenligningen er nå for snever. Når en agent kan inspisere et kodearkiv, endre flere filer, kjøre verktøy, generere en forhåndsvisning og opprette en pull request, er det sentrale samarbeidsproblemet ikke lenger bare «Kan den skrive kode?» Det er «Kan mennesker se, gjennomgå, godkjenne og senere rekonstruere det som skjedde?»
Derfor kan det viktigste designskiftet i programvareteam som bruker agenter, være overgangen fra private meldinger til synlige arbeidsområder. Slack Code beskrives for eksempel som en kombinasjon av prosjektkanaler med kodeagenter, revisjon av kodeforskjeller, forhåndsvisning av HTML i sanntid, arbeidsflyter for tilbakemeldinger og godkjenning, automatisk arkivering og revisjonslogger. GitHub har også lagt til et «Mitt arbeid»-panel i Copilot-appen for organisering av issues og pull requests på tvers av prosjekter. Disse funksjonene peker mot et praktisk prinsipp: En agents arbeid bør ligne mindre på et ugjennomsiktig svar og mer på et endringssett som beveger seg gjennom en kontrollert produksjonsprosess.
Chatten er ikke arbeidsloggen
En samtale med en agent kan være nyttig for å utforske en idé, men er et svakt system for registrering av hva som har skjedd. Viktige detaljer kan bli begravd i en lang tråd: hvilke filer som ble endret, hvilke kommandoer som ble kjørt, hvilke antakelser agenten gjorde, hva en gjennomgår avviste, og om det endelige resultatet skiller seg fra det første forslaget.
Et varig arbeidsområde gjør disse detaljene etterprøvbare. Det bør knytte forespørselen til et bestemt kodearkiv eller prosjekt, bevare agentens plan, vise verktøyhandlinger og filendringer, lenke til tester og forhåndsvisninger og registrere hvem som godkjente resultatet. Det nøyaktige grensesnittet kan variere – en issuesporer, en pull request, en samarbeidskanal eller en agentkonsoll – men informasjonen bør bestå etter at økten er avsluttet.
Dette er viktig av vanlige tekniske grunner, ikke bare av hensyn til etterlevelse. Hvis en feil dukker opp to uker senere, trenger et team mer enn den endelige diffen. Det kan være nødvendig å vite hva det opprinnelige kravet var, hvilken plan som ble generert, hvilke testbevis som forelå, hvilke kommentarer gjennomgåren hadde, og om et menneske uttrykkelig godtok en risikabel avveining. En varig logg gjør denne undersøkelsen kortere.
Fem lag med synlig arbeid
Team som tar i bruk kodeagenter, kan behandle hver endring som en liten, etterprøvbar saksmapppe. Fem lag er særlig nyttige:
- Hensikt: saken, akseptansekriteriene, begrensningene og det etterspurte omfanget.
- Plan: agentens foreslåtte fremgangsmåte før den redigerer filer. For en ikke-triviell oppgave er dette et godkjenningspunkt, ikke pynt.
- Diff: de nøyaktige tilleggene, slettingene, avhengighetsendringene, konfigurasjonsredigeringene og genererte ressursene.
- Bevis: testresultater, lint-utdata, sikkerhetskontroller, skjermbilder og en forhåndsvisning i sanntid eller som kan distribueres, der det er relevant.
- Beslutningslogg: kommentarer fra gjennomgåere, forespurte endringer, godkjenning, avvisning, tilbakerulling eller oppfølgingsarbeid.
Poenget er ikke å tvinge enhver endring gjennom en tungvint komité. En skrivefeil og en endring i betalingsflyten bør ikke ha identiske kontroller. Poenget er å gjøre granskingsnivået proporsjonalt med den potensielle påvirkningen.
Godkjenninger bør knyttes til handlinger
«Menneske i loopen» er for vagt til å være en nyttig kontroll. En person kan godkjenne en plan uten å se den resulterende diffen, eller godkjenne en kodeendring uten å legge merke til at agenten også endret en distribusjonsfil. Bedre arbeidsflyter sier tydelig hva godkjenningen tillater.
Et team kan for eksempel tillate en agent å lese et kodearkiv og kjøre lokale tester automatisk, kreve godkjenning før den skriver utenfor en angitt gren og kreve en separat godkjenning før sammenslåing eller distribusjon. En agent kan foreslå en databasemigrering, men forbys å utføre den i produksjon. De foreslåtte tilnærmingene i De forente arabiske emirater til å klassifisere hvilke oppgaver agenter kan fullføre, kontra bare anbefale, gjenspeiler dette bredere mønsteret: Autonomi bør tildeles per oppgave, ikke antas globalt.
Godkjenninger trenger også omfang og utløp. En godkjenning av «oppdater teksten på landingssiden» bør ikke i det stille autorisere en ny analysepakke. En plan som ble godkjent i går, bør ikke automatisk dekke en vesentlig endret diff i dag. Grensesnittet bør gjøre disse grensene synlige.
Forhåndsvisninger gjør gjennomgang til inspeksjon
Kodegjennomgang er ofte enklere når folk kan inspisere resultatet i stedet for å utlede det fra kildefiler. En HTML-forhåndsvisning i sanntid kan avdekke ødelagte avstander, manglende tilstander, utilgjengelige kontroller eller en utilsiktet endring i navigasjonen som en gjennomgår kan overse i en tekstlig diff.
Forhåndsvisninger er ikke bevis på at noe er korrekt. De bør ligge ved siden av, ikke erstatte, tester og kildekodegjennomgang. Men de skaper et felles diskusjonsobjekt: En gjennomgår kan peke på en bestemt skjerm, tilstand eller interaksjon og legge igjen tilbakemelding knyttet til den foreslåtte endringen.
Dette er særlig verdifullt når ikke-spesialister deltar i gjennomgangen. En produktleder kan kanskje ikke vurdere en endring i rammeverket, men kan være den rette personen til å bekrefte at arbeidsflyten samsvarer med kravet. En designer kan validere en visuell regresjon. En sikkerhetsspesialist kan fokusere på tillatelser og datahåndtering. Det agentassisterte arbeidsområdet kan dirigere hvert spørsmål til personen som er best egnet til å besvare det.
Differ trenger kontekst, ikke bare farger
En velkjent diff i rødt og grønt er fortsatt avgjørende, men agentgenererte endringer kan være omfattende nok til å overvelde en gjennomgår. Team bør be agenter om å holde committer eller endringsgrupper avgrensede, forklare hvorfor hver vesentlige fil ble endret og identifisere genererte filer eller leverandørfiler separat.
Nyttige spørsmål ved gjennomgang er blant annet:
- Hvilken synlig endring for brukeren har skjedd?
- Hvilke filer ble endret utelukkende for å støtte implementeringen?
- Hvilke antakelser gjorde agenten om eksisterende atferd?
- Hvilke tester ble lagt til, endret eller ikke kjørt?
- Kan denne endringen påvirke tillatelser, datalagring, fakturering eller eksterne API-er?
Disse spørsmålene gjør gjennomgangen til en repeterbar undersøkelse i stedet for en vag oppfordring om å «se over dette». De bidrar også til å avdekke en vanlig feilmodus: en plausibel funksjon ledsaget av en ufullstendig testoppdatering eller en utilsiktet konfigurasjonsendring.
Arkiver den viktige begrunnelsen
Det er ikke automatisk nyttig å bevare hvert eneste token i hver modell samtale. Lange historikker kan være kostbare å lagre og vanskelige å søke i, mens forskning på kontekstkomprimering advarer om at sammendrag kan miste viktig informasjon. Et praktisk revisjonsspor bør derfor bevare artefakter som er relevante for beslutninger, i stedet for å lagre alt ukritisk.
Som et minimum bør forespørselen, den godkjente planen, den endelige diffen, resultater fra verktøy og tester, referansen til forhåndsvisningen eller utrullingen, beslutningene fra gjennomgangen og eventuelle innvilgede unntak beholdes. Hvis en agent brukte eksterne kilder eller hentet interne dokumenter, bør de relevante kildehenvisningene og tidspunktet da de ble tatt i bruk i endringen, registreres. For arbeid med høy risiko kan det være berettiget å beholde hele interaksjonen og kjøringsloggen.
Gjør registreringene manipulasjonssikre der konsekvensene tilsier det, og fastsett regler for oppbevaring før en krise oppstår. Et revisjonsspor som forsvinner når en kanal arkiveres – eller som ikke kan skille et endret resultat fra originalen – vil ikke støtte en seriøs undersøkelse.
Hva dette endrer for programvarekarrierer
Den nye ferdigheten handler ikke bare om å skrive bedre ledetekster. Den handler om å utforme arbeid som en annen person kan inspisere og ha tillit til. Utviklere må kunne spesifisere akseptansekriterier, dele opp oppgaver, gjennomgå differ i stor skala, bygge meningsfulle tester og avgjøre når en agent må stoppe og spørre.
Produkt- og designfagfolk vil få en større rolle i gjennomgangen av forhåndsvisninger og presiseringen av hensikten. QA-ingeniører kan bidra til å definere godkjenningsporter og feilsituasjoner. Utviklingsledere må måle gjennomstrømning uten å belønne usynlig risikotaking. Teknologiske skribenter og driftsspesialister kan bidra ved å gjøre beslutninger, unntak og driftsprosedyrer varige.
En nyttig øvelse er å ta en rutinemessig funksjon og kartlegge beviskjeden: forespørsel, plan, branch, diff, tester, forhåndsvisning, godkjenning, lansering og tilbakerulling. Spør deretter hvor en fremtidig kollega ville bli tvunget til å gjette. Hver gjetning er en kandidat for et bedre arbeidsområde, en tydeligere tillatelse eller et mer varig dokument.
En enkel arbeidsregel
La agenter bevege seg raskt innenfor en synlig og reverserbar ramme. Gi dem et definert arbeidsområde, begrens sensitive handlinger, krev godkjenning ved meningsfulle overganger, knytt dokumentasjon til endringen og bevar den endelige beslutningen. Målet er ikke å bremse automatiseringen til den ligner manuell koding. Målet er å gjøre hastighet forenlig med ansvarlighet.
I agentassistert utvikling er den beste samarbeidspartneren ikke systemet som produserer mest kode isolert sett. Det er systemet hvis arbeid kan forstås, utfordres, godkjennes, gjøres om og læres av.
