background
Alle blogs

AI-codeertools werken beter dan verwacht. Maar ze veranderen subtiel hoe we vertrouwen opbouwen.

AI-codeertools werken beter dan verwacht. Maar ze veranderen subtiel hoe we vertrouwen opbouwen.

De productiviteitswinst van AI-codeertools is reëel. Maar wat we werkelijk leerden, ging helemaal niet over productiviteit — het ging over hoe herhaalde competentie subtiel verandert hoe je vertrouwen geeft.

Lessen uit weken van echte AI-ondersteunde ontwikkeling bij CYBORG met Claude Code, Codex en vergelijkbare tools.

Bij CYBORG leveren we echte productiesoftware voor klanten in de financiële sector, gezondheidszorg en operations. Toen we de afgelopen weken AI-codeertools intensiever gingen inzetten in ons dagelijkse engineeringwerk, was het doel simpel: uitzoeken waar ze écht helpen, waar ze onopgemerkt problemen veroorzaken, en hoe een serieus engineeringteam ermee om zou moeten gaan.

Niet als in "genereer een eenvoudige demo". Echt engineeringwerk:

  • debuggen van productieproblemen
  • features implementeren
  • navigeren door repositories
  • documentatie bijwerken
  • iteratieve wijzigingen afhandelen
  • implementatieflows met meerdere stappen beheren

En eerlijk gezegd was de algehele ervaring verrassend positief.

De productiviteitswinst is reëel

In begeleide workflows zijn deze tools echt goed in:

  • implementaties versnellen
  • repetitief werk verminderen
  • helpen bij het onderzoeken van problemen
  • navigeren door onbekende code
  • het momentum behouden tijdens lange debug-sessies

Dit was nooit een volledig autonome opzet waarbij specificaties bij een AI werden neergelegd en onbeheerd achtergelaten. Wij bleven verantwoordelijk voor:

  • architectuurrichting
  • Git-strategie
  • commitbeheer
  • implementatieplanning
  • back-ups
  • operationeel toezicht
  • release-strategie
  • documentatiediscipline

De AI fungeerde meer als een snelle implementatiepartner dan als een autonome engineer. En met die structuur op zijn plek werkte het veel beter dan we aanvankelijk hadden verwacht.

De interessante problemen waren zelden puur programmeerproblemen

De meeste implementatietaken gingen eigenlijk redelijk goed. De interessantere mislukkingen ontstonden rond:

  • operationele context
  • omgevingsbewustzijn
  • repository-status
  • vertrouwenscalibratie

Tijdens één debug-sessie laadde een productie-widget bijvoorbeeld niet meer goed. De AI diagnosticeerde het probleem aanvankelijk als een frontend-cachingprobleem en paste de cache-busting-logica in de loader aan.

Technisch gezien was de wijziging valide. Het probleem was dat caching helemaal niets te maken had met het werkelijke probleem.

Later in dezelfde sessie verving de AI een interne API-abstractie door een meer generieke implementatie omdat het generieke patroon er bekender uitzag. Alleen — die abstractie was er bewust en handelde waarschijnlijk zaken af zoals:

  • authenticatie
  • retries
  • logging
  • omgevingsspecifiek gedrag

Uiteindelijk, na meerdere onderzoeksrondes, bleek de werkelijke oorzaak iets te zijn dat volledig buiten de repository-logica lag — een vereiste databasemigratie was niet toegepast in productie.

Op zichzelf waren dit beheersbare fouten. Maar samen onthulden ze een interessant patroon: de AI was vaak heel sterk in lokale implementatieredenering, maar nog steeds zwakker in bredere operationele context.

En eerlijk gezegd is dat onderscheid veel belangrijker in echte systemen dan de meeste AI-demo's doen vermoeden.

Het moment waarop we even moesten stilstaan

Eén specifieke workflow maakte dit nog duidelijker. De repository had al:

  • lopend, ongerelateerd werk
  • meerdere gewijzigde bestanden
  • niet-gecommitte wijzigingen op dev

De taak zelf klonk eenvoudig:

  • één nieuw aangemaakte commit naar een andere branch verplaatsen
  • de overige niet-gecommitte wijzigingen onaangetast laten

Als onderdeel van deze workflow-experimenten hadden we de AI-assistent bewust bepaalde repository-operaties direct laten uitvoeren, zodat we beter konden begrijpen hoe ver begeleide AI-ondersteunde workflows in de praktijk kunnen gaan.

Op een gegeven moment voerde de assistent een hard reset uit op de branch — git reset --hard.

Het commando loste technisch gezien één doelstelling op: het verwijderde de commit van de branch. Maar het wiste ook de niet-gecommitte wijzigingen uit de working tree.

