Billig å bygge, dyrt å huske

Den siste tiden har jeg jobbet en del med agentisk koding for å lage digitale produkter og spill. Et av oppsettene har jeg skrevet om før. Dette innlegget handler om det som skjer etterpå og underveis i arbeidet. Det som skjer når det er billig å bygge noe, og dyrt å få oversikt over hva du bygger.

Den nye gjørmesurret

Den 2. oktober publiserte Nielsen Norman Group en artikkel av Tanner Kohler: The New Big Ball of Mud. Begrepet er ikke nytt—Brian Foote og Joseph Yoder brukte det i 1997 om programvare som vokser i vildens sky, uten plan, helt til ingen vet hvordan den henger sammen.

Kohler ser det samme hos folk som bygger egne agentsystemer. En rask test blir en varig endring. Systemet vokser bit for bit. Man lapper på i stedet for å bygge om. Rotet havner i en skuff som bare KI-en finner fram i.

Til slutt stiller han et spørsmål jeg har tenkt mye på: Ville du visst hva du skulle endre her uten KIen? Hvis ikke er du litt fucked.

Jeg kjente meg igjen. Som designer er jeg glad i å teste og prøve. Ikke like glad i å feilsøke nøysommelig i et filarkiv.

Er jeg i trøbbel mon tro?

Billig å bygge, dyrt å huske

Agentene mine husker ingenting mellom øktene. Alt viktig står i filer. Det er grunnmuren for agentisk koding.

Det er også der rotet samler seg.

Hver økt legger igjen litt etter seg. Et overleveringsnotat. En ny linje i husreglene. En linje i beslutningsloggen. Hver for seg er de nyttige. Sammen blir de et lag med slam som agentene leser hver eneste gang.

Og agentene er flinke. De følger reglene, også de som burde vært fjernet for lenge siden. Det er det som gjør alt sammen ganske skjørt.

Agenter gjør det billig å bygge og dyrt å huske hva du har bygget.

MEN, Det betyr ikke at det alltid går galt. Nick Hodges argumenterer i InfoWorld for at agentene kan bli verktøyet som rydder opp i gjørma igjen. Resonnementet gir meg litt håp.

Tre typer notater

Det nyttigste i NN/g-artikkelen er et skille mellom tre typer kontekst.

• Global. Det som alltid er sant, for hele prosjektet. Hos meg: “husreglene” og designdokumentet.
• Lokal. Det som gjelder én oppgave. Tenk spesifikasjoner og overleveringsnotater.
• Omgivende (Ambient). En strøm av oppdateringer som ligger der, men som ingen vedlikeholder. Tenk statustavlen, endringsloggen og samtalehistorikken.

Problemet oppstår når de blander seg.

Et overleveringsnotat som sniker seg inn i husreglene, og blir plutselig sant for alle agenter i alle oppgaver. Ingen merker det. Det bare skjer, stille. Skrekk og gru!

Hva jeg beholder og hva jeg ditcher

Her er det jeg gjør nå for å legge til rette for konteksten?

Beholde

• Våre spilleregler. Kommer noe inn, skal noe annet ut. Jeg leser dem selv med jevne mellomrom, linje for linje.
• Setter av ett sted for hver kontekst-type. Det globale bor ett sted. Lokale notater bor ved oppgaven sin.
• Nevner konteksten som gjelder når jeg prompter og gir instrukser. Når jeg ber om en endring, sier jeg om den gjelder alltid eller bare nå.
• Beslutningsloggen. Logger av valg jeg har tatt, sånn at jeg kan huske noe om 1 uke, og om 6 måneder.

Ditche

• Overleveringer som lever evig. Når oppgaven er ferdig, er notatet ferdig. Det som skal leve videre, flyttes til riktig plass igjen.
• Den parable “Roteskuffen”. Mappen i repoet som heter «diverse» er der rotet gjemmer seg. Altfor fristende å ha en sånn.
• Å lappe på i det uendelige. Kohler anbefaler å utsette påbygget så lenge det går. Han sier også at ombyggingen kommer til slutt. Greit å være forberedt på å endre struktur.

Det samme som i menneskelige team?

Når jeg leser om de ulike kontekstnivåene får det meg til å tenke på alle situasjonene jeg har vært i der alle i teamet har litt ulike kontekst, og problemforståelse.

Noen er “nede i grøten” og er mest opptatt av detaljene; enten det er interaksjoner og validering, WCAG, eller optimalisering av innlastningshastigheten.

Andre snakker om de svevende ambisjonene for virksomheten og hvordan ting “bare må forenkles”. Abstrakte utsagn som like godt kunne vært fra en annen planet.

Noen koser seg midt i mellom og over alt; meg selv inkludert.

Ta for eksempel et designsystem ingen eier. Det går fort den samme veien. Komponenter blir lagt til fordi de trengs nå. Ingen tar dem bort fordi de ble brukt i det ene systemet den ene gangen. Til slutt vet ingen hvilken variant som er den riktige.

Forskjellen er at mennesker klager. Agentene de klager litt mindre.

Menneske sier fra når reglene blir for lange. En agent leser dem bare, hver gang og forbrenner tokens.

Løsningen er også den samme: Noen må eie konteksten. Jeg må eie konteksten. Du må eie konteksten.

Agentene kan foreslå endringer. Vi bestemmer.

Det jeg lærte

• Det billigste du gjør, er å bygge. Det dyreste er å huske (les. skape varig kontekst).
• Det som alltid gjelder, bør holdes adskilt fra det som gjelder her og nå.
• Les de globale filene selv. Og prøv å gjøre det oftere enn du tror du trenger.
• Still Kohlers spørsmål: Ville du visst hva du skulle endre, uten KI til å hjelpe deg?

Kan jeg svare ja, er jeg på riktig spor. Kan jeg ikke det, er det nok på tide å rydde litt i notatbanken.

Det kreves stødige hender og kløktige hoder når man skal jobbe med KI og agenter. Som Prometheus og flammen, så er det lett å brenne seg hvis man ikke gjør ting på riktig måte.

Ingen vil sitte igjen med et gjørmesurr.

Kilder

• Tanner Kohler, Nielsen Norman Group: The New Big Ball of Mud: Why Agentic AI Systems Turn Fragile (2. oktober 2026)
• Brian Foote og Joseph Yoder: Big Ball of Mud (1997)
• Nick Hodges, InfoWorld: AI coding agents vs. big balls of mud (27. august 2026)