Kodeassistent skifter model midt

Sådan beskriver praktikeren selv forløbet: arbejdet gjaldt en gennemgribende revision af en kodebase, af den slags der kræver, at man holder styr på mange sammenhængende dele på én gang. Hvilke filer der allerede er rettet, hvilken logik der er testet, og hvilke beslutninger der er truffet undervejs og hvorfor. Det er præcis den type opgave, hvor en AI-assistent er mest nyttig, fordi den kan holde overblikket, mens man selv fokuserer på detaljerne.

Midt i det arbejde skiftede assistenten til Opus 4.8. Ikke fordi opgaven krævede en anden model, men fordi det tekniske grundlag under samtalen ændrede sig. Den nye model havde ingen erindring om de beslutninger, den forrige havde truffet. Den kendte ikke til de aftaler, der var indgået om, hvordan bestemte dele af koden skulle håndteres. Den startede, billedligt talt, med et blankt ark, midt i en opgave der langtfra var færdig.

Det er ikke et enkeltstående uheld. Det er en konsekvens af, hvordan de store AI-udbydere styrer adgangen til deres modeller. Codex har fjernet det faste 5-timers vindue, som tidligere gav brugere et forudsigeligt tidsrum at planlægge efter. Uden det vindue bliver det sværere at vide, hvornår en samtale risikerer at blive afbrudt eller skiftet til en anden model.

Fable 5.0 har på sin side indført en usage-grænse, der ikke opfører sig lineært eller forudsigeligt. Man kan arbejde intensivt i en periode uden problemer, og så ramme et loft på et tidspunkt, der ikke stemmer overens med, hvor meget man reelt har brugt værktøjet. For den enkelte bruger betyder det, at modelskiftet kan komme uden varsel, midt i en sætning, midt i en filgennemgang, midt i en beslutning.

Det er ikke et argument imod at bruge disse værktøjer. Det er et argument for at forstå, hvordan de faktisk fungerer under motorhjelmen, så man ikke bliver overrasket, når grænserne rammer.

Som praktikeren selv fortæller det: da modelskiftet til Opus 4.8 ramte midt i revisionen, var den mest virkningsfulde reaktion ikke at forsøge at tvinge den gamle model tilbage eller genstarte processen fra bunden. Det var at stoppe op og skrive et handover-dokument, ligesom man ville gøre, hvis en kollega pludselig skulle overtage en opgave midt i en arbejdsdag. Dokumentet blev til sidst overdraget til GPT 5.6 Sol, som fuldførte opgaven.

Dokumentet indeholdt de beslutninger, der var truffet undervejs, og hvorfor. Det beskrev, hvilke dele af koden der var gennemgået og godkendt, og hvilke der stadig ventede. Det opsummerede de mønstre og konventioner, som revisionen fulgte, så den nye model ikke skulle gætte sig frem til dem igen. Og det pegede konkret på, hvor arbejdet skulle fortsætte fra.

Den tilgang vendte en irriterende afbrydelse til en håndterbar overgang. I stedet for at genopfinde konteksten fra bunden, kunne GPT 5.6 Sol læse sig ind på arbejdet på få minutter og fortsætte, næsten som om intet var sket.

For danske SMV-ledere, der i stigende grad lader medarbejdere bruge kodeassistenter i det daglige arbejde, er lektien konkret: forudsæt, at modellen bag værktøjet kan skifte uden varsel, og byg arbejdsgangen derefter.

Det betyder i praksis, at man opbygger en vane med løbende at dokumentere beslutninger og status i et arbejdslogget format, som ikke er afhængigt af, hvilken model der sidder bag skærmen. Det betyder også, at man ikke lægger hele projektets hukommelse i én lang samtale med ét værktøj, men sikrer, at den vigtigste kontekst også findes et sted uden for samtalen, i et dokument, en projektbeskrivelse eller en kommentar i koden.

Det er en lille investering af tid, som betaler sig markant tilbage den dag, hvor et usage-loft rammer midt i en vigtig opgave. Virksomheder, der allerede har den vane indbygget, mister minutter. De, der ikke har det, kan miste timer, eller i værste fald beslutninger, der aldrig bliver genskabt korrekt.

Den praktiske plan B er ikke at undgå AI-værktøjerne af frygt for, at de skifter model under en. Den er at arbejde, som om skiftet altid kan ske, og lade det forme vanerne, længe før det rent faktisk sker.