What AWS AI-DLC gets right, and where it stops short
In July 2025, AWS published a blog post titled AI-Driven Development Life Cycle (AI-DLC), written by one of its principal solutions architects. Strip away the vocabulary and the argument is one RACE Programming has been making since before a hyperscaler put its name on it: retrofitting AI as an assistant on top of a people-coordination process wastes most of what AI offers. The lifecycle itself has to change.
When an independent team inside the largest cloud provider on earth arrives at the same diagnosis you did, the correct first response is not defensiveness. It is recognition. The category (an AI-native software development lifecycle, not an AI-assisted one) is now mainstream enough that AWS is publishing on it. That is a tailwind for everyone working in the space.
So let me do the gracious thing first, then the honest thing. Here is what AWS got right. Then: where a blog-post sketch stops, and where a prescriptive framework has to keep going.
What AWS got right
The AI-DLC post and RACE Programming agree on more than they disagree, and the agreements are the load-bearing ones.
AI is a teammate, not a tool. AI-DLC positions AI as a “central collaborator and teammate” rather than a peripheral assistant. RACE Programming calls the same thing the Silicon Software Engineer: an agent that works inside the team, not a plugin bolted onto one engineer’s editor. Both frameworks explicitly reject the two failure modes at the extremes: AI-as-assistant (too timid, because you keep the broken process and just run it faster) and AI-as-autonomous (too reckless, because you let the model generate whole applications no one can stand behind).
The cycle compresses, and the old unit of time dies with it. AI-DLC replaces sprints with Bolts, work cycles “measured in hours or days rather than weeks.” RACE Programming replaces them with the one-week Stint, ending in a Pit Stop. Different durations, identical instinct: the two-week sprint is an artifact of human coding speed, and when coding is no longer the bottleneck, the timebox has to shrink.
The unit of work gets renamed because it changed. AI-DLC introduces Units of Work in place of epics. RACE Programming makes the Executable User Story its originating artifact. Both recognize that a Jira ticket written for a human to interpret is the wrong input for an agent that executes literally.
Humans stay on the decisions; AI takes the execution. AI-DLC’s core loop is “AI creates plans, seeks clarification, and implements plans, while humans make critical decisions,” what it calls “AI Powered Execution with Human Oversight.” RACE Programming draws the same line: the Pit Wall and Team Principal own intent, specification, and approval; the Silicon Software Engineer executes. This is delegation, not prompting, the foundational AI-native skill.
Context is infrastructure. AI-DLC stores “plans, requirements, and design artifacts to your project repository” so context persists across phases. RACE Programming calls this the Conversation Knowledgebase and folds it into Everything as Code: if it isn’t in Git, it doesn’t exist.
When two teams who were not talking to each other converge on the same skeleton (teammate-grade AI, a sub-week cycle, a re-specified work unit, humans on the decisions, context in the repo), the skeleton is probably right. That convergence is the most important thing in the AWS post, and it is worth saying plainly: it validates the thesis.
Where the sketch stops
A blog post sketches a shape. A framework you can hand to a delivery team has to answer the questions the sketch leaves open, and it is exactly those questions that decide whether the thing survives contact with a real engagement. There are four.
1. Topology: a mob, or a small team? AI-DLC’s collaboration model is the Mob: “Mob Elaboration” and “Mob Construction,” where product owners, developers, and architects gather for real-time problem-solving. It defines no role hierarchy; everyone is in the room. RACE Programming goes the other way. Its structural unit is the micro-team: a three-person Pit Crew with named, non-overlapping roles, behind a client-facing Pit Wall. The mob is intuitive and it is also where coordination cost hides, the very cost an AI-native cycle is supposed to remove. Naming who owns what is not bureaucracy; it is how you keep three people from re-deciding the same thing in real time.
2. Specification: “stories and units,” or an executable contract? AI-DLC produces “requirements, stories, and units of work.” Good, but a story is still prose, and prose is what an agent re-interprets. RACE Programming’s Executable User Story is a contract with seven components: user story, working prototype, NFRs in EARS, an ADR, acceptance in Gherkin, test data, and a dollar estimate. The difference is not pedantry. It is the difference between telling an agent what you want and giving it the minimum-sufficient context to build it without drift.
3. Verification: who is allowed to write the tests? This is the sharpest divergence, and it is not stylistic. In AI-DLC’s Construction phase, the AI “proposes a logical architecture, domain models, code solution and tests.” The same agent writes the implementation and the tests that judge it. That is the system grading its own homework. RACE Programming refuses this on principle. A dedicated Quality Engineer owns the executable Gherkin (the test source of truth) and the four-gate Definition of Done. The author of the acceptance intent (AI Product) and the agent that executes the code are separated by a Chinese Wall the AI cannot move. You do not let the thing being verified author its own verification. When implementation is cheap and confident-but-wrong output is the dominant risk, independent verification stops being a nicety and becomes the load-bearing wall.
4. Economics: a promise, or a number? AI-DLC describes its benefits qualitatively: tasks “in hours or days that previously took weeks.” There is no multiplier, no cost model, no client-facing accounting. RACE Programming commits to numbers: roughly three times the scope, or a third of the cost, or two-to-five times faster (pick the corner of the triangle you need) for the same budget as a traditional team, with delivery cost in dollars written into the roadmap before scope locks. A framework that a client buys has to put a number on the table. A blog post does not.
The honest conclusion
None of the four gaps are AWS getting it wrong. They are the difference between an architect describing a promising shape and a delivery organization committing to run on it. AI-DLC is a sketch by someone who sees the same future clearly, and the more hyperscalers sketch that future, the easier RACE Programming’s job becomes, because the category no longer needs defending.
But a sketch validates a category. It does not survive a delivery. The questions AI-DLC leaves open (who owns which role, what makes a specification executable, who is allowed to verify the AI, and what the whole thing costs) are precisely the ones a prescriptive framework exists to answer. That is the line between the two: AI-DLC tells you the lifecycle should change. RACE Programming tells you exactly how, and stands behind the number.
Written by Pavel Khodalev, author of RACE Programming and CTO of First Line Software. Follow new essays via RSS.