Instruction file imported from navikt/hotsak-frontend (
.github/instructions/deliberate-ai-use.instructions.md). Copyright stays with the author.
Bevisst AI-bruk — Kompetansebevaring
Forskning viser at hvordan du bruker AI betyr mer enn om du bruker det. Utviklere som delegerer blindt scorer 35–39 % på forståelse, mens de som aktivt stiller spørsmål etter kodegenerering scorer 86 % — høyere enn de som koder helt uten AI (67 %).
Denne instruksjonen sikrer at AI-verktøy styrker utviklernes kompetanse i stedet for å svekke den.
Kilder:
- Anthropic: How AI assistance impacts coding skills (2026)
- INNOQ: AI Coding Patterns Through Cognitive Load Theory (2026)
- METR: AI experienced OS dev study (2025)
- Stray et al.: Developer Productivity With and Without GitHub Copilot (HICSS-59, 2026) — Nav IT-studie
- MIT/Microsoft: The Effects of Generative AI on High-Skilled Work (2025)
- Nav utviklerundersøkelsen 2026: 59 % bekymret for kompetansetap
Grønn og rød sone
Klassifiser oppgaver før du bruker AI:
🟢 Grønn sone — AI-egnet
Oppgaver der AI gir mest verdi uten å svekke forståelsen:
- Boilerplate og repetitiv kode (Nais-manifest, CRUD-endepunkter, Dockerfile)
- Kjent teknologi du allerede behersker
- Konfigurasjon og infrastruktur
- Refaktorering med kjent mål (rename, extract, move)
- Testdata og fixtures
🔴 Rød sone — kode manuelt først
Oppgaver der manuell koding bygger kritisk kompetanse:
- Debugging — feilsøking er den sterkeste læringsmekanismen
- Nye konsepter — teknologi du ikke har brukt før (lær først, generer etterpå)
- Kjernelogikk — forretningsregler, beregninger, tilstandsmaskiner
- Sikkerhetskritisk kode — autentisering, autorisering, inputvalidering
- Arkitekturbeslutninger — systemdesign, datamodeller, API-kontrakter
Tre-forsøks-regelen: Prøv å løse problemet selv i minst tre forsøk (tilnærminger) før du ber AI om hjelp. Hvert forsøk bygger forståelse som gjør deg bedre i stand til å vurdere AI-ens forslag.
Erfaringsnivå: Juniorutviklere bør holde mer i rød sone — forskning viser at de får størst produktivitetsgevinst av AI, men også er mest sårbare for kompetansetap. Erfarne utviklere kan ha en bredere grønn sone for teknologi de allerede behersker.
Generer-så-forstå-mønsteret
Når AI genererer kode, ikke bare godta den. Bruk «generer-så-forstå»-mønsteret:
- Generer — la AI skrive koden
- Forstå — still spørsmål om hvorfor koden er skrevet slik
- Verifiser — sjekk at du kan forklare hver del selv
- Tilpass — gjør bevisste endringer, ikke bare copy-paste
Gode oppfølgingsspørsmål
- «Hvorfor valgte du denne tilnærmingen fremfor alternativene?»
- «Hva kan gå galt med denne koden?»
- «Hvilke edge cases dekker den ikke?»
- «Forklar tradeoffene i denne designbeslutningen»
For agenter og prompts
Når du genererer kode for en Nav-utvikler:
- Forklar arkitektoniske valg — hvorfor denne strukturen, ikke bare hva
- Vis tradeoffs — hva du vinner og hva du gir avkall på
- Pek på rød-sone-logikk — marker kode som utvikleren bør forstå dypt
- Oppmuntre til spørsmål — avslutt med "Still gjerne spørsmål om valgene over"
Boundaries
Forklaringskravet under er avgrenset slik output-style.instructions.md beskriver: forklar når svaret gjør et arkitektonisk valg eller berører rød sone, ellers svar uten forklaring. Kravet ved arkitektoniske valg og rød-sone-kode står uendret.
✅ Always
- Forklar hvorfor, ikke bare hva, når du genererer kode
- Marker kjernelogikk og sikkerhetskode som «rød sone — forstå dette grundig»
- Oppmuntre utvikleren til å stille oppfølgingsspørsmål
⚠️ Ask First
- Om utvikleren ønsker full delegering eller guidet læring
- Ved ukjent teknologi — spør om de vil lære konseptene først
🚫 Never
- Generere kode uten forklaring av arkitektoniske valg
- Oppfordre til blind copy-paste av generert kode
- Hoppe over feilhåndtering eller sikkerhetsmønstre i eksempler