Software factory: wat het is en hoe je er een runt in 2027

Kort antwoord: een software factory (in het Nederlands ook softwarefabriek of softwareontwikkelstraat) is het systeem dat een constante stroom werkverzoeken omzet in geteste, uitgerolde software, waarbij AI-agents het meeste productiewerk doen. Het combineert een intakewachtrij, gedeelde context, afgeschermde omgevingen waarin agents werken, automatische checks, menselijke controlemomenten, uitrol en monitoring tot één herhaalbare lijn. De agent is één machine aan die lijn. De fabriek is de hele lijn, plus de mensen die hem draaien.

In deze gids lees je wat een software factory is, waar de term vandaan komt (hij betekent vier verschillende dingen, afhankelijk van wie je het vraagt), hoe een moderne fabriek laag voor laag is opgebouwd, hoe één wijziging erdoorheen gaat, wie hem runt, wat het kost, hoe je hem meet en hoe een realistisch pad naar een draaiende fabriek in 2027 eruitziet. We behandelen ook wanneer een fabriek overdreven is.

Dit artikel is geschreven voor founders, CTO's en engineering leads van bedrijven met grofweg 5 tot 50 engineers die al met coding agents werken en willen doorgroeien van "een paar mensen met Claude Code of Cursor" naar een betrouwbaar productiesysteem. Bijna elke pagina die nu op dit onderwerp rankt, is geschreven door een leverancier die één laag van de fabriek verkoopt. Deze niet.

‍

De belangrijkste punten

• Een software factory is een herhaalbaar systeem om software te maken: vaste input, vaste tooling, automatische checks, menselijke controlemomenten en gemeten output. In 2026 doen AI-agents steeds vaker het productiewerk binnen dat systeem.

• De agent is niet de fabriek. Het meeste werk zit in alles eromheen: specs die erin gaan, afgeschermde omgevingen, controle, review, uitrol en leren van fouten.

• Meer output verplaatst het knelpunt. Als agents parallel code schrijven, worden de reviewwachtrij en de CI-pipeline de beperking. OpenAI zag sommige CI-systemen binnen ongeveer zes maanden zo'n tien keer zoveel belasting krijgen.

• Je runt een fabriek op cijfers, niet op gevoel: de vier DORA-metrics plus agentmetrics zoals acceptatiegraad, ingreepgraad, wachttijd voor review en kosten per gemergde wijziging.

• Bouw hem in drie fasen. Kruipen met één agent en volledige review, lopen met parallelle agents en een beheerde wachtrij, en pas rennen met automatisch mergen voor werk waarvan bewezen is dat het laag risico heeft.

• De meeste kleine teams moeten geen volledige fabriek bouwen. Een gerichte versie op één repository en één soort werk levert het grootste deel van de winst op.

‍

Wat is een software factory?

Een software factory is een beheerd systeem om software te produceren met herhaalbare input, gestandaardiseerde tooling en meetbare output, waarbij elke stap van verzoek tot release vastligt, waar mogelijk geautomatiseerd is en door een controlemoment wordt bewaakt. In de vorm van 2026 doen AI coding agents het meeste uitvoerende werk: ze maken van specificaties code, tests en pull requests, terwijl mensen bepalen wat er gebouwd wordt, de regels opstellen en goedkeuren wat live gaat.

De nuttigste vergelijking is een echte fabriek. Een fabriek is geen losse machine. Het is de indeling, de aanvoer van materiaal, de kwaliteitscontroles, de mensen die toezicht houden en het proces om de lijn steeds beter te maken. Een team waarin elke ontwikkelaar een AI-agent op zijn laptop draait, heeft machines. Een software factory heeft een productielijn.

Dat onderscheid is belangrijk, want daar gaat de meeste moeite in zitten. De gids van Warp over de architectuur van een software factory noemt orkestratie, feedbackloops en centrale omgevingen als fundament, met agents als uitvoerende laag erbovenop. Met andere woorden: de agent is het deel dat je koopt. De fabriek is het deel dat je bouwt.

‍

De vier betekenissen van "software factory"

De term is ouder dan AI-agents, en zoekresultaten halen de betekenissen door elkaar. Het helpt om te weten welke iemand bedoelt voordat je adviezen vergelijkt.

