According to the 2025 DORA report, AI's primary role in a development team is that of an amplifier: it magnifies the strengths and weaknesses the organisation already had. It adds that the greatest return on AI investment comes not from the tools themselves but from a strategic focus on the organisational system around them.
If that is right, the useful question for a CTO is not which assistant to buy but what their team is amplifying. A framework that IT teams have used for years helps answer it: look at four perspectives —people, processes, tools and indicators— and find which one is holding back the others.
The thesis of this piece is that with AI the framework still holds, but the questions that fill it have changed, and that the tool, the perspective that gets the most attention, is the one that decides the least. An AI transformation can fail without the assistant being to blame: often it is because one of the other three is still being diagnosed with yesterday's questions.
A classic framework with new questions
In a diagnosis without AI one asks about skills and career paths, about automation, deployment frequency and the definitions of ready and done, about developer experience, and about what gets measured. All of those questions are still legitimate. What happens is that, once an agent writes a good part of the code, each one shifts.
| Perspective | The usual question | The question with AI |
|---|---|---|
| People | What skills does the team have and what career path does each person have? | Who can write a specification an agent can execute, and review the code it generates? How does a junior learn to do it? |
| Processes | Is it automated? How often do we deploy? What do ready and done mean? | What makes a task ready: a specification that can be checked? What makes it done: verification, and at what point does a person sign off? |
| Tools | What developer experience do they offer and how much cognitive load do they add? | Where does the context the agent reads live, who maintains it, and does it survive a change of tool? |
| Indicators | Are we measuring the right things? Where are the bottlenecks? | Do we measure delivery and quality, or activity (lines, licences, accepted suggestions)? Where does the work wait now? |
onext's own elaboration, based on the classic framework for diagnosing an IT team
The four rows have one thing in common: the new question no longer looks at the code, it looks at what surrounds it. Who asks for it, how it is checked, what context guides it and how you know it was worth it. Let's take them one by one.
People: who can specify and who can review
The skill that is scarce in a team with agents is not typing. There are two, and almost no training plan names them: writing a specification an agent can execute without guessing and reviewing code you did not write, with the judgement to spot what looks right and is not. A test for this week: pick three changes shipped last month and ask, for each, who wrote what the agent was asked to do and who understands why the result is correct. If the answer is "nobody in particular", that perspective has a gap.
Career paths change with it. A junior's classic route went through writing the first draft, getting it wrong and debugging their own mistake, and that is the exercise the agent now does. If nobody replaces it, the team produces more today and grows fewer people able to sign off the code tomorrow. We develop this in junior developers and AI; the way out is for the junior to write the specification and explain their change without the assistant in front of them. The same goes when hiring: if an agent solves the technical test, what you need to look at is judgement.
A note on scale. This perspective is about the development team; adoption across the whole company, with its resistance and its culture, has another dimension and we cover it in people and culture, beyond training.
Processes: ready is the specification and done is the verification
In an agile team, ready and done are the two gates of a task: when it is ready to start and when it is finished. With AI, both gates change content.
- Ready = the specification. A task is ready when there is a specification with acceptance criteria that can be checked. This is the idea behind Spec-Driven Development (SDD): the specification is the source of truth and the code is derived from it. A three-line user story was enough for a person who knew the product; it is not enough for an agent that does not.
- Done = verification, and where a person signs off. A task is finished when the result has been checked against the specification and, at the risk points, a person has signed off. Passing tests are not enough if the agent generated them from its own code. Nor is the point to approve everything: approving everything is not control, it is a traffic jam.
This moves the bottleneck. It is reasoning, not a measurement: if the agent produces more changes per hour, the queue no longer forms at writing but at review and verification, and a review process designed for an author who is no longer there becomes the limit. That is why deployment frequency, which used to depend mostly on automation, now also depends on what it costs to verify a change. We have covered each piece separately: the specification as the place where you sign off, the SDD method and the review that still expects an author.
Tools: rules over tools
The third perspective is usually read as "which assistant do we use". With agents, the question that decides is another one: where does what the agent needs to know live. Project rules, patterns, standards and architecture decisions can sit in the heads of two people, in a chat history, or in versioned files the agent reads on every task. Only the third option is governable. We call that Rules over Tools and it is the practical side of context engineering.
The market is moving that way. AGENTS.md describes itself as "a README for agents": a predictable place for the context and instructions a coding agent needs, and different tools read it. Claude Code, for its part, loads CLAUDE.md files and can also read a repository's AGENTS.md. When knowledge lives in files, changing tool does not mean starting from scratch, and that is what makes the tool secondary. Secondary does not mean irrelevant: you still choose on security, cost and fit, but it stops being where the method lives.
There is a limit worth knowing. Claude Code's documentation says it plainly: those files are context, not enforced configuration, and the more specific and concise the instructions, the more consistently the model follows them. What must always hold should not live only in text: it goes into an automated check, a repository rule or a hook that blocks the action. Text to guide; checks to guarantee.
Developer experience, which is what this perspective measures, has three dimensions according to Noda, Storey, Forsgren and Greiler: feedback loops, cognitive load and flow state. With agents, the first two become concrete. An agent without context forces you to re-explain the project every session, and that is cognitive load. A slow review is a long feedback loop. The diagnostic question is not "are they happy with the assistant?" but "what does each person have to explain again every time, and how long do they wait for an answer?". How that context gets built is in context engineering, the discipline that holds AI teams up.
Indicators: measure delivery and quality, not activity
"What you don't measure you can't improve" is still true, with a new trap: with AI, what is easy to measure is activity. Lines generated, active licences, accepted suggestions. These numbers rise almost on their own when a tool is adopted and do not say whether software arrives sooner or better. It is the same problem we describe in the ROI of Copilot and Cursor.
DORA measures delivery with five metrics, in two groups. Throughput: change lead time (from commit to production), deployment frequency and failed deployment recovery time. Instability: change fail rate and deployment rework rate, meaning unplanned deployments that result from a production incident. They work because they are read together: if AI raises throughput but also instability, the team is only reaching production faster with more problems. The data comes from the repository and the deployment system, not from a survey.
The second reason to measure is that perception fails. In the randomised trial METR published in July 2025, 16 experienced developers worked through 246 real tasks in repositories they knew well. With AI tools they took 19% longer; they had expected to be 24% faster and, afterwards, still believed they had been 20% faster. The authors themselves qualify the result: a small sample, veteran developers on familiar projects and early-2025 tools. It does not prove that AI is useless. It proves that an impression is not a measurement, and that you need a baseline before you start. What exactly to measure, and what to stop measuring, we develop in KPIs for AI development teams.
How to use the four perspectives this week
You do not need a project to start. A two-hour session with the team and one real delivery from the last month is enough:
- Pick a change that reached production and reconstruct its journey: who asked for it, what specification there was, what the agent generated and what context it read.
- Mark where it waited: in the specification, in review, in verification or in a deployment.
- For each perspective, write down one question from the table that the team cannot answer with data.
- Pick the perspective with the most gaps and set one delivery metric to review in a month.
A weak perspective limits the others: good context is no use if nobody can specify, and measuring delivery is no use if review has no owner. And if your doubt comes earlier —where to start with AI across the whole company, not just the development team— the piece that fits is the seven layers of maturity.
The question left for your team is the usual one in another form: are you delivering sooner than a year ago, or just typing faster? If it is hard to answer with data, you already know which perspective to review first.
Frequently asked questions
What are the four perspectives of a development team working with AI?
People, processes, tools and indicators. They are the classic perspectives for diagnosing an IT team, but with AI the questions change: in people, who can write specifications and review generated code; in processes, what ready and done mean; in tools, where the context the agent reads lives; and in indicators, whether you measure delivery and quality or just activity.
What do "ready" and "done" mean when an agent writes the code?
Ready becomes a specification with acceptance criteria that can be checked, because an agent does not know the product the way a team member does. Done becomes the result having been verified against that specification and, at the risk points, a person having signed off. Passing tests are not enough if the agent generated them from its own code.
What is "Rules over Tools" and why does it matter that context lives in files?
It is the principle that project rules, patterns, standards and architecture decisions should be written down in versioned files that the agent reads on every task, above any specific tool. Formats such as AGENTS.md are read by different tools, so changing tool does not mean starting from scratch. It is the practical side of context engineering.
Which indicators show whether AI improves delivery?
Delivery and stability indicators, not activity ones. DORA proposes five: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Lines generated, active licences or accepted suggestions rise when a tool is adopted and do not say whether software arrives sooner or better.
Why isn't it enough to ask the team whether AI makes them faster?
Because perception fails. In METR's July 2025 randomised trial, 16 experienced developers took 19% longer with AI tools and, afterwards, believed they had been 20% faster. The authors warn about the small sample and that the tools were from early 2025. The lesson is to measure with repository and deployment data, with a baseline taken beforehand.
Where do you start a diagnosis of the four perspectives?
With a real delivery from the last month. You reconstruct its journey (who asked for it, what specification it had, what the agent generated, what context it read), mark where it waited and write down, for each perspective, the question the team cannot answer with data. You then pick the perspective with the most gaps and one delivery metric to review in a month.
Sources
- DORA (Google Cloud), "State of AI-assisted Software Development 2025".
- DORA, "DORA's software delivery performance metrics" (five metrics: throughput and instability).
- Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, "DevEx: What Actually Drives Productivity", ACM Queue, March-April 2023 (PDF copy hosted by one of the authors).
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", 10 July 2025.
- AGENTS.md, an open format for guiding coding agents.
- Claude Code documentation, "How Claude remembers your project".
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification, human verification and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →