TDR-er i AI-alderen: Når beslutningen ble tatt av en modell

Tre spørsmål, én antagelse

En TDR svarer på tre spørsmål:

• Hva valgte vi?
• Hvorfor valgte vi det?
• Hva vurderte vi og forkastet?

Strukturen er enkel, og den har vist seg robust. Jeg har skrevet om den både i Hvordan etablere tekniske standarder som faktisk etterleves og i Hvordan håndtere uenighet i teknologivalg.

Michael Nygard beskrev i 2011 en enkel form for Architecture Decision Records: tittel, kontekst, beslutning, status og konsekvenser. Malen hans har ikke et eget punkt for vurderte alternativer. Det har blant annet MADR, som gjør alternativene og avveiningene eksplisitte. Jeg skriver TDR fordi beslutningene som er verdt å skrive ned i et team, sjelden er bare arkitektoniske.

Men strukturen hviler på en antagelse: at noen faktisk vurderte alternativene. Og hva skjer når vurderingen skjedde i en chat som er lukket, med alternativer ingen husker, foreslått av en modell som ikke kjenner systemet?

Beslutninger uten spor

Tenk deg en utvikler som skal velge caching-strategi. I stedet for et design review tar hen en samtale med AI. Tjue minutter senere er valget tatt, koden generert, PR-en åpnet. Utvikleren dokumenterer verken forutsetningene eller alternativene i PR-en. Valget kan være utmerket, men begrunnelsen blir igjen i chatten.

For resten av teamet er beslutningen vanskelig å følge:

• ingen vet hvilke alternativer som ble vurdert
• ingen vet hvilke premisser modellen fikk
• ingen kan etterprøve resonnementet

Om et halvt år spør noen «hvorfor valgte vi dette?» PR-en viser hva som ble endret, men ingen kan forklare hvorfor. Valget er dokumentert. Begrunnelsen mangler. Det er kunnskapsgjeld, samme mekanisme som beskrevet i Teknisk gjeld som et teamfenomen, bare raskere.

«AI foreslo det» er ikke en begrunnelse

En TDR som bare sier «vi valgte X fordi AI anbefalte det», forteller oss hvor forslaget kom fra. Den forteller ikke hvorfor det passer her. Hvilke krav oppfyller det? Hvilke ulemper aksepterer teamet?

Modellen skal ikke stå ansvarlig for konsekvensene eller vedlikeholde koden. Det skal teamet.

Det er ikke bare et ingeniørprinsipp. Da Air Canada anførte for en kanadisk tvisteløsningsnemnd at selskapet ikke kunne holdes ansvarlig for det deres egen chatbot hadde fortalt en kunde, kalte nemnda anførselen bemerkelsesverdig: chatboten er fortsatt bare en del av Air Canadas nettsted, og selskapet ble pålagt å betale erstatning (Moffatt v. Air Canada, 2024 BCCRT 149). I denne saken ble organisasjonen holdt ansvarlig for feilinformasjonen fra chatboten. Det avgjør ikke ansvaret i enhver AI-sak, men viser at det å vise til modellen ikke i seg selv fritar organisasjonen for ansvar.

Derfor gjelder samme regel som alltid: begrunnelsen i en TDR må være teamets begrunnelse. AI kan ha belyst alternativene, utfordret antagelser, avdekket fallgruver, og det er utmerket. Men det som dokumenteres, er hva dere vektla, og hvorfor.

Den oppdaterte TDR-en

I praksis trenger ikke malen endres mye. Men to ting fortjener plass:

1. Prosess-sporet

Begynn gjerne med én linje:

«Alternativene ble utforsket i dialog med AI. Sammenligningen under er vår vurdering av forslagene.»

Den linjen sier hvor forslagene kom fra, men ikke hvor grundig de ble vurdert. Legg derfor til hva dere faktisk undersøkte: dokumentasjon, erfaring fra produksjon, målinger eller en prototype. Skill mellom det dere har kontrollert, og det dere fortsatt antar. Da kan neste leser se hva beslutningen bygger på.

2. Premissene

Premissene du gir modellen, påvirker hvilke forslag du får. «Hva er beste caching-strategi?» og «hva er beste caching-strategi for et system med disse trafikkmønstrene og denne infrastrukturen?» kan gi forskjellige forslag.

Dokumentér premissene som lå til grunn. Det er dem fremtiden vil trenge når konteksten endrer seg, og det er da TDR-er er mest verdt.

Hvordan kan det se ut?

Ta caching-valget fra starten. Et forenklet, tenkt TDR-utdrag kan se slik ut:

Valg og premiss: Vi prøver lokal cache for produktbeskrivelser. Dataene kan være opptil fem minutter gamle; pris og lagerstatus hentes separat og omfattes ikke av valget.

Forkastet alternativ: Vi velger foreløpig bort en delt cache for å unngå en ekstra tjeneste å drifte. Vi aksepterer at instansene kan vise ulike versjoner innenfor femminuttersgrensen.

Validering før produksjon: Kjør en lasttest med forventet antall instanser. Kontroller minnebruk, belastning på databasen og at data ikke vises etter utløpstiden. Legg resultatene ved beslutningen.

Ny vurdering: Ta opp valget igjen hvis kravene til ferskhet blir strengere, eller testene viser at løsningen overskrider avtalte grenser for minnebruk eller databasebelastning.

Dette er ikke en anbefaling om lokal cache. Det er et eksempel på hva en kollega trenger for å forstå valget, utfordre det og vite hva som fortsatt gjenstår å sjekke.

AI som TDR-forfatter? Ja – med gjennomgang

AI kan hjelpe med å gjøre en diskusjon fra et design review til et lesbart utkast. Det kan senke terskelen for å dokumentere, særlig når teamet allerede har gjort vurderingene muntlig.

Men et ryddig utkast kan også skjule hull. Gå gjennom det sammen med dem som tok beslutningen. Stemmer premissene? Ble alternativene faktisk diskutert, eller har modellen lagt dem til? Står en planlagt test plutselig omtalt som gjennomført? Rett det før dokumentet blir en del av prosjektets hukommelse.

Hastighet uten hukommelse

En TDR skal bevare hvorfor. Det behovet består når AI hjelper oss med både forslagene og teksten.

Som tech lead kan du gjøre dette til en liten del av arbeidsflyten: Sett av tid til å gå gjennom begrunnelsen når teamet tar et teknisk valg. Spør hva dere valgte, hvorfor, og hva dere valgte bort. La dem som skal leve med løsningen, få utfordre svaret.

Om et halvt år skal en ny kollega kunne forstå hvorfor dere valgte denne løsningen, og hvilke endringer som ville gjort et annet valg bedre.