Wat is een software factory? Zo laat je AI-agents werken als een fabriek

Veel bedrijven gebruiken AI zoals je een slimme stagiair gebruikt: iemand vraagt iets, krijgt een antwoord en plakt het ergens in. Dat levert losse winst op, maar geen voorspelbaarheid. Een software factory pakt het anders aan. Het is een werkwijze waarin elk stuk werk dezelfde route aflegt langs vaste stations, met controles ertussen en één mens die tekent voor productie. AI-agents bemannen een deel van die stations.

In dit artikel leggen we uit wat een software factory is, waar het idee vandaan komt, wat het een organisatie kan opleveren, hoe je het opzet en hoe wij het zelf aanpakken. Ook vertellen we wat er misging.

1. Wat is een software factory?

Een software factory is een systeem dat software voortbrengt zoals een fabriek producten maakt: met herhaalbare stappen, vaste onderdelen, meetbare kwaliteit en een duidelijke overdracht tussen stations. Het gaat niet om één slim hulpmiddel maar om de route eromheen.

Korte geschiedenis

Het idee is zestig jaar oud. Eind jaren zestig pleitte Robert Bemer, destijds bij General Electric, voor het organiseren van softwareontwikkeling als fabriek, met gedeelde gereedschappen en hergebruik. In 1969 startte Hitachi zijn Software Works, een van de eerste echte softwarefabrieken met vaste processen en kwaliteitsmetingen. Michael Cusumano beschreef in 1991 in zijn boek Japan's Software Factories hoe Japanse bedrijven dit systematisch deden en wat dat opleverde aan kwaliteit en voorspelbaarheid.

Daarna kwamen versiebeheer, geautomatiseerd testen en continuous integration en delivery: elke wijziging loopt automatisch langs bouwen, testen en uitrollen. De nieuwe stap is dat een deel van de stations nu door AI-agents wordt bemand. Een fabriek bestaat uit stations, de agent is maar één station, er is een menselijke poort en er is een dashboard.

Onze eigen invulling hieronder is daarop geïnspireerd, maar is gebaseerd op hoe wij werken.

2. Het patroon: van signaal tot productie, en terug

Elke software factory volgt hetzelfde patroon. Werk begint met een signaal, bijvoorbeeld een klantvraag, een fout of een idee. Het loopt langs stations en komt in productie. Daar volgt meting, en die meting levert nieuwe signalen op.

De stations:

• Triage. Is het signaal duidelijk genoeg en belangrijk genoeg?

• Plan. Wat hoort erbij, wat niet, en wanneer is het af?

• Bouw. Een agent of een mens maakt het.

• Test. Een andere partij controleert of het werkt.

• Review. Een tweede lezer beoordeelt het resultaat.

• Beveiliging. Een aparte blik op risico's en rechten.

• Release. Het gaat in stappen naar productie, waar een mens tekent.

• Monitoren. Je ziet hoe het in gebruik gedraagt.

Het belangrijkste is de feedbacklus. Een fabriek die alleen vooruit loopt, leert niets. Monitoring en klantgedrag voeden nieuwe signalen, en die starten de band opnieuw.

3. Waarom nu, en wat kan een organisatie ermee?

AI-agents zijn goed genoeg om een deel van het werk echt over te nemen, maar meestal niet goed genoeg om ongecontroleerd te draaien. Precies daarvoor bestaat een fabriek: veel werk, vaste controles.

Drie opbrengsten voor een organisatie:

Snelheid. Werk wacht minder op iemand die toevallig tijd heeft. Een kleine wijziging kan binnen een dag van idee naar gecontroleerd resultaat.

Voorspelbaarheid. Als elke wijziging dezelfde stappen doorloopt, kun je meten hoe lang dat duurt en waar het stokt. Je werkt met cijfers in plaats van met gevoel.

Kwaliteit. Controles zitten in de werkwijze en hangen niet af van wie er die dag oplet.

Dit gaat niet alleen over software. Elke herhaalbare kennisstroom heeft dezelfde vorm: offertes opstellen, maandrapportages maken, klantvragen afhandelen, contracten voorbereiden. Overal waar werk een vaste route heeft, kun je stations benoemen, controles inbouwen en één verantwoordelijke aanwijzen. Voor een klein bedrijf is dat vaak de grootste winst: minder afhankelijkheid van één persoon die alles weet.

4. Hoe zet je het op?

Een fabriek begint niet met gereedschap maar met afspraken. Vier bouwstenen:

Afgebakende rollen. Elke agent krijgt een taak en een grens: wat mag hij lezen, wat mag hij aanpassen, wat nooit. Wie bouwt, beoordeelt zijn eigen werk niet. Leg de rol vast in een bestand, niet in een mondelinge afspraak.

Poorten. Tussen stations zit een overdrachtsmoment met een duidelijke vraag: is aan de voorwaarden voldaan om verder te gaan? Een poort is geen sfeer maar een controle.

Checks die rood kunnen worden. Een regel die alleen op papier staat, wordt vroeg of laat overgeslagen. Een regel die de band stilzet, niet. Begin met een paar harde checks: tests, een controle op geheimen in de code, een controle op toegestane rechten. Een regel zonder check noemen wij eerlijk een voornemen.

