Welke fouten maken ontwikkelaars bij het coderen met AI-assistenten?

AI-assistenten zoals Copilot, Claude en de ingebouwde modellen van Cursor hebben veranderd hoe snel code wordt geschreven. Ze hebben niet veranderd hoe zorgvuldig deze moet worden gereviewd. De meeste schade die ik van AI-ondersteunde codering heb gezien, komt niet van de modellen zelf, maar van een handvol terugkerende gewoonten.

Suggesties accepteren zonder ze te lezen

De grootste is een completion accepteren door tab in te drukken omdat het plausibel lijkt en compileert. Plausibel is niet hetzelfde als correct. Ik heb gezien hoe een voorgestelde SQL-query stilzwijgend een WHERE-clausule verliest bij een refactor, en de persoon accepteerde het omdat de variabelenamen klopten. Als je niet elke regel die een assistent je geeft met dezelfde snelheid leest als een pull request van een collega, ga je iets uitrollen wat je niet begrijpt. Behandel elke suggestie als een eerste concept van een junior-ontwikkelaar die snel is maar geen geheugen voor de conventies van je codebase heeft.

Het vertrouwen voor beveiligingsgevoelige code

AI-assistenten zijn getraind op grote hoeveelheden openbare code, en veel van die code heeft ingebouwde beveiligingsproblemen. Vraag om een snelle file upload handler en je krijgt vaak iets zonder extensiecontrole, geen groottebeperkingen, en een pad gebouwd door string concatenatie in plaats van os.path.join of een veilige library call. Hetzelfde geldt voor auth: assistenten stellen graag voor om JWT's in localStorage op te slaan, of geheimen te vergelijken met == in plaats van een constant-time vergelijking. Dit is niet kwaadwillig, het is gewoon statistisch veel voorkomend in trainingsgegevens. Voor alles wat authentificatie, file I/O, deserialisatie of SQL raakt, schrijf je de logica zelf of voer je de output van de AI uit door dezelfde threat-modeling vragen als je zou doen met nieuwe code: wat gebeurt er met vijandige input, wat gebeurt er als deze aanroep mislukt, wie anders kan dit endpoint bereiken.

Het afhankelijkheden en API's laten verzinnen

Modellen hallucineren pakketnamen en functiehandtekeningen met volledige zekerheid. Dit is het "slopsquatting" probleem — aanvallers registreren de nep-pakketnamen die modellen vaak suggereren, dus een ongecontroleerde pip install of npm install kan iets ophalen wat helemaal niet je logging library is. Controleer voordat je een afhankelijkheid toevoegt die een assistent aanbeveelt, dat deze echt op PyPI of npm bestaat, controleer het downloadaantal en de laatste publicatiedatum, en scan de bron als deze klein genoeg is. Dezelfde voorzichtigheid geldt voor API-aanroepen: als de assistent naar een methode verwijst die je niet herkent, controleer je de werkelijke documentatie voordat je aanneemt dat deze bestaat.

Het mentale model van je eigen code kwijtraken

Wanneer je zelf code schrijft, bouw je een mentale kaart op van waarom elk onderdeel bestaat. Wanneer je grote blokken AI-gegenereerde code accepteert gedurende een sessie, wordt die kaart snel dun. Dan verschijnt drie weken later een bug en debug je code die je nooit echt hebt geschreven en niet volledig onthoud. De oplossing is niet om AI-gegenereerde code te vermijden, het is om langzaam genoeg te gaan zodat je elk onderdeel voor jezelf, of voor een teamgenoot, kunt uitleggen voordat je het samenvoegt. Als je niet kunt uitleggen wat een functie doet en waarom het op die manier doet, voeg het dan nog niet samen.

Tests overslaan omdat de code