AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action

Ben Linders · rss · 2026-07-30 source ↗ Reader 🖥️

practical · news article + Q&A interview, reporting a conference talk — InfoQ's Ben Linders summarizes a QCon London talk by Nathen Harvey (Google/DORA) and follows it with a short interview. It relays DORA's empirical research but is itself a secondary, compressed write-up, not the primary report.

Structure

Key terms

• team profiles DORA AI Capabilities Model (Team Profiles & Capabilities)
  Seven empirically-derived clusters from DORA's 2025 survey data, grouping teams by measured factors (team performance, product performance, individual effectiveness, friction, burnout) — a data-derived typology, not a maturity ladder or self-assessment quiz.
• capabilities
  DORA's specific research construct (in the Accelerate/DORA capability-model tradition): practices statistically associated with better outcomes when combined with AI adoption — e.g. 'strong version control practices,' 'working in small batches' — measured, not aspirational competencies.
• AI as amplifier AI as Amplifier
  AI magnifies whatever organizational system already exists — good practices compound, dysfunction accelerates — so AI's effect is conditional on the underlying system, not intrinsic to the tool.
• organizational system
  The combination of technology, teamwork, business drivers, and customer focus DORA researches together — deliberately broader than 'software delivery' alone.
• software delivery instability
  A DORA delivery-performance metric family (rollback rate, hotfix/incident-driven rework following deployment) — a specific measured quantity, not a colloquial sense of things feeling shaky.

Propositions

• explicit⚡ disputed & corroboratedAI functions as an amplifier of the underlying organizational system: the greatest returns on AI investment come from strategic focus on that system, and without that foundation AI creates localized pockets of productivity that are lost to downstream chaos.conf: high
  supportsAI Won't Save the Kingdoms We Built · p7 — Both frame AI as valuable only as an amplifier of an already-coherent operating model/organizational system, never as a substitute for one — Cutler's leadership essay and DORA's own research converge on the same claim.
  supportsDORA Community Discussion - Operationalizing DORA within a large organization · p12 — Same DORA/Harvey 'amplifier, not savior' thesis, here applied in an enterprise DORA-rollout case study rather than the primary research write-up.
  supportsAI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy · p10 — The identical Harvey/2025-DORA amplifier quote is reused as evidence in a different secondary piece — same primary claim, independent framing.
  supportsPresentation: AI-First Software Delivery: Balancing Innovation with Proven Practices · p5 — Both state AI amplifies whatever engineering practices (weak or strong) already exist, from independent practitioner sources.
  extends ←State Of AI-Assisted Software Development · p1 — Same amplifier thesis; this is the primary report, the InfoQ piece a compressed secondary write-up of it.
  contradicts ←The Acceleration Whiplash · p4 — Faros's uniform-across-maturity telemetry finding directly contradicts DORA's amplifier/foundation thesis that strategic focus on organizational fundamentals protects the returns on AI investment.
  supports ←Thomas Nys' Post · p6 — Both frame AI as an amplifier of the underlying organizational/technical system rather than an independent source of value — without that foundation, gains stay localized and get lost downstream.
• explicitdevelopedDORA's 2025 survey and qualitative research identified seven distinct team profiles that differ significantly on team performance, product performance, individual effectiveness, friction, and burnout.conf: high
  extends ←State Of AI-Assisted Software Development · p2 — Adds full per-cluster percentages, performance/well-being/stability descriptions, and the explicit 'speed vs. stability is a myth' finding (prop 3) absent from the secondary summary.
• explicitestablishedDORA identified seven capabilities — clear and communicated AI stance, healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, user-centric focus, and quality internal platforms — that, combined with AI adoption, drive better outcomes.conf: high
  extends ←State Of AI-Assisted Software Development · p5 — Adds the detailed measurement basis, certainty levels, and specific outcome pathway for each of the seven capabilities (the InfoQ piece only lists them).
  supports ←Leading your engineers towards an AI-assisted future · p4 — Hodgson's recommendation to combine DORA/SPACE metrics with AI-adoption metrics anticipates DORA's own later empirical finding that AI adoption's benefit is conditional on exactly these organizational capabilities, not adoption alone.
  supports ←The Pragmatic Engineer 2025 Survey: What's in your tech stack? · p5 — Both treat company/organizational AI policy as a measurable, consequential variable rather than background noise — this survey's Amazon anecdote (third-party LLMs banned, only internal tools allowed) is a concrete instance of the kind of organizational AI-stance variation DORA's capability framework is built to capture.
