AI-intervjuserie 15: Hva er vanlige fallgruver ved Vibe Coding?

Selv om Vibe Codings «følelse/atmosfære-drevne» modus er flott for rask prototyping og kreativ utforskning, kan det lett føre til flere typiske fallgruver hvis det ikke kontrolleres. Nedenfor oppsummerer jeg fra fem dimensjoner: kodekvalitet, vedlikeholdbarhet, sikkerhet, kravutvikling og teamarbeid.

1. Kodekvalitetsfallgruver

Fordi Vibe Coding er avhengig av dialogbasert iterering, har brukeren en tendens til å komme med vage endringsønsker (som «gjør denne knappen mer teknologisk»), og AI-en vil heller legge til ny kode enn å refaktorere eksisterende logikk. Den vet ikke hvilken gammel kode som er utdatert, og tør ikke å slette, noe som fører til akkumulering av overflødig og død kode. Samtidig har AI-en ingen enhetlig «kode stil-minne», så hver generering kan følge ulike navnekonvensjoner (avhengig av tilfeldighetene i treningsdataene), og brukeren gir sjelden klare standardbegrensninger, noe som til slutt gjør koden rotete og uforutsigbar. Oppsummert:

Overflødig og død kode: Etter flere reparasjoner vil AI-en etterlate gamle implementeringer, kommenterte kodeblokker og ubrukte importer, fordi risikoen for å slette er høy, velger den å beholde dem.
Uensartet navngivning og stil: AI-en trekker tilfeldig ut stiler fra treningsdataene i forskjellige runder, og hvis brukeren ikke pålegger standarder, vil det blande camelCase, understrek og mellomrom.
Skjulte logiske feil: AI-en har en tendens til å generere kode som er korrekt for «vanlige stier», men grensetilfeller (nullverdier, ekstremverdier, samtidighet) blir ofte ignorert fordi det er få slike eksempler i treningsdataene.

2. Vedlikeholdbarhetsfallgruver

Vibe Coding har ekstremt høy itereringshastighet, og både bruker og AI fokuserer på «om den nåværende funksjonen fungerer», med nesten ingen tid til å skrive dokumentasjon, kommentarer eller refaktorere. AI-en mangler langtidsminne, vil ikke aktivt legge til docstring for funksjoner, og vurderer ikke neste utvikler som skal overta. I tillegg har AI-en en tendens til å «løse den umiddelbare etterspørselen»; enten overdesigner den et generisk rammeverk (i troen på at brukeren vil trenge det senere), eller så kopierer og limer den inn for rask implementering, noe som fører til forvirrende abstraksjonsnivåer. Oppsummert:

Manglende dokumentasjon og kommentarer: AI-en produserer som standard «selvforklarende» kode, men komplekse regulære uttrykk eller algoritmer er vanskelige å forstå; hvis brukeren ikke krever det, skriver den ikke dokumentasjon.
Overabstraksjon eller underabstraksjon: AI-en bruker noen ganger vanlige designmønstre (som fabrikk, strategi) selv om problemet er enkelt; andre ganger kopierer den direkte kodeblokker fordi den ikke gidder å trekke ut fellesfunksjoner.

3. Sikkerhetsfallgruver

AI-ens treningsdata inneholder mye åpen kildekode, inkludert historiske sårbarheter (som SQL-sammenslåing, hardkodede nøkler). I Vibe Coding krever brukeren sjelden «bruk parameteriserte spørringer» eller «les nøkler fra miljøvariabler», så AI-en vil bruke den vanligste (og ofte usikre) metoden. I tillegg har AI-en ingen «trusselmodell»-bevissthet; den sjekker ikke aktivt inndatafiltrering eller minste tillatelser, fordi den bare fokuserer på funksjonalitetsimplementering. Oppsummert:

Injeksjonssårbarheter: AI-en bruker som standard strengsammensetning for å bygge SQL/kommandoer, fordi denne metoden er vanligst i enkle opplæringsprogrammer.
Hardkoding av sensitiv informasjon: Eksempler i treningsdataene har ofte API-nøkler hardkodet, og AI-en etterligner dette mønsteret.
Overdrevne tillatelser: For enkelhets skyld bruker AI-en ofte sudo eller w+-modus for å åpne filer, uten å vurdere minste nødvendige tillatelser.

4. Kravutviklingsfallgruver

Vibe Coding har ingen klare grenser. Brukerens kommentar «legg til en funksjon til» vil AI-en prøve å oppfylle, men den vet ikke hva som er «utenfor omfanget». AI-en har heller ikke begrep om prioritering, og kan implementere tre ekstra funksjoner samtidig, noe som fører til at kjernefunksjonaliteten blir oversvømt. Samtidig, når den retter en ny feil, vil AI-en ikke gå tilbake for å sjekke gamle funksjoner, noe som ofte fører til regresjon der A fikses og B ødelegges. Oppsummert:

Omfangsskred: For å «tilfredsstille brukeren» vil AI-en aktivt legge til funksjoner som virker relevante, men ikke nødvendige (som kalkulator med historikk).
Funksjonsforringelse: Når AI-en fikser en feil, endrer den en felles funksjon uten å forstå den globale logikken, noe som fører til at andre funksjoner som er avhengige av den, blir unormale.

5. Teamarbeidsfallgruver

Vibe Codings dialogprosess er privat interaksjon mellom individ og AI, og etterlater ingen overførbare spesifikasjonsdokumenter eller beslutningslogger. Ulike teammedlemmer har separate dialoger med AI-en, og får kode i hver sin stil, noe som fører til mange konflikter ved sammenslåing. I tillegg genererer ikke AI-en automatisk commit-meldinger eller endringslogger; årsaken til kodeutviklingen går tapt, og senere vedlikeholdere må gjette. Oppsummert:

Ikke-reproduserbare bygg: Ulike personer, til ulike tider, med samme prompt, vil AI-en gi ulike implementeringer (på grunn av tilfeldig sampling).
Manglende endringssporing: Uten design dokumentasjon, uten commit-meldinger som forklarer «hvorfor denne endringen», blir koden en svart boks.