Software Factory
Coordinate agents across the whole software lifecycle.
A coding agent speeds up one developer. A Software Factory coordinates agents across planning, implementation, review, deployment, and operations. People set the intent, own the rules, and remain accountable for the result.
People curate intent | deterministic gates check every change | your team runs the system
Illustrative Factory run
Factory run runningIn 60 seconds
The Factory is the delivery system, not the coding agent
People set intent and boundaries. Agents execute bounded steps. Deterministic gates produce evidence. Your team owns the system and expands autonomy only where feedback and risk allow it.
The moving constraint
More output reveals the next constraint
Deployment comes first: if the architecture cannot support frequent releases, nothing downstream can flow. Once that foundation is in place, Build becomes the constraint. Agentic Engineering then moves it to review, intent, and learning.
Intent: Work is not bounded clearly enough. Build: Environment and context slow execution. Review: Plausible output exceeds judgment capacity. Deploy: Infrequent releases block every later improvement. Learn: Production feedback reaches the next run too late.
- 01
Intent
Work is not bounded clearly enough.
Current constraint
- 02
Build
Environment and context slow execution.
Current constraint
- 03
Review
Plausible output exceeds judgment capacity.
Current constraint
- 04
Deploy
Infrequent releases block every later improvement.
Current constraint
- 05
Learn
Production feedback reaches the next run too late.
Current constraint
The distinction
Faster developers do not automatically create a faster organization
Agents inside individual editors shorten coding sessions. The delivery system around those sessions can still move at its old pace.
Scattered agent use
The products are available, but each person uses them differently.
- Context lives in private sessions and disappears with them.
- The agent writes code. Planning, review, deployment, and operations stay unchanged.
- More generated code reaches the same review capacity, so the constraint moves downstream.
- The organization cannot show what changed in delivery.
The investment amplifies gaps that were already present.
A working Software Factory
People, agents, quality gates, and feedback operate as one system.
- Intent, context, rules, and gates live in the repository and apply to every run.
- Agents work across planning, implementation, review, deployment, and operations.
- Deterministic checks decide what proceeds. People decide what should exist.
- Delivery data shows what improved and where the next constraint sits.
Speed comes from the system the team shares.
Agents write the code. Review is where it piles up
More pull requests can overwhelm the same review capacity. A Factory can add fixed checks and agent review before human judgment, reducing avoidable work in the queue.
The path
Individual speed is not organizational velocity
Coding sessions can get shorter while cycle time, delivery measures, and the backlog barely move. Agent use is an early level. The rest of the climb coordinates systems, parallel runs, and the delivery organization around them.
- L1 False summit
Ad-hoc adopter
- Technical
- Developers copy and paste code into a chat window.
- Organizational
- There is no shared setup. Results swing from person to person.
- L2 False summit
Structured collaborator
- Technical
- An agentic engineering product sits in every editor. Typing gets faster.
- Organizational
- Every developer types faster. The team ships no sooner.
- L3 False summit
Agent manager
- Technical
- Agents write code against a strict harness. You are on the loop, not in it.
- Organizational
- Reviews pile up and velocity stalls. This is the velocity trap.
- L4 Step 01
Systems orchestrator
- Technical
- Agents run asynchronously across repositories, triggered by an issue rather than a person at the keyboard.
- Organizational
- Velocity becomes predictable. Gates catch the obvious bugs; people judge the subtle ones.
- L5 Step 02
Fleet commander
- Technical
- One engineer runs a fleet of those loops in parallel.
- Organizational
- One engineer ships many merged pull requests a day without writing every line by hand.
- L6 Step 03
Factory operator
- Technical
- The pipeline runs agents end to end behind deterministic gates.
- Organizational
- The whole organization ships. No single person sits in every loop.
You build the Factory that builds the product
A Software Factory is the system that builds your software. Engineering attention moves from writing every line to designing and steering the system that produces changes.
A coding agent
Sits in your editor. You trigger it, watch it, and review every diff because almost right is still wrong. It makes you faster at typing. The bottleneck stays.
A Factory of agents
Can run bounded lifecycle steps on a schedule or trigger. People read the evidence, steer the rules, and remain accountable for what ships.
Deterministic orchestration
Code sequences the agents, not ad-hoc prompts. The run is repeatable.
Automation ratchet
Repeated corrections can become rules or tests, so later runs start with more useful context.
The lifecycle
What happens between intent and production
The sequence starts with curated intent and continues after merge.
Intent
Curated intent and planning
People decide what should exist and express it in a form agents can read. Requirements, context, and constraints become a plan that a person checks before implementation begins.
Implementation
Implementation and tests
Agents write code and tests inside the team's architecture and rules. Each change carries evidence that it behaves as intended.
Convergence
Review and convergence
Automated checks, agent review, and human review work on the same change until it meets the team's standards. Work that does not converge returns to planning.
Operations
Deployment and operations
The sequence continues into monitoring and incident response. Production signals become input for the next planning cycle.
Technical guardrails
The controls that keep agents inside useful boundaries
The quality of the surrounding engineering system determines how much autonomy it can support.
Context
Context engineering
Domain knowledge, standards, examples, and constraints live in layers inside the repository. Every run starts with the context the team uses in real delivery.
Boundaries
Architecture boundaries
Domain boundaries, modules, and API contracts limit the surface one change can touch. Small change radii make agent work easier to verify.
Evidence
Tests
Tests are executable specifications. They tell agents and people whether a change holds without relying on interpretation alone.
Deterministic
Quality gates
Builds, types, linting, tests, security checks, and coverage apply fixed rules. A gate checks evidence; it does not vote.
Learning loop
Feedback
Repeated manual corrections become rules, tests, or examples. Each run and production incident improves the context for the next one.
Inside the Factory
One explicit pipeline from planning to operations
This reference diagram maps the agents, human decisions, platforms, and feedback loops that can make up a Factory run. It is a design model, not a live customer system.
- Human input: Defines product intent, creates work, answers escalation questions, and starts a remote session when judgment must stay in the loop.
- Feature planner: Triages new work, checks whether the intent is sufficient, classifies risk, and routes ready items into the backlog.
- Feedback digest: Combines user feedback and usage signals, then files enhancements or priority bugs with their evidence attached.
- Product improver: Audits the live product. Low-risk improvements enter the backlog; high-risk changes wait for a person.
- Needs-human requeue: Detects a human answer to an escalated item and sends the work back through triage instead of leaving it blocked.
- Stale-issue reviewer: Finds claimed work that stopped moving, releases it for another run, or escalates repeated failures.
- Feature builder: Claims a feature, implements it against the repository rules, runs tests, and opens a pull request.
- Bug fixer: Claims a priority bug, reproduces the failure, fixes it, verifies the result, and opens a pull request.
- Remote sessions: A person and an agent work live on architecture, debugging, refactoring, or other work that needs continuous judgment.
- PR reviewer: Checks the change against its intent, repository rules, and test evidence, then reports findings before merge.
- PR shepherd: Finds stalled pull requests, nudges their review, and closes duplicate work before the queue grows.
- CI: Runs deterministic builds, tests, security checks, and other fitness functions, then reports their status to review.
- Deploy platform: Builds and publishes the merged change into a production-like or production environment.
- Deploy workflows: Runs the post-merge workflows that notify verification when a deployment is ready.
- Post-merge verifier: Checks the deployed change immediately after merge and files a priority bug when production behavior is wrong.
- UI verifier: Exercises the deployed interface in a real browser and turns visible regressions into actionable work.
- Incident responder: Investigates an incident, identifies the likely cause, and routes a hotfix or follow-up item back into planning.
- Performance monitor: Watches runtime performance and files evidence-backed work when a regression crosses its threshold.
- Automation auditor: Finds repeated manual corrections, updates Factory rules, and flags stalled review paths.
- Daily metrics: Captures daily throughput, autonomy, and CI health so the Factory can be reviewed from evidence.
- Weekly recap: Combines the daily snapshots into a weekly account of what shipped, failed, and changed in the system.
- Update drafter: Turns verified delivery data into a review-ready internal or public update instead of inventing a success story.
Scroll horizontally through the static pipeline.Swipe horizontally through the static pipeline.
The diagram shows decisions and boundaries. It is not a live system and changes with the work.
Snapshot from the Factory dashboard
The line stays observable. Throughput, autonomy, and CI health show where the system moves and where it needs attention.
Issue Time to Close
| <15m | 49 |
|---|---|
| 15-30m | 68 |
| 30-60m | 69 |
| 1-2h | 51 |
| 2-4h | 39 |
| 4-8h | 8 |
PR Time to Merge
| <5m | 188 |
|---|---|
| 5-10m | 123 |
| 10-20m | 38 |
| 30-60m | 20 |
| 1-2h | 6 |
Autonomous Rate and CI Health
| Day | Autonomous % | CI pass % |
|---|---|---|
| Apr 14 | 97% | 98% |
| Apr 16 | 86% | 98% |
| Apr 18 | 85% | 98% |
| Apr 20 | 82% | 97% |
| Apr 22 | 87% | 98% |
| Apr 24 | 85% | 94% |
| Apr 26 | 85% | 50% |
| Apr 28 | 85% | 98% |
| Apr 30 | 85% | 98% |
Recorded across nine Factory runs in April. This is an internal system snapshot, not a client outcome or a live feed.
Why it works
AI multiplies what you already have
DORA describes AI-assisted development as an amplifier of the surrounding system. The Software Factory work focuses on that system: context, quality, feedback, and ownership.
- Trust in AI
- A quality internal platform
- AI-accessible data
- User-centric focus
- Automated guardrails
-
Designed for model portability
We keep context and gates separate from one model where the selected integrations allow it. A replacement still needs evaluation against your code and acceptance criteria.
-
Your approved boundary
Code handling, data residency, and model access follow the deployment model, vendors, data classification, and security rules your organization approves.
-
Knowledge transfers to your team
Agreed context, configuration, gates, pipelines, and documentation stay in your repositories. Internal owners learn to operate and improve them.
Organization and ownership
The technical system needs an operating model
A Factory changes who decides, who steers, and who owns the delivery system after the pilot.
Steering
People curate intent
Product and engineering leaders choose outcomes, constraints, and acceptable risk. Agents can propose plans, but people remain accountable for the work entering production.
Decision rights
Rules have named owners
Architecture boundaries, quality gates, and escalation paths need owners who can change them when the evidence changes.
Transfer
Your team owns the Factory
Context, agent configuration, gates, pipelines, and documentation stay in your repositories. Internal owners learn to operate and improve them without us.
Portability
Models can change
The surrounding context and gates should not depend on one model vendor. Results differ between models, so every change still needs evaluation against your real work.
The direction
Your people steer. The Factory carries bounded work
As the feedback system becomes stronger, people can spend less attention on routine diffs and more on intent, architecture, risk, and outcomes. The safe level of autonomy depends on the codebase, quality gates, deployment model, and operating responsibility.
We test these practices in production work and transfer what holds up in the client's context.
Explore the hycle hypothesis (German)Engagement sequence
From diagnosis to a Factory your organization can run
The Assessment identifies the first constraint. Team Training builds shared practices. A Pilot tests the system in one real value stream, and rollout extends what the evidence supports. Community supports developers alongside these engagements.
-
01 | Diagnose
A decision point with evidence and a prioritized roadmap.
Factory Readiness Assessment
Establish the baseline, identify the first constraint, define an outcome hypothesis, and decide what should happen next.
Assessment details -
02 | Enable
Shared practices and a possible Pilot team.
Team training
Your team builds context, agents, and quality gates on its own stack and code, then leaves with working artifacts in its repositories.
Training details -
03 | Test
Scope follows the Assessment evidence.
Factory Pilot
Run one Factory slice in a real value stream, with delivery data and operating boundaries the organization can inspect.
Pilot details -
04 | Extend
A program shaped by the Assessment and Pilot.
Rollout & scale
Extend the Factory to more teams, establish platform ownership, and change the operating model where the Pilot identified a need.
Rollout details
Experience behind the Factory
Our work with engineering teams shapes how we build the Software Factory. The organizations below have worked with h&w. Moonfare shows how Agentic Engineering spread through one team. The Hamburg Innovation Award named the Software Factory a 2026 START finalist.
We went from 2 engineers playing with agentic coding to 20 using it daily. We've created 17 skills and 9 agents available to every engineer. Skeptics now embrace it. We're targeting daily sprints across the development lifecycle by summer.
Tom Hibbert VP Engineering, Moonfare
Finalist, Hamburg Innovation Award 2026 (START) The Software Factory was a finalist in the 2026 START category. What to decide before building a Factory
How is a coding agent different from a Software Factory?
A coding agent works inside one person's session. A Software Factory coordinates agents across planning, implementation, review, deployment, and operations.
The shared context, rules, and gates belong to the team. The work therefore changes the technical system and the operating model around it.
What do people remain responsible for?
People decide what should exist, set the constraints, own architecture and quality gates, review risk, and remain accountable for production outcomes.
The Factory changes where developers spend attention. It does not remove engineering responsibility.
How do you prevent generated code from lowering quality?
Every change passes fixed checks such as builds, types, tests, linting, and security controls. Human review concentrates on the judgment those checks cannot provide.
Autonomy expands only where the feedback system can support it. Compliance and security requirements still come from your organization.
Does the Factory lock us into one model?
Context, rules, gates, and pipelines can remain independent of one model vendor. That makes replacement possible without rebuilding the entire delivery system.
Equivalent results are not guaranteed. A different model needs evaluation against your code, constraints, and acceptance criteria.
Where should we start?
Start with one real value stream that matters and has enough complexity to expose the boundaries. The Factory Readiness Assessment identifies that candidate and the first constraint to address.
How do you know whether it works?
We track PR Throughput, AI Utilization, Change Confidence, and Change Failure Rate against a baseline. The organization also defines the business outcome that matters for the selected value stream.
DORA describes AI-assisted development as an amplifier of the surrounding system. That is why measurement includes delivery conditions, not product adoption alone.
Go deeper
Explore the research
The knowledge layer separates definitions, independent research, implementation reports, methods, and limitations. Each article shows the sources behind its claims.
- 01 What is a Software Factory? The system, its responsibilities, and where people remain accountable.
- 02 Why faster coding does not guarantee faster delivery What METR, DORA, CircleCI, and DX measure, and why their findings differ.
- 03 Verification in a Software Factory Deterministic gates, agent review, human judgment, and safe operating modes.
- 04 Software Factory evidence and its limits What public implementations establish, what they do not, and how h&w labels its own evidence.
Find the first constraint before you build
The Factory Readiness Assessment establishes your baseline, identifies the constraint that matters first, and recommends the next decision for one real value stream.