• explicitAs AI adoption increased, self-reported individual effectiveness and perceived code quality both increased, with individual effectiveness showing the largest relative increase of any factor DORA measured.conf: high
• explicitestablishedSoftware delivery instability (deployments rolled back, hotfixes required to correct deployment-introduced errors) also increased as AI adoption increased, even as perceived code quality and individual effectiveness improved.conf: high
  supportsAI isn't making developers more productive – it's making them busier · p4 — DORA's own instability-rising finding corroborates the 'weak-link hypothesis' — AI-driven volume increases outrun fixed downstream (review/integration/production-stability) capacity, producing exactly the kind of downstream cost this claim identifies.
  supports ←2024_final_dora_report · p2 — This 2024 finding (AI adoption reduces delivery stability) is the earlier-year evidence that DORA's 2025 AI Capabilities Model report corroborates with its own instability finding.
  extends ←State Of AI-Assisted Software Development · p4 — Frames the same instability finding explicitly as a reversal from the 2024 report on throughput specifically, which the secondary article doesn't state.
  supports ←Measuring AI's Unintended Consequences · p8 — Shore's recommendation to watch DORA metrics as an AI unintended-consequence indicator matches DORA's own 2025 finding that delivery instability rises with AI adoption even as perceived quality also rises.
• explicitThis co-occurrence — perceived quality up, delivery instability also up — may signal misaligned incentives or lack of visibility into the production impact of changes, such as engineers optimizing for shipping features without ownership of how those features land in production.conf: medium
  supportsAI productivity is burning out your best engineers · p4 — Both describe a visibility gap: velocity/quality-perception metrics look good while a real downstream cost (production instability; validation burden and its 'lag effect') accumulates unmeasured.
• explicitcorroboratedAI puts pressure on DORA's long-standing finding that small batch sizes improve delivery performance, because models tend to suggest large change sets or pull requests that are harder to review and carry more risk; the remedy is collaborating with AI to decompose large changes into smaller, independently deployable units.conf: high
  refinesThe Future Of Software Engineering · p8 — The other piece asserts AI is already causing a regression to larger batch sizes 'reversing a decade of DORA findings' as a settled trend; Harvey's framing treats this as a manageable pressure teams can counteract by actively collaborating with AI to decompose changes, not an inevitable reversal.
  supports ←2024_final_dora_report · p3 — Both reports converge on the same small-batch-size mechanism for why AI pressures delivery stability — the 2024 report states it as a fresh hypothesis, the 2025 report restates it as an established pressure point.
• explicitQuality internal platforms extract value from AI investment in two ways: making a capability accessible to the whole organization (driving adoption), and shifting complexity down into the platform so it is hidden from and doesn't have to be reasoned about by individual builders (e.g. centrally enforcing a security policy).conf: high
• implicitApplying DORA's findings well requires treating them as a falsifiable hypothesis to test against local context rather than as a universal prescription — which team profile you're in should change which capability you prioritize first.conf: medium

Arguments

Narratives

• The 'constrained by process' team profile's spider chart: high burnout, high friction, low individual effectiveness, low time spent on valuable work, yet comparatively good software delivery instability and only slightly lower throughput than other profiles.
  → Demonstrates that team profiles are genuinely multi-dimensional — a team can look fine on delivery-stability metrics while being burned out, frustrated, and low-value, which is exactly the blind spot a narrow 'AI improved our deploy metrics' narrative would miss.

Questions addressed

• ✅ Does AI improve individual productivity and code quality, as perceived by developers?
  Yes — self-reported individual effectiveness and perceived code quality both increased with AI adoption, per DORA's 2025 survey.
• ✅ Does AI improve software delivery stability?
  No — software delivery instability increased alongside AI adoption, the opposite direction from the perception-based measures.
• ⭕ What causes the quality-perception-up / delivery-instability-up contradiction?
  Harvey offers a hypothesis (misaligned incentives, lack of visibility into production impact) but the article does not report DORA testing this hypothesis against the data — it remains interpretive commentary, not an established causal finding.
• ⭕ Are the seven team profiles and seven capabilities validated as robust across industries, company sizes, and geographies, or specific to DORA's 2025 sample?
• ⭕ Given the seven capabilities, how should a team decide which one to prioritize first for its specific team profile?

