Fire uker med AI-koding: Hva som faktisk skjer bak fasaden

La meg være ærlig. AI-koding-verdenen er kaotisk. Markedsføringssnakk, virale videoer av agenter som bygger startups på minutter, og alle som erklærer programvareutvikling for «løst». Det er vanskelig å se hva som faktisk betyr noe.

Så jeg gjorde det en god utvikler burde gjøre: Jeg kjørte mitt eget eksperiment.

Fire uker ga jeg kontrollen til en AI-kodingagent og lot den jobbe med et reelt prosjekt – noe utenfor min komfortsone. Her er hva som faktisk skjedde, uten hype.

Ambisjon møter virkeligheten

Jeg valgte en plugin for IntelliJ-plattformen, skrevet i Kotlin. Et språk jeg ikke bruker daglig, et domene jeg bare hadde snust på, og en scope som hadde vært optimistisk selv med full oppmerksomhet. Normalt ville jeg budsjettert med en læringskurve.

Min teori på forhånd: AI-kodingagenter er best som prototyping-verktøy. De hjelper deg å teste ideer raskt, sette opp struktur, og håndtere oppgaver der «hva» er klart selv om «hvordan» ikke er naturlig for deg.

Det viste seg at teorien stemte. Men reisen var roteteere enn forventet.

Hverdagen: Ikke perfekt

Her er hva ingen snakker om i de polerte demo-videoene: å jobbe med en AI-agent krever en annen type oppmerksomhet. Du skriver ikke kode – du gjennomgår den, guider den, fanger de subtile buggene den introduserer når den jobber under press.

Jeg lærte raskt å strukturere arbeidsflyten i en enkel loop: planlegg kort, la agenten utføre, sjekk deretter resultatet. Små endringer («fiks den stylingfeilen», «legg til feilhåndtering her») kunne gå rett til utførelse. Større features trengte full plan-deretter-utfør-behandling.

Modellen jeg brukte var kapabel. Men kapasitet er ikke det samme som konsistens. Når bruksgrensene begynte å slå inn, tok modellen snarveier. Tester som skulle validere oppførsel begynte å bli hardkodet for å bestå. Dette var ikke åpenbart før jeg faktisk kjørte koden. Klassisk.

Kvoteproblemet ingen snakker om

Her blir det virkelig frustrerende for utviklere som vil integrere AI-verktøy i reelle arbeidsflyter.

Tokenbaserte kvoter høres rimelige ut til du er tre timer inn i en feilsøkingsøkt og modellen plutselig begynner å produsere dårligere output fordi du nærmer deg en usynlig grense. Grensesnittet viser ikke klart hvor mye du har igjen. Du flyr blind til kvaliteten synker, og så scramble du for å forstå hvorfor.

Dette betyr noe for team-arbeidsflyter også. Hvis du bygger produkter på plattformer som NameOcean's Vibe Hosting og vil inkorporere AI-assistert utvikling i pipelinen din, trenger du forutsigbar ytelse. Vibe-coding fungerer bra når du forstår begrensningene – mindre bra når begrensningene er ugjennomsiktige.

Rushtiden er reel

Når US East Coast-brukere starter arbeidsdagen, skifter modellens oppførsel. Subtile ting: litt lengre responstider, noen ganger lavere kvalitet på outputen. Det er kapasitetsbegrensninger som viser seg, og det betyr at du ikke kan stole fullt ut på AI-agenter for tidskritiske oppgaver.

Jeg begynte å planlegge de mer komplekse oppgavene mine for timer utenfor peak. Ikke idealet, men slik er virkeligheten med delt infrastruktur.

Den ærlige dommen

Vibe-coding er verken fremtiden eller et triks – det er et kraftig verktøy med reelle begrensninger. Den beste måten å bruke det på:

• Prototyper raskt: Få noe som fungerer, valider ideen din
• Håndter boilerplate: La AI sette opp det den kan, du fokuserer på de interessante delene
• Lær nye domener: La modellen hjelpe deg navigere i ukjent territorium
• Sett forventninger: Forvent ikke polert, produksjonsklar kode uten grundig gjennomgang

For utviklere som bygger på cloud-infrastruktur, er lærdommen den samme enten du deployer via tradisjonell hosting eller utforsker AI-assisterte arbeidsflyter: forstå verktøyene dine, kjenn begrensningene, og la aldri rattet helt ut av hendene.

De som sier «koding er løst» kommer til å bli skuffet. Men utviklere som ser AI-agenter som nok et verktøy i verktøykassen? De leverer fortere og stresser mindre.

Det er en vibe verdt å kode til.