Hovedutfordringen var å skrive om en 15 år gammel ASP.NET WebForms-applikasjon til en løsning med ASP.NET Core 8 på backend og Vite, React og TypeScript på frontend.

Språkversjonene var gamle, teknologistakken var gammel, og alt var bygget på eldre teknologier jeg aldri hadde jobbet med før. Å forstå hvordan applikasjonen kunne overføres til den nye løsningen, og trekke ut forretningslogikken, var den største flaskehalsen for å komme i gang med prosjektet.

For et par år siden ble det gjort et forsøk på å bygge om prosjektet med ASP.NET på backend og en Angular-basert SPA på frontend, men forsøket mislyktes på grunn av kompleksiteten i applikasjonen og det underliggende systemet.

La oss begynne med det som måtte på plass før KI-agentene kom inn i bildet.

For at KI-agenter skal kunne jobbe, trenger de et tydelig bilde av hva de skal bygge. Jeg mente også at dette prosjektet trengte en klar vei fra start til mål.

Siden applikasjonen hadde vært i produksjon i 15 år, kunne jeg ikke bare sette i gang og skrive om side for side uten et helhetlig bilde eller en gjennomtenkt arkitektur som tok hensyn til det underliggende systemet.

Derfor brukte jeg Claude til å kartlegge den eksisterende applikasjonen i et Obsidian-kompatibelt hvelv. Der samlet jeg kontrakter, sider, API-er, designsystem, begrepsliste, brukerreiser, forretningslogikk og annen nødvendig informasjon.

Da jeg hadde kartlagt helheten, fått applikasjonen til å kjøre lokalt og fått godkjent teknologistakken, laget jeg en kort liste med overordnede oppgaver, noen arkitekturdiagrammer og dokumenter ved hjelp av KI-agenter.

Etter noen gjennomganger fikk vi fastlagt hvilke rammeverk og biblioteker vi skulle bruke.

Endelig kunne jeg sette opp prosjektet og begynne omskrivingen. Det var da jeg begynte å bruke KI-agenter til å bygge løsningen.

Grunnen til at jeg sier alt dette før jeg snakker om KI-agenter, er at måten vi bygger programvare på, ikke har endret seg. Vi jobber fortsatt med de samme språkene og rammeverkene, og vi bygger fortsatt programvare for mennesker. KI-agenter har økt utviklingstempoet vårt.

Som utviklere er jobben vår å bygge programvare som varer, som tåler feil, og som enkelt kan rettes når noe går galt. Vi må også sørge for at koden er lesbar og forståelig for den som skal skrive den om om 20 år.

Jeg har sett ganske mange verktøy som hjelper med koding ved hjelp av KI-agenter. Det finnes rollebaserte, spesifikasjonsbaserte og mange andre systemer for agentbasert utvikling.

For en som meg, som har jobbet som fullstack-utvikler fra starten av, ga den spesifikasjonsbaserte tilnærmingen mest mening. Men da jeg skrev om denne applikasjonen, brukte jeg en kombinasjon av rollebaserte agenter og spesifikasjonsbaserte ferdigheter. La meg utdype.

Jeg har bygget **adlc-toolkit**, et verktøysett for Agentic Development Life Cycle, med 18 ferdigheter og 13 agenter.

Hver forespørsel går gjennom en arbeidsflyt med fem faser:

1. Spesifikasjon
2. Arkitektur
3. Implementering
4. Gjennomgang
5. Avslutning

Hver fase bruker ulike underagenter til å utføre oppgaven den har fått.

For mindre oppgaver brukes en enklere arbeidsflyt med tre faser: planlegging, implementering og til slutt gjennomgang og levering.

Verktøysettet oppretter også et Obsidian-kompatibelt hvelv i kodearkivet, der det lagrer kontekst for senere bruk, beslutninger som er tatt, og oppdateringer om oppgaver.

Jeg synes agentene fungerer fint slik de er, så lenge de får riktige instruksjoner og tilstrekkelig kontekst. Dette håndterer adlc-toolkit svært effektivt.

Før hovedagenten starter en underagent, gir den underagenten nok kontekst, et tydelig mål og detaljer om hvordan oppgaven skal utføres, og hvordan resultatet skal rapporteres tilbake.

Slik verktøysettet er utformet, er valideringen ganske enkel. Etter hvert trinn gir det en oppsummering av hva som er gjort, og hva som gjenstår. Min jobb er å kontrollere at dette stemmer.

Nå hadde jeg prosjektplanen klar, den eksisterende applikasjonen kartlagt i et Obsidian-hvelv og et verktøy for agentbasert utvikling klart til bruk.