De eerste betekenis komt uit de industrie. Eind jaren zestig en in de jaren zeventig zetten bedrijven als Hitachi "software works" op die productiediscipline toepasten op programmeren: vaste processen, herbruikbare onderdelen en kwaliteitscontrole. Michael Cusumano beschreef de Japanse aanpak in 1991 in zijn boek Japan's Software Factories, en de geschiedenis die Factory van het concept schreef gaat terug tot Robert Bemer bij General Electric. Het idee was hergebruik en herhaalbaarheid, tientallen jaren vóór AI.

De tweede betekenis komt uit de defensiewereld. Vanaf ongeveer 2017 richtten de Amerikaanse luchtmacht en het ministerie van Defensie "software factories" op, zoals Kessel Run en Platform One: interne DevSecOps-teams met vaste pipelines, goedgekeurde tooling en vooraf goedgekeurde omgevingen, zodat software sneller bij het leger kon komen. Ook daar verschuift het label. In een interview van oktober 2026 zei de leiding van Kessel Run dat het in die zin geen software factory meer is en is overgestapt op een model waarin de overheid stuurt en leveranciers uitvoeren.

De derde betekenis kom je in Nederland en België vaak tegen: een softwarefabriek op basis van low-code, waarin bedrijfsapplicaties worden samengesteld uit configureerbare bouwblokken in plaats van met de hand geschreven. Nuttig, maar een ander onderwerp. Een agentic software factory is dus niet hetzelfde als low-code: agents schrijven echte code in je eigen codebase, die je volledig bezit.

De vierde betekenis, en de betekenis die de zoekresultaten in 2026 domineert, is de agentic software factory: een productiesysteem waarin groepen AI coding agents het bouwwerk doen en mensen de bedoeling, de regels en de eindcontrole bepalen. Daar gaat deze gids over. Het oorspronkelijke idee van herhaalbare productie met kwaliteitscontrole blijft; alleen de werkers aan de lijn veranderen.

‍

Software factory vs SDLC, CI/CD, DevOps en platform engineering

Een software factory overlapt met een aantal bekende begrippen. De korte versie: elk daarvan is een onderdeel van de fabriek, en geen ervan is het geheel.

• De SDLC is het proces: de fasen die elke wijziging doorloopt, van plannen tot release. De fabriek is het systeem dat dat proces vele keren tegelijk draait. Hoe elke fase verandert met AI, lees je in onze gids over de AI SDLC.

• CI/CD is de pipeline die een wijziging bouwt, test en uitrolt. In een fabriek wordt die de onafhankelijke kwaliteitscontrole op het werk van agents, en moet die veel meer volume aankunnen.

• DevOps is de cultuur en werkwijze van gedeeld eigenaarschap tussen ontwikkeling en beheer. Een fabriek gaat daar al van uit.

• Platform engineering bouwt het interne ontwikkelplatform: de vaste routes, omgevingen en self-service tools die engineers gebruiken. Gartner verwachtte dat 80% van de grote software-engineeringorganisaties in 2026 een platform engineering-team heeft. In een fabriek draaien ook de agents op dat platform.

Een fabriek is dus wat je krijgt als platform, pipeline en proces zijn ontworpen voor agents als volwaardige werkers, met intake aan het begin, mensen bij de controlemomenten en meting overal.

‍

Hoe een software factory is opgebouwd: de 8 lagen

Een werkende software factory heeft acht lagen. Je hebt ze niet allemaal op volle sterkte nodig op dag één, maar wel een minimale versie van elk, want een fabriek is zo snel als zijn zwakste laag.

‍

‍

1. Intake

Werk komt binnen als tickets, bugmeldingen, alerts of verzoeken en wordt omgezet in een heldere specificatie voordat een agent begint. Hier wordt de meeste kwaliteit gewonnen of verloren. Een vaag ticket levert een zelfverzekerde, verkeerde pull request op. Minimale versie: een korte spec-template die elke taak moet invullen, met acceptatiecriteria en wat buiten de scope valt.

2. Context

Agents moeten weten hoe je codebase werkt: architectuur, afspraken, welke patronen ze gebruiken en waar ze nooit aan mogen komen. Dat staat in regelbestanden in de repository, in documentatie en in een kennisbank met eerdere beslissingen. Minimale versie: één goed bijgehouden regelbestand per repository dat wordt bijgewerkt zodra de review een fout vindt.

3. Afgeschermde omgeving

Agents draaien in geïsoleerde omgevingen met een eigen kopie van de code, beperkte rechten en geen toegang tot wachtwoorden, sleutels of productiedata. Die isolatie maakt het veilig om meerdere agents tegelijk te laten werken. Minimale versie: containers of cloudomgevingen die een agent kan opstarten en weggooien.

