Eerst gebruikten ze ChatGPT om kosten te besparen. Toen huurden ze ons in om de technische schuld van AI op te ruimen.

5 aug 2025 10 min lezen

Artikel samenvatten met AI

Het zal je verbazen hoeveel bedrijven dit nu doen.

Zoals rapporten uit de hele industrie aangeven, is er nu een groeiende gespecialiseerde sector voor ingenieurs die zich richten op het corrigeren van AI gegenereerde codefouten.

Het patroon is opvallend consistent geworden. Bedrijven wenden zich tot ChatGPT om migratiescripts, integraties of volledige functies te genereren, in de hoop tijd te besparen en kosten te besparen. De technologie lijkt immers snel en toegankelijk.

Dan falen de systemen.

En ze bellen ons.

De laatste tijd krijgen we steeds meer van dit soort verzoeken. Niet om een nieuw product te leveren, maar om de rommel te ontwarren die achterbleef nadat iemand een taalmodel vertrouwde met zijn productiecode.

Op dit moment begint het op een eigen niche-industrie te lijken. Het repareren van door AI gegenereerde bugs is nu een declarabele service. En in sommige gevallen een hele dure.

GitClear's 2024 rapport bevestigt wat we bij klanten hebben gezien: AI codeertools versnellen de levering, maar voeden ook dubbel werk, verminderen hergebruik en drijven de onderhoudskosten op lange termijn op.

In één geval kwam een klant naar ons toe nadat een door AI gegenereerde migratie kritieke klantgegevens had laten vallen. We spendeerden 30 uur herstellen wat verloren is gegaan, de logica vanaf nul herschrijven en de pijplijn opschonen. Het ironische is dat het goedkoper zou zijn geweest om een senior ontwikkelaar het op de ouderwetse manier te laten schrijven.

Maar laten we duidelijk zijn, we zijn niet "tegen AI". Wij gebruiken het ook. En het is nuttig in de juiste context, met de juiste voorzorgsmaatregelen. Maar wat mij frustreert aan het overdreven vertrouwen op AI en de wijdverspreide implicaties ervan - en waarschijnlijk jou ook - is het magische denken. Het idee dat een taalmodel het echte ingenieurswerk kan vervangen.

Dat kan niet. En zoals het gezegde luidt: the proof is in the pudding. Als bedrijven het tegendeel beweren, betalen ze uiteindelijk iemand zoals wij om het op te ruimen.

Hoe ziet zo'n opruimklus eruit? Dit is wat de AI-afficionados je niet vertellen als het gaat om verloren tijd en geldverspilling.

Hoe een typische aanvraag eruit ziet

De boodschap komt meestal als volgt binnen:

"Hé, kun je eens kijken naar een microservice die we hebben gebouwd? We hebben ChatGPT gebruikt om de eerste versie te genereren. We hebben het naar staging gepushed en nu is onze RabbitMQ wachtrij helemaal overspoeld."

Het begint altijd klein. Een taak die te saai of tijdrovend leek. Iets als het parsen van een CSV, het herschrijven van een cron job of het aansluiten van een eenvoudige webhook. Dus geven ze het door aan een taalmodel en hopen er het beste van.

Maar het zit zo: de symptomen komen pas veel later. Soms dagen later. En als ze dat doen, is het zelden duidelijk dat de hoofdoorzaak AI gegenereerde code was. Het lijkt er gewoon op... dat er iets niet klopt.

"Je kunt architecturaal denken niet uitbesteden aan een taalmodel. AI kan dingen versnellen, maar er zijn nog steeds ingenieurs nodig om systemen te bouwen die niet uit elkaar vallen onder druk."

Dmitry Nazarevich

Technisch directeur

Na een dozijn van deze gevallen beginnen zich patronen af te tekenen:

Geen testen. Helemaal niet. Niet eens een hello-world assert. Gewoon ruwe, speculatieve code die nooit goed is geoefend.
Geen besef van systeemgrenzen. We hebben ChatGPT-scripts gezien die drie microservices synchroon bevragen, timeouts negeren en de hele gespreksketen opblazen bij de eerste mislukking.
Misbruik van transacties. Eén klant gebruikte AI gegenereerde SQL met geneste transacties binnen een Node.js service met Knex. Het werkte, totdat het niet meer werkte en de helft van de schrijfacties stilzwijgend mislukten.
Subtiele raceomstandigheden. Vooral in codebases met meerdere threads of async. Het soort bugs dat niet opduikt in ontwikkeling, maar productie op schaal verwoest.

