Context window: Den harde grensen
Mine 27,500 linjer kode tilsvarte cirka 250-300,000 tokens. Claudes context window er 200,000 tokens. Når kodebasen ble større enn det AI kunne "se", begynte den å oppføre seg som en med alzheimer - glemme nylige endringer, gjenta samme operasjon flere ganger, og foreslå funksjoner som allerede eksisterte.
Praktisk erfaring: AI fungerer best med 10-15,000 linjer om gangen - typisk størrelsen på én modul. Dette er halvparten av teoretisk maksimum, men det er her kvaliteten holder seg høy.
To forskjellige suksesshistorier
Prosjekt 1: Hyttelotteri integrert i Minside (Claude Code)
Eksisterende minside-applikasjon på ~20K linjer. La til 10K linjer lotteri-funksjonalitet.
Total: 30K linjer. Rask og ren implementasjon.
For å stressteste Claude Code, ba jeg den gjøre en major refaktorering (bytte axios med OpenAPI) på hele 30K-linjers kodebasen. Dette var bevisst ambisiøst. Claude klarte det teknisk, men det ble ineffektivt - masse feil, lang tid, konstant korrigering. Lærdommen: Ved context window-grensen fungerer ikke store tverrgående endringer godt.
Prosjekt 2: Full applikasjon fra scratch (Replit)
0 til 27,500 linjer bygget fra bunnen. Fungerte overraskende bra hele veien, men begynte å vise tegn til "alzheimer" mot slutten.
Dokumentasjonsstruktur som fungerer
Jeg bruker AGENTS.md (eller CLAUDE.md) i roten for systemoverikt og MODULE.md per modul. Nøkkelen:
Claude kan faktisk generere MODULE.md selv når den ser hele modulen (10-15K linjer). For større systemer kan den begynne å "rote".
# AGENTS.md
## Moduler
- /server (12K linjer) - Backend API
- /client (10K linjer) - React frontend
- /shared (8K linjer) - Utilities
## Ikke rør
- /auth - Sikkerhetskritisk
- PaymentService - PCI compliance
Tips: Be Claude generere MODULE.md etter at en modul er ferdig. Den lager bedre dokumentasjon enn du gidder skrive selv.
Plan-todo.md: AI-ens arbeidshukommelse
For hver feature lager jeg en plan-todo.md. Dette er ikke for deg - det er for AI-en når du må restarte chat-sesjonen (og det bør du, ihvertfall innimellom).
# Feature: Booking-kansellering
## Problem
Brukere kan ikke kansellere bookinger. Må refundere ved kansellering >7 dager før.
## Løsning (high-level)
- API endpoint for kansellering
- Sjekk 7-dagers regel
- Refunder via PaymentService
- Send bekreftelse på email
## TODO (AI oppdaterer denne)
- [x] POST /api/bookings/:id/cancel - endpoint med basic validering
- [x] cancelBooking() i BookingService med business logic
- [x] Integrasjon mot PaymentService.refund()
- [ ] Email-template for kansellering
- [ ] Frontend: Kanselleringsknapp med bekreftelsesdialog
- [ ] E2E test av full flyt
Når du må restarte chat: "Les plan-todo.md for kansellerings-feature og fortsett der vi slapp."
Skalering: Fra magi til "alzheimer"
0-20K linjer: AI ser hele kodebasen, kan foreslå tverrgående refaktoreringer, forstår all business logic. Dette er den magiske fasen.
20-30K linjer: Responstid øker. AI begynner å "glemme" deler av kodebasen. Løsningen: Fokuser på én modul om gangen.
30K+ linjer: AI kan ikke lenger se hele bildet. Store refaktoreringer blir ineffektive. Men modulær utvikling fungerer fortsatt fint - "Les hele /server modulen og implementer X" går bra.
Når skal du restarte?
Claude komprimerer automatisk context når den fylles opp, men da mister den detaljer. Du merker det når:
- AI glemmer ting dere nettopp har diskutert
- Den foreslår å genere kode den kanskje allerede har generert
- Forslagene viser mindre innsikt i kode dere nettopp har gjort noe med og diskutert
Ikke vent på automatisk komprimering, som kan ta ganske lang tid. Når du merker "alzheimer-symptomer": avslutt, oppdater plan-todo.md, start på nytt.
Praktiske grep som fungerer
Hold deg til moduler. Så lenge AI ser hele modulen (10-15K linjer), fungerer alt fint. Store tverrgående refaktoreringer ved 25K+ linjer? Mulig, men ineffektivt.
La AI lage sin egen dokumentasjon. "Analyser /server modulen og generer MODULE.md" gir deg dokumentasjon som faktisk stemmer.
Strukturer for 15K moduler fra start. Design for AI-vennlige modulstørrelser fra dag én.
Iterativ utvikling er default. Start med en løs idé, la AI prøve, korriger kursen. Går mye raskere enn overplanlegging.
Hvor AI virkelig leverer
- Rigide spesifikasjoner: API-integrasjoner, protokoller, dataformater - alt med eksakte regler
- Debug-loop: Paste feilmelding, få fix umiddelbart
- Test-generering: Comprehensive test-suites basert på eksisterende patterns
- Boilerplate: CRUD, validation, standard endpoints
- Konsistent refaktorering: Men hold deg innenfor modulgrenser ved store kodebaser
Kodekvalitet er ikke problemet
Ærlig talt har jeg lite å utsette på koden AI genererer. Den følger patterns konsistent, strukturerer logisk, og håndterer edge cases fornuftig. Problemet ved 30K+ linjer er ikke kodekvalitet, men at AI ikke ser hva som allerede eksisterer - derav duplikater og inkonsistente løsninger.
Arbeidsflyt som skalerer
Min typiske dag med 30K+ linjer kodebase:
1. Velg modul basert på feature (må være <15K linjer)
2. Start chat: "Les AGENTS.md og server/MODULE.md"
3. "Les plan-todo.md for [feature]"
4. La AI lese hele modulen
5. Implementer iterativt
6. Ved "alzheimer-symptomer": Restart med oppdatert plan-todo.md
Dette gir konsistent 3-5x produktivitet selv på komplekse enterprise-features.
"Men agentisk AI da?"
Jeg brukte faktisk Replit Agent for hele 0-27K prosjektet. Den er imponerende og kan jobbe mer selvstendig, men treffer samme context window-vegg. Forskjellen fra Claude Code er ikke dramatisk - begge planlegger, implementerer, tester og fikser. Replit kommer bare litt lengre før den trenger hjelp.
Alle moderne AI-kodeverktøy er delvis "agentiske". Det som betyr noe er ikke hvor autonom AI-en er, men om den kan se nok context til å gjøre jobben effektivt.
Konklusjon
AI-assistert utvikling handler om å forstå og respektere context window limits:
Mine to prosjekter beviser at AI kan levere både på greenfield (0-27K linjer) og integration (10K linjer inn i eksisterende system). Men respekter grensene - store refaktoreringer ved context window limit blir ineffektive selv om de er teknisk mulige.
Gemini 3 lover 1M tokens (teoretisk 150K linjer). Inntil det er battle-tested: mestre dagens 200K token reality med smart scoping.
Selv om prosjektene mine gir tydelige indikasjoner, er dette fortsatt to relativt små systemer og erfaringer gjort over kort tid. Konklusjonene er derfor praktiske observasjoner, ikke endelige sannheter. Etter hvert som verktøyene forbedres – spesielt med større context windows og bedre minnehåndtering – kan noen av disse erfaringene endre seg. Men slik verktøyene fungerer i dag, virker mønstrene ganske stabile.
Her kan du se ett av resultatene.
