Den farlige illusion af AI-kompetence

Forrige uge så jeg en kollega køre npm test på en pull request, der var "leveret" af en AI-kodningsassistent. Test-suiten fejlede ikke bare—den fejlede spektakulært. Fejlmeddelelser, der ville få selv den mest junior udvikler til at rødme. Ingen API keys konfigureret. Endpoints der returnerede JSON i helt forkert format. Authentication middleware der ikke authenticated noget som helst.

Commit-beskeden lød: "Implementeret user authentication flow 🍕"

Den pizza-emoji burde have været vores første advarsel.

Dette er ikke en historie om, at AI er dårlig. AI-kodning har faktisk forbedret min arbejdsgang på utallige måder. Dette er historien om den farlige illusion af kompetence—det uncanny valley af selvsikker AI-output, der ser så poleret ud, at ingen kommer i tanke om at betvivle det, før produktion bryder sammen kl. 2 om natten.

Yes-Man problemet

Her er hvad ingen taler om: AI-kodningsassistenter er de ultimative ja-sigere. De protesterer ikke. De stiller ikke afklarende spørgsmål kl. 3 om natten, når du selv burde have stillet dem. De genererer det, du bad om—eller det, de tror du bad om—med den ufortjente selvtillid fra en førsteårs-konsulent.

Din seniorudvikler, der måske ville have sagt "faktisk er det en forfærdelig idé, fordi..."—den person findes ikke i din IDE. Der er bare dig, en autocomplete-motor og 10.000 linjer kode, der "ser rigtig ud," indtil du faktisk prøver at køre den.

Det er fælden. Mindste modstands vej er altid at acceptere AI-forslag. Og ligesom enhver muskel, du ikke træner, skrumper evnen til at vurdere arkitektoniske beslutninger stille og roligt, indtil du indser, at du har godkendt dårlig kode i månedsvis.

Test-underskuddet

Her er en statistik, der burde give enhver engineering manager sved på panden: Studier tyder på, at udviklere bruger mindre end 20% af deres tid på faktisk at teste det, de bygger. Læg nu AI-genereret kode oven på det, og du har en opskrift på katastrofe.

Når AI genererer kode, gør den det uden nogensinde at køre den i din specifikke miljø, med din specifikke databasetilstand, mod dine specifikke tredjeparts-afhængigheder. Koden eksisterer i et vakuum—teknisk korrekt, kontekstuelt bankerot.

Løsningen er ikke at stoppe med at bruge AI. Løsningen er at blive religiøs om en simpel praksis: flett aldrig kode, du ikke personligt har testet i dit lokale miljø.

Ja, det er langsommere. Ja, det føles som om du kæmper imod AI-produktivitetsgevinsterne. Men her er sagen—den 10x engineer-produktivitetsboost, alle lovede dig? Det er en nettotab, hvis du sender bugs hurtigere afsted, end du kan rette dem.

Cognitive Offloading-kløften

Tænk på AI-assistance som en lommeregner til matematik. Lommeregnere gjorde ikke mennesker dårligere til matematik—de befriede os fra kedeligt arbejde, så vi kunne fokusere på højere niveauer. Men hvis du aldrig har lært lang division, vil du ikke forstå, hvad lommeregneren egentlig laver, når den giver dig et svar.

Det samme gælder softwareudvikling. Hvis du lader AI håndtere de " kedelige dele" uden nogensinde at forstå, hvad de dele gør, når du først har forstået det, ender du med at nå et punkt, hvor du ikke kan vurdere, om AI-outputtet er korrekt. Du tager maskinens ord for alt, og det er lige så klogt som at lade en bil køre sig selv gennem en byggeplads uden at holde øje med vejen.

Dette handler ikke om at bevare programmering som en slags håndværksmæssig kunst for purister. Det handler om at bevare evnen til at fange katastrofale fejl, før de når brugerne.

Find balancen

Jeg er ikke imod AI. Hos NameOcean bruger vores Vibe Hosting-platform faktisk AI til at hjælpe udviklere med at sende hurtigere. Værktøjerne er fantastiske, når de bruges som forstærkere af menneskelig dømmekraft, ikke som erstatninger for den.

Det sunde forhold til AI-kodning ser således ud:

• Brug AI til at generere boilerplate, scaffolding og første udkast
• Brug AI til at udforske nye API'er og dokumentation
• Aldrig brug AI som en erstatning for at forstå din egen kodebase
• Altid test det, AI producerer, før det rører produktion
• Behandl AI-forslag som kode-review-feedback—brugbar input, ikke evangelium

Udvikleren, der sendte den utestede PR? De var hverken dovne eller inkompetente. De faldt i en fælde, som hele industrien lige nu graver for sig selv: forførelsen af momentum over kvalitet.

Ship fast, break things, move quick—det er mantraet. Men et sted undervejs glemte vi, at ødelagte ting koster rigtige penge, rigtige brugere og rigtig tillid at reparere.

Konklusionen

AI-kodningsassistenter er til moderne udvikling, hvad stavekontrol er til skrivning—nyttige værktøjer, der fanger stavefejl, men ikke kan fortælle dig, om dit argument giver mening. Du har stadig brug for den menneskelige hjerne til at spørge "skal vi overhovedet bygge denne funktion?" og "løser dette faktisk brugerens problem?"

De udviklere, der vil trives i denne nye æra, er ikke dem, der bruger mest AI. De er dem, der bruger AI strategisk, mens de holder deres grundlæggende ingeniør-dømmekraft skarp. De er dem, der stadig forstår, hvad der sker under motorhjelmen, selv når de ikke drejer hver en bolt i hånden.

AI er ikke problemet. Antagelsen om, at AI gør menneskeligt tilsyn valgfrit—det er problemet.

Så brug endelig alle de AI-værktøjer du har til rådighed til at bygge dit MVP. Men før du trykker på merge, så husk: pizza-emojien i commit-beskeden vil ikke være der, når dine brugere får en 500-fejl ved midnat.