De Multiplier-methode

Parallelle uitvoering

De meeste teams werken lineair: één developer, één taak, één branch, één probleem tegelijk. De methode draait dat om — parallelle tracks die gelijktijdig lopen, met meerdere AI-sessies naast elkaar over worktrees, en direct context-switchen zodra iets blokkeert.

Scope verbreden, met een collega op een issue itereren, en afhankelijk van de omvang — direct implementeren. Het team blijft eigenaar van de code. De PO zit in de loop en is onderdeel van de iteratie. Het team draagt de technische implementatie, de PO toetst de validiteit, en afhankelijk van de setup krijgt QA een gedocumenteerde checklist: wat is er gedaan en hoe valideer je het.

Daarom leveren dezelfde AI-tools met deze methode een 4–20x multiplier op, en zonder 1,3x. De tools maken de multiplier niet. De workflow doet dat — en die workflow kan je team leren.

Schone code stapelt op

In 20 weken verwijderde deze methode 319.000 regels code. Regels code zijn op zichzelf een betekenisloze metriek — maar de schaal laat zien wat er gebeurt wanneer het opruimen van technische schuld niet langer concurreert met feature-werk, maar ernaast plaatsvindt.

Elke opruimactie maakt het volgende werk goedkoper, en AI versterkt dat effect. Een consistente codebase betekent dat de AI patronen exact volgt: minder correcties, hogere kwaliteit output. Rommelige code betekent lagere AI-nauwkeurigheid. Schone code betekent AI die de conventies volgt.

AI schrijft werkende code, geen onderhoudbare code

Het kerninzicht: AI levert uitstekende MVP's en eenmalig werk. Maar AI optimaliseert voor de huidige check. De mens optimaliseert voor alle toekomstige checks.

Bij een flaky test voegt een AI een wachttijd van 30 seconden en een retry-loop toe. Dan slaagt de test. Maar een mens repareert — of laat de AI repareren — de race condition en maakt de test deterministisch. AI schrijft een generieke dictionary; een mens maakt er een strongly-typed response van. AI is als een senior developer die junior-keuzes maakt — het is aan ons om te sturen.

Zonder menselijke tussenkomst bouwt elke sessie voort op de shortcuts van de vorige, en glijdt de codebase af naar slop. Mét bouwt elke sessie voort op een codebase die explicieter is dan daarvoor. Het doel is niet "AI inrichten voor je team". Het is je team leren om rendement uit AI te laten opstapelen in plaats van schuld.

De storage-doorbraak

Een nieuwe implementatie liep vast: bestanden waren niet soepel beschikbaar voor een externe service door interne encryptie die niet langer nodig of gewenst was. Om dat op te lossen, losten we drie problemen op die elk al maanden stillagen:

• Testen was te lastig omdat documenten opgesloten zaten achter versleutelde blob storage.
• Blob storage was ontoegankelijk voor nieuwe services omdat alles handmatig versleuteld was.
• De storage-migratie lag stil omdat het "te veel werk" was.

De nieuwe story dwong versnelling af. Door ze naar dezelfde root cause te herleiden, kwamen alle drie los: de oude decrypt-storage-story reanimeren, een fallback-patroon bouwen zodat versleuteld en onversleuteld naast elkaar bestaan — wat de testomgeving read-only blob-toegang geeft én directe levering naar productie mogelijk maakt. De download-decrypt-upload-taak wordt in een aparte unit of work gevalideerd. Drie blockers opgelost in één dag.

Zo ziet de multiplier eruit: niet sneller typen, maar de verbanden zien over silo's heen en er direct naar handelen. En ondertussen blijven de stories bij met implementatiedetails en gemaakte keuzes — snelle iteratie, transparant en navolgbaar voor het team.

Overdragen, niet alleen voordoen

De methode is overdraagbaar. Maar je kunt mensen niet simpelweg de tools geven. Het gat dichten tussen 1,3x en de volledige multiplier vraagt drie dingen tegelijk: