Six Engineers, 76 Days, and Why AI-DLC Is Now Essential

How AWS’s AI-Driven Development Lifecycle turns spec driven development with Kiro from a productivity trick into a governable engineering discipline

There is a number doing the rounds at the moment that should stop every technology leader in their tracks. In his 2025 letter to shareholders, Andy Jassy described how six engineers rebuilt the entire Amazon Bedrock inference engine in 76 days using Kiro, Amazon’s agentic coding service. The original estimate for that work was 40 engineers and a full year. The new engine, called Mantle, now sits at the heart of Bedrock’s scaling.

It is worth letting the ratio land. Roughly 40 person years of planned effort delivered by six people in two and a half months. As Jassy put it, that is not an incremental improvement. It is a category shift in how software gets built.

This was not a weekend hackathon or a throwaway prototype. It was production infrastructure underpinning one of the largest AI services in the world. And the thing that made it repeatable, rather than a one off feat of heroics, is a methodology that AWS has since written up and open sourced: the AI-Driven Development Lifecycle, or AI-DLC.

I want to make the case that AI-DLC is not just interesting. For any organisation that is serious about shipping software with AI in the next few years, it is becoming essential. Here is why, and here is how to get real value from it inside Kiro.

The problem AI-DLC actually solves

Most teams have already discovered that bolting AI onto the existing development process gives you a fraction of what the tools can do. There are two common failure modes, and both leave value on the table.

The first is fully autonomous generation, where you hand the agent an ambiguous prompt and hope an entire application falls out the other end. This is the “vibe coding” pattern, and in any serious context it is unreliable, hard to explain, and effectively impossible to govern. For a regulated business it is a non starter.

The second is timid autocomplete, where AI is treated as a slightly cleverer tab complete. It is easy to govern because it changes almost nothing, but it captures only a sliver of the available leverage. You get the typical ten to fifteen percent productivity bump and a backlog that still grows faster than the team can clear it.

Underneath both sits a structural ceiling. Traditional Agile still depends on humans to write, review, test, and deploy every line. Even disciplined Scrum teams are limited by human cognitive throughput, which is why delivery is measured in weeks and the backlog never shrinks. Hiring does not fix this; it just moves the bottleneck.

AI-DLC charts a deliberate middle path. AI orchestrates the work, generating plans, code, tests, and infrastructure configuration at every stage. Humans keep oversight, decision authority, and accountability. The developer’s job shifts from writing code to directing and validating what the agent produces. It sounds like a subtle distinction. The operational impact is anything but.

What AI-DLC is, in plain terms

At its core AI-DLC runs on a simple repeating mental model. The AI proposes a plan, asks clarifying questions to fill gaps in its context, and only implements once a human has validated the approach. That loop repeats for every activity in the lifecycle, and each pass leaves behind richer context for the next.

Two of the phases are run as a mob, so it is worth pausing on the word. The term comes from mob programming, a practice popularised by Woody Zuill in which the whole team works on one problem at the same time, in the same place, rather than splitting it up and reconciling the pieces later. One person acts as the hands while everyone else directs, and the group reasons through the work out loud as it goes. AI-DLC takes that idea and adds the agent as a participant in the room. The AI proposes, drafts, and asks questions, while the people provide the context, make the judgement calls, and approve each step. The point of working this way is shared understanding in real time, and that shared understanding is exactly what produces the high quality context the agent depends on.

The Three Phase Loop

The methodology organises this into three phases.

Inception decides what to build and why. A cross functional group works together to turn business intent into requirements, user stories, and small consumable units of work. AWS calls this Mob Elaboration. The key insight here is that AI thrives on specificity: the richer and clearer the inputs, the higher the quality of everything generated downstream.

Construction decides how to build it. With the validated context from Inception, the agent proposes a logical architecture, domain model, code, and tests, including security and resilience tests and Infrastructure as Code. Humans review and refine continuously. The cadence flips from “write code, then review” to “review generated code as it lands”. Documentation is produced and updated on the fly.

Operations covers deployment and what comes after. Infrastructure as Code flows through CI/CD pipelines, and agents can assist with monitoring and incident investigation. Crucially, what is learned in production feeds back into the agent’s context, informing the next Inception cycle.

AI-DLC even retires some of the familiar Agile vocabulary to reflect the new tempo. Sprints become “bolts”, short and intense cycles measured in hours or days rather than weeks. Epics become “units of work”. The seven person Scrum team gives way to an “AI Pod” of two or three developers working in a mob format. The language change is not cosmetic. It signals that the unit of delivery has shrunk and the clock has sped up.

Why it is essential, not merely useful

Velocity is the headline, but velocity is not the reason AI-DLC matters. The reason is that it makes that velocity safe to scale. This is the part that turns a clever productivity story into something a CTO can actually stand behind in front of a risk committee.

Consider what happens when AI generated change volume goes up by an order of magnitude and your controls do not. You get speed today and an unmanageable liability tomorrow. Code nobody can trace to a requirement, changes nobody can explain to an auditor, and a security posture that was designed for a slower, smaller flow of commits. Speed without governance is not an advantage. It is a time bomb.