4. Agents en modellen

Dit is de laag waar de meeste mensen als eerste aan denken: de coding agents zelf en de modellen erachter. Tools in deze categorie zijn onder meer Claude Code, OpenAI Codex, de Copilot coding agent van GitHub, Cursor, Devin en de Droids van Factory. Met Agent HQ van GitHub draaien agents van verschillende leveranciers in één controlepaneel. Minimale versie: één agent die het team goed kent, met de mogelijkheid om van model te wisselen zonder de rest om te bouwen.

5. Automatische controle

Bij elke wijziging draaien automatische checks voordat een mens ernaar kijkt: tests, typecontroles, linting, security- en dependencyscans en projectspecifieke regels. In een fabriek is CI geen gemak meer, maar de onafhankelijke beoordelaar van het werk van agents. Minimale versie: een testsuite die de code dekt waar agents aan werken, en foutmeldingen die een agent kan lezen en oplossen.

6. Review

Een mens reviewt elke wijziging tegen de spec en beslist of die gemergd wordt. Dit is nu de duurste stap aan de lijn en de stap die het snelst een wachtrij wordt. Minimale versie: een vaste eindverantwoordelijke reviewer per wijziging, en de regel dat pull requests klein blijven.

7. Uitrol

Goedgekeurde wijzigingen gaan naar productie met dezelfde veiligheidsregels als altijd: gefaseerd uitrollen, feature flags, monitoring en snel terugdraaien. Minimale versie: geautomatiseerde uitrol met terugdraaien in één stap.

8. Inzicht en leren

De fabriek legt vast wat elke agent deed, waarom, en wat het resultaat was, zodat runs opnieuw af te spelen zijn en fouten te herleiden. Fouten uit de review worden regels, evaluaties en betere specs. Dit is de laag die de fabriek beter maakt in plaats van dezelfde fouten te laten herhalen. Minimale versie: een wekelijkse bespreking van wat agents fout deden, die eindigt met bijgewerkte regels.

‍

Eén wijziging door de fabriek, van begin tot eind

Een concreet voorbeeld maakt de lagen tastbaar. Stel dat een klant meldt dat exports mislukken bij accounts met meer dan 10.000 records.

De melding komt in de intakewachtrij. Een mens, of een agent met een mens die goedkeurt, maakt er een spec van: het foute gedrag, het verwachte resultaat, een test die het probleem reproduceert en de opmerking dat het exportformaat niet mag veranderen. Een agent pakt de spec op in een schone omgeving, leest de repositoryregels, vindt de oorzaak (een time-out op één grote query), schrijft een fix die de data in delen ophaalt, voegt de reproductietest toe en opent een kleine pull request.

CI draait de volledige testsuite, de securityscan en de performancecheck. Alles slaagt. De reviewer leest de wijziging tegen de spec, ziet dat de paginagrootte hard in de code staat en vraagt om die uit de configuratie te halen. De agent past de pull request binnen een paar minuten aan. De reviewer keurt goed, de wijziging gaat achter een flag live voor 10% van de accounts, de monitoring blijft schoon en de volgende ochtend krijgt iedereen de fix.

Daarna gebeuren er twee dingen die er een fabriek van maken en niet alleen een snelle fix. De run wordt vastgelegd, zodat iedereen kan zien wat de agent deed en waarom. En de reviewopmerking wordt een regel: "limieten en paginagroottes komen uit de configuratie, nooit uit constanten". De volgende agent die aan vergelijkbare code werkt, maakt die fout niet meer.

Denk ook aan het faalscenario. Was de spec vaag geweest ("fix exports"), dan had de agent misschien het exportformaat herschreven, waren de tests nog steeds geslaagd en had de reviewer een grote, verwarrende wijziging voor zich gehad. Daarom bepalen intake en review, niet de agent, hoe goed de fabriek is.

‍

Zoek je een startpunt voor de intakelaag? Onze gratis AI product requirements template geeft je een specformat waar agents mee kunnen werken, met acceptatiecriteria en regels voor wat buiten de scope valt.

‍

Wat er verandert als agents parallel werken

De belofte van een fabriek is doorvoer: veel agents die tegelijk aan veel wijzigingen werken. Dat verplaatst het knelpunt op manieren die teams vaak niet zien aankomen.

