Sveve-kodingens bedrag: Hvorfor AI kan skrive kode, men ikke erstatte systemdesignere

La meg være ærlig: vi har alle vært der. Du oppdager et nytt AI-verktøy for koding, og plutselig føler du at du kan bygge hva som helst. Årevis med "hvis jeg bare hadde tid til å bygge den ideen"? Nå har du tid. Bare beskriv hva du vil, snakk med AI-en, og lever.

Følelsen er berusende. Og farlig.

Fristelsen med "godt nok"-kode

For en måned siden bestemte jeg meg for å teste grensene for sveve-koding ved å bygge et "enkelt" minnesystem for AI-agenter. Du vet, greia som lar en kodeassistent huske hva den har lært på tvers av økter i stedet for å starte fra scratch hver gang.

Hvor vanskelig kan det være? Lagre noen fakta, hent dem når relevant, kanskje flagg motsetninger. En smart database med et fint API.

Koden kom fort. Virkelig fort. Agenten jeg jobbet med spyttet ut en Rust-demon, et klassifiseringssystem, fire hentestrategier med omranking via lokale modeller. Etter enhver målestokk så det imponerende ut. Testene besto. Kompilatoren var fornøyd.

Og så prøvde jeg å bruke det.

Her er greia med minnesystemer for agenter: de handler egentlig ikke om lagring. De handler om mening. Og mening viser seg å være filosofisk vanskelig på måter som får din nøye typed kode til å virke som å bygge en rakett og glemme tyngdekraften.

Motsetningsproblemet ingen snakker om

Målet mitt var enkelt: hvis agenten lærer noe nytt, sjekk om det strider mot det den allerede "vet." Virker rimelig. Et minne som motsier andre minner uten forklaring er ikke bare unyttig — det er aktivt skadelig. Du forurenser kontekstvinduet med motstridende informasjon.

Hva kan være enklere? Sammenlign to fakta. Flaggmotsetningen.

Bortsett fra.

Hva er egentlig en motsetning i et slikt system? Hvis agenten lærte på mandag at "Prosjekt X bruker PostgreSQL" og lærte på tirsdag at "Prosjekt X bruker MySQL" — er det en motsetning? kanskje tech-stakken endret seg. kanskje en kilde var feil. kanskje "Prosjekt X" refererer til forskjellige prosjekter. kanskje "bruker" betyr forskjellige ting i forskjellige kontekster.

Mennesker håndterer dette gjennom år med akkumulert common sense, kontekst, og evnen til å si "dette føles feil" uten å kunne artikulere akkurat hvorfor. AI-systemer kan generere sikker prosa om enhver av disse tolkningene, men den sikkerheten er ofte bare mønstergjenkjenning uten forankret forståelse.

Der sveve-kodingen knekker

Sveve-koding er ekspert på å løse problemer du kan formulere tydelig. Du har en bug? Beskriv symptomene. Du trenger en funksjon? Spesifiser input og output. AI-en håndterer implementasjonsdetaljene med bemerkelsesverdig kompetanse.

Men systemdesign — ekte systemdesign — handler om å løse problemer du ikke kan formulere tydelig. Det handler om å forutse interaksjoner mellom komponenter som ikke eksisterer ennå. Det handler om å spørre "hva skjer hvis..." for scenarioer du ikke har forestilt deg.

Da jeg ba AI-assistenten min om å "implementere motsetningsdeteksjon," ba jeg den egentlig om å løse et problem jeg ikke kunne definere presist. Resultatene var... kreative. Vi utforsket Belnap-gitter, fireverdig logikk, formell verifikasjon med Agda-bevis, Petri-nett. Assistenten var med på alt jeg foreslo, og ærlig talt var noen av ideene genuint interessante.

Men "interessant" betyr ikke "fungerer."

Beviset i Agda var korrekt. Arkitekturen var godt dokumentert. Og systemet oppdaget fortsatt ikke motsetninger pålitelig fordi vi formaliserte feil abstraksjon. Vi bygde en vakker katedral på et fundament av sand, og verken AI-en eller jeg skjønte det før vi hadde investert måneder.

Den ubehagelige sannheten

Her er hva sveve-koding-tilhengere ikke forteller deg: det vanskelige med programvareutvikling var aldri å skrive koden. Det er å finne ut hva du skal bygge.

Dette var alltid sant. Hva som har endret seg er at gapet mellom "jeg hadde en idé" og "jeg har kode" har kollapset dramatisk. Det er genuint flott for prototyping, for læring, for å utforske hva som er mulig.

Men det betyr også at du kan feile mye raskere og dyrere enn før. Du kan generere fjell av selvsikker kode som løser feil problem, og du kanskje ikke oppdager det før du har bygget et helt system på et feil fundament.

Hva som faktisk hjelper

Ingenting av dette betyr at AI-assistert utvikling er en dårlig idé. Det er det ikke. Men å bruke det effektivt krever andre ferdigheter enn ren kodeevne:

Du må vite hva du ikke vet. Når AI-en foreslår en løsning i et domene du ikke kjenner til, er ikke det tidspunktet for å si "høres bra ut, implementer det." Da må du grave dypere.

Proof of concepts må testes brutalt mot virkelige brukstilfeller. Hvis du bygger et minnesystem, bruk like mye tid på å prøve å knekke det som du brukte på å bygge det. Spesielt prøv å knekke kjerneantakelsene du ikke visste at du gjorde.

Sikkerheten er ikke din. Når en AI-assistent er svært sikker på en designbeslutning, lever den sikkerheten i modellen, ikke i din forståelse. Et system du ikke forstår dypt er et system du verken kan vedlikeholde eller feilsøke.

Systemdesign er fortsatt en disiplin. Du kan bruke AI til å utforske design raskere, til å implementere deler av systemer fortere, til å prototype ideer som ville tatt uker å bygge manuelt. Men du trenger fremdeles noen som kan evaluere om designet gir mening, om komponentene samvirker korrekt, om kjerneabstraksjonene holder.

Bunnlinjen

Jeg bygger fortsatt minnetoolen min. Den blir bedre, sakte. Jeg har lært å stille andre spørsmål, å teste grundigere, å være mer mistenksom overfor "godt nok"-resultater.

Men jeg har også lært å respektere gapet mellom "koden fungerer" og "systemet er korrekt." Det gapet har alltid eksistert. AI-verktøy har ikke lukket det — de har bare gjort det lettere å ignorere.

De beste sveve-koderne er ikke de med de beste promptferdighetene. De er de som vet når stemningen er feil.

Lyst til å utforske hva som er mulig med AI-assistert hosting og utvikling? NameOcean's Vibe Hosting kombinerer kraftig infrastruktur med verktøyene du trenger for å bygge, deploye og skalere ditt neste prosjekt.