Software factory en dark factory

Wat is een software factory en wat is een dark factory?

Een software factory is een pijplijn waarin coding agents het schrijven, het testen en de eerste review doen, met veel wijzigingen tegelijk, terwijl mensen beslissen wat er gebouwd wordt en de poorten bewaken waar het werk door moet. Het woord factory gaat over herhaalbaarheid, niet over grootte: dezelfde stappen lopen elke keer, en wat eruit komt draagt een verslag van de controles die het doorstaan heeft.

Een dark factory is diezelfde pijplijn met het menselijke nalezen eruit. De naam komt uit de industrie, waar een fabriek zonder volk op de vloer geen reden heeft om de lichten aan te laten. In software betekent het net hetzelfde gemis: een agent schrijft de wijziging, een agent schrijft de test, een agent leest de diff na, en het enige menselijke contact is de specificatie die erin gaat en het gedrag dat eruit komt.

Het zijn twee punten op dezelfde lijn, en elk team dat met een coding agent werkt zit er ergens op. Je plaats hangt niet af van hoeveel agents je draait, wel van welke controles een wijziging moet doorstaan voor een klant ze ziet.

Waar de naam vandaan komt

Software factory is geen vondst van 2026. Hitachi was het eerste bedrijf ter wereld dat het woord op een echte softwareafdeling plakte, zijn Software Works, in 1969, en Toshiba, NEC en Fujitsu bouwden hun eigen versie; Michael Cusumano van MIT beschreef die vier in zijn boek Japan's Software Factories uit 1991. Het idee toen is het idee nu: standaardiseer het proces, bouw gereedschap voor de stukken die zich herhalen, controleer de kwaliteit onderweg. Het Amerikaanse ministerie van Defensie leende het woord om dezelfde reden, te beginnen met de luchtmachteenheid Kessel Run in 2017, waar het staat voor een goedgekeurde pijplijn waar een team door kan opleveren zonder elke controle opnieuw te bevechten.

Dark factory komt van de werkvloer. FANUC draait zijn fabriek in Oshino in Japan sinds 2001 met de lichten uit, waar robots robots in elkaar zetten en de site wekenlang zonder toezicht doorloopt. Niemand beweert dat die fabriek zichzelf ontworpen heeft. Ingenieurs legden de onderdelen, de toleranties en de proeven vast, en een meetopstelling aan de lijn beslist of een stuk goedgekeurd is. Dat is het deel van de vergelijking dat meegaat, en het deel dat de meeste artikels overslaan.

Hoe de pijplijn eruitziet

Een bedrijf dat dit ernstig aanpakt heeft vijf stappen, en je herkent ze hoe de leverancier ze ook noemt.

1. Er gaat een specificatie in, geen chatbericht. De bedoeling, de randvoorwaarden, wat buiten scope valt, en de controle die bewijst dat de feature werkt.

2. Agents werken parallel op aparte branches. Meerdere pogingen aan dezelfde taak, of meerdere taken tegelijk, elk in een eigen sandbox, zodat een mislukte run alleen tokens kost.

3. Een machine leest na voor er een mens aan komt. Een tweede agent die de code niet geschreven heeft, legt de diff naast de specificatie, zodat menselijke aandacht aankomt bij een wijziging waar al eens tegenin gegaan is.

4. De geautomatiseerde controles beslissen. Tests, een build die schoon doorloopt, een securityscan, een afstemming tegen output waarvan je weet dat ze klopt. Dit is de poort die effectief tegenhoudt, en alles wat ervoor komt dient om ze te voeden.

5. Een mens keurt de merge goed. Iemand met een naam en een functie aanvaardt de wijziging in de branch die productie wordt.

Het gedocumenteerde geval waar het nalezen in stap vijf geschrapt is, is StrongDM, een bedrijf in beveiligingssoftware waarvan het AI-team in februari 2026 zijn regels publiceerde: code mag niet door mensen geschreven worden, en code mag niet door mensen nagelezen worden. Hun vervanging is een Digital Twin Universe, gedragsklonen van diensten zoals Okta en Slack, waartegen de agents duizenden end-to-end scenario's per uur draaien. Een deel van de scenario's houden ze weg bij de agents, zodat een run niet bijgestuurd kan worden om te slagen op het examen dat hem zal quoteren. Hun eigen regel voor hoe hard je moet duwen: heb je vandaag geen duizend dollar aan tokens uitgegeven per menselijke ingenieur, dan kan de fabriek beter.

Reviewcapaciteit bepaalt hoeveel werk er de deur uit gaat