Review wordt de wachtrij. Als tien agents elk binnen een uur een pull request kunnen openen, is de grens hoeveel wijzigingen mensen zorgvuldig kunnen lezen. Teams die dat negeren, mergen zonder echte review of zien de wachtrij groeien.

CI wordt de volgende beperking. In een stuk over hoe OpenAI zijn eigen agentic software factory draait beschreef de Pragmatic Engineer dat sommige CI-systemen in ongeveer zes maanden zo'n tien keer zoveel belasting kregen. De leveringsdata van CircleCI over 2026 wijzen dezelfde kant op: bij een gemiddeld team steeg de activiteit op feature branches met ongeveer 15%, terwijl de doorvoer op de main branch met bijna 7% daalde. Er werd meer code gemaakt, maar minder ervan bereikte productie.

Agents worden bovendien steeds capabeler. METR stelde in 2025 vast dat de lengte van taken die AI-agents kunnen afronden ongeveer elke zeven maanden verdubbelt. Goed nieuws voor de fabriek en een waarschuwing voor de controlemomenten: grotere taken betekenen grotere wijzigingen om te reviewen, dus werk opknippen in kleine stukken wordt elk jaar belangrijker, niet minder.

‍

Hoe je een software factory runt: mensen en vaste momenten

Een fabriek heeft minder mensen nodig die met de hand code schrijven en meer mensen die de lijn draaien. In een klein bedrijf zijn dit petten, geen functietitels, maar iemand moet elke pet dragen.

• Eigenaar van de fabriek: is verantwoordelijk voor het hele systeem, de cijfers en de verbeteringen. Meestal de CTO of een senior engineer.

• Specschrijvers: productmensen en engineers die verzoeken omzetten in heldere specificaties. Geen werk in de fabriek heeft meer invloed op de kwaliteit.

• Eindverantwoordelijke reviewers: senior engineers die aanspreekbaar zijn op elke wijziging die gemergd wordt. Eén naam per wijziging, nooit "het team".

• Platformeigenaar: houdt omgevingen, CI-capaciteit, rechten en uitrol gezond terwijl het volume van agents groeit.

Drie vaste momenten houden het draaiend. Een dagelijkse blik op de wachtrij: wat wacht op een spec, een review of een besluit. Een wekelijkse foutenbespreking: elke fout van een agent die in de review is gevonden, wordt een regel, een test of een betere template. En een maandelijkse blik op de cijfers en de rekening, om te bepalen welk soort werk de fabriek als volgende oppakt.

‍

Hoe meet je een software factory?

Zonder scorekaart kun je geen fabriek runnen. Begin met de vier DORA-metrics en voeg de metrics toe die alleen bestaan als agents het werk doen.

• Doorlooptijd van goedgekeurde spec tot productie.

• Uitrolfrequentie.

• Percentage mislukte wijzigingen.

• Tijd tot herstel.

• Acceptatiegraad: het aandeel pull requests van agents dat zonder of met kleine aanpassingen wordt gemergd.

• Ingreepgraad: hoe vaak een mens een taak moet overnemen.

• Wachttijd voor review: hoe lang wijzigingen op een mens wachten.

• Herstelwerk: gemergde wijzigingen die binnen twee weken gerepareerd moeten worden.

• Kosten per gemergde wijziging: tool- en modelkosten plus reviewtijd, gedeeld door het aantal uitgerolde wijzigingen.

Het onderzoek geeft een goede reden om te meten in plaats van aan te nemen. Het DORA-rapport 2025 van Google vond dat 90% van de respondenten AI gebruikt op het werk en dat ruim 80% zich productiever voelt, maar 30% heeft weinig of geen vertrouwen in door AI gegenereerde code. De fabrieken die werken, zijn de fabrieken die met cijfers kunnen laten zien waar dat vertrouwen verdiend is.

‍

Wat kost een software factory?

De tools zijn het goedkope deel. Abonnementen voor coding agents en modelgebruik kosten meestal tientallen tot een paar honderd euro per engineer per maand, en parallelle achtergrondagents voegen daar gebruikskosten aan toe. De dure delen zijn reviewtijd, CI-capaciteit en het engineeringwerk om de intake-, omgevings- en leerlagen te bouwen.

