Kontekst, konstruksjon og rekonstruksjon

Notater om en arbeidsmåte med kodeagenter · september 2026

Jeg har arbeidet som utvikler i over tjue år, og jeg leser ikke lenger algoritmene. Jeg har ikke lenger kapasitet til det hvis jeg skal bruke den på det som er viktigere for meg: arkitekturen, strukturen, spørsmålet om en konstruksjon tåler de neste tre kravene. Resten lar jeg kontrollere – av agenter, mot hverandre, i en prosess som oppsto i praksis, og som jeg først fant begrunnelsen for i ettertid. Disse notatene er et forsøk på å skrive den ned.

Kontekst og beslutningslogg

En kodeagent har ikke noe minne. Det den har, er forløpet i økten: instrukser, svar, filer den har lest, testresultater, dens egne overveielser. I løpet av en oppgave danner dette en sammenheng som strekker seg utover koden – hvilket alternativ som ble forkastet, hvor et grensetilfelle oppsto, hvordan et hull i spesifikasjonen ble fylt. Det kan ikke lenger utledes av koden alene. Koden er det som blir igjen når konteksten kastes.

Derfor tømmer jeg aldri konteksten. Gjennomganger, spørsmål og rettelser går alltid tilbake til økten der arbeidet ble bygget. Det strider mot det vanlige rådet: Tøm økter ofte, del opp oppgaver i kontekstfrie biter. Rådet er riktig, men retter seg mot en annen arbeidsform: kontekster som består av omveier, side etter side med verktøyutdata og mislykkede feilsøkingsforsøk som blir stående i vinduet og fortsetter å virke inn. En kontekst som består av beslutninger, blir ikke dårligere av å bli lengre. Den blir tettere. Og siden omtrent høsten 2025 har modellene oppdaget et feilspor på minutter i stedet for timer; omveiene som blir igjen i konteksten, er korte og markert som forkastet – informasjon, ikke støy.

Den stille motstanderen er komprimeringen. Den registrerer hva som ble endret, men mister hvorfor, fordi et sammendrag ikke kan vite hvilken begrunnelse det senere blir bruk for. Agenten etterpå tror den er den samme; den er en ny agent med et godt sammendrag. Sikringen mot dette er ikke å tømme, men å bevare: Under arbeidet lar jeg viktige beslutninger skrives inn i en fil i prosjektet – løsningen som ble valgt, grunnene, alternativene som ble forkastet, de åpne spørsmålene. Anthropic beskriver bevaring av arkitekturbeslutninger som et mål for komprimering og supplerer dette med varige arbeidsnotater. Min erfaring er at notatene er det mest pålitelige av de to.

Intensjon og gjennomføring

Sløyfen er: bestemme hva som skal bygges – la det bygges autonomt – vurdere – få det korrigert. Jeg bestemmer hva som skal gjøres; agenten bestemmer hvordan. Hvor grensen går, flytter seg med hver modell. Om det bør være en kø på et bestemt sted, var for et år siden en arkitekturbeslutning jeg måtte angi; i dag ser agenten det selv. Min oppgave er å holde meg over denne stigende linjen.

Jeg begynner hver oppgave med det samme spørsmålet: «Hvordan ville du løst dette?» Av svaret ser jeg, før én linje kode finnes, om intensjonen er forstått og hvilke antakelser agenten tar med seg. En misforståelse koster to setninger på dette tidspunktet; etter at arbeidet er bygget, koster den en gjennomgang og refaktorering. Spørsmålet gjør dessuten framgangsmåten til agentens eget utkast. Den bygger ikke etter oppskrift; den bygger sitt eget forslag, som jeg har godkjent eller korrigert. Begrunnelsen står dermed uttrykkelig i konteksten, ikke bare implisitt i koden – og den er første oppføring i beslutningsloggen.

Av dette følger hvor jeg legger ned innsats, og hvor jeg ikke gjør det. Det finnes struktur som kompenserer for dagens modellsvakheter: promptkjeder, håndlagde roller, stillaser rundt modellen. Den blir foreldet med neste modell, og jeg har sluttet å investere i den. Og det finnes struktur som bevarer intensjonen – mål, rammebetingelser, grunner. Den blir ikke foreldet, for ingen modell, uansett hvor god, vet hva jeg ville hvis det ikke står noe sted. Å dirigere framfor å strukturere er et veddemål på at modellene blir bedre hver måned. Så langt har det vunnet hver måned.

Gjennomgang og rekonstruksjon

Etter koderens egenkontroll følger en gjennomgang fra en annen modell – i mitt tilfelle Claude mot Codex. Innvendingene går tilbake til koderen, som tar stilling. Rettelsene eller forsvaret går tilbake til den som gjennomgår. Det som fortsatt er uavklart etterpå, avgjør jeg.

