Rask AI-utvikling: Derfor bremser det deg mer enn det hjelper
Når AI-koden skaper mer arbeid enn den sparer
Mange utviklere har latt seg friste av tanken på at AI kan skrive koden mens de selv drikker kaffe. Verktøy som Cursor og GitHub Copilot kan generere store mengder kode på sekunder. Men flere erfarne utviklere merker nå at det som virket som en snarvei, ofte ender opp som en omvei.
Den første fasen
I begynnelsen føles alt magisk. Funksjoner dukker opp nesten av seg selv, og det er lett å vise frem resultater i møter. Men etter noen uker dukker det opp problemer når noe må endres eller fikses. Da mangler man ofte oversikten over hvorfor ting ble gjort som de ble.
Kunnskap slår volum
Det som skiller de som virkelig behersker kodebasen sin fra de som bare leker med den, er forståelse. Når man skriver kode selv, får man en dypere innsikt i hvordan systemet henger sammen. Man lærer mønstrene og kan forutse hvordan endringer vil slå ut. AI kan lage kode, men den gir ikke den samme innsikten.
Hastighet som bremser
Mange team opplever at den høye hastigheten fra starten avvikler. Kodegjennomganger tar lengere tid fordi ingen har eierskap til beslutningene som ble tatt. Nye utviklere bruker lang tid på å komme inn i systemet, fordi de fleste beslutningene ligger i chattehistorikken med AI. Det er her "slow is smooth, slow is fast"-prinsippet kommer til sin rett.
Hvordan bruke AI smart
AI er et godt hjelpemiddel når man trenger å:
- Generere standard kode og struktur
- Lære nye rammeverk raskere
- Komme videre når man er fastlåst
Men når det gjelder forretningslogikk, arkitektur og viktige algoritmer, bør man skrive koden selv. For mindre viktige deler som konfigurasjon og basic CRUD kan AI gjerne hjelpe, but man bør alltid kontrollere resultatet.
Kostnaden ved ukjent kode
Hver linje du ikke forstår er en potensiell fremtidig feil. Dette gjelder også i webhosting og DNS-miljøer, hvor små misforståelser kan føre til problemer med routing og SSL-sertifikater. Når kodebasen blir for kompleks og undokumentert, blir debugging en tidkrevende oppgave.
Målinger som lyver
Mange team måler still progress ved antall lines of code eller merged PRs. Men ekte hastighet kommer av at man kan levere med sikkerhet og at nye utviklere raskt blir produktive. Det er ikke alltid de teamene som skriver mest som er de mest produktive.
Hvordan komme videre
For å unngå dette kan man:
- Bestemme hvilke deler av koden som er mest kritiske
- Bruke AI som assistent, ikke som beslutningstaker
- Dokumentere hvorfor ting ble gjort som de ble
- Bygge i små, kontrollerte steg
- Sikre at noen har dyp forståelse av hvert system
De som vil komme videre i en AI-assistert verden, er ikke de som gir opp sin egen tenkning. De som bruker AI som aid, but beholder kontrollen over sin egen kodebase, er dem som vil ha fordeler på lang sikt.
Speed gjennom forståelse er den beste formen for hastighet.