En natuurlijk, als alles instort, laat de AI geen commentaar achter waarin staat: "Trouwens, ik gok hier."

Dat deel is voor jou.

Geval 1: Het migratiescript dat stilletjes klantgegevens liet vallen

Deze kwam van een snelgroeiend fintechbedrijf.

Ze waren bezig met het uitrollen van een nieuwe versie van hun klantgegevensmodel, waarbij één groot JSONB-veld in Postgres werd opgesplitst in meerdere genormaliseerde tabellen. Vrij standaard werk. Maar met krappe deadlines en te weinig handen, besloot een van de ontwikkelaars om "de zaken te versnellen" door ChatGPT te vragen een migratiescript te genereren.

Aan de oppervlakte zag het er goed uit. Het script parste de JSON, haalde de contactinformatie eruit en voegde deze in een nieuwe user_contacts tafel.

Dus ze voerden het uit.

Geen generale repetitie. Geen back-up. Rechtstreeks naar de staging, die, zo bleek, gegevens deelde met de productie via een replica.

Een paar uur later kreeg de klantenservice e-mails. Gebruikers ontvingen geen betalingsmeldingen. Anderen hadden ontbrekende telefoonnummers in hun profiel. Toen hebben ze ons gebeld.

Wat ging er mis?

We hebben het probleem getraceerd naar het script. Het deed de basisextractie, maar het maakte drie fatale aannames:

Het kon niet omgaan met NULL waarden of ontbrekende sleutels in de JSON-structuur.
Het voegde gedeeltelijke records in zonder validatie.
Het gebruikte ON CONFLICT DO NOTHING, dus alle mislukte invoegingen werden stilzwijgend genegeerd.

Resultaat: over 18% van de contactgegevens was verloren gegaan of beschadigd. Geen logboeken. Geen foutmeldingen. Gewoon stil gegevensverlies.

Wat er nodig was om te repareren

We stelden een klein team samen om de rommel te ontwarren. Dit is wat we deden:

