Uw AI-gebouwde app werkt. Dat is precies het probleem. De app draait boekingen, facturatie of het klantportaal goed genoeg dat betalende gebruikers ervan afhankelijk zijn, en niemand wil degene zijn die iets breekt. Toch duurt elke nieuwe feature langer dan de vorige, wie de eerste versie met een AI-tool bouwde is vertrokken of heeft niets vastgelegd, en uw beste engineers besteden hun week aan bugs in plaats van aan de roadmap.
Dus komt de vraag bij u op tafel: refactoren of herbouwen, of een deel vervangen door iets kant-en-klaars? Elk antwoord heeft luide voorstanders. Developers die de code erfden, willen alles opnieuw laten genereren door de AI-tool. Finance kiest wat dit kwartaal het goedkoopst lijkt. Leveranciers presenteren hun platform als vervanging. Voor de meeste AI-gebouwde apps is het echte antwoord geen van de drie in pure vorm, maar een bewuste mix, per module gekozen, met refactoren als standaard.
Het gaat om echt geld. In een enquête van McKinsey onder CIO’s bedroeg technische schuld 20 tot 40% van de waarde van het volledige technologielandschap, en ging 10 tot 20% van het budget voor nieuwe producten op aan het afhandelen ervan. Deze gids geeft u een praktisch kader om te bepalen wanneer u refactort, wanneer het herbouwen van een onderdeel gerechtvaardigd is, hoe u dat gefaseerd aanpakt en hoe u de beslissing op bewijs neemt, zonder het bedrijf op het spel te zetten. Het bredere overzicht staat in onze gids over AI coding in productie.
TL;DR
Refactoren verbetert de opbouw van bestaande code zonder te veranderen wat gebruikers zien; herbouwen vervangt code door een nieuwe versie die hetzelfde gedrag moet nabootsen. Voor een AI-gebouwde app met actieve gebruikers refactort u de delen die nog aan de eisen van het product voldoen, en herbouwt u een onderdeel pas als bewijs laat zien dat een gerichte aanpassing of ondersteunde upgrade een essentiële eis niet haalt tegen aanvaardbare kosten en risico.
- Refactoren is de juiste standaard wanneer de bedrijfslogica klopt, de problemen in een paar modules zitten en er een ondersteund upgradepad is: het product blijft omzet draaien terwijl de code achter tests verbetert.
- Het herbouwen van een onderdeel is gerechtvaardigd in vier situaties: het data- en autorisatieontwerp kan de vereiste toegangsgrenzen niet afdwingen zonder onevenredig veel herwerk, een niet-ondersteunde technologie blokkeert noodzakelijke updates en is niet te upgraden of in te kapselen, de kernprocessen zijn de architectuur ontgroeid, of een schriftelijke vergelijking toont dat vervangen minder totale kosten of risico heeft.
- Gefaseerd herbouwen, bekend als het strangler fig-patroon, vervangt één onderdeel tegelijk (vaak de datalaag of de login) terwijl de rest van de app blijft draaien.
- De keuze tussen refactoren en herbouwen hoort op bewijs te rusten: tests, een analyse van afhankelijkheden en een bevindingenrapport van een review die onafhankelijk is van wie voor het werk betaald zou worden.
Refactoren, herbouwen of vervangen: wat is het verschil?
Refactoren, herbouwen en vervangen zijn drie verschillende antwoorden op een codebase die moeilijk aan te passen is geworden. Refactoren verandert de opbouw van de code, niet het gedrag: Martin Fowler omschrijft het in zijn Definition of Refactoring als een wijziging in de interne structuur van software die haar begrijpelijker en goedkoper aan te passen maakt, zonder het waarneembare gedrag te veranderen.
Herbouwen vervangt code door een nieuwe versie die moet doen wat de oude deed; “rewrite”, “rebuild” en “opnieuw beginnen” beschrijven dezelfde beslissing. Vervangen ruilt een standaardmodule, zoals login, betalingen, e-mail of zoeken, in voor een managed service of kant-en-klaar product.
| Optie | Wat verandert | Wat blijft | Risico | Typische aanleiding |
|---|---|---|---|---|
| Refactoren | Opbouw, naamgeving, dubbele code, tests | Gedrag, data, gebruikers, koppelingen | Laag bij kleine stappen achter tests | Code werkt maar is lastig aan te passen |
| Herbouwen | Eén onderdeel, of in zeldzame gevallen de hele codebase | De data (na migratie) en de gebruikers | Hoog: verborgen fixes gaan verloren, planning loopt uit | Een onderdeel haalt een essentiële eis niet met gerichte aanpassingen |
| Vervangen | Eén standaardmodule wordt een managed service | Alles rond die module | Gemiddeld: koppeling en dataoverdracht | Een standaardfunctie die het product niet zelf hoeft te bezitten |
Ons advies: begin bij refactoren en onderbouw elke stap daarvandaan, per onderdeel.
Waarom lijkt herbouwen met AI-tools goedkoper, en is het dat meestal niet?
Herbouwen van een AI-gebouwde app lijkt goedkoop, omdat AI coding-tools in enkele dagen een nieuwe versie van de code genereren. De code is echter het goedkoopste deel van het product om na te maken. Wat herbouwen weggooit, is alles wat het product sinds de lancering heeft geleerd: randgevallen die na klachten zijn opgelost, data die al in een bepaalde vorm is opgeslagen, koppelingen met hun sleutels, en gedrag waar klanten op rekenen.
De klassieke waarschuwing tegen herbouwen stamt uit april 2000. In Things You Should Never Do, Part I beschreef Joel Spolsky hoe Netscape besloot zijn browser vanaf nul te herschrijven en daarna bijna drie jaar geen grote nieuwe versie uitbracht. Oude code oogt vaak rommelig, mede omdat er jaren aan bugfixes in zitten.
Veel AI-gebouwde apps voegen een tweede risico toe: ze gaan in productie zonder geautomatiseerde tests of geschreven specificatie, dus niemand kan aantonen dat een opnieuw gegenereerde versie alles doet wat de huidige doet. Het goedkope beeld van opnieuw genereren klopt alleen zolang het product weinig gebruikers, weinig opgeslagen persoonsgegevens en weinig koppelingen heeft.
Zes signalen die bepalen of u refactort of herbouwt
Code moet gerefactord worden als ze het juiste doet maar lastig aan te passen is geworden; een onderdeel herbouwt u pas als het niet kan wat het product hierna nodig heeft, nadat haalbare oplossingen zijn beoordeeld. Zes signalen laten zien aan welke kant een deel van een AI-gebouwde app staat, en de meeste kunt u controleren zonder code te lezen. Lees de tabel per onderdeel, niet voor de app als geheel.
| Signaal | Wijst naar refactoren als… | Reden om herbouwen te onderzoeken als… | Hoe u het controleert |
|---|---|---|---|
| 1. Bedrijfslogica | De regels kloppen met hoe het bedrijf nu werkt | De regels passen niet bij het huidige bedrijfsmodel | Loop de drie belangrijkste gebruikersstromen door met wie ze beheert |
| 2. Datamodel | Toegangsgrenzen zijn af te dwingen met schema-, beleids- of autorisatiewijzigingen | De vereiste toegangsgrenzen zijn niet af te dwingen zonder het grootste deel van de datalaag om te bouwen | Vraag de developer hoe de app garandeert dat klant A nooit de data van klant B ziet |
| 3. Spreiding van problemen | Bevindingen zitten in een paar modules | Dezelfde soort bug komt in de hele codebase voor | Tel welke modules de laatste tien bugmeldingen raakten |
| 4. Stack | Framework en runtime hebben een ondersteund upgradepad | Een belangrijke technologie wordt niet meer ondersteund en is niet te upgraden of in te kapselen | Vergelijk versies met de gepubliceerde ondersteuningsdata van de leverancier |
| 5. Kennis | Iemand kan uitleggen hoe de code werkt, of er zijn tests en een specificatie | Niemand kan het uitleggen en het product is ver van de oorspronkelijke opzet afgedreven | Vraag de developer één module in 15 minuten uit te leggen zonder de AI-tool te openen |
| 6. Kosten van wijzigen | Fixes blijven lokaal | Elke fix breekt regelmatig iets anders | Houd vier weken bij hoe vaak een fix een nieuwe bug veroorzaakt en hoeveel teamtijd naar fixes gaat in plaats van features |
Gebruik de zes signalen als aanleiding voor onderzoek, niet als stemming met een drempelgetal. Zijn de problemen lokaal en kan de bestaande architectuur de volgende release dragen, geef dan voorrang aan tests en gericht refactoren. Haalt een onderdeel een essentiële eis niet nadat haalbare fixes en upgrades zijn beoordeeld, baken dan een gefaseerde vervanging van dat onderdeel af. Vergelijk kosten, hinder voor klanten, beveiligingsimpact en terugdraaimogelijkheden voordat u het werk goedkeurt.
Signaal 4 vraagt om zorgvuldigheid. De Node.js Release Working Group stopte op 30 april 2025 met de ondersteuning van Node.js 18, dus een app op die runtime krijgt daarvoor geen beveiligingspatches meer. Het eerste antwoord op een runtime zonder ondersteuning is een upgradeplan voor de runtime en de afhankelijkheden; herbouwen komt pas aan bod als die upgrade niet haalbaar is. Ook signaal 5 werkt twee kanten op: ontbrekende tests maken refactoren trager, maar herbouwen riskanter, want er is niets om de nieuwe versie mee te vergelijken. De oorzaken achter signaal 6 staan in onze gids over AI technical debt.
Weet u niet in welke kolom uw product valt?
De meeste van de zes signalen zijn alleen in de code zelf te lezen. Een AI-built product review beoordeelt engineering en beveiliging samen en legt de bevindingen in begrijpelijke taal uit. Zo ziet u welke delen u houdt, welke u refactort en welke u eventueel herbouwt, voordat u budget vastlegt.
Waarom is refactoren de standaard voor de meeste AI-gebouwde apps?
Refactoren is de standaard voor de meeste AI-gebouwde apps, omdat het product live blijft en omzet blijft draaien terwijl de code verbetert. Als elke wijziging klein blijft en door tests wordt gecontroleerd voordat de volgende begint, blijven de verborgen fixes in de huidige code behouden en is elke fout terug te draaien. Het team kan bovendien parallel features blijven opleveren, iets wat een volledige herbouw meestal maandenlang blokkeert.
Legacy code refactoren die een AI schreef: eerst tests
Legacy code refactoren die een AI schreef, begint met karakteriseringstests: geautomatiseerde tests die vastleggen wat de code vandaag doet, goed of fout, voordat iemand iets verandert. Michael Feathers introduceerde de term in Working Effectively with Legacy Code (2004). Met die tests op hun plaats wordt een regressie (iets wat eerst werkte en nu niet meer) zichtbaar op het moment dat ze ontstaat, in plaats van in een e-mail van een klant.
Een praktische volgorde: dek eerst de drie stromen af die geld opleveren (aanmelden, de kernactie, betalen), refactor dan de module met de meeste bugmeldingen en herhaal. Elke ronde eindigt met tests die slagen en een product dat nog draait.
Is AI goed in het refactoren van code?
AI coding-tools zijn nuttig voor herhalend, goed afgebakend refactorwerk: hernoemen, dubbele code samenvoegen tot één functie en eerste versies van tests schrijven. Ze zijn zwakker bij wijzigingen die kennis van het hele systeem of van de bedrijfsregels vragen, zoals de manier waarop klantdata gescheiden wordt. Refactoren met AI is veilig als een mens elke wijziging beoordeelt en de tests bij elke wijziging draaien.
Wanneer is herbouwen de juiste keuze?
Herbouwen is gerechtvaardigd als een essentiële producteis niet veilig of economisch met gerichte aanpassingen te halen is. Beoordeel de keuze per onderdeel, niet automatisch voor de hele app.
- Het data- en autorisatieontwerp kan de vereiste toegangsgrenzen niet afdwingen zonder onevenredig veel herwerk, nadat haalbare schema- en beleidswijzigingen zijn beoordeeld. Liggen klantgegevens vandaag open, dicht die toegang dan direct, los van de keuze op langere termijn.
- Een niet-ondersteunde technologie blokkeert noodzakelijke beveiligings- of productupdates, en een ondersteunde upgrade of afgebakende vervanging is niet haalbaar.
- Kernprocessen, deploymenteisen of bedrijfsregels zijn zo sterk veranderd dat de bestaande architectuur niet meer past, bijvoorbeeld na een pivot naar een nieuw type klant of een on-premise-eis.
- Een vastgelegde vergelijking van herstel, herarchitectuur en gefaseerde vervanging laat zien dat vervangen over de planningshorizon minder totale kosten of operationeel risico heeft.
De AVG (GDPR) is relevant voor de eerste situatie: artikel 25 vraagt om gegevensbescherming door ontwerp, dus passende technische maatregelen in de manier waarop persoonsgegevens worden verwerkt. De verordening schrijft het resultaat voor, niet de methode, en vereist dus op zichzelf geen herbouw.
Leg vóór een herbouw het verwachte gedrag, de acceptatiecriteria en de migratie- en terugdraaiplannen vast. Dat zijn waarborgen voor de gekozen aanpak, geen zelfstandige redenen om te herbouwen.
De middenweg: één onderdeel tegelijk herbouwen
De middenweg tussen refactoren en een volledige herbouw is één onderdeel tegelijk vervangen terwijl de huidige app blijft draaien. Martin Fowler noemde dit in 2004 het strangler fig-patroon en werkte het essay in 2024 bij: nieuwe onderdelen worden rond het oude systeem gebouwd en nemen één route of feature tegelijk over, tot het oude deel uit kan. Gebruikers blijven de hele tijd werken, en elke stap is te controleren en terug te draaien.
Begin waar de signalen het slechtst zijn en het risico beheersbaar is; bij AI-gebouwde apps is dat vaak de datalaag of de authenticatie. Vervang standaardmodules door een managed service in plaats van ze te herbouwen. Een typisch geval: een boekingsproduct op abonnementsbasis waarbij facturen, login en het klantdashboard werken, maar de scheiding tussen klanten op kwetsbare applicatielogica rust. Een verstandig plan herontwerpt de datalaag en de toegangsregels, verhuist de login naar een managed identity-service en houdt facturen en dashboard, die gerefactord worden zodra ze opnieuw worden aangesloten.
De gefaseerde route vraagt iemand die oude en nieuwe delen gedurende de hele overgang op elkaar laat aansluiten. Heeft uw team die capaciteit niet, dan kan product engineering de overgang leiden terwijl uw eigen team het product in beweging houdt.
Wat kost herbouwen naast de code?
Herbouwen van een AI-gebouwde app kost meer dan de nieuwe code, omdat er ander werk bij komt. Tabel 3 zet de verborgen kostenposten voor elke begroting op een rij, naast hoe ze zich verhouden tot refactoren.
| Kostenpost | Refactoren | Gefaseerd herbouwen van een onderdeel |
|---|---|---|
| Datamigratie | Meestal geen, of kleine schemawijzigingen | Records gaan naar een nieuw model: oefenen, controleren, overstap |
| Parallel draaien | Geen | Oude en nieuwe onderdelen draaien tijdens de overgang naast elkaar |
| Featurewerk | Gaat door naast het refactoren | Vertraagt of stopt voor de delen die worden vervangen |
| Opnieuw testen | Stromen die elke wijziging raakt | Elke stroom die afhangt van het vervangen onderdeel |
| Review vóór herlancering | Optioneel, per release | Nodig voor het nieuwe onderdeel voordat het live verkeer krijgt |
Datamigratie. Oefen een migratie van persoonsgegevens naar een nieuw model eerst in een passend beveiligde testomgeving, waar mogelijk met synthetische of geminimaliseerde data. Controleer aantallen records, eigenaarschap en toegangsregels; plan back-ups, terugdraaien en een gecontroleerde overstap in productie. De AVG geeft in artikel 5, lid 1, onder f, en de artikelen 25 en 32 de relevante beschermingsbeginselen, maar vereist geen volledige herbouw of een specifieke migratiearchitectuur.
Parallel draaien. Oude en nieuwe onderdelen naast elkaar laten draaien kan de kosten voor infrastructuur, monitoring en support tijdens de overgang verhogen. Hoeveel hangt af van welk deel van het systeem dubbel draait, hoe lang de overlap duurt en of managed services gedeeld kunnen worden; neem die overlap dus expliciet op in de begroting.
Review vóór herlancering. Het herbouwde onderdeel heeft een eigen go- of nog-niet-besluit nodig, beschreven in onze gids over de production readiness review. Wat de review zelf kost, staat in onze gids over de kosten van een AI code audit.
Wie neemt de beslissing tussen refactoren en herbouwen?
De founder neemt de beslissing tussen refactoren en herbouwen, maar op basis van een bevindingenrapport, niet op gevoel na een slechte week. Twee belangen zijn het waard om rustig te benoemen: het team dat de code schreef, verdedigt die misschien, en een leverancier die voor de herbouw betaald zou worden, heeft een reden om die aan te raden. Bewijs uit een review die onafhankelijk is van wie het werk uitvoert, neemt beide weg; wat zo’n review omvat, leest u in onze gids over de AI code audit.
Leg de beslissing ook vast. Voor organisaties met een ISO/IEC 27001:2022-managementsysteem is Annex A-maatregel 8.32 over wijzigingsbeheer de relevante richtlijn: belangrijke wijzigingen worden gepland, beoordeeld en goedgekeurd voordat ze live gaan. Stel vóór de beslissing drie vragen: welke signalen wijzen naar herbouwen, wat gaat er voor gebruikers mis als we drie maanden wachten, en wat is het kleinste deel dat we als eerste kunnen vervangen?
Hoe Sunbytes helpt bepalen wat u houdt, refactort of herbouwt
Een keuze tussen refactoren en herbouwen vraagt meer dan een score voor codekwaliteit. Ze vraagt bewijs over welke gebruikersstromen, afhankelijkheden en beveiligingsmaatregelen vandaag werken, en welke wijzigingen die in gevaar brengen.
De AI-built product review van Sunbytes beoordeelt de afgesproken code, beveiliging, kritieke processen en deployment-inrichting, en levert onderbouwde bevindingen, geprioriteerde aanbevelingen en een toelichting in begrijpelijke taal. Met die uitkomsten weegt uw team gericht refactoren, een gefaseerde vervanging van een onderdeel of een apart afgebakend product engineering-traject af. Herstelwerk en hercontroles bespreken we als vervolgwerk; ze zijn niet automatisch inbegrepen.
Sunbytes is een in Nederland opgericht bedrijf, met het hoofdkantoor in Utrecht en sinds 2011 een delivery hub in Vietnam. In meer dan 15 jaar heeft Sunbytes ruim 300 projecten opgeleverd voor klanten in 20 landen en is het ISO 27001-gecertificeerd. Start met een AI-built product review om bewijs en scope helder te hebben voordat u tot herbouwen besluit.