AI-DLC puts the governance where it belongs, at the start, through what AWS calls steering files. These are structured documents that tell the coding agent how to behave: your security policies, architecture standards, approved dependency lists, regulatory requirements such as the EU AI Act, and your responsible AI principles. Instead of bolting controls on after the fact, you fold them into the agent’s operating parameters from the outset. This is governance as code, and it is the single most important idea in the whole methodology.

It is backed by end to end traceability. A failing test can be traced to the code, the code to a user story, the user story to a requirement, and the requirement to the original business intent. That chain is exactly what audit and regulatory review demand, and it is generated as a by product of the workflow rather than reconstructed painfully after release.

The methodology also brings a measurement discipline. It promotes a set of metrics that are designed to pull against one another so that you cannot game one at the expense of the rest: mean time to deployment, mean time to recovery, change failure rate, events by severity, technical debt, and customer satisfaction. Speed that quietly wrecks reliability shows up immediately rather than six months later.

And there is a clean economic argument. AWS frames it through its Cost-to-Serve-Software lens with a worked example: a bank with 1,000 developers at an all in cost of 130,000 dollars each carries 130 million dollars of developer expense. A fifteen percent improvement is 20 million dollars of cost avoidance against a two million dollar investment, a tenfold return. You can quibble with any single assumption, but the order of magnitude is hard to ignore.

Put those together and the case for “essential” writes itself. AI assisted development is already happening in your organisation whether you have sanctioned it or not. The only real choice is whether it happens inside a governed, traceable, measurable framework, or outside one. AI-DLC is the framework.

This is not only a regulated industries story

It would be easy to read all of the above and conclude that AI-DLC is a heavyweight process for banks and insurers, something you reach for only when an auditor is looking over your shoulder. That would be a mistake, and it would miss the most important thing about the methodology.

Think about what happened to Agile. It emerged from a specific frustration with rigid, document heavy delivery, and within a few years it had been adapted to almost everything: two person startups, scale ups, government departments, and enterprises with thousands of engineers. Nobody runs Agile in quite the same way, and that is precisely why it spread. The principles were universal; the implementation flexed to fit the context. AI-DLC has exactly that shape.

The open source rules are explicitly adaptive. The workflow only runs the stages that add value to a given request, complex changes get the full treatment while a small bug fix stays lightweight, and the depth of design scales with the risk of the work. A solo founder shipping a side project and a platform team rebuilding core infrastructure are running the same loop of plan, clarify, implement, and review. They are simply dialling the ceremony up or down to match what is in front of them.

Strip away the compliance language and the benefits are universal. Every team, in every sector, wants code that matches intent rather than an abstract guess at it. Every team wants its conventions applied consistently without restating them in each conversation. Every team gains from documentation and tests generated as work happens rather than bolted on later, and from being able to trace a change back to the reason it was made. A startup may never face a regulator, but it will still thank itself for that traceability the first time it has to work out why a feature behaves the way it does, or onboard a new engineer into a codebase the founders built at speed.

So the governance machinery that makes AI-DLC safe for a bank is the same machinery that makes it sane for everyone else. In a regulated environment those controls are mandatory. Everywhere else they are simply good engineering, applied earlier and enforced automatically. That is why this matters across development environments of every shape and size, and why, like Agile before it, it is likely to become the default rather than the exception.

Spec driven development is the actual unlock

If there is one principle to take away, it is this: context quality drives output quality. The Mantle result did not come from a magic prompt. It came from feeding the agent precise, well structured context and keeping humans in the decision seat throughout.

This is why spec driven development sits at the centre of AI-DLC, and why Kiro is built around it. A specification is not bureaucratic overhead. It is the highest leverage artefact you can give an agent, because it is the difference between the model building what you meant and the model building an abstract guess at what you meant. The steering files are simply standing specifications: the conventions, constraints, and decisions that should apply to every piece of work without you restating them in every chat.

Once you internalise that, the workflow stops feeling like a constraint on the AI and starts feeling like the thing that lets you trust it with more.

AWS Kiro IDE — https://kiro.dev

Getting the best out of AI-DLC in Kiro

AI-DLC is deliberately tool agnostic. AWS open sourced the rules under a permissive licence at github.com/awslabs/aidlc-workflows, and they work with Kiro, Cursor, Cline, Claude Code, and GitHub Copilot. The rules are identical across platforms; only the file location changes. That portability matters, because it means adopting AI-DLC is not a bet on a single vendor.

That said, Kiro is the most native home for it. Kiro is AWS’s agentic IDE, it was the tool behind the Mantle rebuild, and its steering system maps directly onto the methodology. Here is how to set it up and, more importantly, how to get real leverage from it.

Install the rules as steering files. Download the latest release from the repository, then place the core rules under .kiro/steering/aws-aidlc-rules and the detailed rules under .kiro/aws-aidlc-rule-details. In the IDE you should see a core-workflow entry in the steering panel; from the CLI, /context show confirms the rules are loaded. Run in Vibe mode, and if Kiro nudges you towards spec mode, decline it so the AI-DLC workflow stays in charge.

