De Agentic Software Factory Uitgelegd: Historie, Architectuur en Enterprise Controls

Gebouwd voor snelheid: ~10ms latentie, zelfs onder belasting
De razendsnelle manier om je modellen te bouwen, volgen en implementeren!
- Verwerkt 350+ RPS op slechts 1 vCPU — geen tuning nodig
- Productieklaar met volledige enterprise-ondersteuning
De term van het seizoen in softwarelevering is industrieel: de software factory — steeds vaker de agentic software factory of AI software factory genoemd — een systeem dat aan de ene kant signalen opneemt (bugreports, specificaties, feedback van klanten, zakelijke vereisten) en aan de andere kant uitgerolde, geverifieerde software oplevert, waarbij vloten van AI coding agents het werk uitvoeren binnen een feedbackloop, terwijl engineers de intentie bepalen en resultaten beoordelen. In de eerste helft van 2026 kwamen verschillende organisaties samen op een agent-native herleving van de metafoor: BCG Platinion gebruikte in maart "Agentic Software Factory", en Factory.ai publiceerde in juni zijn "Factory 2.0"-manifest — een onderling verbonden, end-to-end systeem waarvan de incrementele eenheden agents zijn, met de zin die we eenmalig citeren: "Dit systeem zal worden gebouwd door engineers, en zal op zijn beurt hun software bouwen" (Factory.ai, juni 2026). BCG Platinion verklaarde het "Agentic Software Factory-tijdperk" voor geopend en meldde dat sommige organisaties die dit model hanteren productiviteitswinsten van 3–5× beschrijven — een gerapporteerde schatting van praktijkdeskundigen, geen onafhankelijke categorie-benchmark. Het officiële engineeringaccount van Spotify meldt meer dan 1.500 door agents gegenereerde pull requests die zijn gemerged naar productie, met 60–90% tijdsbesparing voor de onderzochte migratieworkflows. En OpenAI meldde het bouwen en beheren van een interne beta vanuit een lege repository met drie engineers die coding agents aanstuurden en zonder handmatig geschreven code — de circa één miljoen regels omvatten applicatiecode, tests, CI-configuratie, documentatie, observability en interne tooling (BCG Platinion, 2026). De AI Engineer World's Fair rekende "enterprise software factories" tot zijn vijf bepalende trends (AI Daily Brief), en definitiegidsen uit de praktijk verschijnen nu wekelijks (murraycole.com; Plannotator). Veel van die gidsen leggen de assemblage-lijn uit. Deze behandelt het onderdeel dat een productie-engineer als eerste zou controleren en waar het enthousiasme meestal aan voorbijgaat: de voorzieningen (utilities). Een fysieke fabriek is slechts zo goed als haar stroom-, leiding-, meet- en veiligheidssystemen; een agentic software factory is slechts zo goed als haar modeltoevoer, credential-afhandeling, kwaliteitscontrole en verbruiksmeting — de laag die niet uit agents of de pipeline bestaat, en waar deze gids een naam aan geeft, in kaart brengt en een checklist voor biedt. Zoals met al onze referenties voor opkomende termen, zullen we deze pagina bijwerken naarmate de woordenschat en de praktijk zich verder ontwikkelen.
Wat is een Software Factory? Een Definitie
Een software factory behandelt softwarelevering als een productiesysteem in plaats van een ambachtelijke werkplaats: gestandaardiseerde inputs, een gedefinieerd assemblagepad, tussentijdse kwaliteitscontroles en herhaalbare, door bewijs ondersteunde outputs. In een agentic software factory voeren coding agents een groter deel uit van de planning, implementatie, testen en review, terwijl engineers intenties bepalen, acceptatiecriteria vaststellen, toegang beheren en bewijsmateriaal beoordelen. Het patroon kan hele stations automatiseren, mensen ondersteunen binnen stations of afgebakende deeltaken uitvoeren. Het is breder dan een coding assistant omdat het het productiesysteem rondom de agent omvat, en breder dan CI/CD omdat het sturing geeft aan het werk dat bínnen de delivery pipeline wordt uitgevoerd — niet alleen aan de overgangen tussen fasen.
Een Korte Historie: Van Geïndustrialiseerd Hergebruik naar Agent-Native Delivery
De term kent een oprecht lange historie, en het traceren ervan legt uit wat wel en niet nieuw is. Het idee van de software factory gaat ten minste terug tot het voorstel van Robert W. Bemer uit 1968 en het in 1975 gepubliceerde fabrieksexperiment van System Development Corporation — gedisciplineerde, herhaalbare softwareproductie op geïntegreerde tooling. Microsoft herleefde en commercialiseerde een gerelateerde model-gedreven formulering in zijn boek Software Factories uit 2004 — templates, referentie-implementaties en richtlijnen die geaccepteerde patronen automatiseren — terwijl latere enterprise-programma's zoals die van BMW de naam toepasten op gestandaardiseerde platforms, processen en gedeelde delivery-infrastructuur die meer dan 12.000 ontwikkelaars en ongeveer 140.000 CI-jobs per dag ondersteunden. De ontwikkeling in 2026 is niet de uitvinding van de software factory, maar een hernieuwde agent-native interpretatie waarin autonome coderingssystemen een groter deel van het werk binnen het productiesysteem uitvoeren — wat zorgt voor een verandering in doorvoer, review-economie, foutmodi, identiteitsvereisten en de relatie tussen productie-controls en autonome uitvoering.
Software Factory vs Coding Agents, Loop Engineering en Platform Engineering
Drie grenzen positioneren de term ten opzichte van verwante begrippen. Versus een coding agent: de agent is een werknemer; de fabriek is het productiesysteem waarin de werknemer opereert — inputs, stations, QC, bewijslast — en een briljante agent in een ongedefinieerd proces is een ambachtsman, geen fabriek, wat een van de redenen is waarom de gerapporteerde resultaten met vergelijkbare agents zo sterk variëren tussen organisaties. Versus loop engineering: loop engineering — de discipline die onze gids voor loop engineering behandelt — is het ambacht van één autonome verifieer-en-herhaalcyclus: de triggers, checks, budgetten en stopcondities. De fabriek is loops op industriële schaal: veel loops, bemande stations, gedeelde QC, één stroom van signaal naar oplevering — loop engineering verhoudt zich tot de software factory zoals machine-ontwerp zich verhoudt tot de fabriek. Versus platform engineering: de golden paths en self-service infrastructuur van het platformteam kozen voor een standaardisatie van de omgeving waarin mensen werkten; de fabriek erft dit allemaal en versterkt een vraag die platform engineering lang heeft beheerd voor service-accounts, CI-bots en machine-identiteiten — wat gebeurt er wanneer de entiteit die het golden path gebruikt een autonome agent is met credentials, een 24/7-dienstrooster, een hogere variabiliteit en geen instinct voor wanneer iets niet goed voelt. Die vraag is het scharnierpunt naar de tweede helft van deze gids, omdat het antwoord niet meer agents is en ook geen betere pipeline. Het zijn voorzieningen (utilities).

