Hvordan jeg bruker AI
Det siste året har jeg tatt i bruk AI for fullt i måten jeg utvikler på. Jeg lærer fortsatt nye grep hver uke, bommer innimellom når jeg gir for løse rammer, og merker samtidig stor gevinst i hvor mye jeg faktisk får bygget og ferdigstilt.
Ja, AI tar unna mye av kodeskrivinga jeg før gjorde for hånd. Det gir meg mer tid i begge ender av arbeidet: å tenke skikkelig gjennom arkitekturen i starten, og å pusse på detaljene i brukeropplevelsen til slutt.
Hvor tiden min går
Prompten er bare startskuddet. Slipper du en modell løs uten rammer, produserer den raskt dobbelt så mye kode som nødvendig. Ansvaret for at alt henger sammen er fortsatt mitt.
Kjørereglene mine
Rammer før kode
I prosjekter som VGS Bordtennis starter jeg med korte notater om arkitekturen og en egen AGENTS.md med faste regler. En språkmodell vet ikke av seg selv at en Samsung TV i skolekantina fryser <video> elementer på bilde 0 i Infoskjermen.no, eller at hele appen skal klare seg med fem npm pakker. Slike valg må jeg kartlegge og låse på forhånd.
Spike and Stabilize
Etter mye egen prøving og feiling landet jeg på en rytme som viste seg å være en etablert metode kalt Spike and Stabilize, beskrevet av Dan North. Først bygger jeg en rask førsteversjon hele veien fra database til UI (Spike) for å se om ideen faktisk fungerer. Når kjernefunksjonen sitter, bytter jeg til Stabilize: rydder vekk støy, håndterer edge cases og gjør koden klar for produksjon.
Slank kode gir kort kontekst
Jo flere filer og lag en modell må hoppe mellom, desto fortere mister den oversikten. I VGS Bordtennis er koden bevisst holdt slank i tre flate lag med tydelige seksjoner, slik at jeg kan holde konteksten nede på 100 til 200 linjer om gangen.
Strengere tester når tempoet øker
Jo fortere koden skrives, desto viktigere blir testene. Før endringer rulles ut i VGS Bordtennis kjører automatiske tester mot en egen SQLite database, pluss en stresstest med 100 samtidige spillere fordelt på to skoler uten feil.
Hva som hører hjemme i porteføljen
På GitHub ligger det mange raske eksperimenter der jeg bare tester et verktøy eller en ide i fart. De fungerer fint som kladdebok. Prosjektene jeg viser frem her skal derimot tåle at man ser under panseret, der mine egne valg styrer arkitekturen, flyten og detaljene.
Det samme gjelder det visuelle. I VGS Bordtennis har vi noen genererte tullevideoer på storskjermen i kantina for å fange oppmerksomheten i friminuttet. Her i porteføljen viser kortene de faktiske sidene og funksjonene jeg har laget, slik at du ser mitt arbeid. Der AI er selve poenget, som 3D versjonen av meg på forsiden, er den merket åpent.
Randy J. Hunt skriver godt om akkurat dette i On AI-Generated Work in Design Portfolios.
Tre prosjekter, tre ulike strategier
Første versjon gikk fra plan til drift på en uke med en blanding av arkitekturbygging, raske iterasjoner på design og finpuss med AI. Flat kodebase, developerlog.md og AGENTS.md holder konteksten kort mens prosjektet vokser.
Her var strategien helt motsatt. Jeg gjorde grunnarbeidet selv, laget assets i Figma og bygde opp designsystemet for hånd. AI brukte jeg først helt til slutt for å fange opp inkonsekvenser og syntax feil før utrulling.
Skoleprosjektene er til for å lære. Der bruker jeg nesten ingen AI utover litt sparring underveis, slik at jeg er sikker på at grunnkonseptene sitter ordentlig på egen hånd.
Ideen om en egen /ai side er inspirert av Charlota Blunarova.
Vil du høre mer om hvordan jeg jobber?
Spør AI versjonen