Hier zit het hele argument. Een agent maakt op een namiddag meer wijzigingen dan een team op een week naleest, dus loopt de pijplijn op het tempo van zijn verificatie, nooit op het tempo van zijn schrijven. Hoe snel mensen code lezen ligt al lang vast: het onderzoek van SmartBear bij een team van Cisco Systems legt de bruikbare grens op 200 tot 400 regels in een keer en onder de 500 regels per uur, waarbij het aandeel gevonden fouten scherp zakt boven dat tempo.

Faros AI, dat analysesoftware voor engineeringteams verkoopt, publiceerde in 2025 telemetrie over meer dan 10.000 developers bij 1.255 van zijn klantenteams. Teams die veel AI gebruiken mergeden 98 procent meer pull requests en werkten 21 procent meer taken af, terwijl de gemiddelde pull request met 154 procent groeide, de reviewtijd met 91 procent en het aantal bugs per developer met 9 procent. Er kwamen meer wijzigingen binnen, elk ervan was groter, en de wachtrij om na te lezen slikte de winst op. Dit zijn de klantgegevens van een leverancier en geen onafhankelijke studie, dus neem de percentages losjes en de richting ernstig. DORA, het onderzoeksprogramma van Google over softwarelevering, komt op dezelfde plek uit: AI verhoogt de doorstroom, maar vaak ten koste van de stabiliteit als je fundament niet stevig is.

Vergelijk de twee vormen dus op een dimensie: wat bepaalt hoeveel werk er kan vertrekken. Bij een poort van menselijk nalezen is het plafond het aantal reviewuren, en dat beweegt niet als je agents bijzet; die maken de wachtrij alleen langer. Bij een poort van geautomatiseerde verificatie is het plafond hoe snel de controles lopen en hoeveel echt risico ze dekken, en dat beweegt wel als je controles bijschrijft of rekenkracht bijkoopt. Geen van beide is per definitie veiliger, en een oppervlakkige geautomatiseerde poort laat slechte code sneller door dan een vermoeide mens ooit zou doen. Het verschil is dat je aan de ene beperking kan sleutelen en aan de andere niet.

Twee teams, dezelfde feature

Een groothandel wil klantspecifieke prijslijsten in de webshop: afgesproken prijzen per klantengroep, staffels op volume, en een terugval op de catalogusprijs.

Team A telt zes mensen en zet agents op alles. Op een week openen de agents 40 pull requests in plaats van de gebruikelijke acht, zo'n 400 regels elk tegenover de gewone 160. Dat zijn 16.000 regels die bij twee reviewers aankomen. Aan het tempo dat de Cisco-cijfers werkzaam noemen, ongeveer 400 regels per uur, is dat allemaal nalezen 40 uur werk, dus 20 uur elk in een week waarin ze allebei ook hun eigen taken hebben. De eerste tien worden echt gelezen, de rest wordt overvlogen. Drie weken na livegang krijgt een klantengroep de verkeerde staffel boven een bepaalde besteldrempel, en niemand kan zeggen welke wijziging het gedaan heeft.

Team B telt drie mensen en heeft een poort. Voor er code geschreven wordt zitten ze een uur samen met de verkoopverantwoordelijke en schrijven ze de prijsregels uit als 14 testgevallen, waarvan er twee geweigerd moeten worden: een verlopen afspraak, en een staffel met een gat erin. Daarna bouwen ze een controle die een namiddag kost, een afstemming die de factuurlijnen van vorige maand opnieuw berekent met de nieuwe engine en de totalen vergelijkt met wat er echt gefactureerd is. Er vertrekken zes wijzigingen die week in plaats van 40. Bij de vierde loopt de afstemming vast op een klantengroep, een paar honderd euro verschil: dezelfde staffelfout die Team A in productie tegenkwam. Ze raakt nooit tot aan de merge.

Team B bracht niet minder buiten omdat het minder AI gebruikte. Het bracht minder buiten omdat een poort die iets betekent dingen tegenhoudt, en elke weigering is werk dat niemand voor de neus van een klant moest terugdraaien. Die afstemming blijft ook werken als het team morgen dubbel zoveel agents zet. De wachtrij van 40 uur nalezen doet dat niet.

Wie tekent als niemand de code leest

Niemand leest de code betekent niet dat niemand verantwoordelijk is. Iemand beslist nog altijd dat het ding vertrekt. In een dark factory schuift die beslissing naar voren, van de diff nalezen naar de specificatie, de scenario's en de score aanvaarden, maar ze blijft bij een mens liggen, en alles wat eruit volgt ook.

