Measuring Success in AI-Assisted Development
Breaking down the AI for SDLC success metrics using the SPACE framework and show how Kiro keep teams on track.
One question keeps coming up in my conversations with engineering leaders: "How do I know if AI coding tools are actually working for my team?"
The answer isn't as simple as "we're shipping more PRs." In fact, recent industry research reveals a more nuanced picture, one where speed without structure creates problems that are worse than the ones AI was meant to solve.
In this post, I'll walk through what the latest industry reports tell us about AI-assisted development outcomes, investigate concrete success criteria using the SPACE framework, and show how Kiro is designed to hit those criteria from the start. Spoiler alert: especially how Kiro handle Context Engineering.
What the data actually shows
Let's start with what the research says. I pulled findings from five major reports published between late 2025 and mid-2026:
- DORA AI Capabilities Model (2025) — 5,000 technology professionals surveyed
- Faros AI Engineering Report (2026) — 22,000 developers, 4,000 teams, two years of telemetry
- DX Longitudinal Analysis (2026) — 400+ companies, Nov 2024 to Feb 2026
- DX Q1 Impact Report (2026) — 400+ companies, quarterly benchmarks
- Jellyfish State of Engineering Management (2026) — 636 professionals, 700 companies
Here's the summary:
| Metric | Finding | Source |
|---|---|---|
| PR throughput gain | 5–15% (median 7.76%) | DX Longitudinal |
| Task throughput increase | +33.7% | Faros |
| Bugs per developer | +54% | Faros |
| Incidents per PR | +242.7% (tripled) | Faros |
| PRs merged without review | +31.3% | Faros |
| Code churn (delete-to-add ratio) | +861% | Faros |
| Median time in PR review | +441.5% | Faros |
| AI adoption rate | 93% of developers | DX Q1 |
| Time saved per developer | 3.9 hours/week | DX Q1 |
| Teams seeing productivity increase | 91% | Jellyfish |
The pattern is clear: throughput is up, but quality is not keeping pace. Faros calls this the "Acceleration Whiplash". AI floods a system built for human-paced development with output it was never designed to absorb.
What I've seen: speed alone doesn't get you there
DX found that coding represents only ~14% of a developer's day. Even cutting that time in half yields single-digit improvements to overall throughput. The real bottlenecks are upstream (requirements clarity, planning, scoping) and downstream (review, testing, integration).
As one developer put it: "A four-day task might take three. But that doesn't mean I'm shipping 3x more PRs."
DORA's research adds a critical insight: AI is an amplifier. It magnifies the strengths of high-performing organizations, and the dysfunctions of struggling ones. The seven foundational capabilities that determine whether AI helps or hurts are:
- Clear and communicated AI stance
- Healthy data ecosystems
- AI-accessible internal data
- Strong version control practices
- Working in small batches
- User-centric focus
- Quality internal platforms
Where collaboration fits in: the SPACE "C" dimension
Most of the reports above focus heavily on throughput and quality: the "P" and "A" in the SPACE framework (Satisfaction, Performance, Activity, Communication & Collaboration, Efficiency). But in my experience, the teams that succeed with AI coding tools are the ones that got the "C" right first.
A quick refresher on SPACE
The SPACE framework was developed by Nicole Forsgren and the Microsoft Research team in 2021. It measures developer productivity across five dimensions:
| Dimension | What it measures |
|---|---|
| S — Satisfaction & Well-being | Developer happiness, psychological safety, burnout |
| P — Performance | System outcomes, change failure rate, value delivery |
| A — Activity | Volume of work actions, PR frequency, build counts |
| C — Communication & Collaboration | Knowledge sharing, cross-team coordination, documentation |
| E — Efficiency & Flow | Cycle time, context switching, uninterrupted focus |
What I've noticed in an AI-assisted world is that "communication and collaboration" has a new meaning.
The "C" dimension now includes human-to-AI communication
When AI becomes your pair programmer, the question isn't just "how well do developers communicate with each other?" It's also: how well does your team communicate its knowledge to the AI agent?
Think about it. Your coding standards live in a wiki. Your architecture decisions are in a design doc. Your deployment runbooks are in Confluence. Your API conventions exist as tribal knowledge in the heads of senior engineers. None of this is accessible to the AI when it's generating code.
The root cause of most AI quality failures isn't the model being "dumb." It's the model being uninformed. It writes code that's technically correct but completely wrong for your project because it doesn't have your context.
The Context Engineering concept: the systematic practice of curating, structuring, and delivering the right knowledge to an AI agent at the right time.
An interesting phrase I heard recently is that "Context Engineering is to AI agents what API design is to microservices, the contract that makes collaboration predictable".
Measuring the "C" dimension for AI-assisted teams
Here's how I map SPACE's "C" metrics to the AI-assisted world:
| Traditional "C" Metric | AI-Assisted Equivalent | What to measure |
|---|---|---|
| Knowledge sharing practices | Standards accessible to AI at authoring time | % of coding standards loaded in AI context |
| Cross-team coordination | Shared context packages across the org | # of teams using shared Powers/steering |
| Documentation quality | AI-accessible internal data | Context completeness score per project |
| Decision-making efficiency | Specs as shared contracts between human and AI | % of features starting with a spec |
| Collaboration quality | Human + AI reviewing against same intent | Review time with spec vs. without spec |
Context Engineering: the five methods in Kiro
Kiro provides mechanisms for Better Context. Each maps to a different combination of scope, timing, and source. I think of them as layers, you start at the bottom and add layers as your team matures.
Layer 1: Steering Files
Persistent project knowledge that lives in your repo under
.kiro/steering/. These are markdown files that teach the AI your conventions, patterns, and constraints.Inclusion modes:
- Always — loaded every time (project-wide conventions, security rules)
- Conditional — loaded based on file glob patterns (React rules for
.tsxfiles) - Auto — AI decides relevance (topic-specific guidance)
- Manual — developer activates explicitly
Best for: Team conventions, error handling patterns, naming standards, framework-specific rules.
Layer 2: MCP Servers (Model Context Protocol)
Open protocol connections to external systems — Jira, Confluence, AWS services, monitoring dashboards. MCP servers give the AI tools to query real-time information.
Best for: Pulling ticket details, checking deployment status, querying internal docs — all without the developer leaving the editor.
Layer 3: Powers
On-demand bundled context that combines tools + steering + guidance in a single installable package. Powers activate on keywords, and the best thing: they don't consume tokens until triggered.
Best for: Specialist knowledge without permanent context cost. Distributing org-wide standards across 50+ developers with one-click install. Wrapping MCP servers so tools activate only when relevant.
Layer 4: Agent Skills
Portable instruction packages following the open Agent Skills standard (by Anthropic). Skills bundle step-by-step instructions, example files, reference docs, and executable scripts. They activate on task match.
Best for: Multi-step repeatable workflows: compliance validation, multi-tool orchestration (create ticket → link PR → update board), code review checklists.
Layer 5: Custom Agents
Specialized AI personas with their own behavior, tools, and permissions. A code review agent thinks differently than a development agent. A security agent has different guardrails than a documentation agent.
Configuration: Custom prompt (behavior/guardrails) + MCP servers (which tools) + allowed tools (auto-execute vs. require approval).
Best for: Task-specific personas: a strict code reviewer, a read-only production agent, an incident response agent with different urgency and focus.
Defining success criteria for AI-assisted development
Based on the reports and the SPACE framework, here are some success criteria that matter organized across dimensions that cover all five SPACE letters:
Satisfaction & Well-being (S)
| Metric | Target | Why It Matters |
|---|---|---|
| Developer confidence in AI output | Rising quarterly | Low confidence = time spent second-guessing (DX) |
| Burnout indicators | Stable or declining | AI review burden can increase cognitive load (Faros) |
| Tool satisfaction score | >70% positive | Unhappy devs with AI tools become less productive first (SPACE) |
Performance (P)
| Metric | Target | Why It Matters |
|---|---|---|
| Incidents-to-PR ratio | Stable or declining | Primary quality signal — if rising, slow down (Faros) |
| Change Failure Rate | Stable or declining | Some companies seeing +50% degradation (DX Q1) |
| Bugs per PR | Stable or declining | +28.7% increase is the industry average (Faros) |
| Reopened tickets | <13% increase | Work marked done but sent back = quality gap (Faros) |
Activity (A)
| Metric | Target | Why It Matters |
|---|---|---|
| Daily active usage rate | >60% of team | Correlates with higher time savings (DX) |
| PR throughput per developer | +5–15% sustained | Realistic industry benchmark (DX Longitudinal) |
| Spec adoption rate | >50% of new features | Measures structured vs. unstructured AI use |
| Shadow AI percentage | <10% | Unmonitored usage bypasses guardrails (DX) |
Communication & Collaboration (C) — Context Engineering metrics
| Metric | Target | Why It Matters |
|---|---|---|
| Context completeness per project | Increasing | Projects with steering files produce fewer wrong-path PRs |
| Shared Powers adoption | >3 org-wide Powers active | Measures whether knowledge is distributed vs. siloed |
| Spec-first feature ratio | >50% | Specs are the collaboration contract between human and AI |
| Review time (spec vs. no-spec) | Spec PRs ≤50% of no-spec PRs | Direct measurement of communication quality improvement |
| Context-related rework | Declining | Work restarts caused by "AI didn't know" should trend to zero |
Efficiency & Flow (E)
| Metric | Target | Why It Matters |
|---|---|---|
| Code churn ratio | Monitored monthly | Separates productive refactoring from rework (Faros) |
| Time in PR review | Stable or declining | Rising = review bottleneck forming (Faros) |
| Work restarts | <15% increase | Tasks returning to in-progress = context quality issue (Faros) |
| Net time gain | Positive after review overhead | Time saved coding can be consumed by review (DX) |
| AI spend per developer | Tracked against throughput | Token costs becoming #1 challenge (Jellyfish) |
How Kiro addresses each failure mode
Now let's connect the dots. Each problem identified in the research maps to a specific Kiro capability.
Problem #1: Code arrives for review not ready to ship
What I've seen: PRs merged without review up 31.3%. Median review time up 441%. Faros concludes: "This is an authoring problem, not a review problem."
Kiro's answer: Spec-driven development
Instead of jumping from prompt to code, Kiro works with developers through a structured flow:
- Requirements — What should this do? What are the constraints?
- Design — How should it be built? What's the architecture?
- Tasks — Sequenced implementation steps, each deployable independently
The spec becomes the source of truth before a single line of code is written. The AI executes against the spec, not against a vague prompt.
Success criteria this addresses (SPACE dimensions):
- P: Reduces incidents-to-PR ratio (code matches intent from the start)
- E: Reduces review time (reviewer validates against spec, not reconstructs intent)
- E: Reduces work restarts (clear scope prevents wrong-path development)
- A: Reduces code churn (less rework of code that "looked right but wasn't")
Problem #2: AI-generated code looks right but fails subtly
What I've seen: AI-generated code is "superficially convincing: idiomatic, well-named, stylistically consistent... The structural and logical failures are beneath the surface." (Faros)
Kiro's answer: Neurosymbolic AI and property-based testing
Kiro combines LLM adaptability with symbolic AI's logical reasoning. Property-based testing verifies that code matches its functional requirements, not just that it compiles and passes a few hand-written tests.
Success criteria this addresses (SPACE dimensions):
- P: Reduces bugs per PR (catches logical errors before review)
- P: Reduces Change Failure Rate (code proven correct, not just syntactically valid)
- S: Reduces the senior engineer "review tax" (fewer subtle bugs to catch manually)
Problem #3: AI tools lack the context they need
What I've seen: AI hits a ceiling when institutional knowledge lives in people's heads. DX interviews confirm this repeatedly. DORA lists "AI-accessible internal data" as a foundational capability. Faros recommends: "Build a context engine for your engineering environment."
Kiro's answer: The full Context Engineering stack
This is where all five methods come together:
| Problem | Context Engineering Method | How it helps |
|---|---|---|
| AI doesn't know your conventions | Steering Files (Always mode) | Conventions loaded on every interaction |
| AI can't access your internal systems | MCP Servers | Live connections to Jira, Confluence, AWS |
| Scaling standards across 50+ devs | Private Powers | One-click install, auto-updates for everyone |
| Complex multi-step processes | Agent Skills | Executable workflows, not just documentation |
| Different tasks need different AI behavior | Custom Agents | Scoped personas with tailored permissions |
Success criteria this addresses (SPACE dimensions):
- C: Improves knowledge sharing quality (standards enforced, not just documented)
- E: Reduces context-switching overhead (agent operates with full project context)
- E: Reduces work restarts (fewer "wrong path" implementations)
- P: Improves code quality at authoring (standards enforced before review)
Problem #4: Quality gates exist only at review time
What I've seen: Faros recommends: "Build quality gates into the development environment, not the review queue." The review queue is overwhelmed and reviewers can't absorb the volume AI produces.
Kiro's answer: Agent Hooks
Agent Hooks trigger automated checks during the development process, not after a PR is opened. Think of them as quality gates that fire at the point of authoring:
- Linting and formatting on every change
- Test coverage validation before code is committed
- Security scans inline with development
- Complexity threshold checks
Success criteria this addresses (SPACE dimensions):
- P: Prevents structurally complex code from reaching review queue
- A: Reduces PRs merged without review (automated gates catch issues early)
- E: Reduces median time in PR review (code arrives cleaner)
- C: Addresses DORA capability #7: Quality internal platforms
Problem #5: PRs are getting too large to review safely
What I've seen: Average PR size up 51.3%. Files edited per PR up 59.7%. Faros: "Each AI-assisted code change carries a wider blast radius than before."
Kiro's answer: Spec-driven task decomposition
The spec mode produces sequenced tasks, where each task is a self-contained, deployable unit. This enforces working in small batches at the architecture level, not as a manual discipline that developers forget under pressure.
Success criteria this addresses (SPACE dimensions):
- P: Keeps PR size within reviewable bounds
- P: Reduces blast radius per change
- E: Addresses DORA capability #5: Working in small batches
- C: Aligns with Faros recommendation: "Set PR size guidelines for your coding agents"
Problem #6: Developers can start work easily but can't finish it
What I've seen: In-progress tasks with no activity for 7+ days up 26%. Work restarts up 13.8%. Faros: "Easy to begin and hard to finish."
Kiro's answer: Autonomous agents with spec-bounded scope
Kiro's autonomous agent (in preview) works independently on tasks but within the boundaries defined by the spec. The scope is bounded, so the agent completes what it starts rather than generating sprawling, unfinished work.
Success criteria this addresses (SPACE dimensions):
- E: Reduces stalled in-progress tasks
- S: Reduces cognitive load from managing multiple unfinished threads
- A: Ensures each started task has a clear definition of done
Putting it together: a measurement dashboard
If I were setting up a measurement framework for a team adopting Kiro, here's what I'd track mapped to SPACE dimensions:
| SPACE | Metric | Baseline (pre-Kiro) | Watch Signal |
|---|---|---|---|
| A | Daily active users | Current % | Adoption ceiling |
| C | Spec adoption rate | 0% | Spec bypass |
| C | Context completeness | No steering files | Teams without context = risk |
| A | PR throughput | Current rate | Churn rising with it |
| P | Incidents-to-PR ratio | Current rate | Any increase |
| E | Review time per PR | Current median | Queue depth |
| P | Bugs per PR | Current rate | Compare AI vs. human PRs |
| E | Work restarts | Current rate | Context quality signal |
| C | Shared Powers adoption | 0 | Siloed vs. shared context |
| E | AI spend per developer | $0 | Compare to alternatives |
| E | Net time gain | 0 | Factor in review overhead |
| S | Developer confidence | Baseline survey | Trust in AI output |
What I'd start with tomorrow
If you're reading this and wondering where to begin, here's my practical recommendation:
- Day 1: Create steering files for your top 3 projects. Write down the conventions your senior engineers already know but haven't documented. Put them in
.kiro/steering/. - Week 1: Measure your current baseline: incidents-to-PR ratio, review time, work restarts. You can't improve what you don't measure.
- Week 2: Introduce spec-driven development for one new feature. Compare review time and rework against your baseline.
- Month 1: Build a private Power that bundles your org-wide standards. Have 3+ teams install it.
- Month 3: Review your SPACE metrics across all five dimensions. The "C" metrics (context completeness, spec adoption, shared Powers) should be your leading indicators.
The teams that will succeed with AI aren't the ones that generate the most code the fastest. They're the ones that communicate their knowledge to the AI effectively, and Kiro has awesome feature to handle that.
References:
- DORA AI Capabilities Model (2025). Google LLC. dora.dev/dora-report-2025
- Faros AI Engineering Report 2026: The Acceleration Whiplash. Faros.ai.
- DX, "AI and Engineering Velocity: A Longitudinal Analysis" (2026). getdx.com.
- DX, "AI-Assisted Engineering: Q1 Impact Report" (2026). getdx.com.
- Jellyfish, "2026 State of Engineering Management." jellyfish.co.
- Forsgren, N., Storey, M., et al. "The SPACE of Developer Productivity" (2021). Microsoft Research.
- Kiro — AI-native IDE for spec-driven development. kiro.dev
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article