Diagnose en replicatie (4 uur) We hebben het script opnieuw gemaakt in een sandboxomgeving en het uitgevoerd tegen een snapshot van de database. Zo bevestigden we het probleem en brachten we precies in kaart wat er ontbrak.
Forensische gegevenscontrole (8 uur) We vergeleken de kapotte staat met back-ups, identificeerden alle records met ontbrekende of gedeeltelijke gegevens en vergeleken ze met gebeurtenislogboeken om te achterhalen welke invoegingen mislukten en waarom.
De migratielogica herschrijven (12 uur) We herschreven het hele script in Python, voegden volledige validatielogica toe, bouwden een rollbackmechanisme en integreerden het in de CI-pijplijn van de klant. Deze keer bevatte het tests en ondersteuning voor dry-run.
Handmatig gegevensherstel (6 uur) Sommige records waren niet terug te halen uit back-ups. We haalden de ontbrekende velden uit externe systemen (hun CRM en e-mail API's) en herstelden de rest handmatig.

Totale tijd: 30 technische uren

Twee ingenieurs, drie dagen. Kosten voor de klant: ongeveer $4,500 aan servicekosten.

Maar de grootste klap kwam van de gevolgen voor klanten. Mislukte meldingen leidden tot gemiste betalingen en churn. De klant vertelde ons dat ze minstens $10,000 aan supporttickets, SLA-compensatie en goodwillcredits voor dat ene mislukte script.

Het ironische is dat een senior ontwikkelaar de juiste migratie in misschien vier uur had kunnen schrijven. Maar de belofte van AI snelheid kostte hen uiteindelijk twee weken schoonmaakwerk en reputatieschade.

Wij repareren wat ChatGPT kapot maakte - en bouwen wat het niet kon.

Geval 2: De API-client die de snelheidslimieten negeerde en de productie verstoorde

Deze kwam van een startup die een platform voor documentbeheer voor advocatenkantoren bouwt. Een van hun belangrijkste functies was de integratie met een e-notificatiedienst van de overheid - een REST API van een derde partij met OAuth 2.0 en strikte beperking van de snelheid: 50 verzoeken per minuut, geen uitzonderingen.

In plaats van de integratie toe te wijzen aan een ervaren backend ontwikkelaar, besloot iemand in het team het te "prototypen" met behulp van ChatGPT. Ze lieten de OpenAPI spec vallen, vroegen om een Python client en kregen een schoon uitziend script met requests, logica voor opnieuw proberen met tenacity, en token verversen.

Zag er goed uit op papier. Dus verscheepten ze het.

Wat ging er mis?

In het begin leek alles in orde. De client behandelde individuele verzoeken correct, doorstond de authenticatie en probeerde zelfs opnieuw bij mislukking. Maar tijdens echt gebruik, vooral onder belasting, begon het platform zich onvoorspelbaar te gedragen.

Dit is wat er echt is gebeurd:

Geen respect voor tariefgrenzen. De gegenereerde code las of interpreteerde X-RateLimit-Remaining of Retry-After headers. Het bleef maar blindelings verzoeken sturen.
Opnieuw proberen maakte het alleen maar erger. Toen er 429 fouten terugkwamen, probeerde de tenacity decorator ze automatisch opnieuw. Geen jitter. Geen wachtrij. Alleen een stortvloed aan vervolgverzoeken.
De API-provider heeft hun IP-adres tijdelijk geblokkeerd. 3 uur lang kon niemand op het platform documenten synchroniseren. Geen logs, geen waarschuwingen. Gewoon een stille storing.

Dit was geen eenregelige oplossing. Het was een misverstand over hoe productiesystemen zich gedragen. En het is een geweldig voorbeeld van wat LLM's niet weten; niet omdat ze kapot zijn, maar omdat ze zich niet bewust zijn van runtime.

Stop met het patchen van AI gegenereerde code in prod - breng ons op de hoogte voordat het breekt.

Hoe we het hebben opgelost

De storing opsporen en isoleren (6 uur) We voegden middleware toe om uitgaand verkeer te inspecteren en bevestigden de stortvloed aan verzoeken tijdens piekgebruik. We hebben de storing ook opnieuw gemaakt in staging om het patroon dat de storing veroorzaakt volledig te begrijpen.
Herbouw de API-client (10 uur) We hebben de client herschreven met httpx.AsyncClient, een op semaforen gebaseerde throttle geïmplementeerd, exponentiële backoff met jitter toegevoegd en op de juiste manier omgegaan met Retry-After en rate-limit headers.
Stresstest en validatie (6 uur) We simuleerden echt gebruik met duizenden gelijktijdige verzoeken met Locust, testten het beperken van de snelheid onder verschillende burst-scenario's en bevestigden nul 429s onder langdurige belasting.
Monitoring en waarschuwingen toevoegen (4 uur) We stelden aangepaste Prometheus statistieken in om het API-gebruik per minuut bij te houden en we voegden waarschuwingen toe om het team op de hoogte te stellen als ze in de buurt kwamen van drempelwaarden.

Totale tijd: 26 uur

Twee ingenieurs, verspreid over tweeënhalve dag. Kosten voor de klant: ongeveer $3,900.

Het grotere probleem is dat hun grootste klant - een advocatenkantoor met tijdgevoelige dossiers - twee indieningstermijnen miste door de storing. De klant moest de schade beperken en een korting aanbieden om de klant te behouden.

En dat allemaal omdat een taalmodel het verschil tussen "werkende code" en "productieklare code" niet begreep. En zo werd er stilletjes nog een laag AI technische schuld aan de stapel toegevoegd.

Waarom dit blijft gebeuren

Het enge is niet dat deze dingen fout gaan. Het is hoe voorspelbaar het allemaal wordt.

Elk van deze incidenten volgt hetzelfde patroon. Een ontwikkelaar vraagt ChatGPT om een codefragment. Er wordt iets teruggestuurd dat net goed genoeg werkt om geen fouten te veroorzaken. Ze sluiten het aan op het systeem, maken het misschien een beetje schoon en verzenden het, ervan uitgaande dat als het compileert en draait, het wel veilig moet zijn.

Maar hier zit het addertje onder het gras: Grote taalmodellen kennen jouw systeem niet.
Ze weten niet hoe jullie diensten op elkaar inwerken.
Ze kennen je latency budget, je deployment pipeline, je observability setup of je productieverkeerspatronen niet.

Ze genereren de meest waarschijnlijk ogende code op basis van patronen in hun trainingsgegevens. Dat is alles. Er is geen bewustzijn. Geen garanties. Geen intuïtie voor systeemontwerp.

En de output weerspiegelt dat vaak:

Code die eenmaal werkt, maar faalt onder belasting
Geen defensieve programmering, geen fail-safes
Slecht begrip van echte beperkingen zoals snelheidslimieten, time-outs of uiteindelijke consistentie
Absoluut geen gevoel voor architectonische intentie

Wat nog erger is, is dat de code er correct uitziet. Het is syntactisch schoon. Het voldoet aan linters. Het zou zelfs kunnen worden gedekt door een basistest. Maar het mist dat ene ding dat er echt toe doet: context.

Daarom duiken deze bugs niet meteen op. Ze wachten op implementaties op vrijdagavond, op drukbezochte vensters, op zeldzame randgevallen. Dat is de aard van AI technische schuld - het is onzichtbaar totdat het iets kritisch breekt.

Wanneer AI echt helpt

Zoals we al eerder zeiden, gebruiken we ook AI. Vrijwel elke ingenieur in ons team heeft lokaal een Copilot-achtige setup draaien. Het is snel, behulpzaam en eerlijk gezegd een geweldige manier om de saaie stukken over te slaan.

Maar hier is het verschil: niets komt in de hoofdbranch terecht zonder door een senior engineer te gaan, en in de meeste gevallen, een CI pijplijn die weet waar hij naar moet zoeken.

LLM's zijn geweldig in:

boilerplate voor nieuwe services of API-eindpunten,
testdekking genereren voor bestaande logica,
helpen met herhaaldelijk refactoren in grote codebases,
het vertalen van eenvoudige shellscripts naar infrastructuur-als-code sjablonen,
of zelfs het vergelijken van algoritmische benaderingen die we al begrijpen.

Wat ze niet goed in is, is design. Of context. Of veilige standaardinstellingen.

Daarom hebben we onze workflows zo ontworpen dat LLM-uitvoer wordt behandeld als suggesties, niet als een bron van waarheid. Zo ziet dat er in de praktijk uit:

We taggen alle AI gegenereerde commits zodat ze makkelijk te traceren en te bekijken zijn.
Onze editors hebben inline prompts, maar met afgedwongen pre-commit hooks die alles blokkeren zonder tests of documentatie.
Onze CI bevat regels voor statische analyse die onveilige patronen markeren die we eerder hebben gezien bij LLM's: dingen zoals onbewaakte retries, ongescoopte timeouts, naïeve JSON parsing of onveilige SQL afhandeling.
Elk pull-verzoek met door LLM gegenereerde code gaat door een verplichte menselijke review, meestal door iemand die de domeinlogica en het risicogebied begrijpt.

Als je het goed gebruikt, bespaart het tijd. Blind gebruikt, is het een tijdbom.

Wat we CTO's aanraden

We zijn hier niet om je te vertellen dat je AI gereedschap moet verbieden. Dat schip is gevaren.

Maar een taalmodel commit toegang geven? Dat is gewoon vragen om problemen.

Dit is wat we in plaats daarvan aanraden:

1. Behandel LLM's als gereedschap, niet als ingenieurs

Laat ze helpen met repetitieve code. Laat ze oplossingen voorstellen. Maar vertrouw ze geen kritieke beslissingen toe. Elke code die wordt gegenereerd door AI moet worden beoordeeld door een senior engineer, geen uitzonderingen.

2. LLM-gegenereerde code traceerbaar maken

Of het nu commit tags, metadata of commentaar in de code is, duidelijk maken welke onderdelen afkomstig zijn van AI. Dat maakt het eenvoudiger om later controles uit te voeren, fouten op te sporen en het risicoprofiel te begrijpen.

3. Een generatiebeleid definiëren

Beslis als team waar het acceptabel is om LLM's te gebruiken en waar niet. Boilerplate? Natuurlijk. Auth flows? Misschien. Transactionele systemen? Absoluut niet zonder herziening. Maak het beleid expliciet en onderdeel van je engineeringstandaarden.

4. Monitoring op DevOps-niveau toevoegen

Als je AI gegenereerde code in productie laat komen, moet je ervan uitgaan dat er uiteindelijk iets kapot gaat. Voeg synthetische controles toe. Rate-limit monitors. Bijhouden van afhankelijkheden. Maak het onzichtbare zichtbaar, vooral als de oorspronkelijke auteur geen mens is.

5. Bouwen voor herstelbaarheid

De grootste AI-fouten die we hebben gezien kwamen niet van "slechte" code. Ze kwamen van stille fouten - ontbrekende gegevens, kapotte wachtrijen, retry stormen - die urenlang onopgemerkt bleven. Investeer in waarneembaarheid, fallback logica en rollbacks. Vooral als je ChatGPT migraties laat schrijven.

Kortom, AI kan uw team tijd besparen, maar het kan geen verantwoordelijkheid nemen.

Dat is nog steeds mensenwerk.

Afsluitende gedachten: AI ≠ software-ingenieurs

AI kan je helpen sneller te bewegen. Maar het kan niet voor u denken.

Het begrijpt jouw architectuur niet. Het weet niet wat "klaar" betekent in jouw context. En het maakt al helemaal niets uit als je datapijplijn op vrijdagavond stilletjes kapot gaat.

Daarom moeten we ons als CTO's blijven richten op de veerkracht van het systeem, niet alleen op snelheid.

Het is verleidelijk om AI de saaie stukken te laten doen. En soms is dat prima. Maar elke kortere weg heeft een nadeel. Wanneer AI gegenereerde code er ongecontroleerd doorheen glipt, wordt het vaak AI technische schuld. Het soort dat je pas ziet als je ops team aan het blussen is in productie.

Als je al tegen die muur bent aangelopen, ben je niet de enige. We hebben teams van alles geholpen, van mislukte migraties tot API-rampen. We refactoren niet alleen code. We helpen ook het denken erachter te refactoren.

Want uiteindelijk is dat wat systemen betrouwbaar maakt.

Philip Tikhanovich

Hoofd van de afdeling Python, Big Data, ML/DS/AI

Philip brengt scherpe focus aan in alles wat met data en AI te maken heeft. Hij is degene die in een vroeg stadium de juiste vragen stelt, een sterke technische visie bepaalt en ervoor zorgt dat we niet alleen slimme systemen bouwen, maar ook de juiste, voor echte bedrijfswaarde.

Meer lezen

Inhoudsopgave

Contacteer ons

Boek een gesprek of vul het onderstaande formulier in en we nemen contact met je op zodra we je aanvraag hebben verwerkt.

Naam

Bedrijf

E-mail

Telefoon

Bericht

Stuur ons een spraakbericht

Documenten bijvoegen

Bestand uploaden

Je kunt 1 bestand van maximaal 2 MB bijvoegen. Geldige bestandsformaten: pdf, jpg, jpeg, png.

Door op Verzenden te klikken, stemt u ermee in dat Innowise uw persoonsgegevens verwerkt volgens onze Privacybeleid om u van relevante informatie te voorzien. Door je telefoonnummer op te geven, ga je ermee akkoord dat we contact met je opnemen via telefoongesprekken, sms en messaging-apps. Bellen, berichten en datatarieven kunnen van toepassing zijn.

U kunt ons ook uw verzoek sturen
naar contact@innowise.com

Wat gebeurt er nu?

Zodra we je aanvraag hebben ontvangen en verwerkt, nemen we contact met je op om de details van je projectbehoeften en tekenen we een NDA om vertrouwelijkheid te garanderen.

Na het bestuderen van uw wensen, behoeften en verwachtingen zal ons team een projectvoorstel opstellen met de omvang van het werk, de teamgrootte, de tijd en de geschatte kosten voorstel met de omvang van het werk, de grootte van het team, de tijd en de geschatte kosten.

We zullen een afspraak met je maken om het aanbod te bespreken en de details vast te leggen.

Tot slot tekenen we een contract en gaan we meteen aan de slag met je project.