Sådan arbejder jeg med AI-agenter, og hvor grænsen går
Når jeg lukker computeren, kan der stadig være arbejde i gang. En agent bygger en afgrænset ændring. En anden gennemgår det færdige forslag. Der bliver kørt tests, og resultatet bliver gemt, så jeg kan tage stilling til det bagefter.
Det lyder måske som en hjemmeside, der bliver lavet om, mens ejeren sover. Sådan arbejder jeg ikke. Der er forskel på at give et værktøj lov til at arbejde og at give det lov til at sætte noget i drift.
Jeg har tidligere skrevet om, hvordan én person med AI kan levere hele stakken. Her vil jeg vise mere konkret, hvad der foregår mellem opgavebeskrivelsen og den ændring, du ser på din hjemmeside. Det er også dér, mine grænser bliver tydelige.
Først skal jeg kunne forklare opgaven
En agent får ikke beskeden: Gør hjemmesiden bedre. Den får en opgave med et bestemt formål, et afgrænset område og en beskrivelse af, hvordan resultatet skal kontrolleres.
Tag et tænkt eksempel: En formular mister den valgte kategori, når en besøgende har glemt at udfylde et felt. Opgaven er at bevare valget, vise en forståelig fejl og lade brugeren prøve igen. Det er ikke en anledning til at lave formularens udseende om eller udskifte systemet bag den.
Jeg skal have taget stilling til det, inden arbejdet begynder. Ellers overlader jeg også prioriteringen til agenten. Den kan godt levere en omfattende løsning på et problem, som kunne være løst med en lille rettelse.
Derfor beskriver jeg også, hvad opgaven ikke omfatter. Hvis jeg ikke selv kan forklare, hvornår den er løst, er den som regel ikke klar til at blive sat i gang uden mig.
En branch holder forslaget adskilt
Når en agent arbejder på en branch, arbejder den på en separat udviklingsgren af koden. Den kan gemme sine ændringer dér, uden at de bliver en del af den version, hjemmesiden bruger.
Det giver mig et konkret forslag at gennemgå. Jeg kan se, hvilke filer der er ændret, og sammenligne dem med udgangspunktet. Hvis agenten har rørt noget uden for opgaven, kan jeg opdage det, inden ændringen bliver godkendt.
Ved parallelle opgaver bruger jeg adskilte arbejdskopier. Agenterne skal ikke redigere i de samme filer i den samme mappe og håbe på, at det går. Hvert arbejde skal kunne forstås og vurderes for sig.
En branch er dog ikke i sig selv en sikkerhedsgrænse. Den holder kodeændringer adskilt, men siger ikke noget om, hvilke systemer et værktøj kan tilgå. Adgang og tilladelse til at sætte noget i drift skal styres særskilt. Ellers har man kun adskilt filerne.
Hvad jeg sætter i gang om natten
Natarbejde egner sig til opgaver, hvor retningen er besluttet. Det kan være at rette en kendt fejl, skrive en test for en bestemt adfærd eller gennemføre en lille forbedring med tydelige krav.
Det egner sig dårligere til spørgsmål, hvor jeg stadig mangler at forstå kundens behov. En agent skal ikke gætte på, hvordan en virksomhed vil håndtere aflysninger, eller hvilke oplysninger en formular bør bede om. Den slags skal afklares med den, der faktisk bruger løsningen.
Jeg vil kunne åbne resultatet og se, hvad der er lavet, hvad der er kontrolleret, og hvad der ikke lykkedes. En besked om, at opgaven er færdig, er ikke nok. Hvis en test ikke kunne køres, skal det stå der. Hvis noget kræver en beslutning fra mig, skal det være tydeligt.
Nogle opgaver ender derfor med et brugbart forslag. Andre ender med en forklaring på, hvorfor arbejdet stoppede. Begge dele kan være et ordentligt resultat. Det farlige er et halvfærdigt arbejde, der bliver afleveret som færdigt.
En frisk agent gennemgår ændringen
Den agent, der har bygget løsningen, har også arbejdet sig ind i sin egen forklaring på problemet. Derfor lader jeg en frisk review-agent gennemgå hvert stykke arbejde med opgavebeskrivelsen og de faktiske ændringer som grundlag.
Den skal både se efter fejl og vurdere, om løsningen opfylder opgaven. Det er to forskellige spørgsmål. Kode kan være pæn og velordnet og stadig gøre det forkerte.
I formulareksemplet skal gennemgangen blandt andet spørge: Bliver kategorien bevaret efter en fejl? Kan formularen stadig sendes, når alle felter er udfyldt? Er der ændret andet end det nødvendige? Har testen kun bevist, at en fejlbesked bliver vist, eller også at brugeren kan komme videre?
Review-agenten kan selv tage fejl. Dens fund skal undersøges i koden, før de bliver til rettelser. Jeg vil ikke have ekstra ændringer, bare fordi en overbevisende forklaring får dem til at lyde nødvendige.
En frisk gennemgang giver et ekstra blik på arbejdet. Den fritager mig ikke for at tage stilling til resultatet.
Grønne tests er et krav
Tests skal være grønne, før jeg betragter arbejdet som klar til godkendelse. Ved en fejlrettelse vil jeg helst først have en test, der viser fejlen, og derefter se den bestå med rettelsen.
Det er en vigtig forskel. En test, som altid er grøn, dokumenterer ikke, at fejlen er løst. Den skal kunne skelne mellem den forkerte og den rigtige adfærd.
Men tests dækker kun det, de faktisk undersøger. De kan kontrollere, at formularen beholder et valg. De fortæller ikke nødvendigvis, om fejlbeskeden er forståelig, om feltet ligger ordentligt på en lille skærm, eller om rækkefølgen føles naturlig for brugeren.
Derfor hører den konkrete kontrol også med. Ved synlige ændringer skal resultatet ses i browseren. Ved en arbejdsgang skal den relevante vej prøves igennem. Hvis noget ikke kan kontrolleres i testmiljøet, skal det fremgå, så jeg kan vurdere det før udgivelsen.
Jeg bruger Claude Code i terminalen som en del af arbejdet. Det afgørende for mig er dog ikke navnet på værktøjet. Det er, om jeg kan efterprøve det, værktøjet afleverer.
Intet går live hos en kunde uden mit ja
Her går den tydeligste grænse: En færdig branch, en god gennemgang og grønne tests er ikke en tilladelse til at ændre en kundes hjemmeside.
Jeg skal sige ja til at sætte ændringen i drift. Jeg skal vide, hvad den rammer, hvordan den er kontrolleret, og hvordan vi kommer tilbage, hvis den giver problemer. Og efter udgivelsen skal det kontrolleres, at den rigtige ændring faktisk virker på den rigtige side.
Det gælder også en rettelse, der ser oplagt ud. En lille ændring kan påvirke en formular, en integration eller et forløb, som den besøgende er afhængig af. At agenten er sikker på sin løsning, ændrer ikke den grænse.
Agenterne må bygge. Jeg siger ja til at udgive.
Du skal derfor ikke som kunde holde øje med, om et natligt forsøg pludselig har ændret din side. Det ansvar ligger hos mig.
Kundedata bliver udenfor
Agenterne skal kunne arbejde med kode og med konstruerede testdata. De skal ikke have kundernes oplysninger for at kunne løse en teknisk opgave.
I formulareksemplet kan jeg beskrive felterne og genskabe fejlen med opdigtede værdier. Der er ingen grund til at sende rigtige henvendelser, navne eller mailadresser til AI. En databasekopi fra kundens side hører heller ikke hjemme som bekvemt testmateriale i agentens arbejdsmappe.
Det kræver omtanke allerede, når opgaven bliver gjort klar. Personoplysninger kan ligge i mere end en kundetabel. De kan også stå i en fejlmeddelelse, et skærmbillede eller en fri tekst, nogen har skrevet i en formular.
Hvis en fejl kun kan undersøges med adgang til virkelige oplysninger, undersøger jeg selv den del og giver agenten en teknisk beskrivelse, der kan arbejdes videre med. Jeg sender ikke kundedata ind for at gøre forklaringen nemmere.
Jeg læser det, der bliver sendt til kunder
AI kan hjælpe mig med at formulere et udkast eller gøre en teknisk forklaring lettere at forstå. Men jeg læser selv det, der bliver sendt til kunder, og afsendelsen sker først efter min godkendelse.
Jeg kontrollerer især, om teksten lover mere, end der er belæg for. Der er forskel på, at en rettelse er skrevet, at den er testet, og at den virker på den offentlige side. En mail skal beskrive det trin, vi faktisk er nået til.
Jeg skal også kunne stå inde for tonen og for det, jeg beder kunden tage stilling til. En pæn formulering hjælper ikke, hvis den gør en enkel besked uklar eller får en usikker forklaring til at lyde som et fastslået faktum.
Når du skriver til mig, er det fortsat mig, der har ansvaret for svaret. Du skal ikke vurdere, om et svar kom fra en agent, før du kan stole på det.
Det, jeg gerne vil bruge mere opmærksomhed på
Jeg har skrevet en bredere introduktion til AI-agenter og deres anvendelse, hvis du vil forstå begrebet bedre. I min egen hverdag er spørgsmålet ofte mere enkelt: Er opgaven tydelig nok til at blive løst, og har jeg beviser nok til at godkende resultatet?
Jeg vil gerne bruge værktøjerne til at få flere konkrete forslag og bedre kontroller. Jeg vil stadig selv vurdere, om ændringen overhovedet bør laves. Nogle gange er den bedste beslutning at lade en funktion være enklere eller lade være med at bygge den.
Hvis du er i tvivl om, hvor din egen hjemmeside har brug for opmærksomhed, kan du begynde med det gratis hjemmeside-tjek. Det giver et konkret udgangspunkt for en samtale. Så kan vi tage stilling til, hvad der er værd at rette, inden jeg sætter noget i gang.
