How it works
The software development lifecycle, run by agent factories
Six stages, one loop, on every change.
Writing code is easy. Shipping reliable software is not.
Agents write more code. Review, security and stability pay for it.
- 98%more pull requests merged
- 91%longer pull request reviews
- 45%of AI code failed security tests
With a coding agent, you are the relay
Set the intent, make the calls, let agents run the rest.
Before
With a coding agent
You carry the plan, rerun the tests and read every diff.
- Planyou
- Codeagent
- Reviewyou
- Testyou
- Shipyou
Now
With an agent factory
You set intent and hold the merge. Only real decisions reach you.
- Planyou: intent
- Codeagents
- Reviewyou: judgment
- Testagents
- Shipagents
Intent goes in. Tested, reviewed changes come out.
An agent factory makes agent code shippable, from intent to production.
/build
/test
/review
/ship
/monitor- Queued
- Working
- In review
- Shipped
80 board items · 8 in flight · 1,898 merged · Illustrative
GitHub
Linear
Slack
Anthropic
OpenAI
AWS Bedrock
What happens at each stage
A plan starts as talk and ends as three files.
- Drafting a spec from a Linear issue
- Splitting the plan into waves
- Open decisions come back to you
- Voice notes
- Meeting transcripts
- Tickets and screenshots
- The architect reads your context
- Asks you every open call
- requirements.md: the why
- design.md: the how
- tasks.md: the order
Developer agents build each wave in parallel, tests first.
- Writing the tests first
- Building a wave in parallel
- A guard before every commit keeps broken code off the trunk
- One developer agent
- #2541
- Three in parallel
- #2542
- #2543
- #2544
- Failing test
- Implement
- Lint, types, build, tests
- Commit
A check fails: back to implement
Acceptance tests and CI gate every change.
- Running acceptance tests in a sandbox
- Rerunning CI after a fix
- Failed tests go back to build
- Plan
- Codefirst
- Reviewthen
- Test and CInow
- Deploy
A second agent checks the change against what you meant.
- Reviewing the diff on a second model
- Checking the change against the spec
- Checking it against your design principles
Does it work?
- Acceptance criteria from the spec
Is it built our way?
- Design principles, each with its why
Is it what we meant?
- Intent from the requirements
A factory pull request: problem, solution, key decisions.
Every pull request records what it read, decided and why.
- Merging under the repository policy
- Waiting for your approval on prod
- Writing the final status on the pull request
- Problem
- Solution
- Key decisions, why, source
- Files the agent read
- Presentation layer never writesINT-1
- Reports idempotent per runFR-RP-1
- No token in the browserFR-HC-1
Bugs and incidents come back as fixes.
- Watching the deploy
- Filing a regression as a hotfix
- Turning findings into tickets for the next build
- Watches production
- Turns findings into tickets
- The fix ships through every gate
Back to monitor
One blueprint, fitted to your stack
/onboard fits one blueprint to your repos.
- Roles
- Workflows
- Gates
- Context
- Runtime
- Web app
- Backend services
- Embedded
- Mobile, data, monorepos
You decide how much the agent factory decides
Raise autonomy as it earns it. Merge policies per repository and environment.
- Calibration
- Standard
- Auto
Calibration
Plans and builds, and every plan and every merge waits for you.
Standard
Makes the routine calls and escalates to you on risk or complexity.
Auto
Ships and monitors alone. Regressions return as hotfixes; you review the record.
See the loop run
on one of your own repos
Bring a real ticket. Watch it ship.