Six engineers completed a 30-person project in 76 days

A 30-person challenge

Amazon Bedrock is the foundation for generative AI application development across AWS, providing customers access to leading foundation models through a fully managed API. Behind this service, the inference engine handles billions of requests, routing prompts to models and returning responses at scale.

When the team identified the need to rebuild a critical portion of this inference stack, the conventional estimate was clear. It would require 30 engineers, 12 to 18 months. The existing architecture used a load balancer to distribute requests and dedicated pools of capacity for each model that limited efficiency and utilization for highly-variable, long-running inference requests.

Anthony Liguori, VP and Distinguished Engineer at AWS, saw a different path. Rather than scaling the team to meet the timeline, he wanted to test a hypothesis: that a small group of senior engineers, working with AI as the foundation of their workflow, could deliver the same outcome in a fraction of the time.

He assembled six engineers. All senior, L7 or above. All deeply embedded in the problem space. And he made a deliberate choice that would define the experiment: Kiro would be the primary development environment, and the team would redesign their entire way of working around it.

Not a productivity hack; a workflow redesign

This was not about adding an AI assistant to an existing process and measuring the speedup. The team spent its first weeks doing something counterintuitive: slowing down.

They redesigned their workflow from first principles. How should code be organized so an AI model can reason about it effectively? How should tasks be scoped so an agent can complete them autonomously? What infrastructure needs to exist so that AI-generated code can be validated with high confidence before it reaches production?

The answers became the operating system for the project:

Task-driven development. Complex work broken into small, manageable prompts, each scoped to produce a single, reviewable commit. Not “build me a load balancer,” but “implement the request routing logic following the pattern in module X.”

Context engineering. Code organized into many small, isolated modules so the model only needs to consider a narrow section at any time. A monorepo structure where all code and documentation lives in one discoverable place.

Curated tooling. A minimal, purpose-built MCP server focused on operations and debugging, not a massive default toolset that blows out the context window.

No traditional code reviews. Senior engineers review all AI-generated code directly. Every commit is attributed and reproducible. The team trusts the process because they understand every line.

What I thought would take over a year

The initial expectations were modest. Liguori hoped for a 10 to 20 percent improvement in velocity.

What happened instead surprised everyone.

Within weeks, the team discovered that tasks which normally took a week or two could be accomplished in about an hour. The compounding effect was dramatic. Engineers weren’t just writing code faster; they were moving through the entire development lifecycle without the traditional bottlenecks of compilation debugging, test scaffolding, and context-switching between meetings and deep work.

The team shipped approximately 100,000 lines of new Rust code in 76 days. Individual developers committed 40 or more times per week. Liguori himself committed 951 changes to production; by his own reckoning, more code than in the preceding six to eight years of his career combined.

The team is confident they could sustain over 100 commits per week per developer if build times were faster than 45 minutes, suggesting the current velocity is constrained by infrastructure, not by the approach itself.

The creative work expanded

The more profound shift was not in speed. It was in how engineers spend their time.

Before Kiro, development was fragmented. Compile issues. Debugging unit test failures. Waiting for builds. Context-switching between meetings and deep work. The creative aspects of engineering, design, architecture, and exploring novel approaches, were constantly interrupted by mechanical tasks.

With Kiro, that dynamic inverted. The tedious work of debugging, compilation, test generation, boilerplate became automated. What expanded was the creative work.

The team spends significantly more time in front of whiteboards now. When you can code 10× faster, you invest more in getting the design right. They explored sophisticated algorithms and novel architectural patterns that would have been economically infeasible before. These were ideas that no one would have approved staffing for under traditional estimates.

How the team actually operates

The daily mechanics look nothing like a typical engineering team:

Minimal meetings. One 30-minute daily standup. No 1-on-1’s. No sprint ceremonies. Open-door policy. High bandwidth, low latency communication.

Physical co-location. Everyone sits next to each other. At the speed this team operates, being together is critical for coordination. Decisions that would take a day over Slack take five minutes in person.

Asynchronous progress through agents. Engineers kick off tasks, attend to other responsibilities, and return to completed output. One principal engineer shipped complete changes with only “a couple of hours of contiguous time” because the agent worked while he moved between responsibilities.

Comprehensive testing as the confidence layer. High-fidelity mocking of external services. Full end-to-end canaries. A tight dev/test cycle where changes can be pushed to production with 99% confidence from a developer’s desktop. This is what makes the velocity sustainable, not just fast, but safe.

Cleared calendars. The team treats focus time as non-negotiable. No recurring project-specific meetings beyond the daily standup. No context-switching tax.

A codebase designed for AI

The team’s high success rate, approximately 95% of prompts producing usable code, didn’t happen by accident. It’s attributed to a codebase specifically designed for AI productivity.

The principles, notably, mirror what makes code good for humans:

Extensive documentation. Far more markdown and code comments than any project Liguori has worked on. Kiro generates documentation as it codes, creating a self-reinforcing feedback loop where good docs make the next prompt more effective.

Simple logic and modularity. Small modules that the model can read entirely within its context window. Good prompts reference existing patterns such as, “follow the pattern in module X when implementing Y.”

Comprehensive testing infrastructure. The model can run full end-to-end canaries and self-correct when tests fail. This closes the loop. It can write, test, fix, and commit without human intervention for routine issues.

Steering rules. Minimal rules that ask the AI to keep documentation up to date, creating a virtuous cycle where the codebase becomes more AI-friendly over time.

Rust as a happy accident. Errors caught at compile time with friendly error messages help the AI self-debug. “It was a happy accident that Rust is amazing for GenAI development,” Liguori notes. The compiler acts as a second validation layer that catches issues before they reach production.

Beyond code; the first tool for everything

The transformation extends beyond writing code. Kiro became the team’s first tool for production operations.

When paged at 2 AM, Liguori reaches for Kiro first. The model runs CloudWatch Logs Insights queries across multiple log groups and regions simultaneously, analyzing patterns across production systems faster than any human operator could.

The team built automated triage on every incoming ticket, with the model reaching root cause 80% of the time. All operations run through CloudWatch with zero operator access to production hosts; the model has the same access to operational data as the engineers themselves.

This is where the 20× number becomes tangible. It’s not just 20× faster at writing code. It’s 20× faster at understanding a system, diagnosing a problem, validating a fix, and shipping it safely.

What this means for engineering at scale

This isn’t a story about replacing engineers. It’s about what becomes possible when you remove the friction between creative intent and production reality.

The team that started with 6 has grown to 11. They’ve delivered what Liguori estimates represents two years of output from a traditionally staffed team. But the deeper insight is structural: small, highly communicative teams can now own scope that previously required much larger organizations.

For engineering leaders considering this approach, the evidence points to five conditions that matter:

1. Redesign the workflow, not just the tooling. Teams that add AI to existing processes see modest gains. Teams that restructure how they work see order-of-magnitude improvements. The difference is not the tool; it’s the willingness to rethink everything around it.

2. Start small and senior. Everyone on the team must be deep in the project and hands-on with AI. High-bandwidth communication. Cleared calendars. No part-time participants.

3. Invest in the dev/test cycle first. If you can write, test, and push a change to production with 99% confidence from your dev desktop, your project will be extremely successful with AI. If you can’t, that’s what you need to fix before anything else.

4. Expect the hockey stick. Every developer on the team had a moment where it clicked — starts slow, then accelerates dramatically. The teams that quit in week two never see the compounding gains that arrive in week four.

5. Don’t vibe code. Understand every line. Treat AI like a compiler and prompting like a new programming language. The engineers who succeed are the ones who maintain full ownership of what the model produces.