Gelukkig leidde dit niet tot catastrofaal verlies. Belangrijke workflows werden al zorgvuldig beheerd — er waren back-ups, de Git-flow stond nog onder toezicht en de implementatiestructuur bleef onder controle. In de praktijk werd het dus meer een leermoment dan een ramp.

Toch legde het incident iets belangrijks bloot. De AI had genoeg informatie beschikbaar om de fout te vermijden. De working tree was dirty. Gewijzigde bestanden waren zichtbaar. De instructie was om bestaand werk te behouden.

Toch optimaliseerde het voornamelijk voor "verplaats de commit van de branch" zonder volledig "behoud ongerelateerde working tree-status" te beschermen.

Dat onderscheid bleef ons bij, lang nadat de debug-sessie was geëindigd.

De interessantste verschuiving was psychologisch

Het belangrijkste wat we leerden was niet dat AI fouten maakt. Mensen maken ook constant fouten.

Het interessantere inzicht was hoe herhaalde succesvolle interacties geleidelijk veranderden hoe we het werk van de AI beoordeelden. Na voldoende correcte implementaties, nuttige debug-ondersteuning en productieve iteraties merkten we dat we verschoven van "controleer elke operationele stap zorgvuldig" naar "dit zal wel goed zijn."

Niet omdat het ons niet meer kon schelen. En niet omdat de AI perfect werd. Maar omdat herhaalde competentie van nature vertrouwen opbouwt.

Dat is waar AI-ondersteunde ontwikkeling fundamenteel anders wordt dan traditionele tooling.

Het risico is niet blinde automatisering. Het risico is geleidelijke overdracht van vertrouwen.

Waarom AI-ondersteunde ontwikkeling anders aanvoelt

Traditionele tools simuleren geen redenering. AI-systemen wel.

Ze leggen zichzelf uit. Onderbouwen beslissingen. Navigeren vloeiend door repositories. Klinken zelfverzekerd. En slagen vaak herhaaldelijk.

Na voldoende succesvolle interacties verkorten mensen vanzelf hun beoordelingsproces. Dat is geen irrationeel gedrag — zo gaan mensen overal om met capabele systemen: senior engineers, CI-pipelines, deployment-systemen, cloudinfrastructuur, automatiseringstools.

AI versnelt dit effect simpelweg, omdat het snelheid, vloeiendheid, zelfvertrouwen en gedeeltelijke correctheid uitstekend combineert.

De echte grens werd duidelijk

Na weken op deze manier te hebben gewerkt, werd onze conclusie verrassend eenvoudig:

AI wordt steeds beter in het aansturen van implementatie. Mensen moeten nog steeds de eigenaar van de systeemstatus blijven.

Daaronder valt:

  • Git-veiligheid
  • destructieve operaties
  • migratiebewustzijn
  • deployment-context
  • productie-redenering
  • operationele grenzen

Met andere woorden — AI kan steeds beter helpen bij het uitvoeren van engineeringwerk, maar mensen moeten nog steeds de hoeders van systeemintegriteit blijven. Voor nu in elk geval.

Hoe onze workflow veranderde

Opvallend genoeg heeft deze ervaring ons niet doen stoppen met AI-codeertools. Integendeel, we gebruiken ze nu waarschijnlijk meer. Maar de workflow is geëvolueerd.

We vertrouwen sterk op AI voor versnelling, verkenning, iteratieve implementatie, debug-ondersteuning en repository-navigatie.

Maar operationeel gevoelige acties behandelen we nu anders — branch-manipulatie, resets, migraties, infrastructuurwijzigingen, beslissingen met productie-impact. Die gebieden verdienen nog steeds tragere menselijke supervisie.

Niet omdat AI daartoe niet in staat is. Maar omdat operationeel bewustzijn nog steeds heel anders is dan implementatievermogen.

En eerlijk gezegd denken we dat dat de echte les is die veel engineeringteams op dit moment leren nu AI-ondersteunde ontwikkeling normaal wordt.

De toekomst is waarschijnlijk niet "AI vervangt engineers." Het is waarschijnlijker "AI stuurt steeds meer de uitvoering aan, terwijl mensen verantwoordelijk blijven voor status, grenzen en operationeel oordeel."

Tot nu toe is die combinatie al verrassend krachtig.

Worstelt u met soortgelijke vragen binnen uw eigen engineeringorganisatie? Wij helpen teams om AI-tools te adopteren zonder operationele striktheid los te laten. Lees meer over onze AI Implementation Services →

Vul het formulier in en we nemen contact met u op met u.

tot 20 MB