One thousand pull requests is a striking output count. It is not, by itself, evidence of one thousand useful software changes.
AWS published a software-factory experiment on September 19, 2026 in which it says Kiro Crew helped three full-time developers and nearly 500 community contributors merge 1,000 pull requests in seven days. AWS says every merged change passed continuous integration and review. The report is valuable because it also documents the coordination, permission and cost problems that appear when dozens of agent sessions run together.
The reported result and its limits
The 1,000-PR figure is company-reported. CI and review are important filters, but their strength depends on the tests, reviewers and repository rules. A small documentation correction and a risky runtime change both count as one pull request. The result should therefore be read as evidence that the workflow handled high volume, not proof that it multiplied engineering value by a specific number.
AWS describes a five-stage scaling ladder
| Stage | Approximate scale | New requirement |
|---|---|---|
| Single session | One agent | Clear task and local review |
| Tabbed work | Three to five sessions | Visible ownership and branch separation |
| Memory and schedules | Ten to twenty sessions | Persistent state and repeatable triggers |
| Pipelines | More than twenty | Queueing, handoffs and failure recovery |
| Crew Mode | Roughly fifty or more | Coordinator, permissions, audit logs and cost controls |
This staged view is more reusable than the headline. A team should not jump from two assistants to fifty workers without introducing ownership, idempotency, queue limits and a way to stop or roll back work.
The coordinator becomes a system component
AWS says the coordinator becomes a bottleneck beyond roughly 50 sessions. That is expected: it must understand task state, prevent duplication, resolve dependencies and react when a worker fails. A useful coordinator should expose queue depth, oldest waiting task, retry count, worker health and the reason each task is blocked.
- Give every task a stable identifier and one explicit owner.
- Make repository writes idempotent where possible.
- Set per-worker and global concurrency limits.
- Stop retry loops after a defined ceiling.
- Require human approval for releases, secrets and destructive changes.
Host permissions are the true blast radius
Crew Mode can span laptops, EC2 instances and cloud desktops. The host decides which files, credentials, networks and tools a worker can reach. A prompt-level role is not a security boundary. Use task-specific credentials, narrow workspace mounts, outbound-network allowlists and separate production access from development agents. This is the same boundary that matters in containerized coding subagents.
Audit logs must survive the agent
AWS explicitly calls for tamper-resistant audit logs. Store the task, model, permissions, inputs, commands, tool results, file changes, reviewer decision and final commit outside the worker’s writable environment. If the same agent that performs a change can erase its trace, the record is not an audit boundary.
Measure accepted work instead of raw PRs
| Metric | Why it matters |
|---|---|
| Accepted-change rate | Separates proposed output from changes maintainers keep. |
| Review minutes per accepted change | Shows whether agents reduce or move human work. |
| Rollback and defect rate | Captures quality after merge. |
| Duplicate-work rate | Reveals coordination waste. |
| Cost per accepted change | Combines models, retries and review into one business measure. |
The GitHub Copilot runtime migration offers a useful comparison because large agent-assisted changes still require architecture, tests and maintainers who understand the final system.
How to reproduce the useful part safely
- Start with three independent low-risk tasks and measure review time.
- Add a shared task ledger before adding more workers.
- Introduce one coordinator with an explicit retry ceiling.
- Separate read-only, code-writing and deployment permissions.
- Export audit events to storage the workers cannot modify.
- Use cheaper models or deterministic scripts for monitoring when quality permits.
- Increase concurrency only when duplicate work and rollback rates remain stable.
The practical verdict
The Kiro Crew report is not a universal productivity benchmark. It is a detailed field note about what breaks when agent work becomes a production system. The strongest lesson is that concurrency without permissions, durable coordination, quality metrics and immutable audit trails creates faster uncertainty rather than faster engineering.
A controlled pilot should publish its rejected changes as well as its merges. Rejection reasons reveal whether workers misunderstand architecture, duplicate one another or generate patches that pass tests without solving the issue. That evidence is more useful for capacity planning than a single output total.
Primary source
Checked September 20, 2026. The output and quality figures are AWS-reported and should not be generalized without a disclosed workload and independent reproduction.
