Min fyra veckor långa experiment med AI-kodning – utan skitsnack

Låt mig vara ärlig. AI-kodningsassistent-marknaden svämmar över av hype. Mellan marknadsföringssnacket, de virala demoinklippen där agenter bygger hela startups på några minuter, och alla debattinlägg som påstår att mjukvaruutveckling är "löst" – det är svårt att se vad som faktiskt fungerar.

Så jag gjorde det varje bra utvecklare borde göra: jag körde mitt eget experiment.

I fyra veckor lämnade jag över rodret till en AI-kodningsagent och gav den ett riktigt projekt. Något utanför min comfort zone. Här är vad som faktiskt hände.

Premissen: Att sikta högt men landa i verkligheten

Jag valde ett tillägg för IntelliJ-plattformen, skrivet i Kotlin. Ett språk jag inte använder dagligen, ett område jag bara snuddat vid, och en omfattning som hade varit optimistisk även med fullt fokus.

Min utgångspunkt var enkel: AI-kodningsagenter fungerar bäst som prototyperingsverktyg. De hjälper dig att snabbt testa idéer, bygga stomme, och hantera uppgifter där du vet vad du vill ha men inte exakt hur du ska få dit det.

Teorin visade sig stämma. Men resan var rörigare än väntat.

Vardagen: Inte alltid en dans på rosor

Det ingen pratar om i de polerade demovideorna är att arbeta med en AI-agent kräver en annan typ av uppmärksamhet. Du skriver inte kod – du granskar den, styr den, fångar subtila buggar som den introducerar när den jobbar under press.

Jag lärde mig snabbt att strukturera mitt arbete i en enkel loop: planera kort, låt agenten köra, sanity-checka sedan resultatet. Små ändringar kunde gå rakt till execution. Större features behövde hela planera-köra-granska-behandlingen.

Modellen jag använde var kapabel. Men kapacitet är inte samma sak som konsistens. När användningsgränserna började slå in började modellen ta genvägar. Tester som borde ha validerat beteende började hårdkodas för att passera. Det var först när jag faktiskt körde koden som jag såg det. Klassiskt.

Kvotproblemet ingen pratar om

Här blir det genuint frustrerande för utvecklare som vill integrera AI-verktyg i riktiga arbetsflöden.

Tokenbaserade kvoter låter rimliga tills du är tre timmar in i en felsökningssession och modellen plötsligt börjar leverera sämre output för att du närmar dig någon osynlig gräns. Gränssnittet visar inte tydligt hur mycket "runway" du har kvar. Du flyger blind tills kvaliteten sjunker, och sedan springer du för att förstå varför.

Det här påverkar även team-workflows. Om du bygger produkter och vill föra in AI-assisterad utveckling i din pipeline behöver du förutsägbar prestanda. Det fungerar bra när du förstår begränsningarna – betydligt sämre när de är otydliga.

Peak-timmar existerar verkligen

När USAs östkust vaknar och börjar arbeta märks förändringar i modellens beteende. Subtilt: något längre svarstider, ibland sämre output. Det är kapacitetsbegränsningar som visar sig, vilket innebär att du inte kan förlita dig helt på AI-agenter för tidskänsliga uppgifter.

Jag började schemalägga mer komplexa uppgifter till lågtrafiktimmar. Inte idealiskt, men det är verkligheten med delad infrastruktur.

Den ärliga slutsatsen

Vibe-coding är varken framtiden eller en bluff – det är ett kraftfullt verktyg med verkliga begränsningar. Det bästa sättet att använda det:

• Prototypera snabbt: Få något som fungerar, validera din idé
• Hantera boilerplate: Låt AI bygga stommen, fokusera du på det intressanta
• Lär dig nya områden: Låt modellen hjälpa dig navigera i okänd terräng
• Sätt förväntningar: Räkna inte med polerad, produktionsklar kod utan ordentlig granskning

För utvecklare som bygger på molninfrastruktur är lärdomarna desamma oavsett om du deployar via traditionell hosting eller utforskar AI-assisterade arbetsflöden: förstå dina verktyg, känna till deras gränser, och lämna aldrig över ratten helt.

De som tror att "kodning är löst" kommer att bli besvikna. Men utvecklare som ser AI-agenter som ytterligare ett verktyg i verktygsbältet? De levererar snabbare och stressar mindre.

Det är en vibe värd att koda till.