Det finnes et nytt begrep i utviklerverdenen: vibe-coding. Du beskriver hva du vil ha, AI genererer koden, du trykker "Accept", og det fungerer. Noen ganger. Og når det fungerer, føles det som magi.
Men her er saken: magi er farlig når du ikke forstår trikset.
Dette er ikke et anti-AI-innlegg. Jeg bruker Cursor og Claude daglig. AI har gjort meg til en bedre og raskere utvikler. Men det er en fundamental forskjell mellom å generere kode og å forstå kode — og den forskjellen kommer til å definere hvem som bygger fremtidens systemer.
Min reise: Fra Atom til Cursor
Jeg husker den første gangen jeg åpnet Atom på videregående. HTML og CSS. Ingen IntelliSense, ingen Copilot, ingen LLM som kunne forklare hva display: flex faktisk gjorde. Bare meg, en teksteditor, og en nettleser med DevTools.
Hver syntax error var en kamp. En glemt semikolon i CSS kunne ødelegge hele layouten, og det tok meg tjue minutter å finne den. En <div> som ikke ble lukket riktig kollapset halve siden. Jeg kan ikke telle antall timer jeg brukte på å stirre på kode som burde funke, men som ikke gjorde det — fordi et usynlig tegn var feil et sted.
Det var frustrerende. Men det var også utrolig lærerikt.
Den smerten bygget noe verdifullt: mentale modeller. Jeg lærte å lese feilmeldinger — ikke bare se dem, men forstå dem. Jeg lærte at CSS har en kaskade og spesifisitet. Jeg lærte at DOM-en er et tre, ikke en flat liste. Jeg lærte å debugge systematisk i stedet for å gjette tilfeldig.
Nå jobber jeg i Cursor med Claude som par-programmerer. Og det er fantastisk. Men grunnen til at det er fantastisk, er at jeg forstår hva AI-en foreslår. Jeg kan se når den tar feil. Jeg kan vurdere trade-offs. Jeg kan si "nei, den løsningen skalerer ikke" — fordi jeg har bygget de mentale modellene som kreves for å gjøre den vurderingen.
Hva vibe-coding faktisk er
Vibe-coding er ikke binært. Det er et spektrum.
På den ene enden har du fullstendig AI-generert kode der utvikleren aldri leser output. På den andre har du en erfaren utvikler som bruker AI som et kraftig verktøy, men som forstår og vurderer alt som genereres.
De fleste av oss er et sted midt imellom, og det er helt greit. Problemet oppstår når noen tror de er på den erfarne enden, men egentlig aldri har bygget de grunnleggende ferdighetene som kreves for å vurdere koden.
Vibe-coding er kraftig for prototyping, MVP-er og idevalidering. Jeg bruker det selv — når jeg tester en ny idé, kan jeg gå fra konsept til fungerende prototype på timer i stedet for dager.
Men prototyper er ikke produksjon. Og her treffer vi grensen: du kan ikke debugge det du ikke forstår. Og enda viktigere — du kan ikke reviewe det du ikke forstår.
AI-forsterkeren: 10x bedre eller 10x farligere
Her er det som ingen snakker nok om: AI er en forsterker, ikke en erstatning.
For en erfaren utvikler er AI som å få en ekstra hjerne som kan holde rede på tusen API-er samtidig. Du vet hva du vil bygge, du forstår arkitekturen, og AI hjelper deg å komme dit raskere. Resultatet: du er dramatisk mer produktiv.
For en uerfaren utvikler forsterker AI kunnskapshullene. Koden ser riktig ut. Den kjører. Testene (hvis de finnes) passerer. Men under overflaten kan det ligge alvorlige problemer.
La meg gi et konkret eksempel. En vibe-codet innloggingsflyt:
app.post('/login', async (req, res) => {
const { email, password } = req.body;
const user = await db.query(
`SELECT * FROM users WHERE email = '${email}' AND password = '${password}'`
);
if (user.rows.length > 0) {
const token = jwt.sign({ id: user.rows[0].id }, 'secret123');
res.json({ token });
} else {
res.status(401).json({ error: 'Invalid credentials' });
}
});Den fungerer. Men den har minst fire kritiske sikkerhetshull: SQL injection via string interpolation, passord lagret i klartekst, hardkodet JWT-secret, og ingen rate limiting. En erfaren utvikler ser dette umiddelbart. En vibe-coder ser en fungerende login.
En hard-codet versjon ser fundamentalt annerledes ut:
app.post('/login', rateLimit({ windowMs: 15 * 60 * 1000, max: 10 }),
validateBody(loginSchema),
async (req, res) => {
const { email, password } = req.body;
const user = await db.query(
'SELECT id, password_hash FROM users WHERE email = $1', [email]
);
if (!user.rows[0]) return res.status(401).json({ error: 'Invalid credentials' });
const valid = await bcrypt.compare(password, user.rows[0].password_hash);
if (!valid) return res.status(401).json({ error: 'Invalid credentials' });
const token = jwt.sign(
{ id: user.rows[0].id },
process.env.JWT_SECRET,
{ expiresIn: '1h' }
);
res.json({ token });
});Parameteriserte spørringer. Hashede passord. Miljøvariabel for secret. Rate limiting. Input-validering. Ingen av disse tingene er vanskelige — men du må vite at de trengs. Og den kunnskapen kommer fra å forstå systemene du bygger, ikke fra å akseptere det første AI foreslår.
Hvorfor hard-code-ferdigheter fortsatt er avgjørende
AI kan generere kode. Den kan til og med generere ganske god kode. Men det er fem ting den fundamentalt ikke kan gjøre for deg:
Arkitekturbeslutninger. Skal du bruke mikroservices eller en monolitt? Event-driven eller request-response? PostgreSQL eller DynamoDB? AI kan gi deg fordeler og ulemper — men den kjenner ikke teamet ditt, budsjettet ditt, brukerbasens størrelse, eller de regulatoriske kravene du opererer under. Arkitektur krever kontekst som ingen LLM har.
Sikkerhet i praksis. AI hallusinerer sikkerhetsløsninger. Den kan foreslå RLS-policies som ser riktige ut men som har logiske hull. Den kan generere auth-flyter som mangler edge cases. Sikkerhet krever paranoia — en grunnleggende mistillit til all input — som AI rett og slett ikke har.
Debugging i produksjon. Når systemet ditt krasjer klokken 03:00, hjelper det ikke å spørre AI om hva som gikk galt. Du trenger mentale modeller: hvordan flyter data gjennom systemet? Hvor kan flaskehalsen være? Hva sier loggene? Stack traces, memory profiling, nettverksanalyse — dette krever dyp forståelse.
Kodebase-koherens. Et prosjekt der 50 forskjellige AI-samtaler har generert 50 forskjellige moduler, uten en samlende arkitektur, blir en vedlikeholdsnightmare. Noen må holde den røde tråden. Det er utviklerens jobb.
Å vite hva du ikke vet. Det farligste stedet å være er "unconscious incompetence" — du vet ikke hva du ikke vet. Erfarne utviklere har en intuisjon for når noe er feil, selv før de kan peke på hva. Den intuisjonen bygges gjennom år med å gjøre feil, ikke gjennom å la AI gjøre alt riktig for deg.
Utviklerjobben har endret seg — ikke forsvunnet
Tenk på en arkitekt. Før CAD-verktøy tegnet arkitekter hver linje for hånd. Nå bruker de avansert programvare som kan generere hele bygningsmodeller. Men ingen vil si at arkitekter er overflødige — fordi verktøyet tegner, men arkitekten vet om bygget tåler vind.
Utviklerjobben har gjennomgått en lignende transformasjon. Vi har gått fra "skriv hver linje selv" til "arkitekt, verifiser og orkestrer." Det er ikke en degradering — det er en oppgradering. Vi jobber på et høyere abstraksjonsnivå, med kraftigere verktøy, og kan levere mer enn noensinne.
Men det forutsetter at du har fundamentene. En arkitekt som aldri har lært statikk kan ikke bruke CAD-verktøy trygt. En utvikler som aldri har lært å debugge kan ikke bruke AI trygt.
Til grundere og rekrutterere som leser dette: Når du ansetter utviklere i 2026, se etter folk som kan forklare hvorfor koden fungerer — ikke bare at den gjør det. Spør om trade-offs, ikke bare implementasjonsdetaljer. De beste utviklerne i AI-alderen er de som behandler AI som et verktøy i verktøykassen, ikke som en erstatning for forståelse.
Slik går du fra vibe til hard
Hvis du kjenner deg igjen — hvis du har merket at du aksepterer AI-generert kode uten å helt forstå den — her er fem konkrete steg:
1. Les koden AI genererer. Ikke bare se at den kjører. Les den linje for linje. Forstå kontrollflyt, dataflyt, og feilhåndtering. Hvis du ikke forstår en linje, stopp og lær deg hva den gjør.
2. Bygg noe uten AI. Velg et lite prosjekt — en CLI-app, en enkel API, en nettside — og bygg det fra scratch uten assistanse. Smerten du føler er læring.
3. Lær deg debugging-verktøy. Chrome DevTools, console.trace(), nettverksfanen, memory profiling. Disse verktøyene gir deg innsikt som ingen AI-samtale kan erstatte.
4. Forstå arkitekturen før du ber om kode. Før du ber AI om å bygge en feature, tegn opp hvordan den passer inn i systemet. Hvilke lag berøres? Hvilke data flyter hvor? Hvilke feilscenarier finnes?
5. Review AI-kode som en juniors PR. Anta at koden kan ha feil. Se etter sikkerhetshull, ytelsesproblem, manglende edge cases, og inkonsistens med eksisterende kodebase. AI er din mest produktive juniorutvikler — men den trenger fortsatt code review.
Avslutning
Da jeg satt med Atom på videregående og kjempet med syntax errors, bygget jeg noe som ingen AI kan gi meg: forståelse. Den frustrasjonen, de timene med debugging, de øyeblikkene der alt plutselig klikket — det er fundamentet jeg står på nå.
AI har ikke gjort det fundamentet mindre verdifullt. Den har gjort det mer verdifullt. Fordi når alle kan generere kode, er det forståelse som skiller. Ikke hvem som skriver flest linjer, men hvem som vet hvilke linjer som faktisk trengs.
De beste utviklerne i fremtiden mestrer begge moduser. Vibe-code for hastighet. Hard-code for kvalitet. Og visdom til å vite når du bruker hvilken.