AI-DLC in a Team: the Agent Is No Longer the Bottleneck

In January I wrote about building this blog with AI-DLC, the AI-Driven Development Life Cycle. The setup was as small as it gets: one developer, one coding agent, a set of workflow rules in the IDE. The agent asked me questions, wrote requirements and user stories, proposed a design, generated code, and stopped at each phase so I could approve or correct it. It worked because there was exactly one person to ask.

Real software is not built by one person. The requirements belong to a product owner, the design review to a tech lead, the security questions to someone else again. So this month I deployed AIDLC Collaborative, an open-source sample from aws-samples that runs the same method as a shared platform for a team. I stood it up in a sandbox AWS account, ran intents through it with Kiro CLI as the agent, and watched every stage in the logs.

The short version: the method survives the move from IDE to team intact, the platform around it is serious engineering, and the number that matters most is not a model metric. Two intents consumed the same 48 minutes of agent work. One finished in 81 minutes, the other in 284. The difference was people.

What the team version adds

The methodology is the same one as in awslabs/aidlc-workflows: Inception decides what to build and why, Construction builds it, Operations deploys it. What changes is who runs it and where.

An intent is the unit of work. A team member writes a title and a prompt, picks a scope (feature, bugfix or larger) and an agent CLI: Claude Code, Kiro, OpenCode or Codex. The platform creates a branch named after the intent and runs the workflow.

Inception becomes shared. Requirements, user stories and the split into units are artifacts in a workbench, each with its own discussion thread. Several people can be on the same artifact at once, with live presence. When the agent needs an answer, it asks a question with buttons, and anyone on the project can answer it.

Construction fans out. Each unit gets its own lane, and the lanes run in parallel. A walking-skeleton lane goes first and pauses for approval; after that, lanes run autonomously or stop per batch, depending on the project settings. The lanes fan back in for build and test, and the intent ends in a pull request on GitHub or a merge request on GitLab.

Three safety nets, not one. Deterministic checks run before a stage can pass, an LLM reviewer agent reads the output, and humans approve at gates. A gate that waits for a person costs nothing: the orchestrator parks the run and no compute is used until someone clicks.

The agent never touches git. This is the design decision I like most. The agent works in a workspace; the platform creates branches, commits and pushes. Branch names, commit timing and the final pull request are the platform’s decisions, not something a model improvises in the middle of a stage.

Each stage runs in its own isolated session on Amazon Bedrock AgentCore, and the workflow itself is data: stages, personas, rules and checks are building blocks that an admin can recompose in a visual editor. Observability shows durations, tokens, cost and check verdicts per stage, and a graph traces every artifact back to the intent that produced it.

None of this is new as an idea. What is new is having all of it assembled around one method, with the human steps as first-class parts of the pipeline instead of chat messages somebody may or may not read.

The number that matters: 81 minutes versus 284

The test platform ran two complete intents with Kiro CLI before I started my own, both on the same small repository:

	Intent 1: “Create a todo application”	Intent 2: “Add note taking feature”
Wall clock, start to finish	81 min	284 min
Agent time	48 min	48.5 min
Human waiting inside stages	4 min	42 min
Gaps between stages	small	up to 76 min
Validations / questions	7 / 2	7 / 3
Kiro credits	76.33	84.04
Tokens (input / output)	305k / 68k	260k / 41k
Tests passing at the end	46 unit + 12 integration	119

The agent did the same amount of work both times. The wall clock more than tripled because people answered slower: a question sat unanswered, a gate waited for someone who was in a meeting, a stage finished and nobody opened the next one for over an hour.

In the solo setup from January, this never shows up. I was the only human, I was sitting in front of the IDE, and every question was answered within seconds. In a team, the agent is fast and the humans are the schedule. Three consequences follow, and they are about how you run a team, not about models:

1. Decide who answers what before you start. If requirements questions go to the product owner and design gates to the tech lead, those people need to know an intent is running and roughly when it will ask for them. The platform’s live presence helps, but it does not page anyone.
2. Count gates, not tokens. Seven validations and two or three questions per intent is the real cost to plan for. Each one is a context switch for a person. A model upgrade that saves ten minutes of agent time changes nothing if a gate waits an hour.
3. Zero compute while parked is what makes this affordable. A run that waits 76 minutes for a human costs nothing during those 76 minutes. Without that property, slow humans would also mean an expensive platform.

One measurement detail: for Kiro runs, the observability view shows credits, not dollars. Tokens are priced only for Bedrock models, so if you compare agents on cost, you will be comparing credits with dollars and need your own conversion.

Standing it up is a real deployment

