Dagen til mennesker. Natten til agenter.

Formiddag: fokus

Fra kl. 9 til 11 er der fokustid. Høretelefonerne kommer på, og der er ingen møder. Først gennemgår vi, hvad agenterne byggede i nat. Så former vi de næste opgaver. Hvad skal brugeren kunne, og hvordan ved vi, at det virker?

Efter kl. 11 holder vi show and tell. Det kan være en god prompt, en ny skill eller en fejl, vi ikke vil lave igen. Det, én af os lærer, bliver hurtigt hele teamets. Det er også her vi laver de første spikes, konfigurerer og klargør opgaver til AI-agenterne.

Eftermiddag: mennesker

Fra kl. 12.15 er der tid til samarbejde og kunder: kunderejser, interviews, koncepter og spikes, altså korte tekniske forsøg. Det er det arbejde, hvor man skal forstå andre mennesker og træffe valg sammen. Alt det AI ikke kan udføre

Når vi går hjem, så fortsætter agenterne.

Agenterne kører på hele natten, det er ekstremt effektivt.

Om natten arbejder agenterne på de opgaver, vi har formet i løbet af dagen. Hver opgave kører i et loop:

1. Forstår. Agenten kender alt til projekterne. De ser transskriberinger, briefs, alt indhold der skabes i projektet ser de. Skitserne, koden, referaterne og de beslutninger, der allerede er truffet. Igennem Skills hjælper vi agenterne med at forstå hvad der er vigtigt og hvad der skal sorteres fra
2. Bygger. Ændringen bliver lavet efter de konventioner, der står i kodebasen.
3. Tester. Kodestil og typer bliver tjekket, og de automatiske tests kører både på de enkelte dele og hele vejen igennem, som en bruger ville gøre.
4. Gennemgår. Agenten læser sin egen ændring igen med friske øjne.
5. Retter. Det, testene og gennemgangen finder, bliver rettet. Så starter loopet forfra.

En nat giver plads til mange runder. Loopet fortsætter, til alle tests er grønne, og gennemgangen ikke finder mere. Om morgenen ligger ændringen klar til et menneske, der vurderer den. Ved siden af ligger en log over, hvad agenten har gjort.

Hos DSV Transport betyder det eksempelvis, at en opgave, der bliver formet om dagen, kan være klar til test på deres egne telefoner næste morgen.

Hvorfor agenten sjældent kører i en blindgyde - ADR

Mange loops fanger fejlene. De redder dog ikke en opgave, der peger i den forkerte retning. Det gør konteksten.

Vores agenter arbejder ikke ud fra en kort instruks. De har det hele med: transskriberinger af møderne, mødereferater, briefs fra kunden og de beslutninger, vi har truffet undervejs. Agenten ved derfor, hvorfor opgaven findes, og ikke kun, hvad den går ud på.

Oveni kommer skills. En skill er en skrevet opskrift på, hvordan vi gør noget bestemt. Det kan være, hvordan en opgave skal testes, eller hvad der vejer tungest, når to kilder siger noget forskelligt. Skills sørger for, at agenten prioriterer det rigtige i al konteksten.

Og så godkender et menneske altid, før noget når ud til brugerne. En agent udgiver aldrig noget selv.

ADR holder fast i konteksten

I lange udviklingsforløb har AI en tendens til at tabe fokus. En ny session starter uden hukommelse om de tidligere, og en diskussion, der blev afgjort for tre måneder siden, kan dukke op igen. Så glider løsningen langsomt væk fra det, der oprindeligt blev aftalt.

Derfor skriver vi vores beslutninger ned som ADR'er, Architecture Decision Records. En ADR er et kort notat om én beslutning: hvad vi valgte, hvorfor, og hvad vi valgte fra. ADR'erne ligger i kodebasen ved siden af koden, og agenterne læser dem, før de bygger. Det er ikke nogen ny proces, men den har været meget tidskrævende før AI, men har fået en renæssance.

Det betyder, at konteksten holder, også når projektet er et halvt år gammelt, og også når en ny udvikler eller en ny agent kommer til.

Vi fokuserer på den del AI ikke kan løse. Her gør vi en forskel

Om lidt kan alle lade agenter arbejde om natten. Forskellen ligger i, hvad de får med.

Det rigtige indhold til natten kommer fra det, vi gør om dagen. Det kan AI ikke overtage:

Møde brugerne. AI kan opsummere et interview. Den kan ikke se, hvor en bruger tøver, eller mærke det, der ikke bliver sagt.

Forstå forretningen. Mål, økonomi og organisation. Både det, der står i briefen, og det, der ikke gør.

Vælge og fravælge. Prioritering er dømmekraft. Nogle gange er det bedste råd til en kunde at lade være.

Forme opgaven. Nattens arbejde bliver aldrig bedre end dagens opgave.

Se helheden. Et produkt skal hænge sammen, føles rigtigt og kunne bruges af alle, også af mennesker med et handicap.

Tage ansvaret. Et menneske godkender hver ændring og beslutter, hvornår den bliver udgivet.

Det giver bedre produkter og støtter forretningen

Vi afprøver flere idéer. Når en prototype koster en nat og ikke en sprint, kan vi teste tre løsninger med rigtige brugere i stedet for at diskutere én. Vi vælger ud fra det, der virker, og ikke ud fra det, der lød bedst på et møde.

Tiden går til brugerne. Når agenterne tager meget af byggeriet, bliver der mere tid til research, koncept og test inden for det samme budget.

Vi tester det hele. De samme tests og regler gælder for alle ændringer. Kvaliteten afhænger ikke af, om nogen havde en god dag.

Vi bruger de samme skills og systemet "Brewale" Det, vi lærer i ét projekt, bliver til skills i det næste. Alle skills orkestrerer vi på tværs af udviklere og agenter i Brewale.

Fokuseret tid og kvalitet, fremfor kvantitativ ufokuseret tid. Vi arbejder 30 timer om ugen, fordi mennesker med overskud leverer skarpere løsninger. Fokustiden om formiddagen gør forskellen endnu større.

Hvad får man i et samarbejde med os

Mere for pengene. Når agenterne bygger mere af løsningen, er det kunden, der får gevinsten. Timerne går til der hvor vi konceptualiserer løsningerne, ikke selve udviklingen.

Uafhængighed. ADR'er og skills ligger i kodebasen, og møderne er skrevet ned. Som vores CTO, Hari, beskriver det. Så får I ikke kun et produkt, I får systemet, der bygger produktet. Det ligger ikke i hovedet på én udvikler, det er en del af løsningen med AI-agenter i kodebasen. Både under udvikling, men også efter GO-live.

Vi vil rigtig gerne drifte og samarbejde i lang tid

Uafhængighed betyder ikke, at vi forsvinder. Vi drifter og videreudvikler meget gerne det, vi har bygget. Vi vil bare hellere have, at I bliver, fordi det giver mening, end fordi det er besværligt at skifte.

Vi bygger systemer, der bygger produkter. Og systemet er jeres.