AI Software Factory
A prescriptive, gated SDLC specification for running software delivery through AI agents instead of ad-hoc prompting.
The problem
Most “agent builds software” setups I’d seen — my own included — were a single prompt loop: ask an agent to plan, then build, then maybe test. It works once, on a demo, and then falls apart the moment security, change approval, or audit trail matter. There’s no place where a human is supposed to sign off, no consistent definition of “done” for a given stage, and no way to point at a piece of work and say what phase it’s actually in. That’s a personal productivity problem, but it’s the same problem an engineering org hits when it tries to let agents touch production code: without named gates and named accountable roles, agent-generated work either gets rubber-stamped wholesale or blocked wholesale, because there’s no structure to review against. Regulated teams in particular can’t adopt agentic development at all without an answer to “who approved this, and what proves the checks ran.”
The approach
This is a specification, not yet a running tool — the project is deliberately still in its design phase, and I’ve kept it explicit in the docs that no runnable artifact exists so nothing oversells it. What it defines is a full software development lifecycle built from two structures that operate at once. Seven sequential phases (Initiation, Requirements & Analysis, Architecture & Design, Implementation, Verification, Release & Deployment, Operations & Maintenance) form the waterfall backbone, each with a named exit gate (G0 Charter through G5 Release) that states exactly what must exist and who must have approved it before work can advance — a Requirement Card can’t reach Phase 2 without Business Rules and Given/When/Then acceptance criteria, a build can’t reach Verification without every commit tracing to a Requirement Card ID. Running across those phases are six parallel streams — Requirements, Architecture, Implementation, Security, Quality/Test, Change Management — each owned by a named role (Functional Analyst, Technical Architect, Security Reviewer, Frontend/Backend/DBA, Solution Reviewer, Test Engineer, Release Manager, Ops/SRE), so Security and Architecture are reviewing draft requirements from Phase 1 onward instead of getting bolted on at the end. Every deliverable a role produces — Charter, ADR, C4 diagram, Threat Model, Test/Coverage Report, Change Record, Runbook — has a concrete skeleton file in a templates/ directory, so a phase task isn’t “design the architecture,” it’s “fill in this ADR template and flip its status to Accepted.” Roles are also tiered by model cost: Opus for architecture, security review, and cross-cutting solution review, Sonnet for the mechanical build and requirements-drafting work, with humans or human-paired roles kept explicitly in the loop wherever accountability can’t be delegated — sponsor sign-off on the Charter, Release Manager sign-off on deployment. The spec also names which checks are deterministic (lint, type-check, SAST, test pass/fail) versus which require human judgment, so it’s explicit about where code can gate automatically and where it can’t.
What I learned
The instinct to start from “which agents do I need” produces exactly the ad-hoc orchestration this project is reacting against — it looks reusable but each new task ends up needing its own custom wiring. Starting from the SDLC structure instead — what phase is this in, what gate does it need to pass, who owns that gate — made role assignment and model-tier choice fall out almost automatically, rather than being a separate design decision. The other concrete finding came from grounding the spec in actual research rather than intuition: I pulled and read all 68 references from an external survey on AI-driven SDLC tooling, and the single most corroborated signal across nearly all of them was that human-in-the-loop review has to be a first-class gate, not a courtesy check-in at the end — which is why every gate in this spec names an accountable human or human-paired role rather than leaving approval implicit. The research also surfaced a gap I wouldn’t have found by reasoning alone: the field is heavily skewed toward requirements-to-architecture and architecture-to-code generation (72% of studies combined) and almost silent on architecture-to-architecture work — refactoring and evolving systems that already exist (3%) — even though that’s where most real engineering time actually goes.
Where this could go
The immediate next step is picking one vertical slice — Phase 0 through the G1 Intake gate is the cheapest to make concrete — and actually running it end to end, since the templates and gates are hand-authored and haven’t been validated against a real execution yet. Past that, the open design question that matters most for enterprise adoption is whether low-risk change classes can auto-approve at the Release gate or whether every release stays human-gated by default; regulated environments will want that configurable and auditable, not fixed. The architecture-evolution gap the research surfaced is also a deliberate next target: most of what this spec currently optimizes for is greenfield build, and a team’s real backlog is dominated by modifying systems that already exist, which the SDLC’s phase/gate structure should extend to without a redesign. At team scale, the more interesting shift is that the same gate structure that lets one engineer trust an agent’s output is exactly what lets an engineering org grant agents write access to shared codebases at all — the gates are the mechanism that makes “agents can commit, but only through a provable process” something a compliance or security team can sign off on, not just a convenience for a solo developer.
Takeaway
The bet here is that agentic software delivery doesn’t scale by getting a smarter agent — it scales by giving agents the same phase-and-gate discipline that makes human engineering orgs auditable, and that’s worth designing before writing a line of orchestration code.
Text summarized and optimized using Anthropic’s models and reviewed by a human.