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

Philip Tihonovich

29 mei 2025 10 min lezen

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 in service fees.

But the bigger hit came from customer fallout. Failed notifications led to missed payments and churn. The client told us they spent at least $10,000 on support tickets, SLA compensation, and goodwill credits over that one botched script.

The ironic thing is that a senior developer could’ve written the correct migration in maybe four hours. But the promise of AI speed ended up costing them two weeks of cleanup and reputation damage.

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

The scary part isn’t that these things go wrong. It’s how predictable it’s all becoming.

Every one of these incidents follows the same pattern. A developer asks ChatGPT for a code snippet. It returns something that works just well enough not to throw errors. They wire it into the system, maybe clean it up a little, and ship it, assuming that if it compiles and runs, it must be safe.

But here’s the catch: Large language models don’t know your system.
They don’t know how your services interact.
They don’t know your latency budget, your deployment pipeline, your observability setup, or your production traffic patterns.

They generate the most likely-looking code based on patterns in their training data. That’s all. There’s no awareness. No guarantees. No intuition for system design.

And the output often reflects that:

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

As we mentioned earlier, we use AI too. Pretty much every engineer on our team has a Copilot-like setup running locally. It’s fast, helpful, and honestly, a great way to skip the boring parts.

But here’s the difference: nothing makes it into the main branch without going through a senior engineer, and in most cases, a CI pipeline that knows what to look for.

LLMs are great at:

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’re not here to tell you to ban AI tools. That ship has sailed.

But giving a language model commit access? That’s just asking for trouble.

Here’s what we recommend instead:

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 can help you move faster. But it can’t think for you.

It doesn’t understand your architecture. It doesn’t know what “done” means in your context. And it definitely doesn’t care if your data pipeline silently breaks on a Friday night.

That’s why, as CTOs, we need to stay focused on system resilience, not just speed.

It’s tempting to let AI handle the boring parts. And sometimes that’s fine. But every shortcut comes with a tradeoff. When AI-generated code slips through unchecked, it often becomes AI technical debt. The kind you don’t see until your ops team is firefighting in production.

If you’ve already run into that wall, you’re not alone. We’ve helped teams recover from everything from broken migrations to API disasters. We don’t just refactor code. We help refactor the thinking behind it.

Because in the end, that’s what actually makes systems reliable.

Philip Tikhanovitsj

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.