Trigger the workflow explicitly. Start any task with the phrase “Using AI-DLC, …” and the workflow activates, asks structured questions, and proposes an execution plan showing which stages will run. You review and approve each stage, and the generated artefacts land in an aidlc-docs/ directory you can version and audit.

Lay the foundations first. Before anything else, generate Kiro’s three foundational steering files: product.md for purpose and users, tech.md for your stack and constraints, and structure.md for file organisation and architectural conventions. These load into every interaction and become the baseline the agent reasons from. If your team already maintains a development standards document, this is where it earns its keep, transcribed into steering files the agent actually enforces.

Use inclusion modes deliberately. This is where most teams under use Kiro. Steering files support four loading modes, and matching them to intent keeps context sharp:

• Always for universal standards such as the core workflow, security policy, and coding conventions.
• Conditional (fileMatch) for guidance that should only appear for certain files, for example API design rules scoped to your routes, or test conventions scoped to test files.
• Manual for occasional playbooks you pull in on demand with #file-name, such as a migration runbook.
• Auto for context heavy guidance that loads when your request matches its description, similar to a skill.

You can also link live workspace files into a steering file with the #[[file:path]] syntax, so a rule about API conventions can point at your actual OpenAPI spec and never drift out of date.

Treat steering as a team asset, not a personal one. Workspace steering lives in the repository and travels with the project. Global steering in ~/.kiro/steering applies across all your workspaces, and the same mechanism supports team steering: a central set of standards pushed to engineers' machines through MDM or a shared repository. For a leader trying to hold a consistent engineering standard across multiple teams, contractors, or even multiple countries, this is the lever. Your standards stop being a wiki page nobody reads and become rules the agent applies on every change.

Layer on extensions for hard constraints. The open source rules ship with an extension system. Extensions live under aws-aidlc-rule-details/extensions/, grouped by category such as security/ and testing/, and there are built in examples including a security baseline and property based testing. Each extension can have an opt in prompt presented during requirements analysis; once enabled, its rules are blocking, meaning the agent must verify compliance before a stage can proceed. You can write your own, giving each rule a stable identifier such as COMPLIANCE-01 so it shows up in audit logs and compliance summaries. Treat the bundled security rules as a starting reference, then build and test your own for production.

Version control your steering and review it like code. Steering files are part of your codebase. Commit them, review changes to them, and never put secrets in them. A change to a steering file can change the behaviour of every future generation, so it deserves the same scrutiny as a change to production code.

The honest caveats, which strengthen the case

A piece like this would be worthless if it only sold the upside, so let me be straight about the limits, because they actually reinforce why the methodology matters.

The Mantle headline came with enabling conditions. Every line of generated code was reviewed by a human before it was committed. The work was structured to suit an agent: small isolated modules, a monorepo so the model could see the whole system, and deliberate engineering choices that made it easy for the AI to catch and fix its own mistakes. The number is real, but it is the output of a disciplined environment, not of pointing an agent at a vague brief.

AWS is equally blunt about prerequisites. AI-DLC amplifies existing capability; it does not compensate for its absence. If your CI/CD is slow, your tests are low fidelity, and your security scanning is periodic and manual, AI-DLC will simply expose those gaps faster. Mature DevSecOps is not a nice to have alongside this methodology. It is the precondition for it. The infrastructure work that follows is real: pipelines redesigned for velocity with risk based change categorisation, high fidelity test environments, and security that runs continuously rather than in quarterly bursts.

None of this is an argument against adopting AI-DLC. It is an argument for adopting it properly. The organisations that win will be the ones that treat the supporting infrastructure as part of the investment rather than an afterthought.

Where to start

AWS suggests a sensible three phase adoption, and it holds up. First, get executive alignment, so leadership understands how AI-DLC differs from traditional Agile and ties adoption to measurable outcomes; without sponsorship this stalls at the pilot. Second, build technical enablement, equipping your architects and engineering leads with deep fluency in an agentic tool such as Kiro and identifying champion teams. Third, run hands on pilots where teams bring a real codebase and ship something real over a few days, generating the proof points that earn a wider rollout.

The deeper point is the one Jassy reached for. This is a category shift, not a tuning exercise. The teams that keep treating AI as autocomplete will get autocomplete results. The teams that rebuild their lifecycle around AI, with the discipline and governance that makes it trustworthy, are going to operate at a tempo their competitors cannot match. AI-DLC is the most credible, most governable, and most openly available blueprint for doing exactly that. That is why it is essential.

You can get started by downloading the AWS repo: https://github.com/awslabs/aidlc-workflows

Further reading: the original methodology blog, AI-Driven Development Life Cycle: Reimagining Software Engineering by Raja SP; the financial services deep dive, AI-Driven Development Lifecycle for Financial Services by Silvia Prieto, Jean-Francois Landreau, and Richard Caven; the open source rules at awslabs/aidlc-workflows; and Kiro’s steering documentation.