Det som overrasket meg ved denne prosessen, er at koderen ikke gir seg. Jeg hadde ventet at den skulle godta punktene fra gjennomgangen fordi de hørtes kompetente ut. I stedet viser den til grunner som ble diskutert under gjennomføringen, og som den andre modellen ikke kjenner, og gir etter der den ikke har noen. Resultatet blir klart bedre enn når jeg lar modellen som gjennomgår, gjennomføre sine egne forslag. Min forklaring er konteksten: Kapitulasjonen skjer når en agent skal forsvare kode den ikke har bygget selv – en fersk økt, «her er en diff og en gjennomgang, arbeid deg gjennom punktene». Da har den ingen egen begrunnelse for noen av beslutningene, og gjennomgangen er den eneste oppfatningen i rommet. Koderen i sin egen kontekst møter hver innvending med kunnskap den andre modellen mangler. Når modellen som gjennomgår også retter, går asymmetrien den andre veien: Den ser symptomet, ikke hvordan det oppsto, og rettelsene blir lokalt riktige og globalt usammenhengende. Jeg kan ikke si ut fra min erfaring om konteksten alene forklarer forskjellen. At forskjellen finnes, kan jeg si.

Det samme gjelder subagenter. Det hovedagenten vet om det en subagent har bygget, kommer bare fra sluttrapporten. Forsvaret i gjennomgangen holder bare for det som oppsto i hovedkonteksten.

Og ved slutten av sløyfen trenger jeg ikke koden. Jeg trenger dialogen. En innvending og et svar på den kan vurderes på sekunder: strukturell innvending eller smakssak, overbevist eller bare gitt etter. Det er på dette nivået oppmerksomheten min fortsatt befinner seg. Dialogen beviser ikke at alle lokale feil er funnet; når en omstridt påstand avhenger av den faktiske virkemåten, må en test avgjøre den. Men lokale feil er det sløyfen fanger. Arkitektur er global, og ingen agent ser den innenfra én enkelt oppgave.

Modellens håndskrift og modellbytte

Den som gjennomgår, er en annen modell, helst fra en annen familie. To instanser av samme modell har korrelerte blindsoner; det den ene finner plausibelt, finner den andre også plausibelt. Et modellbytte garanterer ingen uavhengig kontroll – også ulike modeller overser av og til det samme – men det reduserer overlappingen.

I tillegg observerer jeg en virkning jeg ikke kan bevise: En modell rekonstruerer lettere kode den selv har skrevet. Ikke fordi den husker – den husker ingenting – men fordi koden foreligger på dens egen dialekt: modulinndeling, navngivning, feilhåndtering, abstraksjonsnivå, alt ligger der modellen selv ville ha lagt det. Den leser sin egen håndskrift med lukkede øyne.

Forskningen gir begrenset støtte for dette. Panickssery, Bowman og Feng viste i 2024 at modeller gjenkjenner sine egne sammendrag oftere enn tilfeldighetene skulle tilsi, og foretrekker dem i vurderinger. Studien undersøkte sammendrag, ikke kode; den dokumenterer derfor ikke en bedre forståelse av selvgenerert kode, og Chen og kolleger påpeker i 2025 at en preferanse for egne svar først kan regnes som skjevhet etter at man har kontrollert for svarenes faktiske kvalitet. Håndskrifthypotesen forblir altså en hypotese. Baksiden er derimot godt dokumentert og viktigere i praksis: En modell som leser sin egen kode, har en tendens til å anse den som riktig fordi den ser kjent ut. Flyt kjennes som korrekthet. Nettopp derfor må den som gjennomgår, lese en annens håndskrift.

Av dette utleder jeg en regel som ser asymmetrisk ut: Jeg bytter bare koder når jeg har en grunn. Den som gjennomgår, bytter jeg nettopp fordi jeg ikke trenger noen grunn. Kontinuiteten hos koderen er allerede begrunnet i den bevarte konteksten; om håndskriften i tillegg hjelper på tvers av økter, er den åpne hypotesen – og den ville ikke være noen grunn til å holde en påviselig bedre modell borte fra prosjektet.

Det som står igjen

Alt dette er et veddemål på at enhver investering i hvordan går tapt, og at enhver investering i hva lønner seg. Mål, rammebetingelser og begrunnelser for beslutninger må være tilgjengelige når modeller og verktøy skifter; alt annet kan skifte.

Og det som blir igjen av rollen min når man trekker fra tastingen, er omtrent dette: den som vet hva som skal bygges, spør hvordan den andre ville gjort det, vurderer resultatet – og ser når hvordan ikke lenger er hans sak. Det er arbeidsdelingen mellom en oppdragsgiver og en håndverker som stoler på hverandre. At den fungerer med agenter, overrasket meg mindre enn det faktum at jeg måtte slutte å lese koden for å få den til å fungere.