Your people own the rules, and AI agents build the product.
In a Software Factory, your people decide what gets built and own the rules. AI agents do the work from planning to operations, and gates check every change.
Book a call (opens in a new tab)How the Factory runs and where people steer
People steer
- Intent outcomes, constraints, risk
- Rules and gates each with a named owner
- Platform owner maintains agents, context and gates
Code sequences every run
- 01 Planning
- gate 02 Build
- gate 03 Review
- gate 04 Deploy
- gate 05 Operate
Every Factory needs an operating model
Once agents do the work, three answers change: who decides, who steers the agents, and who owns the delivery system after the pilot.
-
People decide what gets built
Product and engineering leaders choose the outcomes, the constraints and the risk they will accept. Agents can propose plans, but people stay accountable for everything that goes to production.
-
Every rule has a named owner
Architecture boundaries, quality gates and escalation paths need owners who can change them when the evidence changes.
-
The Factory runs like a platform
A named person or platform team looks after the agents, context and gates like any internal platform, and agrees with the product teams what the Factory takes on next.
-
Roles converge into one engineering role
Developer, QA and analyst work merges. QA moves from checking individual results to owning the quality of the Factory and its gates.
-
Rituals keep their purpose
Planning, refinement and review stay, minus the fixed schedule. Product people set the pace of the flow, so refinement happens whenever the work needs it.
- The backlog holds assumptions to test
- The daily becomes a short retro on how the agents did
- Product and engineering pair throughout the day
Teams ship faster when agents share one system
Teams ship faster when agents share one system
Agents in individual editors shorten coding sessions, while the delivery system around them can keep its old pace. In a Software Factory, people set the intent, own the rules and stay accountable for the result.
Everyone uses agents their own way
The tools are there, but each person uses them differently.
- Context lives in private sessions and vanishes with them.
- The agent writes code. Planning, review, deployment and operations stay as they were.
- More generated code hits the same reviewers, so the constraint moves downstream.
- The organization cannot show what changed in delivery.
The spend amplifies the gaps you already had.
A working Software Factory
People, agents, quality gates and feedback work 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 moves on. People decide what should exist.
- Delivery data, measured per team only, shows what improved and where the next constraint is.
The speed comes from the system the team shares.
A Software Factory runs agents across the whole lifecycle
A coding agent works inside one person's session. A Software Factory coordinates agents across planning, implementation, review, deployment and operations.
-
A coding agent
Lives in your editor. You start it, watch it and review every diff, because almost right is still wrong. You type faster. The bottleneck stays where it was.
-
A Factory of agents
Can run bounded steps of the lifecycle on a schedule or a trigger. People read the evidence, adjust the rules and stay accountable for what ships.
-
Deterministic orchestration
Code decides the order the agents run in, so every run can be repeated.
-
Corrections become rules
Corrections you keep making can become rules or tests, so later runs start with better context.
Your people steer. The Factory carries bounded work
The stronger the feedback system gets, the less attention people need to spend on routine diffs and the more they can spend on intent, architecture, risk and outcomes. How much autonomy is safe depends on the codebase, the quality gates, the deployment model and who carries operating responsibility.
One explicit pipeline from planning to operations
- 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.
- Resume after human answer: Detects a human answer to an escalated item and sends the work back through triage instead of leaving it blocked.
- Stalled-work check: 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 follow-up: 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 pipeline. Swipe horizontally through the pipeline.
Example: one ticket through a factory
- 00:00 plan Plan with 8 acceptance criteria, reusing the existing API
- 00:51 tests 4 new tests written first: red, 4 failed
- 02:09 implement Green: 4 passed; lint and typecheck clean
- 03:30 review, round 1 First reviewer: no issues
- 04:00 review, round 1 Second reviewer: 3 issues
- 04:12 converge, round 1 3 fixes, back to implement
- 05:11 implement, round 2 3 fixes applied; the repaired test shown to fail when the code breaks
- 07:13 review, round 2 1 issue
- 07:27 converge, round 2 1 fix, back to implement
- 08:23 implement, round 3 Fix applied; its new test failed before, passes after
- 09:30 review, round 3 No issues
- 11:04 converge, round 3 No open issues
- 11:44 acceptance Passes in the browser against every acceptance criterion
- 11:59 commit One commit: 5 files, +128 -5
Agents write the code. Review is where it piles up
More pull requests can swamp the same review capacity. A Factory can put fixed checks and agent review ahead of human judgment, so less avoidable work sits in the queue.
How good the surrounding engineering system is decides how much autonomy it can carry.
-
Context engineering
Domain knowledge, standards, examples and constraints live in layers inside the repository. Every run starts with the context your team uses in real delivery.
-
Architecture boundaries
Domain boundaries, modules and API contracts limit what a single change can touch. A small blast radius makes agent work easier to verify.
-
Tests
Tests are executable specifications. They tell agents and people whether a change holds, without relying on interpretation alone.
-
Quality gates
Builds, types, linting, tests, security checks and coverage apply fixed rules. A gate checks evidence against a rule that does not move.
-
Feedback
Manual corrections you keep repeating become rules, tests or examples. Every run and every production incident improves the context for the next one.
People stay accountable for what the Factory ships
People stay accountable for what the Factory ships
Who runs the Factory once it is built?
A named person or platform team looks after the agents, context and gates like any internal platform. They agree with the product teams what the Factory takes on next, and change a rule when the evidence changes.
What happens to our QA engineers and analysts?
Developer, QA and analyst work converges into one engineering role. QA moves from checking individual results to owning the quality of the Factory and its gates.
Do planning, refinement and review go away?
No. They keep their purpose and drop the fixed schedule. Product people set the pace of the flow, so refinement happens whenever work needs it, and the daily becomes a short retro on how the agents did.
How much do the agents decide on their own?
As much as your feedback system can carry. Safe autonomy depends on the codebase, the quality gates, the deployment model and who carries operating responsibility, and it grows only where the gates hold.
People choose outcomes, constraints and acceptable risk, and stay accountable for every change that reaches production.
Find your first constraint before you build
The Factory Readiness Assessment sets your baseline, finds the constraint that matters first, and recommends your next decision for one real value stream.
Book a call (opens in a new tab)