AI makes good teams faster. And messy teams messier.

AI amplifies the team you have

Most software teams already use AI. Whether it helps depends less on the tool than on the team around it.

Google's DORA research programme surveyed nearly 5,000 technology professionals in 2025. AI adoption among software professionals had reached 90%, and more than 80% believed it had increased their productivity. Its conclusion: (DORA, 2025) (DORA, 2025)

In cohesive organizations, AI boosts efficiency. In fragmented ones, it highlights weaknesses. (DORA, 2025)

The same report found that 30% of respondents had little or no trust in the code AI generates. Adoption is not the hard part. Getting value from it, safely, is. (DORA, 2025)

What the evidence says about speed

The research is mixed, and the reasons are useful.

Context decides. In the field experiments, the gains were largest for less experienced developers doing their daily work. In the METR trial, experts working in projects they already knew well were slowed down. And speed can come at the cost of stability when there are no controls around it. (Cui et al., 2025) (Becker et al., 2025) (DORA, 2025)

The practical lesson: don't rely on how fast AI feels. Agree how you will measure it before you start (Step 6).

Say clearly what's allowed

Without a clear position, people either avoid AI or use it quietly, with company code and data.

DORA's AI Capabilities Model lists a clear and communicated AI stance among the seven capabilities that decide whether AI helps. It found that “ambiguity about what is acceptable stifles adoption and creates risk.” What matters is clarity, not a particular policy: the capability can be achieved “regardless of their unique stance—as long as that stance is clear and communicated.” (DORA, 2025)

A one-page policy is enough to start. It answers:

• Which tools are approved, and on which accounts or licences.
• Which data may go into them, and which may not: customer data, personal data, secrets, code under client contracts.
• What AI may be used for, and where a person must review the result.
• Who to ask when unsure, and how to propose a new tool.

There is a legal side too. Under the EU AI Act, companies that use AI systems must take measures to support the AI literacy of their staff. (AI Act, Art. 4)

Start where the work hurts

AI is not only for writing code. Start where work gets stuck, not where the tool looks most impressive.

Keep the user in view. DORA found that a focus on end users amplifies AI's benefit, and warns that without it, “AI-assisted development teams may just be moving quickly in the wrong direction.” (DORA, 2025)

Keep people learning

AI can make people faster today and weaker tomorrow, depending on how they use it.

In a randomised trial published by Anthropic in 2026, 52 mostly junior engineers learned a new programming library, with or without an AI assistant. The AI group was not significantly faster, and scored 17% lower on a follow-up test of what they had learned, with the largest gap in debugging. (Shen and Tamkin, 2026)

How they used AI mattered. Participants who asked the AI for explanations or conceptual answers kept their learning; those who let it write the code for them scored lowest. The study is small and short, but the pattern matches experience: “How someone used AI influenced how much information they retained.” (Shen and Tamkin, 2026)

Experienced developers stay essential. Birgitta Böckeler of Thoughtworks, with more than 20 years in the field, describes even her successful sessions with coding agents: “I intervened, corrected and steered all the time.” Judging AI output is a skill that comes from experience. (Böckeler, 2025)

In practice:

• Juniors ask AI to explain, not only to write, and must be able to explain every change they submit.
• Pair juniors with seniors on AI-assisted work, especially in review.
• Leave some work to be done by hand on purpose, where learning matters more than speed.

Care about the work, not just the result

Working code is not the same as good code. The team still owns what AI writes.

Kent Beck, creator of Extreme Programming and a pioneer of test-driven development, draws the line between two ways of working: (Beck, 2025)

In vibe coding you don't care about the code, just the behavior of the system. (Beck, 2025)

In augmented coding you care about the code, its complexity, the tests, & their coverage. (Beck, 2025)

For a business, only the second is sustainable. Two habits make it work. Automated tests check every change, by person or by AI. And review stays human, starting with the author. Simon Willison, co-creator of the Django web framework, states the rule plainly: “Don't file pull requests with code you haven't reviewed yourself.” Otherwise “you are delegating the actual work to other people.” (Willison, 2026)

Small steps and safe tools

Small, frequent changes make AI mistakes cheap to find and cheap to undo.

DORA lists working in small batches and strong version control among the capabilities that decide whether AI helps; frequent commits and easy rollback amplified its benefits. (DORA, 2025)

AI coding tools also bring new security risks: they can run commands, install packages and reach other systems. Give them only the rights a task needs, run them in a sandbox, and check every new dependency. (Gumbley and Ryan)

Pilot one workflow, measure, then decide

Start with one team and one workflow that matters but is not critical. Measure before and after.

DORA's software delivery metrics give a neutral baseline that most teams can collect from tools they already use: (DORA)

Add what matters for your goal: review time, bugs found after release, time spent on routine work, the AI bill, and how the team rates the experience. Decide in advance what result would justify a wider rollout, and what would stop it.

Run the pilot long enough to get past the novelty, then decide on the evidence: roll out, adjust, or stop.

Before you roll out

A short list for the owner and the team lead.

• A one-page AI policy says which tools, which data and which uses are allowed.
• Staff know how to use the approved tools, and what not to put into them.
• The pilot starts where work gets stuck, with one team and one workflow.
• Juniors use AI to learn, not only to produce, and work with seniors.
• Every change, by person or by AI, is tested and reviewed by its author first.
• Changes are small, and AI tools run with limited rights.
• Delivery metrics were recorded before the pilot, with success criteria agreed in advance.
• The decision to roll out is made on measured results.

What this would look like for you