This is a sample, not a managed service, and it deploys like the full application it is. The managed installer runs Terraform and Docker from the machine that launches it. My deployment created 1,629 resources and took 24 minutes end to end: about 4 minutes of init and plan, then the rest, with the Neptune graph database cluster taking the longest. The stack includes Lambda, ECS Fargate for the real-time collaboration server, AgentCore in a VPC with a NAT gateway, API Gateway (REST and WebSocket), a single CloudFront distribution, DynamoDB, Neptune, Cognito, S3, ECR and Secrets Manager.

What to plan for:

• The container images build on your machine, one for arm64 and one for amd64, so the deploying laptop needs a Docker-compatible engine and a decent upload link. Colima worked fine for me.
• Never deploy live in front of an audience. At 15 to 30 minutes, the deployment belongs to the day before.
• Each team needs a code host. The platform connects to GitHub or GitLab through an OAuth app or a GitHub App, and every project binds to one repository.
• Teardown is one command and does not ask twice. destroy --yes removes the environment without a confirmation prompt, but keeps the Terraform state bucket, which you delete separately.
• The running cost sits in Neptune, the NAT gateway, Fargate, AgentCore sessions and model tokens. Size them for your region before you leave an instance running for a week.

Credentials: one key can pay for everyone

The agents have no IAM fallback for model calls. Every run needs an explicit credential: a Kiro API key for Kiro CLI, an Amazon Bedrock API key for the other agents. The platform resolves it in a fixed order, personal first, then the project’s space, then the platform-wide default set by an admin.

That order has a governance consequence that is easy to miss. If an admin saves a platform-wide key, every project without its own key runs on it. On a shared instance, one person’s key silently pays for everyone else’s intents. That is convenient for a workshop and wrong for a real team, where each project should carry its own key and the platform default should stay empty.

The failure that painted 14 stages green

My own first intent looked perfect. Fourteen stages completed, all green, each in five to seven seconds. It had done nothing at all.

No tokens, no credits, no output. The runtime log explained why, one second at a time:

[run-stage] spawning cli=kiro stage=intent-capture ...
Access denied: The bearer token included in the request is invalid.
[run-stage] cli=kiro stage=intent-capture exitCode=0

The credential in the Kiro field was a Bedrock API key, pasted into the wrong field. Kiro CLI rejected it, printed the error, and exited with code 0. The platform treats exit code 0 as success, so it marked the stage as succeeded and moved on. Approving the gates just produced more empty green stages.

Two details made this harder to see than it should have been. First, my initial log check read only the newest runtime log stream, and the newest stream was always a fresh container holding just its start line; the error sat in the previous stream. Reading every stream in the log group found it in one command. Second, the platform already has code that classifies “access denied” as a credential error, but it only runs when the exit code is non-zero, so a zero skips it.

With a real Kiro key (they start with ksk_), the same stage ran for 24 seconds, printed Credits: 0.49 • Time: 24s and asked two questions. That footer turned out to be the best health signal: every healthy Kiro stage printed it, none of the rejected ones did.

I reported it upstream as issue #499, with the log lines and a suggested fix, and opened PR #500, a small change that warns in the credential form when a Kiro key does not start with ksk_. It catches my mix-up, not an expired or revoked key, which would still produce green, empty stages until the exit-code handling changes.

The general lesson is older than this platform: a green status proves the orchestrator ran, not that the agent did any work. Judge an agent stage by what it consumed and produced (duration, tokens or credits, output) and make the first intent after setting any credential a smoke test that checks exactly that. A stage that finishes in a few seconds with no usage is an authentication failure until proven otherwise.

What I verified, and what I have not

Verified first-hand: the deployment and its numbers; the two complete intents in the table above, read from the platform’s own execution records; the empty-stage failure, its root cause in the code, and the recovery with a real key; the credential resolution order; zero compute while a run is parked.

Not verified yet:

• My own intent has not reached its pull request. It is running on Kiro with the right key and is parked on a question in Inception. The two complete intents above belong to a teammate on the same test platform.
• Parallel construction lanes. Neither complete intent was split into several units, so the lanes never actually ran side by side. Everything I wrote about fan-out comes from the documentation and the code, not from a run I watched.
• The other agents. Every run I measured used Kiro CLI. I have not yet measured Claude Code on Bedrock through the platform.
• Load. When one intent started, the orchestrator logged a warning that its HTTP connection pool was at capacity with 151 requests queued. Stages still ran normally, but I have not tested several teams starting intents at the same moment.

Honest recommendation

If your team already likes AI-DLC in the IDE, the collaborative version is the right next step to try, because it fixes the part the IDE cannot: the method needs several people, and the IDE only knows one. The gates, the shared artifacts and the platform-owned git are the parts I would keep even if I rebuilt this myself.

Go in with three expectations. Plan the humans before the agents, because they set the schedule. Treat the deployment as an application you operate, not a tool you install. And make your first intent a smoke test that checks usage, not status, because a wrong key does not fail loudly.

The method was never the bottleneck, and in a team the agent is not either. The bottleneck is how fast the right person answers the next question.