De Software Factory in de Enterprise: De Voorzieningenlaag (Utilities)
De rol van TrueFoundry is de voorzieningenlaag, eerlijk afgebakend tot wat de producten bemiddelen. Deelnemende MCP-toolaanroepen die via de MCP Gateway worden geleid, kunnen gebruikmaken van gecentraliseerde serverregistratie, authenticatie, autorisatie, guardrails en observability — terwijl directe API's, browsertoegang, lokale tools, shell-operaties, CI-systemen en andere omleidingspaden afzonderlijke controls vereisen. Voor geregistreerde MCP-servers kunnen credentials centraal worden beheerd en ingevoegd in plaats van te worden ingebed in agent-definities; geconfigureerde OAuth-flows en auth-overrides kunnen gebruikersspecifieke toegang behouden waar dit wordt ondersteund — TrueFoundry ondersteunt de huidige MCP-authenticatiepatronen, waaronder centraal beheerde credentials, OAuth per gebruiker, token passthrough en geconfigureerde auth-overrides; openbare documentatie toont momenteel verschillende beschikbaarheidssignalen voor first-class Agent Identity en OBO-delegatie, dus controleer de ondersteuning voor de beoogde implementatie en versie voordat u vertrouwt op een volledige gebruiker→agent-delegatieketen-attributie. Geconfigureerd gateway-beleid kan guardrails toepassen op overeenkomende LLM- en MCP-operaties; repositorytests, statische analyses, CI-checks, sandbox- en egress-controls, merge-beleid en verbonden evaluators blijven gescheiden onderdelen van het kwaliteitssysteem. Beheerde Agent Harness-runs kunnen uitvoeringstraces bieden, en gateway-records leggen deelnemende model- en MCP-operaties vast. Afgedwongen AI Gateway-budgetregels kunnen aanvullende overeenkomende LLM-verzoeken blokkeren nadat ingestelde limieten zijn overschreden; regels met alleen waarschuwingen bieden inzicht — compute, CI-infrastructuur, toolkosten en downstream side-effects vereisen afzonderlijke limieten.