Hver dag når jeg begynner å jobbe, kjører jeg `/status`, som forteller meg hva jeg jobber med, hva som er gjort, og hva som står for tur. Jeg velger dagens oppgave og kjører hele arbeidsflyten med kommandoen `/proceed`.

Det første verktøyet gjør, er å forstå forespørselen. Det starter en agent som utforsker kodebasen, og stiller meg deretter spørsmål om hva jeg vil jobbe med, og hvordan jeg vil bygge det. Det foreslår også en egen tilnærming. Deretter skriver det en spesifikasjonsfil for oppgaven.

Når jeg har godkjent spesifikasjonen, går det videre til arkitekturfasen. Det søker gjennom kodebasen på nytt etter alle relevante filer og funksjoner vi kan komme til å endre, og lager en plan basert på faktaene det har samlet.

Det bruker også en underagent med rollen som kritisk arkitekturgransker, som utfordrer beslutningene før de legges frem for meg.

Når agentene har ferdigstilt arkitekturen og planlagt oppgaven, blir jeg bedt om å godkjenne eller revidere planen. Etter gjennomgangen kan jeg be om endringer eller godkjenne planen, og så begynner implementeringsfasen.

I implementeringsfasen startes flere underagenter. De jobber enten sekvensielt eller parallelt, avhengig av avhengighetene mellom oppgavene.

Når det er ferdig, begynner gjennomgangen med disse granskningsagentene:

- reflector
- architecture-reviewer
- quality-reviewer
- correctness-reviewer
- ui-reviewer, ved behov

Hver agent får beskjed om å gjøre en uavhengig gjennomgang og være kritisk til arbeidet, samtidig som den følger kodearkivets konvensjoner og regler.

De viser meg problemene de har funnet, hva som ikke fungerer, og hvorfor. Deretter kjører jeg en ny implementeringsrunde for å rette opp problemene. Arbeidet gjennomgås på nytt før det til slutt går videre til avslutningsfasen.

Avslutningsferdigheten håndterer alt etter implementeringen: Den committer endringene, oppretter et utkast til en pull request, oppdaterer dokumentasjonen og sørger for at alt er samstemt og dokumentert i kodebasen.

Jeg skriver ikke kode for hånd lenger, men ingenting legges til i koden min uten at jeg vet om det.

Det dukker opp noen småfeil av og til, men det er normalt og forventet.

Dette er akkurat slik jeg jobbet før KI kom inn i bildet, bortsett fra at KI-agenter nå finner frem i kodebasen og skriver kode mye raskere enn et menneske.

Etter min erfaring tok det tidligere rundt en måned å levere 3 000–4 000 linjer kode. Og det handler ikke bare om å levere koden. Det omfatter også planlegging, feilsøking, å følge konvensjoner og holde dokumentasjonen oppdatert, og så videre.

Nå kan jeg levere en pull request med 4 000 linjer kode på to dager med adlc-toolkit, med den samme tryggheten.

Jeg kan ikke gi deg helt nøyaktige tall, men jeg fullførte prosjektet på under tre måneder, med nye funksjoner som ikke fantes i den gamle applikasjonen.

Og jeg er arbeidsnarkoman, så du bør ikke bruke hvor mye jeg leverer som målestokk for andre.

Men jeg kan si at alle på kundesiden ble svært overrasket og imponert over hvor raskt jeg leverte. De hadde ikke engang planlagt de neste stegene da jeg begynte å levere funksjoner.

Det var et nytt prosjekt, og jeg eksperimenterte med KI for å få best mulig resultat på kortest mulig tid.

Siden jeg ikke trengte å utvikle forretningslogikken på nytt, bare applikasjonslaget, kunne jeg levere mye raskere enn jeg først hadde trodd.

Når det er sagt, tror jeg at uten KI-agenter ville det tatt meg omtrent halvannet år å fullføre arbeidet jeg har gjort de siste tre månedene.

Alle som har sett litt byggearbeid, kan bygge et hus på egen hånd. Men en arkitekt vil måle, analysere og tegne, og først deretter legge grunnlaget før byggingen begynner.

Så det ingeniørfaglige arbeidet må fortsatt gjøres.

Du kan ikke «vibe-kode» en produksjonsklar applikasjon som skal brukes av store kringkastere over hele verden. Problemet med vibe-koding er at du tenker etter at du har handlet. Men som vi alltid har blitt fortalt, er det bedre å tenke før man handler. Det er den ingeniørfaglige delen.

KI-agenter samler informasjon og utfører kommandoer raskere enn vi noen gang har sett før.

Det er vår jobb å bruke fagkunnskapen og erfaringen vår til å få mest mulig ut av verktøyet KI, ved å utnytte det det kan gjøre.