Waarom hergebruik meer uitmaakt in AI-ondersteunde ontwikkeling

Je developer vraagt zojuist aan een AI-assistent een nieuw customer lookup-scherm te bouwen, en het werkt in minuten. Mooi — behalve dat je systeem al drie iets verschillende versies van "een klant opzoeken" in oude modules heeft liggen, en nu is er een vierde. Niemand had dit gepland. Het gebeurde gewoon, één AI-gegenereerde shortcut tegelijk.

Dit is het stille risico van AI-ondersteunde ontwikkeling: het maakt het schrijven van nieuwe code zo goedkoop dat het hergebruiken van bestaande code voelt als de langzamere optie. Maar dat is het niet. Dit artikel legt uit waarom hergebruik nu een bewuste discipline moet worden — misschien meer dan ooit — en geeft je een praktische manier om het af te dwingen.

Waarom maakt AI-codering duplicatie erger, niet beter?

AI code-assistenten zijn patroonherkenners. Vraag er een om "een functie toevoegen die een Nederlands btw-nummer valideert" en die genereert die graag van nul af aan — zelfs als je codebase al een gevalideerde, in de praktijk getest versie drie bestanden verderop heeft. De AI kent de geschiedenis van je codebase niet. Het weet niet dat de bestaande functie zes maanden geleden is gepatcht nadat een echte klant een btw-nummer met een kleine letter in het landprefix indiende dat alles kapot maakte.

Voordat AI-tools bestonden, kostte het schrijven van een nieuwe functie genoeg moeite dat een developer meestal eerst zou zoeken: "zeker heeft iemand dit al opgelost." Die wrijving was per ongeluk gezond — het dwong hergebruik af. AI verwijdert de wrijving, dus nu is het standaardinstinct "genereer het gewoon," niet "ga het opzoeken." Het resultaat in echte projecten ziet er zo uit:

• Drie bijna identieke datumopmaakfuncties, elk met een iets ander edge-case bug.
• Twee aparte routines voor klantadresvalidatie — één gebruikt in de webportal, één in de FileMaker back office — die langzaam uit elkaar driften totdat rapporten niet meer overeenkomen.
• Een API-integratie naar een verzendservice geschreven twee keer, zes maanden uit elkaar, door twee developers die niet wisten dat die ander bestond.

Dit zijn geen exotische fouten. Het zijn de normale uitkomsten van snelle codegeneratie zonder een hergebruikgewoonte.

Wat is eigenlijk fout met wat duplicatie?

Een gedupliceerde functie is niet alleen verspilde moeite — het is een onderhoudsverbintenis die stilletjes samengesteld wordt.

Stel je btw-validatiefunctie krijgt in januari een bugfix. Als er drie kopieën van die functie zijn, wordt maar één gerepareerd tenzij iemand eraan denkt de anderen te controleren. Zes maanden later krijgt een klant in België een afgewezen factuur omdat ze de andere kopie raakt — degene die nooit is gepatcht. Niemand maakt snel verbanden, omdat het van buitenaf eruitziet als een eenmalige storing, niet als een systematisch duplicatieprobleem.

Duplicatie vergroot ook de omvang van het systeem dat een nieuwe developer of AI-assistent moet begrijpen. Meer oppervlak betekent meer plekken waar de AI ook het bestaande patroon volgende keer kan missen, en het probleem neemt toe. Dit verbindt zich rechtstreeks met het idee verkend in Necessity-Driven Development: start with what must exist — elk stukje logica dat bestaat maar niet zou moeten is een stukje complexiteit waar je voor betaalt te dragen, of het ooit noodzakelijk was of niet.

Hoe maak je hergebruik weer de standaard?

Je kunt niet vertrouwen op wilskracht of goede bedoelingen — je hebt een klein aantal concrete controlepunten nodig ingebouwd in hoe werk werkelijk gebeurt.

