– AI er ikke juks, snarvei eller erstatning for utviklere
– De som avfeier det hele fordi de har sett skranglete vibbekoding på sosiale medier, retter kritikken i feil retning, skriver Christian Hjellestad, som gjør "vibe engineering".
Jeg skjønner at enkelte får frysninger av AI-optimismen.
Arja skrev det senest denne uken i sitt leserinnlegg på kode24, og beskriver det godt – hvordan det kan “gå kaldt nedover ryggen” når vi ser slurvete AI-kode og en del hype som lover mer enn den kan holde.
Det perspektivet er nyttig, for vi trenger friksjon i diskusjonen.
Samtidig har jeg et annet utgangspunkt: AI er ikke juks, snarvei eller en erstatning for utviklere. Den er vaskemaskinen som flyttet oss fra skurebrettet til funksjonell, forutsigbar kvalitet – og frigjorde tid til viktigere (og gøyere?) arbeid.
Poenget er ikke å slutte å vaske klær; poenget er å vaske bedre, oftere og bruke hodet på det som gir mer verdi.
Skrev nesten ikke én linje kode
De siste ukene har jeg ledet en ganske kompleks leveranse: en bestillingsløsning som snakker med flere Salesforce-miljøer, validerer organisasjonsnummer mot Brønnøysund sine åpne API-er, kobler inn ERP for automatisk fakturering, og rulles ut på flere språk i flere land.
Jeg skrev nesten ikke en eneste linje kode selv. I stedet gjorde jeg det jeg mener blir kjernen i utviklerrollen fremover: jeg planla, modellerte dataflyt, avgrenset potensielle problemer, satte prinsipper for sikkerhet og tilgjengelighet, beskrev testene – og lot AI gjøre grovarbeidet innenfor de rammene jeg hadde satt.
Vaskemaskin-prinsippet i praksis.
Her skiller jeg mellom “vibbekoding” og “Vibe Engineering”.
- Vibbekoding (eller Vibe Coding om du vil) er når du ber en modell “sleng sammen en komponent” og håper det blir bra.
- Vibe Engineering er etter min mening noe helt annet: Du starter med domenet, risikoene, integrasjonene, ikke-funksjonelle krav og driftsmodellen – og så gir du AI presise oppdrag innenfor et tydelig design.
Da blir AI en dyktig fagarbeider i et system du eier. De som avfeier det hele fordi de har sett skranglete vibbekoding på sosiale medier, retter kritikken i feil retning.
Jeg skrev nesten ikke en eneste linje kode selv. I stedet gjorde jeg det jeg mener blir kjernen i utviklerrollen fremover.
Ikke AI sin feil
Jeg er også enig med kode24s Kurt Lekanger i bekymringen for dårlig tilgjengelighet.
Ja, AI kan spytte ut div-suppe og ignorere ARIA.
Men Kurts poeng er egentlig en oppfordring: hvorfor ikke heller be AI-en om å hjelpe deg med tilgjengelighet?
Gi verktøyet WCAG-lenker, be det sjekke koden og foreslå forbedringer.
Eller som min tidligere kollega Elise også skrev om; bruk automatisk testing.
Jeg har selv gjort testing med pa11y til en fast rutine i all frontend utvikling.
Det er ikke en “AI-feil” når tilgjengeligheten eller sikkerheten er svak; det er latskap eller udyktighet hos oss selv, som ikke spesifiserer, kontrollerer og tester godt nok.
Og WCAG 2.2 er ikke mystisk – den er konkret, testbar og kan inngå i både spesifikasjon og CI.
Jobbe med AI
I min hverdag i Devora betyr dette at arbeidet skjer i tre tempoer:
- Først bruker jeg tid til å forme visjonen – jeg kartlegger hva jeg egentlig vil oppnå, definerer både positive og negative mål (altså hva jeg VIL, og hva jeg IKKE VIL oppnå), skisserer dataflyt og bruker scenarier, ser for meg hvor ting kan feile, og setter standarder for sikkerhet og personvern – før en eneste kodebit lages. Jeg lager et detaljert PRD-dokument, som igjen blir grunnlaget for å dele hele prosjektet opp i mindre oppgaver og delmål.
- Deretter går jeg over til selve utviklingen, hvor jeg i praksis forteller til AI: “Her er planen og skissen, nå vil jeg du skal skrive adapter, kontrakt og tester – men med presise krav til logging, testing og DoD (Definition of done).”
- Til slutt skjer verifikasjonen: jeg får AI til å foreslå testscenarier jeg aldri ville orket å skrive selv, og jeg “trigger” automatisk sjekker mot standarder som WCAG og sikkerhetslister. Og når noe ryker? Da gjør det det raskt og kontrollert – fordi feilene skjer innenfor de rammene jeg allerede har definert.
"Hva med kvaliteten?"
“Men hva med kvaliteten – blir den ikke dårligere når du ikke skriver koden selv?”
Det kommer helt an på hvordan du jobber.
Jeg ser oftere det motsatte. Når jeg bryter problemet ned i små, presise "bestillinger" – og når jeg bruker regler som for eksempel AGENTS.md eller .cursorrules for å instruere verktøyene – får jeg mer konsistent og vedlikeholdbar kode.
Hemmeligheten er at reglene og promptene også er levende dokumentasjon. De skjerper både meg og verktøyet for hver iterasjon. Og for å fjerne en annen vanlig fallgruve – utdaterte eksempler og API-er – setter jeg sammen AI-en med kilde-oppdatert dokumentasjon via MCP-servere som Context7. Da får modellen ferske, versjonsspesifikke kilder inn i konteksten, i stedet for å gjette fra gammel treningsdata.
Resultatet er færre “hallusinasjoner” og færre småfeil som snør seg store i produksjon.
Et helt konkret eksempel på dette opplevde jeg nylig i planleggingen av en SaaS-løsning som skulle utvikles, hvor AI uten instruksjoner fra meg planla hele løsningen i .NET 7, som hadde EoL (End-of-Life) for snart et halvt år siden, i mai.
Hvorfor skjedde dette? Jo enkelt og greit, jeg glemte noe så enkelt som å skrive "use context7" i prompten, som hadde sikret at AI agenten brukte up-to-date dokumentasjon. Men dette var naturligvis enkelt å fikse kjapt, da jeg selv var klar over dette og sørget for å bruke .NET 9 istedenfor.
"Hva med sikkerhet?"
“Ok, men sikkerhet, universell utforming og ytelse da? Er ikke det AI-ens akilleshæl?”
Igjen: det er vår akilleshæl hvis vi ikke spesifiserer, kontrollerer og tester.
Vi har standarder, verktøy og åpen dokumentasjon. Vil jeg sjekke en løsning for tilgjengelighet, kan jeg be AI kartlegge kode mot WCAG 2.2, vise meg hvor vi bryter suksesskriterier, og generere konkrete fix-forslag – og så kjører jeg manuelle og automatiserte tester for å verifisere. Vil jeg styrke sikkerheten, ber jeg om trusselmodeller for komponentene, genererer SAST/DAST-sjekker, og setter policyer i CI.
Dette er ikke en “AI gjør hva den vil”-situasjon; det er klassisk utvikling og DevOps-fag, bare med mye raskere gjennomføring når verktøyet brukes riktig.
Når UU-tilsynet advarer mot en ond sirkel av dårlige kodevaner forsterket av AI, leser jeg det som en beskjed til oss: bygg bedre vaner og gjennomfør bedre tester og kontroll av løsningene som utvikles.
For å gjøre det håndfast: I integrasjonen min ba jeg AI lage førsteutkast til validerings- og lookup-klienter mot Salesforce og Brønnøysund, med tydelige krav til feilhåndtering, caching og logging. Jeg matet inn den offisielle API-dokumentasjonen, ba om en testplan, og kjørte gjennom både suksess- og feilscenarier mot testdata.
Når noe skurret, var det fordi spesifikasjonen min var for løs eller fordi domeneregler måtte presiseres – ikke fordi AI var “dum”. Det tok meg minutter å stramme inn rammene og la verktøyet regenerere i riktig retning.
Dette er forskjellen på “vibbekode” og "Vibe Engineering" med AI.
Betyr alt dette at juniorutviklere mister læring? De kan gjøre det – hvis vi setter dem på autopilot.
Ikke en snarvei rundt ansvar
Betyr alt dette at juniorutviklere mister læring?
De kan gjøre det – hvis vi setter dem på autopilot. Men her har vi også et valg:
La dem skrive mindre biter for hånd, forstå hvorfor en algoritme er valgt, og bruke AI som sparringspartner som forklarer ukjent kode og tegner flytdiagrammer. La dem “eie” små, komplette leveranser fra design til deploy, med observability og rollback-plan.
Da kobler vi motorikk til mening. Og så lenge vi som fagmiljø prioriterer prinsipper og håndverk, vil AI bare senke terskelen for å bygge noe bra – både for erfarne og de med gode ideer uten klassisk bakgrunn.
Til deg som fortsatt er skeptisk: Les Arjas innlegg, og la den uroen få plass – men vend så blikket mot hva vi faktisk kan gjøre annerledes i praksis. Les også Kurts poeng om å la AI hjelpe deg med tilgjengelighet, ikke motarbeide den. Det er et pragmatisk råd som, ved riktig bruk, hever kvaliteten.
Til slutt: bruk ferske kilder i promptene dine. Konfigurer verktøy som Context7 for å dytte inn oppdatert dokumentasjon i sanntid. Med slike grep går vi fra “håpe på flaks” til reproduserbart utviklingsarbeid – i samme fart som kundene og brukerne våre forventer.
For min del er konklusjonen enkel: AI er ikke en snarvei rundt ansvar – den gjør ansvar tydeligere. Vi skriver kanskje færre linjer selv, men vi tar flere avgjørelser som faktisk betyr noe – om arkitektur, sikkerhet, personvern, universell utforming og drift.
Koden kan etter hvert skrive seg selv. Retningen, rammene og kvaliteten må fortsatt noen eie.
Det er oss.