Eran Kahana benoemde de moeilijkheid precies in februari 2026, in een stuk voor CodeX van Stanford Law School over het geval StrongDM: dezelfde soort technologie die de code schrijft, beslist ook of de code werkt, dus delen bouwer en keurder hun blinde vlekken. Zijn illustratie is een agent die een test tevredenstelde door true terug te geven, wat slaagt en niets doet. Hij wijst ook op een gat waar de meeste bedrijven nog niet naar keken: aansprakelijkheidsclausules geschreven voor code die door mensen nagelezen werd, liggen nu op software die geen mens bekeken heeft.

De regelgeving vraagt niet wie het getypt heeft. Raakt een wijziging aan persoonsgegevens, dan geldt de GDPR voor het resultaat. Valt het product onder een conformiteitsbeoordeling of een securityreview, dan gebeurt die nog altijd en zet een mens er zijn handtekening onder. Een ongelezen wijziging die in productie faalt, is jouw wijziging. De formulering van Simon Willison is de bruikbaarste: een computer kan nooit ter verantwoording geroepen worden, en dat is jouw job als mens in de lus.

Laat je software bouwen in plaats van ze zelf te maken, vraag dan wie de wijziging aanvaardt, bij naam, en wat die persoon eerst bekeken heeft. "De pijplijn stond op groen" is een echt antwoord, zolang je er ook bij mag zien wat die pijplijn controleert. "De agent heeft dat geregeld" is dat niet.

Waar moet je op letten bij een software factory

Het volume aan wijzigingen die er goed uitzien. Wat een agent oplevert ziet eruit als verzorgd werk: redelijke namen, een nette commitboodschap, een test ernaast. Het oude signaal dat een wijziging aandacht verdiende, namelijk dat ze zichtbaar gehaast was, is weg. Twintig diffs die er juist uitzien slijten een reviewer af, en de eenentwintigste gaat ongelezen door.

De tests komen van dezelfde bron als de code. Een testset die geschreven is door het systeem dat ze beoordeelt, is een examen dat de student zelf verbeterd heeft. Scenario's achterhouden is een tegenmaatregel; de acceptatiecriteria zelf schrijven, samen met de persoon die het proces kent, is de goedkopere.

Een codebase die niemand in het team begrijpt. Dit is de trage kost. Gaat er iets stuk op een dag dat er veel buiten moet, dan hangt de reactie ervan af dat iemand een beeld in zijn hoofd heeft van hoe het systeem in elkaar zit, en dat beeld bouw je op door code te lezen en aan te passen. Haal het lezen weg en je krijgt het probleem van jaar twee: alles werkt en niemand weet waarom.

De gepubliceerde cijfers over hoeveel code AI schrijft zijn geen metingen. Sundar Pichai zei op de kwartaalcall van Alphabet in oktober 2024 dat meer dan een kwart van de nieuwe code bij Google door AI gegenereerd werd, om daarna door ingenieurs nagelezen en aanvaard te worden, en dat tweede deel valt in de meeste doorvertellingen weg. Satya Nadella zei op LlamaCon van Meta in april 2025 dat 20 tot 30 procent van de code in de repositories van Microsoft door software geschreven was, beter in Python dan in C++. Beide bedrijven noemden sindsdien hogere cijfers. Geen van die uitspraken zegt wat er als door AI geschreven telt, geen enkele is nagekeken door een buitenstaander, en geen enkele zegt wat een controle zou tegengehouden hebben.

Wat een KMO hieruit meeneemt

Jij gaat geen software factory draaien, en je hebt het volume niet dat er een nodig heeft. Wat wel meegaat is kleiner en werkt op elke schaal: een geschreven specificatie, een controle die een machine kan draaien, en een mens met een naam die het resultaat aanvaardt.

Die drie maken elk werk met agents veilig, of het nu een coding agent is die een intern hulpmiddel bouwt of een agent die de leveranciersmails afhandelt. Zonder de specificatie beantwoordt de agent de verkeerde vraag heel goed. Zonder de machinecontrole ben jij de controle, en dat hou je niet bij. Zonder de mens met een naam merkt niemand het wanneer de eerste twee fout zitten.

Begin bij de controle, dat is de goedkoopste van de drie. Kies het ene cijfer in je zaak dat moet kloppen, verkoop in het rapport tegenover verkoop in het bronsysteem, gefactureerd tegenover geleverd, geboekte uren tegenover gefactureerde uren, en laat een machine dat bij elke wijziging vergelijken.