Constraint 01 · Cost
You still need a smart team
AI made the people faster. It did not remove the people.
Redesigning the SDLC for the AI era · Enabling autonomous execution
The SDLC was built for humans handing work to humans. AI should not inherit it.
We replaced the eight-stage human assembly line with two stages.
You test-drive
Factory deploys to your cloud
Business intent in. Production software out. Change it later? Hit update. It ships again.
Don't automate the old SDLC. Replace it.
01
The old design, and why it existed
The traditional SDLC
- Business intent ↓human handoff
- Requirements ↓human handoff
- Architecture ↓human handoff
- Planning ↓human handoff
- Coding ↓human handoff
- Testing ↓human handoff
- Integration ↓human handoff
- Deployment
AI today: copilots and agents make individual boxes faster. Every handoff — and every re-interpretation — survives.
Eight stages. Eight specialties. Seven handoffs. A design for distributing work across humans.
The stages existed for good reasons — specialization, coordination, risk containment. Every one a workaround for human limits. AI just made the people faster. Coding agentsArchitecture agentsTesting agentsDevOps agents
Constraint 02 · Quality
Context still dies at every handoff
What the business meant is re-interpreted seven times before it ships.
The result
The business never gets what it actually wanted. Endless rework until the software is finally usable.
They made the specialists faster. We removed the specialists.
02
What 1729 actually changes
Two stages. That's the whole process.
Stage 1 Control Room
Your team test-drives a working product.
Every interface, every role, real permissions, realistic data.
They approve something that already works, not a document.
Stage 2 Dark Factory
The factory builds everything from what you just approved.
Architecture, code, integrations, infrastructure, tests, release evidence. Deployed to your cloud.
No specialists. No handoffs. No translation loss.
Govern
Your people decide. The Factory executes.
Business outcome. Architecture choices. Security boundaries. Risk acceptance. Production release. Humans hold every one of them. Everything between the two gates is execution.
Lights out on execution. Never on authority.
The proof
Every approved screen is something the system must prove.
Specification, implementation, tests, and evidence evolve together. QA validates the evidence against what you approved — instead of discovering at the end that the wrong thing was built.
You cannot bolt verification onto autonomous execution. It has to be part of the production system.
Old
Build → Build → Build → Test → discover what was wrong
1729
Intent ↔ Specification ↔ Build ↔ Verify
The loop
Hit update. It ships again.
The loop never stops: change the product in the same screens, hit update, and the live system rebuilds and redeploys.
Maintenance is the same two stages, repeated.
03
One initiative or the whole roadmap. Same time.
Your team's hours, week by week
A year-long project becomes six weeks. Your team's part becomes nine hours.
Same initiative, same calendar. The bars are hours from your people, not ours.
Traditional
12 months
on and off, all year
Hours per week from your teamweek 52
Requirements → Build → Test · fix · re-decide → week 52
1729
9 h of your team
6 weeks to ship
4 frontend versions, week 1
Control room 1 wk → dark factory 5 wk → ship, week 6
week 14: change it, hit update, live same day
Done at week 6. The row above is still in design.
Control room 1 wk → dark factory 5 wk → ship wk 6 · wk 14: change it, live same day
Week 1 · Control Room
Four working versions of the frontend, every role, every workflow, and your people clicking through each one until it's right. That's the nine hours.
Weeks 2–6 · Dark Factory
Architecture, code, integrations, tests, and release evidence — with nothing from you until a one-hour evidence review at the gate.
Week 14 · Change
A change, made in the same screens, live the same day.
The whole roadmap, same 52 weeks
The old way created a waiting line. This one doesn't.
1729 · 6 initiatives
6×
the output. Not 6× the time.
Customer onboarding
Pricing exceptions
Partner portal
Refund workflow
Reporting rebuild
Order tracking
wk 1 wk 6 wk 12 all six live by ~week 12 · the row above is still in requirements
Six initiatives do not take six times as long. Your team spends six working sessions — one dark block each — and the Factory runs the builds at once. Capacity is no longer the number of teams you have. It is the number of decisions you can make.
9 h
total from your team, first session to go-live
6 wk
first session to production, on your cloud
Same day
median turnaround for a change after go-live
6 in 12
initiatives live in twelve weeks, same team
Illustrative timeline for a single mid-size initiative.
The old model measures progress in phases. This one measures it in decisions.
04
What the business actually gets
The business gets exactly what it wants. Exactly when it needs it.
01
No queue
Initiatives run in parallel. No priority fights, no delays.
02
Capacity without headcount
Output stops scaling with team size — for new builds and for maintenance.
03
Intent lives in a record
Not in one architect’s head.
04
Variable, not fixed
Fixed technology expense becomes variable technology expense.
Humans stay at the two gates.
The factory owns everything between them — including every future change.
Business intent in. Production software out. Forever.