Gaps

• incompleteThe article never defines what distinguishes six of the seven team profiles beyond naming them; only 'constrained by process' gets a description via its spider chart. A reader cannot self-diagnose which profile their own team matches from this piece alone.
  Read next: The full DORA 2025 'State of AI-Assisted Software Development' report at dora.dev/ai for the profile definitions and their measured criteria.
• incompleteThe piece uses causal language ('drive better outcomes') for the capability-outcome relationship but never states DORA's research design in enough detail (survey design, longitudinal vs. cross-sectional, controls) to know whether that relationship is measured causally or is a correlational finding from self-report survey data — a distinction this reader's stated preference for 'benchmark data over vendor claims' would specifically flag.
  Read next: DORA's published methodology section, or the AI Capabilities Model report (December, referenced in the article) for the underlying statistical treatment.
• incompleteThe article surfaces the counterintuitive quality-up/instability-up finding and Harvey's own hypothesis for it, but never reports whether DORA tested that hypothesis against the data (e.g. correlating instability with specific missing capabilities) — it's presented as plausible interpretation, not a verified mechanism.
  Read next: DORA report sections specifically on drivers of delivery instability, or a follow-up interview probing this finding.
• uninformed'Individual effectiveness' and 'code quality' improvements are explicitly self-reported/perceived, but the article's framing doesn't consistently flag this as perception data rather than a measured outcome — risking a reader treating 'quality improved' as objective rather than a survey-response artifact, especially since the same report shows an objective-leaning metric (delivery instability) moving in the opposite direction.
  Read next: extract-ai-developers-busier-not-more-productive (measured throughput/value vs. self-reported busyness) and extract-8-engineering-metrics-ai-broke (why self-reported satisfaction/effectiveness metrics can mask real degradation) for the general pattern.
  closed byThe Acceleration Whiplash — Faros's telemetry -- bugs, incidents, review time, unreviewed merges, all drawn from engineering systems rather than self-report -- supplies the objective counterpoint that gap g4 says DORA's article failed to flag: 'quality improved' in DORA's 2025 survey is a perception artifact, since objectively-measured production quality is simultaneously declining as AI adoption rises.
• incompleteNo discussion of sample size, company size range, industry mix, or geography for the underlying 2025 DORA survey — a reader trying to judge how far the seven-profile/seven-capability taxonomy generalizes to their own organization (e.g. a Norwegian telco) needs the sample composition, which the article omits entirely.
  Read next: DORA 2025 report methodology appendix.

Closes gaps elsewhere

• The Organization Is the Bottleneck · g1 — Supplies the DORA 2025 report data that piece's evidentiary gap named as the needed reading direction — team profiles, capabilities, and Harvey's specific findings on individual effectiveness, code quality, and delivery instability.
• The Organization Is the Bottleneck · g2 — That gap asked whether 'organizational maturity' should be treated as multi-dimensional rather than a single axis, and named the DORA capability model as the reading direction; this document supplies exactly that — DORA's seven-capability model (AI stance, data ecosystems, version control, small batches, user focus, platforms) and the seven-team-profile typology, both explicitly multi-dimensional.

Related documents

• The Future Of Software Engineering
• Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices
• AI Won't Save the Kingdoms We Built
• 2024_final_dora_report
  AI as Amplifier Burnout & Recovery Developer Experience & Flow DORA AI Capabilities Model (Team Profiles & Capabilities)
• State Of AI-Assisted Software Development
  AI as Amplifier Burnout & Recovery DORA AI Capabilities Model (Team Profiles & Capabilities) DORA & Engineering Metrics
• The Acceleration Whiplash
  DORA AI Capabilities Model (Team Profiles & Capabilities) DORA & Engineering Metrics Measuring AI Impact Pull Requests & Async Code Review
• Presentation: Platform Engineering for Everyone - Success Can’t Be Coded
  Developer Experience & Flow DORA & Engineering Metrics Platform Engineering Sociotechnical Architecture
• The 8 software engineering metrics AI broke
  Developer Experience & Flow DORA & Engineering Metrics Measuring AI Impact
• AI coding creates two kinds of debt. You're only measuring one
  DORA & Engineering Metrics Measuring AI Impact Pull Requests & Async Code Review
• AI isn't making developers more productive – it's making them busier
  DORA & Engineering Metrics Measuring AI Impact Pull Requests & Async Code Review