1. Geef de AI-assistent context, niet alleen instructies. Als je team een AI-coderingstool gebruikt, wijs het dan op de bestaande codebase of een samengestelde referentie van kernfuncties voordat je het iets nieuws vraagt te bouwen. Een prompt als "controleer voordat je dit schrijft of validate_vat_number() al in de gedeelde bibliotheek bestaat" verandert de uitkomst dramatisch.
2. Onderhoud één zichtbare, actuele bibliotheek met gedeelde logica. Dit klinkt voor de hand liggend, maar het "gedeelde bibliotheek" van de meeste teams is eigenlijk drie verlaten mappen en één Slack-thread. In een FileMaker-systeem betekent dit echte gedeelde scripts en custom functies met duidelijke namen en opmerkingen — niet copy-geplakte scriptstappen gedupliceerd over layouts.
3. Voeg een hergebruikcontrole toe aan code review, niet alleen een stijlcontrole. Voordat je nieuwe code goedkeurt — AI-gegenereerd of niet — vraagt iemand expliciet: "bestaat zoiets al ergens?" Deze enkele vraag, consistent gesteld, vangt het meeste duplicatie voordat het wordt verzonden.
4. Geef dingen namen zodat ze te vinden zijn. Een functie genaamd checkVAT2 wordt nooit gevonden door een toekomstige developer of een AI-zoekopdracht. Een functie genaamd validateDutchVATNumber wel. Naamgeving is een hergebruikstrategie, geen kleinigheid.
5. Refactoriseer duplicaten op gezicht, plan het niet voor "later." "Later" is waar duplicatie heen gaat om zich te vermenigvuldigen. Als je twee versies van dezelfde logica spot tijdens een sprint, consolideer ze in die sprint — het is nu goedkoper dan nadat een derde versie verschijnt.
6. Noteer waar hergebruikte logica in je projectdocumentatie leeft. Zelfs een eenvoudige interne wiki-pagina met een overzicht van "kernherbruikbare functies en wat ze doen" bespaart later uren AI- en menselijk giswerk.

Vertraagt dit de snelheidsvoordeel van AI-codering?

Een beetje, aanvankelijk — controleren op bestaande logica kost een paar extra minuten die een AI-only workflow overslaat. Maar het is een fractie van de tijd die je anders zou besteden aan debuggen waarom twee "identieke" rapporten verschillende totalen tonen, of aan uitleggen aan een klant waarom de fix die je vorige maand hebt verzonden hun specifieke scherm eigenlijk niet heeft gerepareerd.

In de praktijk eindigen teams die een hergebruikgewoonte bouwen up omsneller te bewegen over tijd, niet langzamer — omdat de AI-assistent zelf beter output krijgt wanneer het naar een kleinere, schonere, goed georganiseerde codebase wordt verwezen in plaats van een groeiende hoop bijna-duplicaten. Schoon hergebruik werkt in je voordeel op dezelfde manier als duplicatie tegen je werkt.

Snelle checklist: beschermt je AI-ondersteunde workflow tegen duplicatie?

• Heeft je AI-coderingsassistent toegang tot (of bewustzijn van) je bestaande gedeelde functies?
• Is er één duidelijk onderhouden locatie voor herbruikbare logica, niet meerdere verspreid?
• Vraagt code review expliciet "bestaat dit al ergens?"
• Zijn functies en scripts duidelijk genoeg genoemd om te worden gevonden via zoeken?
• Herformuleer je duplicaten onmiddellijk, in plaats van ze onder technische schuld in te dienen?
• Heeft iemand de codebase in de afgelopen 6-12 maanden specifiek gecontroleerd op bijna-identieke logica?

Als je "nee" hebt geantwoord op meer dan één of twee ervan, groeit duplicatie waarschijnlijk al stilletjes in je systeem.

Veelgestelde vragen

Geldt dit buiten FileMaker of zelf gebouwde systemen? Ja — het geldt voor elke codebase waar meerdere developers (of een AI-assistent) onafhankelijk code kunnen toevoegen: web-apps, ERP-aanpassingen, API-integratielagen, allemaal.

Kan een AI-assistent zelf hergebruik afdwingen? Ja, als je het instelt. Sommige teams voeren hun AI-tool een samenvatting van kernfuncties in als onderdeel van de contextvenster voordat elk coderingsproject, wat het effectief dezelfde "controleer eerst" gewoonte geeft als een gedisciplineerde menselijke developer zou hebben.

Is enige duplicatie ooit aanvaardbaar? Af en toe — echt verschillende bedrijfslogica die alleen maar gelijk lijkt zou niet in één gedeelde functie hoeven te worden geforceerd alleen voor hergebruik. Het doel is bewust hergebruik van werkelijk identieke logica, niet hergebruik tegen elke prijs.

Als je systeem is gegroeid door een mix van handmatige ontwikkeling en AI-ondersteunde shortcuts, is het de moeite waard om terug te stappen en te vragen wat werkelijk gedupliceerd is versus wat werkelijk noodzakelijk is. Loggix helpt teams precies dat te doen — auditing en consolidering van aangepaste FileMaker-systemen, inbouwen van gedeelde logica in ERP- en API-integraties, en instellen van AI-tools in een workflow zodat ze goede gewoonten versterken in plaats van stilletjes tegen je te werken.