Waarom AI je Collega's Beste Vriend Wordt (en Dat Een Probleem Is)

Vorige week keek ik toe hoe een collega npm test draaide op een pull request die "klaar" was gemaakt door een AI coding assistant. De test suite faalde niet zomaar—het was een complete ramp. Error messages waar elke junior developer van zou blozen. Geen API keys geconfigureerd. Endpoints die JSON terugstuurden in het compleet verkeerde formaat. Authentication middleware die helemaal niets authenticate.

De commit message? "Implemented user authentication flow 🍕"

Die pizza emoji had onze eerste waarschuwing moeten zijn.

Dit is geen verhaal over hoe slecht AI is. AI code generation heeft mijn workflow op talloze manieren verbeterd. Dit is een verhaal over de gevaarlijke illusie van competentie—die uncanny valley van zelfverzekerde AI output die er zo gepolijst uitziet dat niemand het in twijfel trekt tot productie om 2 uur 's nachts offline gaat.

Het Ja-Zegger Probleem

Hier is iets waar niemand het over heeft: AI coding assistants zijn de ultieme ja-zeggers. Ze duwen niet terug. Ze stellen geen verduidelijkende vragen om 3 uur 's nachts terwijl je die vragen zelf had moeten stellen. Ze genereren wat je vroeg, of wat ze denken dat je vroeg, met het onverdiende zelfvertrouwen van een junior consultant.

Die senior developer die had kunnen zeggen "eigenlijk is dat een vreselijk idee omdat..."—die persoon bestaat niet in je IDE. Er is alleen jij, een autocomplete engine, en 10.000 regels code die "er goed uitzien" totdat je het daadwerkelijk draait.

Dit is de val. De weg van de minste weerstand is altijd AI suggesties accepteren. En zoals elke spier die je niet traint, verdwijnt het vermogen om architectuurbeslissingen te evalueren stilletjes totdat je doorhebt dat je maandenlang slechte code hebt goedgekeurd.

Het Test Tekort

Hier is een statistiek die elke engineering manager zorgen zou moeten baren: studies suggereren dat developers minder dan 20% van hun tijd daadwerkelijk besteden aan het testen van wat ze bouwen. Leg daar nu AI-gegenereerde code bovenop, en je hebt een recept voor rampen.

Wanneer AI code genereert, doet het dat zonder ooit te draaien in jouw specifieke omgeving, met jouw specifieke database state, tegen jouw specifieke third-party dependencies. De code bestaat in een vacuüm—technisch correct, contextueel bankroet.

De oplossing is niet om te stoppen met AI. De oplossing is om religieus te worden over een simpele gewoonte: nooit code mergen die je niet persoonlijk hebt getest in je lokale omgeving.

Ja, het is langzamer. Ja, het voelt als vechten tegen de AI productiviteitswinst. Maar hier is het punt—die 10x engineer productiviteitsboost die iedereen heeft beloofd? Het is een netto negatief als je bugs sneller shipped dan je ze kunt fixen.

De Cognitieve Offloading Afgrond

Denk aan AI assistance zoals een rekenmachine voor wiskunde. Rekenmachines hebben mensen niet slechter gemaakt in wiskunde—ze bevrijdden ons van saai werk zodat we ons konden focussen op hogere concepten. Maar als je nooit staartdelingen hebt geleerd, begrijp je niet wat de rekenmachine eigenlijk doet wanneer het je een antwoord geeft.

Hetzelfde geldt voor software development. Als je AI de "saaie delen" laat afhandelen zonder ooit te begrijpen wat die delen doen, bereik je uiteindelijk een punt waarop je niet kunt evalueren of de AI output correct is. Je neemt het woord van de machine voor alles, wat zo wijs is als een auto door een bouwput laten rijden zonder de weg in de gaten te houden.

Dit gaat niet over programming als een ambachtelijke craft voor puristen. Het gaat over het behouden van het vermogen om catastrofale fouten te vangen voordat ze gebruikers bereiken.

De Balans Vinden

Ik ben niet anti-AI. Bij NameOcean gebruiken we op ons Vibe Hosting platform letterlijk AI om developers sneller te laten shippen. De tools zijn ongelooflijk wanneer ze worden gebruikt als versterkers van menselijk oordeel, niet als vervanging ervan.

De gezonde relatie met AI coding ziet er zo uit:

• Gebruik AI om boilerplate, scaffolding en eerste drafts te genereren
• Gebruik AI om onbekende APIs en documentatie te verkennen
• Nooit AI gebruiken als substituut voor het begrijpen van je eigen codebase
• Altijd testen wat AI produceert voordat het productie raakt
• Behandel AI suggesties zoals code review feedback—bruikbare input, geen evangelie

Die developer die die niet-geteste PR shipde? Die was niet lui of incompetent. Die trapte in een val die de hele industrie zichzelf op dit moment graaft: de verleiding van momentum boven kwaliteit.

Ship fast, break things, move quick—dat is het devies. Maar ergens onderweg zijn we vergeten dat kapotte dingen echte geld, echte gebruikers en echt vertrouwen kosten om te repareren.

De Conclusie

AI coding assistants zijn voor moderne development wat spell-check is voor schrijven—bruikbare tools die spelfouten vangen maar niet kunnen zeggen of je argument klopt. Je hebt nog steeds dat menselijke brein nodig om te vragen "moeten we dit feature uberhaupt wel bouwen?" en "lost dit daadwerkelijk het probleem van de gebruiker op?"

De developers die zullen floreren in dit nieuwe tijdperk zijn niet degene die de meeste AI gebruiken. Het zijn degenen die AI strategisch gebruiken terwijl ze hun fundamentele engineering oordeel scherp houden. Ze begrijpen nog steeds wat er onder de motorkap gebeurt, ook al draaien ze niet meer elke bout met de hand.

De AI is niet het probleem. De aanname dat AI menselijk toezicht optioneel maakt—dat is het probleem.

Dus ga vooral vibe-code'n door dat MVP. Maar voordat je op merge drukt, onthoud: die pizza emoji in de commit message zal er niet staan wanneer je gebruikers om middernacht een 500 error krijgen.