Het beste getal om te volgen is de kosten per gemergde wijziging. Een rekenvoorbeeld met eenvoudige aannames: een team van 6 engineers kost in Nederland ongeveer €600 per engineerdag. In een maand levert de fabriek 120 wijzigingen op. Elke wijziging vraagt gemiddeld 1,5 uur specwerk en 1 uur review, samen 300 uur, of ongeveer €22.500. Tools, modellen en extra CI kosten zeg €3.000. Dat is ongeveer €213 per gemergde wijziging.

Vergelijk dat met je huidige kosten per wijziging vóór de fabriek, en met het herstelwerk erna. Dalen de kosten per wijziging en blijft het herstelwerk gelijk, dan werkt de fabriek. Dalen de kosten per wijziging maar stijgt het herstelwerk, dan heb je kosten verschoven naar het bugfixwerk van volgende maand.

‍

Zelf bouwen, kopen of een partner?

Geen enkel product is een complete software factory, dus de echte keuze is welke lagen je zelf samenstelt en welke je koopt of binnenhaalt.

Koop de standaardlagen: coding agents, toegang tot modellen, CI, omgevingen en uitroltools. Die verbeteren sneller dan een klein team ze ooit zelf kan bouwen, en je wilt ze kunnen wisselen als de markt verandert.

Bouw de lagen die specifiek voor jou zijn: intaketemplates, regelbestanden, reviewstandaarden, evaluaties en de leerlus. Daar zit je kennis van je product en klanten, en dat maakt je fabriek beter dan die van een concurrent met dezelfde agents.

Werk met een partner als je de fabriek wilt laten draaien voordat je de mensen hebt aangenomen om hem te runnen, of als je een senior team de lijn wilt laten inrichten en je engineers wilt laten opleiden om hem te bedienen. Hoe agents samenwerken en hoeveel vrijheid je ze geeft, lees je in onze gidsen over orkestratie van AI-agents en autonomie van AI-agents.

‍

Het pad naar een draaiende software factory in 2027

Probeer niet de hele fabriek in één keer te bouwen. Teams die slagen, gaan door drie fasen en gaan pas verder als de cijfers zeggen dat ze klaar zijn.

‍

‍

Kruipen, de komende één tot drie maanden: één repository, één soort werk, één agent. Elke wijziging begint bij een geschreven spec en krijgt volledige menselijke review. Het doel is het regelbestand, de testdekking en de nulmeting op te bouwen. Ga verder als de acceptatiegraad stabiel is en de review het tempo bijhoudt.

Lopen, in de eerste helft van 2027: een beheerde intakewachtrij, meerdere agents die parallel in afgeschermde omgevingen werken, CI die op de extra belasting is berekend en een vaste reviewer per wijziging. Volg elke maand de kosten per gemergde wijziging en het herstelwerk. Ga verder als de wachttijd voor review en het percentage mislukte wijzigingen een volledig kwartaal onder controle blijven.

Rennen, voor de meeste teams vanaf de tweede helft van 2027: agents handelen goed afgebakende soorten werk volledig af, zoals dependency-updates, kleine bugfixes en extra testdekking, en wijzigingen met laag risico mogen volgens vaste regels automatisch mergen. Mensen richten zich op specs, architectuur en review van risicovol werk. Elke run wordt vastgelegd en is opnieuw af te spelen. Automatiseer het mergen van een soort werk pas als het percentage mislukte wijzigingen daarvoor langere tijd aantoonbaar laag is.

‍

Waar software factories misgaan

De valkuilen zijn voorspelbaar, en dus te vermijden.

• Te vroeg een donkere fabriek. Engineer Addy Osmani noemt een fabriek waar code live gaat die geen mens heeft gelezen een "dark factory". Voor smalle, goed geteste taken kan dat werken. Breed toegepast ontstaat er begripsschuld: een codebase die niemand in het team nog begrijpt.

• Meer doorvoer zonder capaciteit. Meer agents met dezelfde reviewers en dezelfde CI geven een langere wachtrij, geen snellere levering.

• Acties van agents, niet alleen hun code. Een agent die pakketten installeert, API's aanroept of infrastructuur wijzigt, kan schade doen voordat er een review plaatsvindt. Beperk acties in de omgeving zelf, niet alleen in de review.

• Scope die uitdijt binnen één wijziging. Agents lossen graag drie extra dingen op terwijl ze er één moeten fixen. Kleine specs en strenge review tegen de spec voorkomen dat.

• Geen leerlus. Zonder fouten om te zetten in regels herhaalt de fabriek ze op schaal.

