The AI SDLC: what frontier engineering teams do differently
Software development has split into two groups. One changed its coding tools. The other changed how it works. Only the second group is shipping meaningfully faster, and the gap between them is now measurable in multiples, not percentages.
That is the core argument in Kiro’s two guides on frontier engineering, one written for practitioners and one for the managers who have to fund the change. The distinction matters for anyone running an engineering org right now, because the budget conversation about AI usually stops at licenses. Licenses are the cheap part. The expensive part is rebuilding the software development lifecycle so an agent can do useful work inside it.
Developers stop building the software directly and start building the agent setup that builds the software.
The figures
These are published results from teams inside Amazon, measured against their own baselines rather than modelled.
| Team | Result | Detail |
|---|
20x
Amazon Bedrock |
Individual productivity, top end |
Six engineers delivered in 76 days a project scoped for 30 developers over 12 to 18 months. Commits went from 2 per week to 40 per developer. |
6x
Prime Video |
Throughput acceleration |
A 90-week estimate compressed to 24 weeks. In a 10-day sprint on a 10-year-old payments system across 6 production services, the team produced 556 commits against a baseline of 96. |
4.5x
Amazon Stores |
Median productivity gain |
A multi-team pilot with typical engineers on their regular backlogs. Top teams exceeded 10x. One team now ships in an afternoon what used to take two weeks. |
<1%
Practitioners |
Share of code hand-written |
Frontier developers hand-write under 1% of what they produce. Teams working from explicit specs report 1 to 2%. |
Source: Kiro, frontier teams and frontier engineering guides. Results vary by team and codebase.
Two things are worth reading carefully in those numbers.
First, the Prime Video result was not one big multiplier. It breaks into three factors that compounded: roughly 1.5x from accelerating low-judgment work, 1.5x from uninterrupted focus on high-judgment work, and 1.5x from instant access to domain expertise the agents had captured. Around 3.4x from three unremarkable-looking gains stacked together. That is the shape of the opportunity, and it is also why single-metric AI dashboards miss it.
Second, none of these teams got there in week one. The consistent report is that things slow down first, while the team writes steering files, refactors modules, and learns to decompose work for agents. The acceleration comes after. Teams that expected an immediate return without changing their workflow were disappointed.
The ten principles
Kiro’s practitioner guide lists ten. Condensed:
- You are the architect, not the typist. The work is writing intent and verifying output. “Add auth to this API” is not intent. Which roles hit which endpoints, what happens on token expiry, and how to test unauthorized access is intent.
- Maximize agent time, minimize your involvement. Prompt, wait 60 seconds, paste the error back, repeat is the anti-pattern. Give the agent a 30-minute task with validation built in, such as implement the feature, write tests, run them, reach 90% coverage on new code. Then go do something else.
- Build your codebase for agents. A new hire onboards once. An agent onboards every session. That changes the return on READMEs, architecture docs, module boundaries, strong typing, and steering files that encode conventions. In legacy code, prepare one module at a time and scope the agent to it.
- Give agents a fast feedback loop. Linters, unit tests, a browser to verify UI, local mocks, and the ability to bring up the full stack locally. If you use a tool to check your own work, the agent should be able to run it too. Without this, faster generation just means more broken builds.
- Execution is cheap, direction is everything. Implementation details are cheap to change. System design, API contracts, and dependencies are not. Have the agent prototype two plausible designs and compare them, so debates get settled by evidence.
- Treat code as disposable. You can prototype in a day and walk away. The exception is the tests at the boundaries: end-to-end behavior, property-based invariants, and load tests. Those are the contract any rewrite has to satisfy.
- Hold AI output to human standards. You own what ships under your name. Review line by line early, then build an AI reviewer that runs before the pull request and again in CI, and keep human attention on architecture, blast radius, and security boundaries.
- Trust the boundaries, not the agent. Confidence should come from what you can verify and constrain, such as permissions, sandboxes, test gates, and interfaces, rather than from the agent behaving well on a given day.
- Use agents for everything, not just code. Migrations, docs, ticket triage, data pulls, and operational work all belong in scope. Restricting agents to the editor caps the gain at the smallest part of the job.
- Continuously tune your agent setup. Steering files, prompts, and tooling are living assets. Every improvement in model capability compounds on top of the setup you already built.
Worth keeping in front of the team: this is not vibe coding. It is engineering rigor plus agent leverage, and the skill that keeps mattering is managing your own attention.
For engineers and new ICs: the first 90 days
Most of the writing on this topic is aimed at the people approving the spend. If you are the engineer doing the work, or you just joined a team that already works this way, here is the same material as a path you can walk.
Week 1: read the setup, not just the code
- Find the steering files, the specs, and the architecture docs before you open a ticket. On a frontier team, that is the real onboarding material.
- Learn how to run everything locally: tests, linters, mocks, the full stack. Whatever you cannot run, the agent cannot run either.
- Take one small, contained task and do it the slow way, reviewing the agent’s output line by line. You are building a model of where this model is reliable and where it is not.
Weeks 2 to 4: practise writing intent
- Before prompting, write down what done looks like: behavior, edge cases, and how correctness gets verified. Vague prompts push tradeoff decisions to the agent, and undoing those costs more than the spec would have.
- Stretch task length. Move from five-minute prompts to tasks that run 30 minutes with validation built in.
- Expect the dip. The first two weeks feel slower for almost everyone who has done this. It is the cost of building intuition, not a sign it is not working.
Month 2: run more than one thing at once
- Keep a backlog of well-scoped tasks so there is always something to hand off. Your ceiling is now how many agents you can keep meaningfully busy, not how fast you type.
- Review asynchronously. Batch it rather than watching each run.
- Start contributing back to the setup: a steering file, a missing local mock, a script that removes a manual step. This is the highest-leverage work available to a new IC, and it is visible.
Month 3: own outcomes, not pull requests
- Put your attention where your judgment is worth most: design, interfaces, upstream and downstream impact, security boundaries.
- Stay with a change through production. Monitoring the deploy and fixing a regression is part of the loop now, not a separate job.
- Set an end to the day. When agents can run overnight, the discipline is deciding what needs your attention and what does not.
Three things that keep people stuck
Staying in the loop on every prompt. Skipping the spec because it feels like overhead. Treating the agent setup as somebody else’s job. All three feel productive in the moment and cap the gain at a few percent.
The five practices that separate frontier teams
From the managers’ guide, the highest-performing teams at Amazon shared five behaviors:
They invest in agent context. Steering files for conventions and testing patterns. One infrastructure team consolidated code and docs into a monorepo and kept the agents’ inline commentary as persistent memory.
They slow down to speed up. They pushed through the learning curve instead of abandoning it in week two.
They feed agents instead of babysitting them. A steady backlog of well-scoped tasks, multiple agents in parallel, asynchronous review, sometimes overnight runs reviewed in the morning.
They make intent explicit before code is written. Structured specs, requirements, or well-scoped decomposition, so done is defined up front.
They shift testing left. Agents run integration tests locally and self-correct before the pipeline. Code review moves from naming and style to interfaces and architecture.
Where does your team sit?
| Dimension | Still experimenting | Frontier-ready |
|---|
| AI usage | Autocomplete and ad-hoc prompts | Autonomous agents with structured context |
| Requirements | Verbal or buried in tickets | Explicit intent captured before code |
| Code quality | Review catches issues late | Tests and docs generated alongside code |
| Legacy code | Avoided or refactored by hand | AI analyzes and modernizes with guardrails |
| Governance | Per-developer tool choices | Org-wide steering files and policies |
Most orgs I speak to sit in the left column while reporting AI adoption in the board deck, because seat licenses are easy to count and workflow change is not.
The adoption path
- Onboard. One team, one contained feature or module. No org-wide rollout on day one.
- Experiment. Write the first structured requirements. Let agents generate code, tests, and docs. Compare quality against the current workflow.
- Scale. Add steering files for org-wide conventions. Roll out to more teams. Measure correctness, not just speed.
- Sustain. Build a champion model, share steering files and context across the org, and make AI-native development the default.
What to measure while you do it
This is where most programs go quiet. Seat licenses and prompt counts tell you nothing about whether the lifecycle actually changed. The Prime Video breakdown suggests what to instrument instead:
- Share of code that is agent-generated versus hand-written, trended per team, as the leading indicator of workflow change.
- Agent-hours per engineer per week, since the real constraint is how many agents someone can keep meaningfully busy.
- Focus time on high-judgment work, because one of the three multipliers was uninterrupted attention, not the model.
- Rework and revert rate on agent-generated changes, so speed gains are not paid for in production incidents.
- Review cycle time and where reviewers spend attention, which should move from style to interfaces if the shift is real.
- Throughput per engineer against a pre-adoption baseline, ideally the same team on the same backlog, which is what made the Amazon Stores pilot credible.
If you cannot separate the teams that restructured their workflow from the teams that installed a plugin, you cannot tell a 4.5x program from a flat one. That measurement gap is exactly the problem we built Waydev to solve.
The teams defining this way of working are doing it right now, and the practice is still immature. Nobody has fully worked out how to review agent output at scale, or how to design test infrastructure for agents rather than humans. That is an argument for starting, not for waiting.
Sources
- Kiro, practitioner’s guide to frontier engineering, including the ten principles and the guidance for individual engineers: kiro.dev/topics/frontier-engineering
- Kiro, frontier teams and spec-driven development, including the measured results, the five practices, the maturity model, and the adoption framework: kiro.dev/topics/frontier-teams
- Principle detail pages: architect not typist, maximize agent time, build for agents, fast feedback loop, direction over execution, code is disposable, human standards
All figures above are Kiro’s published results from Amazon teams. Results vary by team and codebase and are not guarantees.