De vraag van de fabrieksinspecteur. Welke operaties zijn in het slechtste uur van het systeem bemiddeld, welke identiteiten en machtigingen zijn van toepassing, welke limieten worden afgedwongen, welk bewijsmateriaal blijft bewaard en waar moet een mens toestemming geven om door te gaan? Een geloofwaardig antwoord omvat normaal gesproken de agent-runtime, model-gateway, MCP-gateway, sandbox- en netwerk-controls, broncodebeheer- en CI-beleid, en de downstream-systemen die de agents kunnen veranderen.

Enterprise Controls om te Evalueren voor het Schalen
Welke modelaanroepen worden bemiddeld door de gateway en welke omzeilen deze? Waar worden credentials opgeslagen, ingevoegd, gedelegeerd en ververst? Welke acties zijn MCP-aanroepen, directe API's, browseracties, shell-operaties of CI-jobs? Welke kwaliteitscontroles zijn gateway-guardrails, repositorytests, evaluators of merge-beleidsregels? Welke kosten worden beperkt door de AI Gateway en welke vereisen infrastructuur- of leveranciers-controls? Welke tool-aanroepen kunnen worden gepauzeerd door goedkeuringen in de Agent Harness — en welke goedkeuringen horen thuis bij broncodebeheer, CI/CD of downstream-applicaties? Dit zijn risico-afhankelijke evaluatiecriteria, geen categoriegrens; de antwoorden die er toe doen zijn afhankelijk van wat de fabriek bouwt en wat ze kan beschadigen.
De Toekomst van de Software Factory: Waar we op gaan Letten
Voorspellingen, onder voorbehoud. Let erop of organisaties standaardiseren op een gemeenschappelijke categorienaam; of fabrieksplatformen specifiek voor codering blijven; hoe repository- en CI-controls integreren met agent-runtimes; hoe bedrijven defectontsnapping, reviewlast, kosten en rollback-percentages meten; of leveranciersneutrale model- en tool-interfaces de norm worden; en hoe de verantwoordelijkheid zich verdeelt tussen fabriekleveranciers, interne ontwikkelaarsplatforms en governance-infrastructuur, dezelfde migratie die we zagen bij loop engineering en agentic engineering. Of het fabriekspatroon zich uitstrekt voorbij code is het bekijken waard: het patroon — gestandaardiseerd signaal erin, door agents bemande stations, QC, door bewijs ondersteund artefact eruit — beschrijft documentproductie, onderhoud van datapipelines en security-operaties net zo goed, en "fabriek" zou uiteindelijk de algemene industriële vorm van agentic werk kunnen gaan noemen, waarbij de voorzieningen (utilities) — met variatie — in alle vormen terugkeren. Verwacht dat de economische aspecten het gesprek over voorzieningen naar een hoger niveau tillen: op de schaal die Spotify rapporteert (meer dan 1.500 gemerged door agents gegenereerde PR's tot nu toe), moeten organisaties token-uitgaven, blootstelling van credentials en controleerbaarheid mogelijk behandelen als expliciete operationele aandachtspunten. Het is de moeite waard om te volgen of "laat me de meters en vergrendelingen van de fabriek zien" een standaard inkoopvraag wordt. Consolidatiedruk tussen fabrieksleveranciers en de platformlaag is aannemelijk, en leveranciersneutrale voorzieningen kunnen de overstapkosten verlagen en het gemakkelijker maken om van agent- of modelleverancier te wisselen naarmate de mogelijkheden zich ontwikkelen: een fabriek waarvan de stroom, leidingen en meters uw eigen beheer zijn, kan haar robots vervangen als de stand der techniek verandert — wat het argument voor modelonafhankelijkheid is dat Factory.ai zelf maakt, doorgevoerd tot zijn infrastructurele conclusie. We zullen deze gids bijwerken naarmate de praktijk volwassen wordt; een hypothese die het testen waard is, is of duurzaam voordeel minder voortvloeit uit het aantal agents dan uit de kwaliteit van het productiesysteem eromheen.
Software Factory FAQ
Wat is een software factory in AI?
Een agentic (AI) software factory is een herhaalbaar leveringssysteem waarin vloten van AI coding agents gestandaardiseerd, meerstaps werk uitvoeren — planning, codering, testen, review — langs een gedefinieerde pipeline met geautomatiseerde kwaliteitscontrole, wat resulteert in door bewijs ondersteunde outputs zoals pull requests met geslaagde checks, terwijl engineers de intentie bepalen, kwaliteitsnormen stellen en resultaten beoordelen.
Hoe verschilt een software factory van het gebruik van coding agents?
Een coding agent is één werknemer of uitvoeringscomponent; een software factory is het bredere productiesysteem eromheen — gestandaardiseerde inputs, een gedefinieerd assemblagepad, kwaliteitscontroles, telemetrie en meting. Enterprise-adoptie hangt daarom af van zowel de capaciteit van de agent als van de workflow, controls en het bewijsmateriaal eromheen.
Is "software factory" een nieuwe term?
Nee. Het idee van de software factory gaat ten minste terug tot het voorstel van Bemer uit 1968 en het experiment van SDC uit 1975, werd geherformuleerd in het boek Software Factories van Microsoft uit 2004 en werd later toegepast op enterprise-leveringsplatforms zoals dat van BMW. Wat is veranderd in de agent-native herleving van 2026 is de arbeidsverdeling: autonome coderingssystemen voeren een groter deel uit van de planning, implementatie, testen en review, wat de doorvoer, de economie van het toezicht, foutmodi en identiteitsvereisten verandert.
Welke infrastructuur heeft een enterprise software factory nodig?
Enterprise controls variëren per architectuur en risico. Veelvoorkomende behoeften zijn onder meer beheerde modeltoegang, centraal beheerde credentials voor deelnemende tools, repository- en CI-checks, geconfigureerde gateway-guardrails, runtime- en verzoekbewijzen, afzonderlijke limieten voor LLM- en infrastructuuruitgaven, en menselijke autorisatie voor ingrijpende acties. Geen enkel platform levert of bemiddelt noodzakelijkerwijs elke laag.
Referenties
- Primaire casusbronnen — Spotify Engineering, "1,500+ PRs Later" (background coding agent, Deel 1) (het aantal gemergede PR's; de 60–90% besparing op onderzochte migratieworkflows); OpenAI, "Harness Engineering" (de interne beta, teamgrootte, repository-inhoud en de beperking van geen handmatig geschreven code).
- Historie — IEEE Computer Society, Robert W. Bemer (het software-factoryvoorstel uit 1968); Gepubliceerd "Software Factory"-werk van System Development Corporation uit 1975 (IEEE); Greenfield, Short, Cook & Kent, Software Factories (Wiley, 2004); AWS casestudy, BMW Software Factory (de schaal van 12.000 ontwikkelaars, ~140.000 dagelijkse CI-jobs).
- De term en zijn moment — Factory.ai, "Factory 2.0: From coding agents to software factories" (juni 2026: de agent-native definitie; modelonafhankelijkheid; de geciteerde regel); BCG Platinion, "The Agentic Software Factory" (de kadering van het tijdperk; 3–5x winst; de cijfers van Spotify en OpenAI); AI Daily Brief over de AI Engineer World's Fair (enterprise software factories als een bepalende trend); definitie- en praktijkgidsen: Factory.ai's gids, Plannotator (de lijn uit 2006 van Microsoft en BMW), murraycole.com (de praktijkweergave van de bouw; de vragen over geheimen en de sandbox).
- TrueFoundry-documentatie — virtuele modellen; MCP Gateway (officiële architectuurdiagram); guardrails; budgetten; analytics en guardrail-statistieken (officiële afbeelding).
- Dit blog — loop engineering op enterprise-niveau; loops beheren op vlootschaal; de agentic token-explosie in CI/CD; coding agents draaien in de enterprise; spec-driven development; OAuth op de MCP-laag; graph engineering, uitgelegd.
Er is één direct citaat van minder dan vijftien woorden gebruikt uit de geciteerde aankondiging van Factory.ai, in de tekst toegeschreven; alle andere definities, cijfers en verklaringen van praktijkdeskundigen — inclusief de productiviteits- en Spotify/OpenAI-cijfers van BCG, wat de gerapporteerde claims van die organisaties zijn — zijn geparafraseerd met links naar de meegestuurde bronnen. "Factory" is het product en merk van Factory.ai; "software factory" wordt hier gebruikt als de algemene sectorterm die de geciteerde bronnen hanteren, en deze pagina maakt geen aanspraak op het product van welke leverancier dan ook. De framing van voorzieningen en de enterprise-mapping zijn redactionele bijdragen van TrueFoundry op basis van functionaliteiten geparafraseerd uit openbare documentatie die actueel was op het moment van schrijven; de productafbeeldingen zijn TrueFoundry's eigen documentatie-assets, overgenomen met bronvermelding. Geen van de geciteerde bedrijven of auteurs beoordeelt of ondersteunt TrueFoundry. Dit is een dynamisch naslagwerk en zal worden herzien naarmate de praktijk en het jargon zich verder ontwikkelen.
TrueFoundry AI Gateway levert een latentie van ~3–4 ms, verwerkt 350+ RPS op 1 vCPU, schaalt moeiteloos horizontaal en is klaar voor productie, terwijl LiteLLM last heeft van hoge latentie, moeite heeft boven een gemiddeld aantal RPS, geen ingebouwde schaling heeft en het meest geschikt is voor lichte workloads of prototypes.















.png)

.webp)



.webp)








.webp)





