In AI-kringen doet een idee de ronde dat de dark factory heet. Het komt uit de maakindustrie: in een volledig geautomatiseerde fabriek loopt niemand meer op de werkvloer, en een vloer zonder mensen heeft geen verlichting nodig. De machines produceren in het donker.
Toegepast op software is het beeld verleidelijk. AI-agents nemen requirements aan, schrijven de code, draaien de tests, herstellen wat stukgaat, reviewen elkaars wijzigingen en leveren op. De menselijke betrokkenheid gaat richting nul, dus waarom zou je nog meekijken?
Ik denk dat de dark factory qua richting gelijk heeft over autonomie, en volledig ongelijk over de lichten.
Ik weet dat, omdat ik zelf zo'n fabriek draai. Al ruim een jaar doet een autonoom agent-systeem dat ik bouwde (Jengo) echt productiewerk voor mij en mijn klanten: taken oppakken van een bord, code schrijven in geïsoleerde worktrees, pull requests openen, deployen naar servers en terugrapporteren. Er zijn dagen waarop het meer wijzigingen oplevert dan ik regel voor regel zou kunnen lezen, zelfs als ik niets anders deed.
Die ervaring heeft me één ding boven alles geleerd: autonomie en transparantie zijn onafhankelijke dimensies. Je kunt ze allebei maximaliseren. En dat zou je ook moeten doen.
"Klaar" is geen antwoord
Geef een autonoom systeem een simpele instructie: voeg deze feature toe aan de applicatie. Een paar uur later meldt het: klaar.
Indrukwekkend. En op zichzelf onbruikbaar. Want nu heb je vragen:
· Welke requirements heeft het afgeleid uit mijn instructie van één regel?
· Wat heeft het veranderd, en viel er iets buiten de oorspronkelijke scope?
· Welke tests bewijzen dat de feature echt werkt?
· Waar was goedkeuring voor nodig, en wie heeft die gegeven?
· Kan ik het pad volgen van mijn verzoek naar elke regel die veranderde?
Als die antwoorden moeilijk te krijgen zijn, heb je geen capabele fabriek gebouwd. Je hebt een capabele fabriek gebouwd en het licht uitgedaan. De capaciteit is echt; de verantwoording is weg.
Alles is een keten
De oplossing is niet meer toezicht. Het is structuur. In mijn systeem bestaat elk stuk werk als schakel in een keten:
Requirement → taak → agent → branch → commit → pull request → test → review → goedkeuring → deployment.
Niets zweeft los rond. Een pull request wijst terug naar de taak die hem veroorzaakte. De taak wijst terug naar het requirement. Het deploymentlog wijst terug naar de pull request. Als iets in productie zich vreemd gedraagt, reconstrueer ik de geschiedenis niet uit mijn hoofd of uit ruwe Git-archeologie · ik volg de keten terug.
Dit is meer dan een auditlog. Git vertelt je wat er veranderde. De keten vertelt je waarom het bestaat: een geschiedenis van intentie, niet alleen een geschiedenis van wijzigingen.
Traceerbaarheid is geen micromanagement
Hier gaat het vaak mis in het denken. "De lichten aan houden" betekent niet dat een mens elk commando goedkeurt. Dan gooi je het hele punt van autonomie weg.
Het onderscheid dat ertoe doet is risico. In mijn opzet merget de agent een refactor, herstelt hij een falende test of werkt hij interne tooling bij, volledig zelfstandig. Maar bepaalde acties zitten altijd achter een poort: productie aanraken, iets naar een klant sturen, geld uitgeven, met credentials werken. Die verzoeken landen als pushnotificatie op mijn telefoon, mét context, en wachten op een expliciete ja.
Het systeem kent het verschil tussen een omkeerbare interne wijziging en een externe wijziging met gevolgen. Die ene ontwerpkeuze is wat mij in staat stelt om van de productielijn weg te lopen zonder het zicht op de productie te verliezen. Ik bestuur de fabriek. Ik bedien de machines niet.
Van codereview naar besluitreview
Naarmate agents capabeler worden, is deze verschuiving onvermijdelijk. Traditionele governance gaat ervan uit dat mensen de software schrijven, dus bouwden we onze waarborgen rond het lezen van code. Maar als agents honderden wijzigingen per week produceren, is "heeft een mens elke regel gelezen?" niet langer de juiste vraag.
De juiste vraag wordt: kunnen we bewijzen waarom deze wijziging bestaat, hoe ze is gevalideerd, en onder wiens verantwoordelijkheid ze live ging?
Dat is een ander soort review. Geen inspectie regel voor regel, maar besluitreview: zijn de grenzen gerespecteerd, dekten de tests het requirement, is het risicovolle deel expliciet goedgekeurd? Het schaalt waar regel-voor-regel lezen dat niet doet, en eerlijk gezegd vangt het meer van wat er echt toe doet.
Een verlichte fabriek kan leren
Er is een bonus die me in de praktijk verraste. Als alles verbonden is, wordt de fabriek meetbaar, en een meetbare fabriek kan zichzelf verbeteren.
Mijn systeem houdt een doorlopend logboek bij van elke fout en elke les. Patronen die zich herhalen worden gepromoveerd tot harde regels die de agents bij het opstarten laden, elk met een betrouwbaarheidsscore. Een deployment die in week één misging, wordt een regel die dezelfde fout in week veertig voorkomt. De transparantielaag is geen compliance-overhead; het is de bodem waar het systeem van leert. Een donkere fabriek herhaalt haar fouten in het donker.
Laat de lichten aan
Dus nee, het verschil tussen een dark factory en een light factory is niet mensen versus AI. Beide kunnen volledig autonoom zijn. Het verschil is zichtbaarheid.
De dark factory zegt: de machines werken, je hoeft er niet bij te zijn.
De light factory zegt: de machines werken, je hoeft ze niet te bedienen · maar je kunt precies zien wat er gebeurt, en je kunt het achteraf bewijzen.
Ik schreef eerder over waarom workflow belangrijker is dan autonomie. De light factory is hoe die workflow eruitziet zodra agents het meeste werk doen: geen mensen die machines babysitten, en geen black box die code produceert die niemand volledig begrijpt, maar een autonome fabriek waarin requirements, taken, wijzigingen, tests, goedkeuringen en deployments samen één waarneembaar systeem vormen. Meer autonomie hoeft nooit minder controle te betekenen.
Laat de fabriek zichzelf draaien. Maar laat de lichten aan.
Terug naar overzicht