Meten. Hoe lang duurt een ronde, hoe vaak gaat er iets mis, waar blijft werk liggen? De DORA metrics (doorlooptijd, frequentie van uitrollen, foutpercentage bij uitrollen en hersteltijd) zijn daarvoor een gangbare basis.

Daaroverheen: één mens die tekent. Niet omdat de agents niets kunnen, maar omdat verantwoordelijkheid niet te delegeren is.

5. Zo pakken wij het aan bij Norwin AI

Rollen per agent. Zeventien rollen in drie groepen: sturend (product, ux, de regie), ontwikkeling (backend, frontend, devops en meer) en reviewend (reviewer, beveiligingsreviewer, kritische architect die tegenspreekt, pentester, compliance). Elke rol heeft een eigen beschrijving van wat hij wel en niet mag.

Eén regiesessie. Alle bouwsessies melden hun stand en hun vragen aan één regiesessie, nooit in hun eigen sessie. De regiesessie bundelt de vragen tot besluiten met een advies per vraag. De beslisser antwoordt in één keer, en het antwoord wordt letterlijk op het werkitem gezet, waar de sessie het leest. De beslisser krijgt dus geen veertig onderbrekingen, maar één overzicht.

Een hartslag. Elke twee uur, en 's nachts ook, loopt de regiesessie alles na: welke sessies draaien of zijn vast, welke wijzigingen klaarstaan, wat de geautomatiseerde controles zeggen, welke reviews ontbreken. Waar de vaste regels het toestaan, wordt samengevoegd. Daarna werkt hij de cockpit bij.

Een cockpit. Het overzicht voor de mens: banen per onderwerp, wat loopt, wat wacht op review, wat wacht op de beslisser, wat er in voorraad ligt, plus de DORA-metingen. Je ziet in één blik waar gewerkt wordt en wat stagneert. De beslisser hoeft niet in elke sessie te kijken.

Werk in brokken. Drie tot zes samenhangende werkitems horen bij één brok met één branch en één reviewronde, met een grens aan de omvang. Wie duizenden regels moet beoordelen, beoordeelt niets meer.

De mens tekent. Binnen vaste regels voegt de regiesessie samen op de ontwikkelomgeving. Naar de testomgeving en naar productie gaat niets zonder de beslisser. Wijzigingen die rechten, inloggen of externe toegang raken, voegt de beslisser altijd zelf samen.

Beveiliging en data. Elke rol heeft de minste rechten die bij het werk passen, geheimen staan nooit in de code en elke wijziging in bedrijfsgegevens laat een auditspoor achter.

6. Wat misging: onze lessen

We draaien dit nu een tijdje, en niet alles ging natuurlijk in één keer goed.

Besluiten letterlijk vastleggen. We gaven besluiten eerst door in een bericht aan de sessie. Sessies weigerden dat terecht: een doorgegeven besluit is tekst van een derde. Nu staat het besluit woordelijk op het werkitem.

Een wisselvallige test bestaat niet. Een testronde viel steeds net op de tijdsgrens van vijftien minuten. We noemden het een wisselvallige test en herstartte de test. Het bleek een structureel probleem in de verdeling van de tests. Oftewel, wie "het is een toevalstreffer" zegt, stopt met zoeken.

Een grens meet wat je meet, niet wat je bedoelt. We begrensden de omvang van code per uitgedacht brokstuk, maar telden testcode mee. Zo werd goed testen gestraft. Kijk bij elke grens wat hij beloont.

Een andere blik vindt wat twee gelijke lezers missen. Twee reviewers met eenzelfde opdracht hebben dezelfde blinde vlekken. De tegenspreker vond bevindingen die de anderen niet zagen.

7. Zo begin je

Begin niet met tien agents, maar met één route van wijziging tot productie.

1. Kies één repository en één soort werk. Bijvoorbeeld kleine bugfixes of één afgebakende module. Zorg dat er al een test is die laat zien of het werkt.

2. Leg de stations vast. Schrijf op welke stappen een wijziging doorloopt: issue, plan, bouw, test, review, release. Leg per stap vast wie of wat die doet, en wat een agent daar wel en niet mag.

3. Maak de poorten hard. Zet de controles in de pipeline, niet in een vergadering: tests, een controle op geheimen in de code, een check op rechten en een verplichte review met akkoord. Wat niet rood kan worden, is geen poort.

4. Houd één mens aan het eind (van elk station). Agents mogen bouwen, testen en reviewen. Naar productie gaat niets zonder de handtekening van één beslisser.

5. Maak het zichtbaar en meet. Zorg voor één overzicht waarop je ziet wat loopt, wat wacht en wat vastzit. Meet de doorlooptijd van issue tot productie. Kijk na twee weken waar het werk blijft liggen. Meestal is dat niet het bouwen, maar de review of de beslissing. Pas daar je route aan, voordat je meer agents toevoegt.

Tot slot

Bij Norwin AI begeleiden we bedrijven en organisaties bij hun AI-transformatie: van inzicht waar kansen voor AI liggen tot maatwerkprojecten en uitvoering. Wil je weten waar in jouw bedrijf dit zich leent? Neem contact met ons op voor een vrijblijvend gesprek.