AI-kodare och illusionen om kompetens

Förra veckan bevittnade jag en kollega köra npm test på en pull request som hade "levererats" av en AI-kodningsassistent. Testerna misslyckades inte bara – de exploderade spektakulärt. Felmeddelanden som skulle få vilken junior utvecklare som helst att rodna. Inga API-nycklar konfigurerade. Endpoints som returnerade JSON i helt fel format. Autentiserings-middleware som inte autentiserade någonting.

Commit-meddelandet löd: "Implemented user authentication flow 🍕"

Den pizzan hade borde ha varit vår första varningssignal.

Det här är ingen historia om att AI är dåligt. AI-genererad kod har genuint förbättrat mitt arbetsflöde på otaliga sätt. Nej, det här handlar om den farliga illusionen av kompetens – den kusliga dalen av självsäker AI-output som ser så pass polerad ut att ingen tänker på att ifrågasätta den förrän produktionen går ner klockan 02:00.

Ja-sägarproblemet

Här är något ingen pratar om: AI-kodningsassistenter är ultimat ja-sägare. De ifrågasätter inte. De ställer inga klargörande frågor vid 03:00 när du borde ha ställt dem själv. De genererar det du bad om – eller det de tror du bad om – med den ogrundade självsäkerheten hos en konsult på sitt första år.

Din seniora utvecklare som kanske hade sagt "nej, det där är en fruktansvärd idé eftersom..." – den personen existerar inte i din IDE. Det finns bara du, en autocomplete-motor och 10 000 rader kod som "ser rätt ut" tills du faktiskt försöker köra den.

Det är fällan. Minsta motståndets lag leder alltid till att man accepterar AI-förslag. Och precis som med varje muskel du inte tränar, så atrofierar förmågan att utvärdera arkitekturbeslut i tysthet – tills du inser att du har signerat av på dålig kod i månader.

Testningsunderskottet

Här är en siffra som borde oroa varje teknikchef: studier visar att utvecklare spenderar mindre än 20% av sin tid på att faktiskt testa det de bygger. Lägg nu AI-genererad kod ovanpå det, och du har en katastrof inbäddad i din pipeline.

När AI genererar kod gör den det utan att någonsin köra den i din specifika miljö, med ditt specifika databastillstånd, mot dina specifika tredjepartsberoenden. Koden existerar i ett vakuum – tekniskt korrekt, kontextuellt bankrutt.

Lösningen är inte att sluta använda AI. Lösningen är att bli religiös om en enkel regel: slå aldrig ihop kod du inte personligen testat i din lokala miljö.

Ja, det är långsammare. Ja, det känns som att du kämpar mot AI-produktiviteten. Men här är grejen – den 10x ingenjörsproduktivitetsökning alla lovade dig? Den är netto-negativ om du levererar buggar snabbare än du kan fixa dem.

Kunskapsavlastningsklippan

Tänk på AI-assistans som en miniräknare för matematik. Miniräknare gjorde inte människor sämre på matte – de befriade oss från tristess så vi kunde fokusera på högre nivåer. Men om du aldrig lärde dig långdivision, kommer du inte förstå vad miniräknaren faktiskt gör när den ger dig ett svar.

Samma sak gäller mjukvaruutveckling. Om du låter AI sköta de "tråkiga delarna" utan att någonsin förstå vad de gör, kommer du så småningom nå en punkt där du inte kan utvärdera om AI-outputen är korrekt. Du tar maskinens ord för allt – ungefär lika klokt som att låta en bil köra genom ett vägarbete utan att titta på vägen.

Det här handlar inte om att bevara programmering som någon slags hantverksmässig konst för puritaner. Det handlar om att behålla förmågan att fånga katastrofala misstag innan de når användarna.

Hitta balansen

Jag är inte emot AI. På NameOcean använder vår Vibe Hosting-plattform bokstavligen AI för att hjälpa utvecklare leverera snabbare. Verktygen är fantastiska när de används som förstärkare av mänskligt omdöme, inte som ersättningar för det.

Den hälsosamma relationen med AI-kodning ser ut så här:

• Använd AI för att generera boilerplate, stomme och första utkast
• Använd AI för att utforska obekanta API:er och dokumentation
• Aldrig använd AI som substitut för att förstå din egen kodbas
• Alltid testa det AI producerar innan det når produktion
• Behandla AI-förslag som kodgranskningsfeedback – användbar input, inte dogma

Utvecklaren som levererade den otrestade PR:n? De var inte lata eller inkompetenta. De föll i en fälla som hela branschen gräver åt sig själv just nu: frestelsen att välja momentum över kvalitet.

Leverera fort, bryt saker, rör dig snabbt – det är mantrat. Men någonstans på vägen glömde vi att trasiga saker kostar riktiga pengar, riktiga användare och riktigt förtroende att reparera.

Bottensatsen

AI-kodningsassistenter är för modern utveckling det stavningskontroll är för skrivande – användbara verktyg som fångar skrivfel men inte kan berätta om ditt argument håller. Du behöver fortfarande den mänskliga hjärnan för att fråga "borde vi ens bygga den här funktionen?" och "löser det här faktiskt användarens problem?"

De utvecklare som kommer att trivas i denna nya era är inte de som använder mest AI. Det är de som använder AI strategiskt samtidigt som de håller sin grundläggande ingenjörsmässiga fingertoppskänsla skarp. De som fortfarande förstår vad som händer under huven även när de inte vrider varje mutter för hand.

AI är inte problemet. Antagandet att AI gör mänsklig översyn valfri – det är problemet.

Så kör på och vibe-koda dig igenom den där MVP:n. Men innan du trycker på merge, kom ihåg: pizzan i commit-meddelandet kommer inte att vara där när dina användare får ett 500-fel vid midnatt.