If you are comparing a two-day workshop with a hands-on engagement lasting several weeks to get your team working with coding agents, you are most likely comparing prices. It is the wrong comparison.
The idea this insight defends: a workshop teaches what the tool does; what changes a team's delivery is how it writes down what has to be built, how it reviews what the agent produces and where a person decides. That is not learned in a classroom, it gets installed by working. So the useful question is not how much the workshop costs, but what remains in the team three months later.
What a workshop is for (and what it is not)
A workshop is not a waste of time. It gets the whole team looking at the same thing, sharing a vocabulary and losing the fear of trying. What it cannot do in two days is change habits that are built through repeated decisions on real code: what you ask the agent for, what you compare its output against and who approves it. The table is ours:
| Fits in a workshop | Only gets installed by working |
|---|---|
| What the agent does and how to ask it for something | Writing the specification of a real task before asking for the code |
| Examples prepared for learning | Cases from the team's own code, which do not always work out |
| Good review practices in general | Reviewing each change against acceptance criteria agreed beforehand |
| A shared vocabulary | Written context in the repository (conventions, decisions, limits) that the team maintains |
| Enthusiasm the following Monday | Someone to ask when the agent gets it wrong in week three |
onext's own work
What the evidence says, and what it does not
We know of no study measuring how long it takes a development team to change the way it works with agents. There are scattered signals pointing in the same direction.
The first comes from DORA, Google Cloud's research programme on software teams. Its 2025 report on AI-assisted software development says that AI's primary role is as an amplifier, magnifying an organisation's existing strengths and weaknesses, and that the greatest returns come not from the tools themselves but from the underlying organisational system. If what gets amplified is the team's method, the method is what needs work.
Its capabilities model for AI-assisted teams points the same way. The seven capabilities it identifies include a clear and communicated stance on AI use, strong version control practices and working in small batches. Our reading: these are team practices, not course content. A team either has them in its day-to-day work or it does not.
The third is a passing mention, but a telling one: the page of DORA's report on the return on AI in software development, updated on 22 April 2026, talks about managing the initial "productivity dip" of a new rollout. It does not say how long it lasts or how deep it goes. It says it exists, and that is enough not to expect results on the Monday after the workshop.
The figure that circulates most on adoption time comes from Microsoft: according to a survey of 1,300 Microsoft 365 Copilot users, at 11 weeks most say the tool improves their work, and Microsoft recommends encouraging people to keep using it until then because it takes time to build new habits.
Risk The 11-week figure is a perception survey published by the vendor itself in March 2024, among Microsoft 365 Copilot users (including Microsoft employees) with at least three weeks of use. They are not developers and it is not about coding agents. We cite it only as a signal of the order of magnitude: weeks, not days.
And then there is the obvious, which also has evidence behind it: what is not practised is forgotten. In 2015 Jaap Murre and Joeri Dros replicated Ebbinghaus' forgetting curve, with a single subject who learned lists and relearned them after minutes, hours or days. It is a memory experiment and says nothing about software teams; we use it only as a reminder that a workshop without practice afterwards is forgotten.
When comparing formats, the useful question is not how much the workshop costs, but what remains in the team three months later.
What gets installed by working
The core of the method is writing before asking. With Spec-Driven Development (SDD), what a change has to meet is written before the code, and the agent works against that. We explain it in Spec-Driven Development with AI. Templates to get started are within anyone's reach; what does not come with the template is the team's own method, and that method is adjusted task by task.
The same goes for review. Reviewing against criteria written beforehand is faster than reading a whole change and trying to guess what was wanted, but a team only gets there after doing it dozens of times. When it does not, the agent's gain sits waiting in review, as we explain in more code, same delivery. And without that method, what goes up is speed, not stability: with AI your team ships faster, but not more stably.
The third part of the method is the safety net: version control, tests and a clear way to undo what the agent does, which is worth having before handing the agent to the team. And the last, a person who decides where there is risk. None of these parts is learned by watching; all of them are learned by getting something that matters wrong and fixing it with help.
How to do it without stopping delivery
The usual objection to an engagement lasting weeks is that the team cannot stop. You do not need to stop delivering: the Quick-start works with a pilot team, on real work already planned and in parallel with its sprint. The work is on something that had to be delivered anyway.
Starting with one specific team has another advantage. The use of coding agents spreads mostly between colleagues, and the way of using them travels with it, as we saw in coding agents spread through peers, not by decree. A pilot team working with method and in plain sight is what the others copy later.
The three-month test
Whatever format you choose, after three months you can check whether the method has stayed in the team. No survey needed; looking at the repository and one review meeting is enough:
- The agent's changes start from a specification written before the code, not from a chat request nobody else has read.
- Review compares the change against acceptance criteria; it does not just read it and leave comments.
- The team's context (conventions, decisions, the agent's limits) is written in the repository and someone maintains it.
If none of the three is visible after three months, the team learned the tool but did not change its method. Which delivery indicators to watch as well is covered in KPIs for AI development teams.
Start with a workshop, then carry on with the method. If you want to take the first step, there is onext's online SDD workshop.
If you want to see with someone from outside what your team would need, the diagnostic is free, and if the diagnostic shows no difference, there is no Quick-start. What the rest of the path looks like is in AI-Accelerated Development.
Frequently asked questions
Is an AI workshop useful for a development team?
It is useful to get started: the team sees what the tool does, shares a vocabulary and loses the fear of trying it. What two days do not change is how the team delivers: how it writes down what has to be built, how it reviews what the agent produces and where a person decides. That gets installed through the team's real work.
How long does it take a development team to adopt AI?
We know of no reliable figure for development teams. The one that circulates most, Microsoft's 11 weeks, is a perception survey of Microsoft 365 Copilot users published by the vendor itself. DORA, for its part, talks about an initial productivity dip when rolling out AI, without saying how long it lasts. Microsoft talks about weeks and DORA gives no timeframe; neither talks about days.
What is the difference between training on a tool and changing the team's method?
Training on the tool teaches what the agent can do. Changing the method means deciding how the team works with it: specifications written before the code, criteria the review is checked against, small changes and a person who decides where there is risk. The first fits in a classroom; the second can only be checked with work that reaches production.
Do you have to stop delivering to adopt a new method with AI?
You do not need to stop delivering: the Quick-start works with a pilot team, on real work already planned and in parallel with its sprint. That is the difference from a workshop: the work is on something the team had to deliver anyway.
What should you ask before hiring an AI workshop or a hands-on engagement?
A single question sorts out the comparison: what will remain in the team and in its repository three months from now. If the answer is the course material, it is training. If it is specifications, review criteria and written context that the team maintains, it is method.
What can you check after three months to know whether the method has stuck?
Three things you can see without a survey: whether the agent's changes start from a specification written beforehand, whether review compares the change against criteria instead of just reading it, and whether the team's context (conventions, decisions, limits) is written in the repository and someone maintains it.
Sources
- DORA, "State of AI-assisted Software Development 2025" (the page shows only the year), accessed 25 October 2026.
- Kevin M. Storer and Derek DeBellis, "Introducing the DORA AI Capabilities Model", Google Cloud Blog, 23 September 2025.
- DORA, "ROI of AI-assisted Software Development report", page updated 22 April 2026.
- Microsoft WorkLab, "AI Data Drop: The 11-by-11 Tipping Point", 19 March 2024 (survey of 1,300 Microsoft 365 Copilot users).
- Jaap M. J. Murre and Joeri Dros, "Replication and Analysis of Ebbinghaus' Forgetting Curve", PLOS ONE, 6 July 2015.
- The table, the three-month test and the reading of DORA's capabilities as team practices are onext's own work.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →