The 2025 DORA report, State of AI-Assisted Software Development, is based on more than 100 hours of qualitative research and survey responses from nearly 5,000 technology professionals worldwide. Its central conclusion is that AI acts as an amplifier: it strengthens the advantages of capable engineering organizations while magnifying the dysfunctions of weaker ones. Thoughtworks’ engineering-leadership interpretation emphasizes the same tension.
Organizations are seeing improvements in:
Individual effectiveness Coding throughput Software quality Delivery capacity Overall performance
At the same time, some are experiencing:
Greater delivery instability Toolchain fragmentation Validation overhead Context loss Developer frustration Architectural debt Increased cognitive load
The core leadership lesson is:
AI does not repair weak software-delivery systems. It accelerates whatever system already exists. When planning is ineffective, AI helps teams build the wrong thing faster. When teams are siloed, AI increases local output while making integration harder. When testing and architecture are weak, AI produces larger volumes of fragile change. When developer experience is poor, AI becomes another disconnected tool employees must manage.
Thoughtworks identifies three foundations for sustainable AI value:
Operate engineering as an optimization engine Use evidence, experiments, feedback, technical metrics, business cases, and financial analysis to convert insight into continuous improvement. Strengthen platform engineering Give teams self-service capabilities, paved roads, integrated controls, adaptable infrastructure, and reusable AI services. Prioritize developer experience Reduce context switching, simplify workflows, improve knowledge access, integrate tools, and make the development environment easier to navigate. The report also changes how engineering productivity should be understood.
Traditional activity measures such as:
Lines of code Story points Commit volume Prompt counts AI-tool adoption become even less useful when machines can generate large amounts of output quickly.
Engineering leaders should instead examine:
Lead time Deployment frequency Change failure Recovery performance Reliability Rework Review burden Developer experience Customer outcomes Business value The correct unit of analysis is usually the team or value stream - not the individual developer.
A mature AI-assisted engineering strategy should therefore:
Define business outcomes before selecting tools. Strengthen architecture and automated testing. Map the complete value stream. Remove bottlenecks outside coding. Build an integrated internal platform. Create governed AI access. Improve documentation and knowledge retrieval. Measure developer friction. Track quality, stability, and rework. Run controlled experiments. Scale only practices that create net value. Avoid using engineering metrics punitively.
The transition from AI-augmented to AI-first software development should be evolutionary. AI-augmented organizations add tools to existing practices. AI-first organizations redesign the entire delivery system around intelligent assistance, automation, agents, fast feedback, explicit controls, and human judgment.
The central principle is:
The engineering organization - not the AI model - is the primary unit of transformation.
1. What the 2025 DORA Report Is Really Saying
The visible headline is AI. The deeper subject is organizational capability. DORA’s research does not argue that one coding assistant, model, or agent architecture guarantees high performance. It argues that the underlying delivery system determines whether AI becomes productive leverage or additional instability. This distinction matters because leaders often treat AI adoption as a procurement decision.
They ask:
Which coding assistant should we purchase? How many developers are using it? How many prompts are submitted? How much code is generated? How quickly can we scale licenses? Those questions measure deployment. They do not measure transformation.
A meaningful engineering transformation asks:
Are valuable changes reaching users faster? Is reliability improving? Are teams spending less time searching and waiting? Is rework declining? Is architecture becoming healthier? Are developers able to focus on difficult problems? Is the organization learning faster? Is AI producing measurable financial or customer value? The difference between these two approaches is the difference between installing a tool and improving an operating system.
2. AI as an Amplifier
DORA’s central metaphor is precise. AI is an amplifier. An amplifier does not determine whether the original signal is good. It increases the signal’s strength.
In a strong engineering environment, AI may amplify:
Clear product priorities modular architecture reliable tests rapid feedback effective collaboration strong documentation platform self-service
In a weak environment, it may amplify:
Conflicting requirements tangled dependencies unclear ownership slow approvals fragile pipelines poor knowledge security weaknesses This explains why organizations using similar AI tools report very different results. The model may be similar. The surrounding system is not.
3. Faster Coding Is Not the Same as Faster Delivery
Coding is one stage in a longer value stream.
A software change may pass through:
Problem identification Prioritization Requirements Design Architecture Implementation Review Testing Security validation Deployment Operational verification Customer feedback
If AI accelerates implementation but the other stages remain constrained, total delivery performance may barely improve. The bottleneck simply moves.
A team may generate more pull requests while:
Review queues grow test environments remain slow approvals remain manual deployment windows remain infrequent operational teams become overloaded This is why higher coding throughput can place pressure on the wider engineering ecosystem rather than improving the complete outcome. Thoughtworks explicitly warns that faster code generation can produce instability when it enters systems with weak architecture, poor tests, or tangled pipelines.
4. The Productivity Paradox
AI can increase visible output while reducing net productivity. Imagine that developers generate twice as much code. At first, this appears positive.
But the additional code may create:
More review work More defects More integration conflicts More security findings More maintenance More documentation More operational complexity The organization may then spend greater effort managing the output than the AI saved during creation.
This is the productivity paradox:
Local speed can produce system-level delay. Engineering leaders must therefore measure the entire flow, not the fastest stage.
5. AI Engineering Waste
Thoughtworks identifies several forms of waste that appear specifically in AI-assisted development. Prompt-response latency Developers wait for models to generate, revise, or complete responses. Small delays repeated throughout the day can disrupt concentration. Context loss
The system forgets or lacks project-specific information, forcing engineers to repeatedly explain:
Architecture business rules prior decisions coding standards Toolchain fragmentation
Developers move among:
IDE assistants chat interfaces code-review bots documentation tools agent platforms Each tool may have different context, controls, and capabilities. Validation overhead
Engineers must inspect generated code for:
Correctness security architectural fit maintainability hidden assumptions These costs are real engineering work. They should be included in productivity analysis.
6. Developer Experience Is Now a Strategic Constraint
AI cannot compensate for a poor developer environment indefinitely.
Developers still need:
Reliable local setup Fast builds stable test environments clear ownership accessible documentation understandable deployment paths responsive internal platforms When these foundations are weak, AI may generate suggestions that cannot be implemented easily.
The developer spends time:
Translating AI output locating missing context fixing environment problems navigating access controls understanding undocumented systems A world-class developer experience is therefore not a convenience. It is a condition for realizing AI value.
7. Systems Thinking
Systems thinking means viewing software delivery as an interconnected system rather than a collection of local activities.
It examines relationships among:
People processes architecture tools incentives information governance customer demand A local improvement can have negative consequences elsewhere.
For example:
Faster coding may overwhelm review. More automated testing may increase infrastructure cost. More autonomy may create architectural divergence. More documentation may create search noise. Thoughtworks argues that systems thinking is essential because it allows organizations to integrate tools, workflows, and organizational knowledge while reducing friction and cognitive load across the whole SDLC.
8. Engineering Leadership Must Manage the System
The engineering leader’s role is not merely to encourage developers to use AI. It is to design the conditions in which AI can be useful.
That includes:
Choosing suitable workflows removing structural bottlenecks investing in platform capabilities protecting architectural integrity improving knowledge systems designing measures establishing governance managing workforce change The leader must look beyond tool usage toward system behavior.
9. Operate as an Optimization Engine
Thoughtworks recommends treating engineering as an optimization engine.
This means building a recurring loop:
Gather evidence. Identify a bottleneck. Form a hypothesis. Run a controlled experiment. Measure technical and business results. Scale, modify, or stop. This is stronger than imposing a universal AI rollout. Different teams may have different constraints.
One team may benefit most from:
Code generation
Another may need:
Better knowledge search
Another may need:
Test creation
Another may need:
Incident summarization A hypothesis-led approach matches the tool to the problem.
10. Pair Technical Measures With Business Measures
Engineering improvements should not be justified only by technical activity.
A shorter lead time matters because it may:
Improve customer responsiveness reduce opportunity cost increase experimentation accelerate revenue
Better reliability may:
Protect customer trust reduce support cost prevent regulatory exposure Thoughtworks recommends pairing technical metrics with business cases and financial modeling so engineering change remains aligned with organizational priorities.
11. Platform Engineering as the Backbone
Platform engineering creates shared capabilities that product teams can use without rebuilding infrastructure repeatedly.
A mature platform may provide:
Standard development environments CI/CD deployment paths observability identity secrets security controls reusable AI services Thoughtworks describes effective platforms as paved roads containing self-service, streamlined delivery, and built-in guardrails. It also emphasizes adaptability and technology independence so platforms can incorporate future AI capabilities without becoming locked to one rigid solution.
12. Platform as Product
An internal platform should be managed like a product.
It needs:
Defined users Product ownership Roadmap Documentation Support Service expectations User research Adoption measures A platform imposed without understanding developer needs may become another source of friction. The goal is not mandatory centralization. It is reducing repeated cognitive and operational burden.
13. The AI Paved Road
An AI-enabled engineering platform may provide:
Approved models Secure coding assistants Context retrieval Prompt and agent templates Sandbox environments Evaluation tools Cost monitoring Audit logs Policy controls This gives developers a safer and more consistent way to adopt AI. Without a paved road, teams may independently select tools, expose sensitive data, create incompatible workflows, and duplicate effort.
14. Avoiding Platform Lock-In
AI platforms are changing rapidly.
An internal platform should separate:
Developer experience model providers orchestration knowledge sources governance This makes it easier to change models without redesigning the complete workflow. Technology agnosticism does not require supporting every tool. It means preserving strategic flexibility.
15. Developer Portals and Unified Experience
A developer portal can provide one entry point for:
Documentation service ownership deployment templates operational information AI capabilities support The value is not the portal itself. The value is reduced search, context switching, and uncertainty. Thoughtworks emphasizes meeting developers where they work, including the IDE, command line, and portal, rather than forcing every interaction through one interface.
16. Knowledge Is Infrastructure
AI-assisted development depends heavily on context.
The system needs access to:
Code architecture domain concepts product rules historical decisions operating procedures engineering standards If this knowledge is inaccurate, fragmented, or inaccessible, the AI will produce weaker output. Knowledge management should therefore be treated as infrastructure.
17. Static Documentation Is Not Enough
Static documentation can become:
Outdated duplicated disconnected from code difficult to search AI creates an opportunity to move toward contextual knowledge access.
Developers may ask:
Why was this architectural decision made? Which service owns this data? How should this component be used? Which policy applies? The answer should be grounded in authoritative and current sources. Thoughtworks notes that code-aware systems can reduce the time engineers spend searching through static documentation and surface contextual answers directly.
18. More Documentation Is Not Always Better
AI can generate documentation cheaply. That does not mean organizations should generate unlimited documentation.
Excess output creates:
Duplication contradictory guidance maintenance burden search noise
The better goal is:
Accurate owned current discoverable useful knowledge
19. Value-Stream Management
Value-stream management examines how work moves from an idea to a customer outcome.
It identifies:
Queues handoffs delays rework approval bottlenecks ownership gaps AI should be inserted where it improves flow. The complete value stream should then be measured to see whether the intervention created net improvement.
20. Coding May Not Be the Main Bottleneck
Many organizations assume developers are the primary constraint.
The real bottleneck may be:
Slow prioritization unclear requirements security approval test environments manual release processes dependency coordination customer validation If coding is not the constraint, making coding faster may create limited value. Leadership should identify the actual constraint before investing heavily.
21. DORA Metrics Still Matter
The traditional DORA delivery measures remain useful because they examine speed and stability rather than raw coding activity.
They commonly include:
Deployment frequency Lead time for changes Change failure rate Recovery performance These metrics help leaders understand whether teams can deliver frequently and reliably. They should be used as signals for improvement, not as simplistic targets for individual evaluation.
22. Speed and Stability Are Complementary
One of DORA’s long-standing contributions is challenging the assumption that organizations must choose between: Speed Reliability Strong engineering systems can improve both. AI should be judged by whether it supports this balance. If code throughput rises while change failures increase sharply, the system has not achieved sustainable acceleration.
23. Delivery Instability
The 2025 findings associate AI-assisted development with positive outcomes but also warn about instability in some environments.
Possible causes include:
Larger change volume weaker review inadequate tests rapid architectural drift overloaded pipelines inexperienced tool usage Instability is not proof that AI is harmful. It is evidence that the surrounding controls have not matured at the same speed as production capacity.
24. Engineering Metrics Must Be Multidimensional
No single metric captures engineering performance.
A balanced framework should include:
Flow Lead time queue time deployment frequency Quality Defects change failure escaped issues rework Reliability Recovery availability
incident impact Developer experience Cognitive load tool friction confidence satisfaction Business outcomes Adoption revenue customer value risk reduction AI-specific measures
Acceptance validation effort failure rate cost context quality
25. Do Not Measure Individual Developers by Output Volume
AI makes individual activity measures even more dangerous.
A developer can generate:
More lines More commits More pull requests without creating more value.
Individual activity metrics can encourage:
Unnecessary code fragmented changes gaming reduced collaboration risk avoidance Software is a team outcome. Measurement should primarily support learning at the team and system level.
26. Measure Validation Overhead
One of the most important AI-era measures is the cost of verification.
Track:
Review time revisions rejected suggestions security corrections architectural corrections test repair An AI tool that saves one hour of coding but creates two hours of review is not productive.
27. Measure Rework
Rework may appear after the initial change.
It can include:
Bug fixing refactoring incident response documentation correction architectural cleanup AI-generated work should be evaluated over its lifecycle, not only at first submission.
28. Measure Cognitive Load
Developer experience affects:
Productivity quality retention burnout learning
Cognitive load may rise when engineers must manage:
Multiple AI tools inconsistent interfaces unreliable output frequent context reconstruction Surveys, interviews, workflow data, and observational research can help reveal this burden.
29. The Seven Team Profiles
The 2025 DORA research introduced team profiles to show that engineering organizations are not homogeneous.
Teams differ in areas such as:
Performance organizational support user focus AI adoption stability developer experience This implies that one AI strategy should not be applied identically to every team.
A struggling team may first need:
Better fundamentals clearer ownership more reliable delivery
A mature team may be ready for:
Advanced agents broader automation higher autonomy
30. Diagnose Before Standardizing
Enterprise standards are useful. Uniform implementation is not always.
Before scaling an AI practice, leaders should understand:
Team maturity product risk architecture test strength developer needs customer impact This allows differentiated adoption without abandoning governance.
31. User Focus
AI-assisted engineering should remain grounded in user needs. A faster delivery system that produces low-value features is not high performing.
Teams need:
Customer feedback Product discovery Outcome measures Clear priorities DORA’s research consistently connects strong performance with the ability to understand users and deliver meaningful outcomes.
32. AI Can Increase the Risk of Feature Waste
When production becomes cheaper, organizations may build more ideas.
That can increase:
Feature sprawl maintenance burden product complexity The organization needs stronger prioritization - not weaker prioritization - as delivery capacity grows.
33. Product Management Becomes More Important
Engineering productivity may increase faster than the organization’s ability to decide what should be built.
Product management must improve:
Problem selection customer research prioritization experimentation outcome measurement AI can help analyze information. Humans remain accountable for product direction and tradeoffs.
34. Leadership Must Redesign Capacity Allocation
When AI releases engineering capacity, leaders must decide how to use it.
Options include:
More features Technical debt reduction Reliability Security Modernization Developer experience Experimentation If all additional capacity is allocated to feature volume, technical health may deteriorate. A balanced portfolio is necessary.
35. Invest in Engineering Foundations
High-performing organizations should strengthen:
Modular architecture automated tests deployment automation observability documentation security ownership These practices increase the value of AI because generated changes can move through the system more safely.
36. Architecture Limits the Value of AI
In a highly coupled system, even a small change may require:
Coordinating multiple teams testing many dependencies long integration cycles significant operational risk AI cannot remove those structural constraints automatically. Architecture modernization may generate greater returns than additional coding-tool adoption.
37. Automated Testing Becomes More Important
Greater code production requires stronger automated assurance.
The test system should include:
Unit tests Integration tests Contract tests Security tests Performance tests Production monitoring Tests should not all be generated by the same model that produced the code without independent validation.
38. Small Batches
Smaller changes are generally easier to:
Review test deploy reverse understand AI can encourage large generated changes. Leadership should preserve small-batch discipline. Agentic and AI-assisted tools should produce bounded, explainable changes wherever possible.
39. Fast Feedback
AI is most useful when it receives rapid feedback from:
Tests linters builds policy checks users operations Long feedback cycles make mistakes more expensive. Engineering leaders should invest in the feedback system around the model.
40. Psychological Safety
Teams need to be able to say:
The tool is not helping. The generated code is unsafe. The metric is misleading. The rollout increased workload. The experiment failed. Without psychological safety, leaders may receive inflated adoption reports and hidden quality problems.
41. Responsible Experimentation
AI engineering experiments should have:
Hypothesis baseline defined users success measures risk limits review date The decision should be based on evidence.
Possible outcomes include:
Scale modify stop investigate further Stopping an ineffective AI initiative should be treated as learning, not failure.
42. Moving From AI-Augmented to AI-First
Thoughtworks distinguishes the current AI-augmented phase from a future AI-first model. AI-augmented AI supports existing processes. The workflow remains mostly human designed and human operated. AI-first The workflow is redesigned around intelligent systems, automated coordination, agents, and human oversight. The transition should not be rushed.
AI-first delivery requires:
Strong platforms explicit governance trustworthy knowledge reliable testing clear ownership mature observability Thoughtworks argues that the foundations built now determine whether organizations can make that future transition successfully.
43. Engineering Roles Will Change
The modern engineer’s value increasingly includes:
Problem framing Prompt and context design Solution architecture Validation Systems thinking Security Product judgment Thoughtworks emphasizes that engineering value is moving beyond code writing toward architecture and validation of AI-generated outputs. Coding knowledge remains essential. Engineers need it to identify when AI output is wrong.
44. Junior Development
If AI handles routine coding and debugging, junior engineers may receive fewer opportunities to learn.
Organizations should create deliberate pathways involving:
Pairing Code review System walkthroughs Debugging exercises Production observation AI-output critique Rotations The future senior engineer cannot emerge without sufficient foundational practice.
45. Engineering Managers
Engineering managers must move beyond monitoring activity.
Their responsibilities increasingly include:
System improvement Team health AI adoption strategy Skill development Delivery flow Cross-team coordination They should not use AI metrics as individual surveillance tools.
46. Security Leadership
Security teams need to help create safe paved roads rather than relying only on late-stage review.
They should embed:
Secure defaults Secret protection Dependency controls Policy checks Model governance Auditability This allows teams to move faster within defined boundaries.
47. The Business Case for AI-Assisted Development
A complete business case should include:
Benefits Faster delivery reduced toil improved quality greater experimentation better knowledge access Costs Licenses model usage integration platform work training
review governance rework Risks Security intellectual property vendor dependency instability workforce disruption AI value should be measured as net value after these factors.
48. Avoid the License-Utilization Trap
A company may purchase thousands of licenses and then focus on maximizing usage. This reverses the logic. The purpose is not to justify the purchase by increasing activity. The purpose is to improve engineering outcomes.
Low usage may indicate:
Weak training poor integration unsuitable workflows low value The response should be diagnosis, not coercion.
49. A Practical Engineering Leadership Framework
Step One: Define outcomes
Identify desired improvements in:
Delivery quality reliability developer experience customer value Step Two: Establish baselines Measure the current value stream before changing it. Step Three: Identify constraints Find the actual bottlenecks. Step Four: Select targeted use cases Match AI to specific problems. Step Five: Strengthen foundations
Improve:
Tests architecture platforms knowledge observability Step Six: Run experiments Use controlled pilots and balanced measures. Step Seven: Evaluate system effects Include downstream work, stability, cost, and developer experience. Step Eight: Scale selectively Expand practices that create proven net value. Step Nine: Update roles and learning
Prepare engineers and managers for new responsibilities. Step Ten: Repeat Treat engineering effectiveness as continuous optimization. A 90-Day Leadership Plan Days 1 - 30: Diagnose Map the software-delivery value stream. Establish delivery and reliability baselines. Survey developer friction. Inventory AI tools. Identify two or three material bottlenecks. Days 31 - 60: Design experiments Choose targeted AI use cases.
Define success and failure criteria. Strengthen testing and review controls. create platform integrations. train participating teams. Days 61 - 90: Evaluate Measure lead time, quality, rework, review effort, and experience. compare results with the baseline. investigate unintended effects. scale, adjust, or stop each experiment. publish lessons across engineering. A 12-Month Roadmap Quarter One: Foundation
Establish engineering-effectiveness governance. improve delivery measurement. strengthen automated testing. identify knowledge and platform gaps. Quarter Two: Integration Deploy approved AI capabilities through the platform. reduce tool fragmentation. improve code and documentation search. create role-based learning. Quarter Three: Optimization Use experiments to improve complete value streams. address review and deployment bottlenecks.
monitor stability and cognitive load. update capacity allocation. Quarter Four: AI-First Readiness Pilot agentic workflows in mature teams. embed policy and observability. redesign selected roles. refresh platform architecture. evaluate business and financial impact. Common Failure Patterns
50. Measuring AI Adoption Instead of Value
Tool usage is reported as success without evidence of better outcomes.
51. Measuring Lines of Code
Generated output is confused with useful delivery.
52. Accelerating Coding While Ignoring Review
Pull-request queues and validation work increase.
53. Scaling Before Fixing Foundations
AI is introduced into weak architecture, testing, and delivery systems.
54. Allowing Tool Fragmentation
Developers manage multiple disconnected AI products.
55. Ignoring Context Quality
AI receives incomplete or outdated organizational knowledge.
56. Automating Broken Work
AI accelerates unnecessary processes and technical debt.
57. Using Metrics Punitively
Teams optimize numbers rather than improving the system.
58. Applying One Strategy to Every Team
Different products and teams receive the same adoption model despite different maturity and risk.
59. Neglecting Developer Experience
Productivity initiatives increase cognitive load and burnout.
60. Confusing AI-Augmented With AI-First
Organizations claim transformation while simply adding assistants to unchanged workflows.
Key Takeaways
The 2025 DORA report concludes that AI acts as an amplifier of organizational strengths and weaknesses. The research included nearly 5,000 technology professionals and more than 100 hours of qualitative data. AI-assisted development can improve individual effectiveness, throughput, quality, and organizational performance. Those gains can coincide with delivery instability and developer-experience problems. Faster coding is not the same as faster software delivery. Local productivity gains can move bottlenecks into review, testing, deployment, and operations. Lines of code, story points, prompt counts, and raw adoption are weak measures of value. AI engineering waste includes latency, context loss, tool fragmentation, and validation overhead. Systems thinking is necessary for understanding how AI affects the complete delivery environment. Engineering organizations should operate as optimization engines based on evidence and experiments. Technical measures should be connected to business and financial outcomes. Platform engineering provides the self-service capabilities and controls needed to scale AI safely.
Internal platforms should be managed as products. Developer experience is a strategic performance factor. Knowledge quality and contextual retrieval strongly influence AI usefulness. Value-stream management helps identify the real bottlenecks outside coding. Speed and stability should be improved together. Team-level measurement is generally more appropriate than individual productivity scoring. The move from AI-augmented to AI-first delivery should be gradual and foundation led. The organization’s engineering system - not the AI tool - is the main determinant of sustainable value.
Frequently Asked Questions
What is the 2025 DORA report about?
It examines the state of AI-assisted software development and the organizational capabilities that influence whether AI improves software delivery.
How large was the research sample?
The research included survey responses from nearly 5,000 technology professionals and more than 100 hours of qualitative data.
What is the main conclusion?
AI acts as an amplifier, strengthening both effective practices and organizational dysfunctions.
Does AI improve developer productivity?
It can improve individual effectiveness and throughput, but the net result depends on review, testing, architecture, integration, and delivery systems.
Why can AI increase instability?
It can increase the volume and speed of change faster than testing, review, deployment, and operational systems can absorb.
What is AI engineering waste?
It includes:
Prompt latency context loss fragmented tools validation overhead rework
Are lines of code useful as a productivity metric?
No. More generated code may increase complexity and maintenance without producing greater value.
Should AI adoption be measured?
Yes, but adoption should be treated as an input rather than the final outcome.
Which metrics matter?
Useful measures include:
Lead time deployment frequency change failure recovery rework developer experience business outcomes
Should DORA metrics be used to rank individual engineers?
No. They are better used to understand team and system performance and guide improvement.
Why is platform engineering important?
Platforms provide secure self-service, standardized delivery paths, shared AI capabilities, and built-in controls.
What is a paved road?
It is a supported and streamlined path that helps teams build and deploy software without repeatedly solving common infrastructure and governance problems.
What is developer experience?
It is the quality of the environment through which developers understand, build, test, deliver, and operate software.
Why does knowledge management matter?
AI tools need accurate context about code, architecture, business rules, and prior decisions.
What is systems thinking?
It is the practice of understanding the interactions among people, processes, technology, architecture, incentives, and outcomes.
What is value-stream management?
It examines the full movement of work from idea to customer value and identifies bottlenecks, queues, handoffs, and rework.
What is the difference between AI-augmented and AI-first?
AI-augmented organizations add AI to existing work. AI-first organizations redesign workflows, platforms, roles, and controls around intelligent systems.
Should every engineering team adopt AI in the same way?
No. Adoption should reflect team maturity, product risk, architecture, workflow, and user needs.
How should engineering leaders start?
They should establish baselines, identify actual bottlenecks, select targeted use cases, and measure complete system effects.
What is the greatest leadership mistake?
Treating AI deployment as a substitute for engineering excellence.
Conclusion
The 2025 DORA report marks an important transition in the software industry. The question is no longer whether AI will enter software development. It already has. The more important question is what happens after individual developers become faster.
Does the organization:
Deliver value sooner? Maintain reliability? reduce cognitive load? improve customer outcomes? strengthen engineering capability?
Or does it create:
More code more review more instability more technical debt more developer frustration? DORA’s amplifier principle explains why both outcomes are possible. AI strengthens the system into which it is introduced. A mature engineering organization can use AI to accelerate feedback, reduce toil, surface knowledge, strengthen testing, and expand delivery capacity. An immature organization may use the same tools to increase output inside a dysfunctional value stream. Thoughtworks’ leadership interpretation is therefore well founded.
Sustainable AI value requires:
Systems thinking engineering foundations integrated platforms strong developer experience evidence-based optimization business-connected measurement The organization should not pursue faster coding in isolation. It should pursue faster and safer movement from customer need to operational value.
That requires leadership attention to:
Planning architecture testing review deployment knowledge teams incentives metrics It also requires humility. AI-assisted engineering is still evolving. Some use cases will create significant value.
Others will add cost, noise, or risk. Leaders should create systems that can learn the difference quickly. The strongest engineering organizations will not be those that report the highest AI adoption. They will be those that integrate AI into a disciplined improvement system capable of measuring its real effect, strengthening what works, and stopping what does not.
The defining question is not:
How much more code can our developers produce with AI?
It is:
How can our complete engineering system convert greater AI-assisted development capacity into faster learning, safer delivery, better products, stronger developer experience, and durable business value?
Relevant Articles and Resources
The 2025 DORA Report: An Engineering Leadership Perspective - Thoughtworks An interpretation of the report’s implications for coding throughput, delivery instability, systems thinking, developer experience, platform engineering, measurement, and the transition toward AI-first delivery. State of AI-Assisted Software Development 2025 - DORA The official report and research overview, including the conclusion that AI acts as an amplifier of existing organizational strengths and weaknesses. DORA 2025 State of AI-Assisted Software Development Report - Google Research The publication record describing the research sample, methodology, authors, and central findings. Announcing the 2025 DORA Report - Google Cloud An official overview of the report, team profiles, and the DORA AI Capabilities Model. DORA Research: 2025 Overview Background on DORA’s ongoing research into the capabilities that drive software-delivery and operational performance. The 2025 DORA Report - Thoughtworks Thoughtworks’ report hub and related engineering-effectiveness resources.
How Developers Are Using AI: Inside Google’s 2025 DORA Report - Google A public overview of how AI adoption is changing software-development practice.