Grensen mellom "vibe coding" og seriøs AI-utvikling viskes ut – og det burde bekymre deg

Tidligere skilte vi klart mellom raske AI-hacks og ekte profesjonell utvikling. Nå smelter skillet. Det stiller tøffe spørsmål om ansvar, tillit og hva som egentlig er produksjonsklart i AI-tiden.

Den opprinnelige planen: Enkelt og ryddig

Det var enkelt før.

Vibe coding handlet om kaos. Ikke-utviklere ba AI lage ting. Resultatet fikk dukke opp som det var. Bruk det til personlige verktøy, engangs-scripts eller helgeprosjekter. Krasjer? Du fikser det selv. Null problemer.

Agentic engineering var det proffe. Erfarne utviklere brukte AI for å booste kompetansen sin. Sikkerhet på plass. Kode som holder. Ytelse i orden. Du var sjefen. AI bare et verktøy.

Teorien lød bra. Virkeligheten? Et rot.

Den ubehagelige sannheten

AI-modellene blir skremmende gode. Selv erfarne folk dropper gjennomgangen.

Du ber Claude eller en kode-agent lage en JSON-endepunkt med SQL, tester og docs. Du vet det blir bra. Så du leser ikke koden. Bare merger.

En gang? Ok. Ti ganger? Dårlig vane. Hundre ganger? Du har glidd tilbake til vibe coding – med en tittel du ikke har tjent.

Black box-problemet (som egentlig er vanlig)

Motargumentet holder vann: I store team leser du ikke all kode fra kolleger. Du stoler på bildekonverteringstjenesten uten å grave i koden. Biblioteker? Bruker dem blindt. Du delerger og går videre.

Hvorfor? Folk bygger rykte. De har hud i spillet. Ansvar er innebygd.

AI har ingen rykte å tape. Ingen jobb å miste. Den spytter ut kode basert på treningsdata.

Likevel lykkes den stadig. Tillit føles logisk.

Den ekte faren: Avvik normaliseres

Fra ingeniørfaget (NASA-stil): normalization of deviance. Du bryter regler uten konsekvenser. Til slutt ser det ikke ut som brudd lenger.

Hver gang AI-kode slippes igjennom uten sjekk og funker perfekt, nærmer du deg dagen det ryker – og produksjon krasjer.

Ikke fordi AI er upålitelig. Fordi den er god nok til at vi senker kravene.

Slik holder du hodet kaldt (og ansvarlig)

Lager du software som teller – med andres data eller opplevelser? Følg dette:

1. Risikovurder koden. Alt trenger ikke samme sjekk. En config-fil? Lettvint. Autentisering? Grundig. Betaling? Maks rigor.

2. Definer "review" presist. Ikke alltid linje-for-linje. For lavrisiko AI-kode: Kjør tester, sjekk flyt, spot-sjekk sikkerhet, vurder ytelse.

3. Se på AI som et team internt. Stol på rutinejobber. Du styrer arkitektur og sensitivt. Du er senior. De er juniorer – ikke omvendt.

4. Følg med på din egen bias. Hopper du over sjekk fordi "det pleier å funke"? Noter det. Spor feil (de kommer). La data styre tillit, ikke bekvemmelighet.

Den sure realiteten

Vi er midt i overgangen. Verktøyene er rå. Produktiviteten din skyter i været. Men vi har ikke knekt ansvars-koden ennå. Bransjen snakker knapt om det.

Open source løste det før: Rykte, åpenhet, ansvar via innsyn. AI trenger sin versjon.

Inntil da? Ansvaret er ditt. Vær på vakt. Vær ærlig om hva du sjekker og hvorfor. Kode som funker betyr ikke at du bygde den.

Hvordan bruker du AI-kodeverktøy? Havner du i gråsonen? Del i kommentarene – denne debatten formes nå, og vi proffer må styre den.