Voor Europese teams komen daar twee checks bij: de verwerkersvoorwaarden van elke AI-leverancier toetsen aan de AVG, en een vastgelegde training in AI-geletterdheid voor de mensen die met agents werken, wat de AI Act sinds februari 2025 verplicht stelt. Die vangrails beschrijven we uitgebreider in onze gids over de AI SDLC.

‍

Wanneer je geen software factory nodig hebt

Een fabriek is een investering, en voor veel teams is een lichtere opzet de betere keuze.

• Je hebt minder dan ongeveer vijf engineers en één product: een goed draaiende AI SDLC met goede specs en review levert het meeste op, zonder de extra lagen.

• Je werk bestaat vooral uit zoeken: als je nog niet weet wat je moet bouwen, is doorvoer niet je probleem.

• Je codebase heeft weinig tests: bouw eerst de tests, anders levert de fabriek wijzigingen op die niemand kan controleren.

• Je wijzigingen zijn veiligheidskritisch of zo zwaar gereguleerd dat ze formele traceerbaarheid vragen die workflows met agents nog niet bieden.

Een goede toets: zit je backlog vol met goed begrepen, terugkerend werk en zijn je senior mensen daar hun dagen mee kwijt, dan verdient een fabriek zich terug. Zit je moeilijkste probleem in bepalen wat je moet bouwen, dan niet.

‍

Hoe wij onze eigen fabriek draaien bij Codelevate

Wij bouwen klantsoftware en onze eigen producten volgens de principes van een fabriek, dus dit is praktijk en geen theorie. Werk begint als geschreven spec, agents bouwen in geïsoleerde omgevingen, automatische checks draaien voordat iemand reviewt, een vaste persoon keurt elke wijziging goed tegen de spec en een mens beslist over elke release.

Onze websitebouw is een goed voorbeeld van een kleine productielijn. Vier gespecialiseerde agents werken na elkaar: één maakt van een ontwerp of briefing een precieze bouwspec, één toetst elke waarde aan het designsysteem van de klant voordat er iets gebouwd wordt, één bouwt, en één controleert het resultaat en geeft een akkoord of een genummerde lijst met fouten terug. Twee van die stappen zijn harde controlemomenten. Vindt de review een fout, dan wordt die een regel in de kennisbank van het project, en elke agent leest die regels voor zijn volgende taak. Dezelfde fout hoort maar één keer te gebeuren.

De les die we steeds opnieuw leren: de agents zijn het makkelijke deel. De fabriek is de specs, de controlemomenten en het geheugen. Dat maakt de output betrouwbaar genoeg om live te zetten.

‍

Tot slot

Een software factory is een productielijn voor software, en in 2026 zijn de werkers aan die lijn steeds vaker AI-agents. De agent is het deel dat je kunt kopen. De fabriek is het deel dat je bouwt: intake die heldere specs oplevert, afgeschermde omgevingen die parallel werk veilig maken, controle en review die de kwaliteit bewaken, en een leerlus die de lijn elke week beter maakt. Begin klein, meet vanaf de eerste maand de kosten per gemergde wijziging en het herstelwerk, en haal mensen alleen uit de lus waar de cijfers bewijzen dat het veilig is. Zo kan een team van 10 in 2027 leveren als een team van 30 zonder de grip op de eigen code te verliezen.

‍

‍

Gratis download: onze AI product requirements template geeft je intakelaag een specformat waar agents goed mee werken. Wil je een software factory laten draaien op je eigen backlog? Dan richten we samen met je team de eerste lijn in, draaien die met je mee en leren je engineers hem zelf te bedienen. Plan een gesprek met Nicko om te zien hoe dat er voor jou uitziet, of lees hoe een vast productteam van Codelevate werkt.

‍

Bronnen

Geraadpleegd op 4 november 2026.

• Warp, Modern software factory architecture, augustus 2026, en What is a software factory, september 2026.

• Factory, Inside the software factory, and what it takes to build one, juli 2026.

• Air & Space Forces Magazine, Kessel Run Q&A, oktober 2026.

• Gartner, Platform engineering.

• GitHub, Welcome home, agents (Agent HQ), oktober 2025.

• The Pragmatic Engineer, Inside OpenAI's agentic software factory, september 2026.

• CircleCI, Software factory: what it is and how to build one, september 2026.

• METR, Measuring AI ability to complete long tasks, maart 2025.

• Google Cloud, Announcing the 2025 DORA report, september 2025.

• Addy Osmani, Software factories, light and dark, juli 2026.