Je met AI gebouwde app werkt wel, maar aanpassingen worden steeds lastiger. Een nieuwe functionaliteit kost meer tijd dan verwacht, en het oplossen van het ene probleem leidt vaak tot een ander. Wanneer dit blijft gebeuren, moet je achterhalen wat de oorzaak is, voordat je besluit of je de bestaande code wilt verbeteren of (een deel ervan) opnieuw wilt opbouwen.
De keuze hangt af van wat het product in de toekomst moet kunnen, wat de kosten van de verschillende opties zijn en welke impact de wijzigingen hebben op de gebruikers. Sommige onderdelen moeten wellicht worden geoptimaliseerd (refactoring), andere zijn toe aan een volledige herschrijving, en voor standaardfunctionaliteit is het soms beter om gebruik te maken van een bestaande externe dienst.
Deze gids helpt je bij het herkennen van waarschuwingssignalen, het bepalen welke onderdelen technisch onderzoek vereisen en het vergelijken van de verschillende opties, nog voordat je budget toewijst. Daarnaast leer je hoe je wijzigingen zo plant dat de goed functionerende delen van je product behouden blijven. Het bredere overzicht staat in onze gids over AI coding in productie.
TL;DR
Voor een live, door AI ontwikkelde app is het raadzaam om gerichte refactoring toe te passen waar dat aan de overeengekomen eisen voldoet. Overweeg het herbouwen of vervangen van een component wanneer er bewijs is dat dit een beter resultaat oplevert.
- Refactor wanneer de architectuur geschikt blijft en de onderliggende problemen kunnen worden aangepakt met beheersbare wijzigingen.
- Overweeg het herschrijven van een component wanneer haalbare oplossingen en upgrades niet aan een essentiële eis kunnen voldoen tegen acceptabele kosten en risico’s. Voor standaardfuncties kunt u een beheerde service als alternatief overwegen.
- Controleer vóór goedkeuring van het budget: bevestig de getroffen workflows, technische beperkingen, leveringsschattingen en release-garanties voor elke realistische optie.
Refactoren, herbouwen of vervangen: wat is het verschil?
Refactoren herstructureert de implementatie, terwijl de resultaten die gebruikers en gekoppelde systemen waarnemen gelijk blijven. Het kan code begrijpelijker en eenvoudiger aan te passen maken. Bugfixes en nieuwe features moet u apart benoemen, omdat ze het gedrag bewust veranderen.
Herbouwen levert een nieuwe implementatie op op basis van afgesproken eisen. Leg vóór de start vast welk bestaand gedrag behouden moet blijven, welke fouten moeten worden verholpen en welke nieuwe eisen ondersteund moeten worden. Herbouwen betekent niet dat elk gedrag van de oude versie moet worden overgenomen.
Een onderdeel vervangen betekent voor die functie een bestaand product of een managed service inzetten, bijvoorbeeld voor betalingen, e-mail of zoeken. Bij die beslissing horen ook de integratie, de terugkerende servicekosten en de verantwoordelijkheid voor het beheer.
| 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.
Zes signalen die bepalen of u refactort of herbouwt
Gebruik de volgende zes signalen voor een eerste beoordeling met uw team. Bugmeldingen, releasehistorie, feedback van klanten en gesprekken met developers helpen u vast te stellen waar aanpassingen lastig worden. Om die informatie te verzamelen hoeft u de code niet zelf te bekijken. Technisch onderzoek brengt vervolgens de oorzaken in kaart en bepaalt welke opties haalbaar zijn. Beoordeel elk onderdeel afzonderlijk, omdat één applicatie verschillende problemen kan bevatten.
| 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 deze observaties om te bepalen welke vragen verder onderzocht moeten worden. Laat het technische team vaststellen of de oorzaken lokaal zijn of meerdere onderdelen raken, welke oplossingen haalbaar zijn en welke andere processen een wijziging kan beïnvloeden. Vergelijk de benodigde inzet, hinder voor klanten en gevolgen voor de beveiliging voordat u de uitvoering goedkeurt. Neem ook een terugdraaiplan op: hoe het team bij een mislukte deployment terugkeert naar een eerder werkende release en omgaat met eventuele datawijzigingen.
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.
Wilt u nagaan wat er achter de waarschuwingssignalen zit?
Met uw eerste beoordeling bepaalt u waar u moet zoeken. Een technische review kan de code, toegangsregels voor data en gekoppelde diensten onderzoeken om de oorzaken van de problemen vast te stellen. Gebruik die bevindingen samen met ramingen voor de uitvoering om gerichte fixes, het herbouwen van een onderdeel of vervanging door een managed service te vergelijken.
Hoe vergelijkt u de totale kosten van elke optie?
AI coding-tools kunnen de tijd verkorten die nodig is om een nieuwe implementatie te bouwen. Neem in de raming ook de controle op de afgesproken eisen, de aansluiting op bestaande diensten, de omgang met opgeslagen data en de invoering bij gebruikers van het live product mee.
Vergelijk elke optie op basis van dezelfde vereiste uitkomsten, betrokken processen en planningsperiode. Maak onderscheid tussen de kosten van nieuwe features en de kosten van het verbeteren of vervangen van de bestaande implementatie. Zo kunt u de alternatieven eerlijker beoordelen.
| Werk om te begroten | Het bestaande onderdeel refactoren | Het onderdeel herbouwen |
|---|---|---|
| Datawijzigingen | Neem compatibiliteitscontroles en eventuele ondersteunende schemawijzigingen mee. | Neem migratie en controle op de volledigheid en consistentie van de gegevens mee als het datamodel of de opslag verandert. |
| Infrastructuur tijdens de overgang | Houd waar nodig rekening met tijdelijke omgevingen of gefaseerde releases. | Houd rekening met overlap tussen de oude en nieuwe implementatie als de migratie dat vereist. |
| Teamcapaciteit | Reserveer tijd voor refactoren, review en gepland featurewerk. | Reserveer tijd voor herbouwen, integratie, overdracht en ondersteuning van de huidige versie. |
| Testen | Controleer alle betrokken processen, inclusief foutscenario’s en interacties met andere onderdelen. | Valideer het afgesproken gedrag en alle processen die door de vervanging worden geraakt. |
| Releasevalidatie | Stem review, monitoring en herstelvoorbereiding af op de impact van de wijziging. | Pas dezelfde risicocriteria toe, inclusief controles die specifiek zijn voor de nieuwe implementatie. |
Spreek voor beide aanpakken af wie de release goedkeurt, welke controles moeten slagen en wie het product daarna monitort. Onze gids over de production readiness review legt die controles uit. Is een aparte technische review nodig, neem die dan expliciet op in de begroting; zie onze gids over de kosten van een AI code audit.
Wanneer past refactoren bij het probleem?
Refactoren is een praktische optie wanneer de huidige architectuur de afgesproken eisen kan ondersteunen en de oorzaken van lastig aanpasbare code binnen die architectuur kunnen worden aangepakt. Begin met een beperkte verbetering die het team kan testen en beoordelen. Gebruik de uitkomsten om de raming voor het vervolgwerk aan te scherpen. Plan capaciteit voor zowel onderhoud als featurewerk, want of het team kan blijven opleveren hangt af van de scope en de beschikbare mensen.
Legacy code refactoren die een AI schreef: eerst tests
Voeg karakteriseringstests toe voordat u onbekende, door AI gegenereerde code aanpast: geautomatiseerde controles die vastleggen hoe geselecteerde delen van de applicatie zich vandaag gedragen. Vergelijk die uitkomsten met de afgesproken eisen. Bepaal welk gedrag behouden moet blijven en leg bekende fouten apart vast, zodat bestaande fouten geen acceptatiecriteria voor de volgende versie worden.
Begin met de processen waarop klanten het meest vertrouwen, inclusief relevante foutscenario’s en toegangsbeperkingen. Deze tests bieden een basis om regressies op te sporen: gedrag dat eerst werkte en door een wijziging stukgaat. Hoe bruikbaar ze zijn, hangt af van wat ze afdekken. Combineer ze daarom met code review en controles na deployment.
Is AI goed in het refactoren van code?
AI-tools voor programmeren zijn nuttig voor repetitief refactoringwerk met een duidelijke reikwijdte: het hernoemen van elementen, het onderbrengen van dubbele code in een aparte functie en het schrijven van eerste opzetten voor tests. Ze zijn minder effectief bij wijzigingen waarvoor inzicht in het volledige systeem of de bedrijfsregels vereist is, zoals het aanpassen van de wijze waarop klantgegevens worden gescheiden. Door AI ondersteunde refactoring is veilig, mits een mens elke wijziging controleert en er bij elke aanpassing tests worden uitgevoerd.
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.
Leg vóór een herbouw het verwachte gedrag, de acceptatiecriteria en de migratie- en terugdraaiplannen vast. Dat zijn waarborgen voor de gekozen aanpak.
De middenweg: één onderdeel tegelijk herbouwen
Bij een gefaseerde herbouw wordt voor één functie een nieuwe implementatie ingevoerd terwijl de andere delen van de applicatie blijven werken. Deze geleidelijke migratieaanpak, vaak het strangler fig-patroon genoemd, vereist dat verantwoordelijkheden van elkaar kunnen worden gescheiden en tussen de oude en nieuwe implementatie kunnen worden overgedragen.
Kies het eerste onderdeel door de afbakening, afhankelijkheden en waarde voor het bedrijf te onderzoeken. Zoek naar invoer en uitvoer die het team kan vastleggen, gedrag dat het kan controleren en een impact die het kan beperken. Het juiste startpunt hangt af van het systeem.
Spreek vóór de overstap naar live verkeer af hoe de implementaties samenwerken, hoe eventuele datawijzigingen worden gecontroleerd en wanneer wordt teruggekeerd naar de vorige versie. Herstel kan extra werk vragen zodra data is gewijzigd, dus controleer dat plan vóór deployment.
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 Sunbytes product engineering de overgang leiden terwijl uw eigen team het product in beweging houdt.
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.
