The potential is here. But it won’t wait.
GitHub Copilot, Claude Code, Cursor — these tools are delivering productivity gains of 40 to 55% in code output, shorter development cycles, improved test coverage, and more.
Yet behind the technological promise lies a reality that many organizations are learning the hard way: the tool alone changes nothing. Results come from practices — and evolving the practices of delivery teams, each with their own rhythm, habits, and priorities, demands a structural effort that simply rolling out a tool cannot trigger on its own.
AI in the Development Pipeline: A Topic That Must Not Be Confined to Software Engineers
The most common mistake is to treat AI-Assisted Coding as a topic reserved exclusively for Software Engineers: the tool generates code, so it seems only natural to hand it over to those who write it. But this narrow approach consistently delivers results that fall short of what the technology can truly offer.
The value of AI in development extends well beyond development activities themselves. It is built across the entire value chain — and that is precisely where the structural shift lies. When an organization embraces a true end-to-end approach, every role on the team rethinks its scope and responsibilities in depth.
Product Managers and Business Analysts, once confined to writing specifications, can now build prototypes alongside users in near real time, as close as possible to actual field needs. The Business Analyst then leverages this prototype to structure the work: data, edge cases, specifications — all the elements that will allow Software Engineers to implement the solution with significantly less ambiguity.
Software Engineers, in turn, are not replaced by AI: they refocus their expertise on steering the tools, making architectural trade-offs, and managing complexity. Deploying agents unlocks an unmatched multiplier effect on productivity, without compromising the security or integrity of the codebase.
Testers, for their part, are shifting from manual scripting to augmented automation, channeling their added value into business validation, test depth, and coverage.
This shift in posture is no marginal adjustment. It redefines the very notion of contribution within an AI-augmented development team. Failing to bring the entire chain on board is not only a missed opportunity of significant scale — it also undermines adoption itself, leaving entire parts of the organization outside the momentum.
Training: necessary, but not sufficient
Many organizations’ instinctive response to this challenge is training. Sessions, modules, certifications… Top-down training builds knowledge. It does not build adoption.
Adoption follows a different logic: when faced with a development challenge, a team member spontaneously turns to the tool because they have experienced its value firsthand. That reflex isn’t acquired in a classroom. It is built through experience, through the first concrete wins, through successive adjustments in real-world situations. You learn to work with AI by working with AI — on real tickets, real user stories, real problems pulled straight from the team’s roadmap.
That said, training lays the foundations that adoption requires.
It is experimentation on concrete topics that turns knowledge into reflex. And it is cooperation within teams — PMs, BAs, Software Engineers, and Testers learning together, on the same challenges — that ensures lasting adoption rather than isolated skill-building. Every role must master its own part for the orchestra to play in harmony.
Accelerating AI Adoption Across Teams: What Actually Works
The question is no longer whether the tools are up to the task, but why adoption stalls in so many organizations after the first few weeks — and how to break through.
-
Start by defusing the fear, not by imposing the tool
The first barrier to adoption is not technical: it is the fear of becoming less competent, or replaceable. Gartner identifies it as a structural obstacle in its work on organizational entrenchment. Development teams are not rejecting the technology — they fear losing their grip on their craft.
In this context, a more demanding idea must be accepted: delegating certain tasks to AI means letting certain skills atrophy — and doing so deliberately. Not all skills deserve the same degree of vigilance. Some are intangible foundations — judgment, the ability to frame a problem, stakeholder relationships — that no delegation should ever undermine. Others are execution tasks whose atrophy is not only acceptable, but desirable: they free up bandwidth for higher-value activities. It is this differentiated reading that enables delegation with discernment. The point is not to keep everything; it is to know what is worth keeping.
Once the fear is dispelled and the idea is accepted, adoption progresses — not under constraint, but by conviction.
-
Build adoption around people, not tools
Offering the same learning path to every team is a common mistake. Each role has its own use cases and its own friction points. What the most effective rollouts have in common is a two-level structure: end-to-end across the development chain on one side (the horizontal view), and persona by persona on the other (the vertical view). Every role must master its own part before the team can play together.
-
Invest in champions as much as in top-down training
Peer-driven proof is a structuring force in AI adoption. Organizations that build a network of AI ambassadors — credible profiles drawn from within the teams themselves — see adoption rates up to three to four times higher than those of a conventional rollout. These champions are practitioners who test and share concrete use cases. Citi, for instance, has deployed more than 4,000 AI ambassadors across 84 countries, reaching 70% adoption across its entire workforce. (Source: Lead with AI)
-
Run team experiments on real business problems
Teams don’t adopt AI through fictional cases — they adopt it by solving real tickets, real user stories, real problems from their own backlog. The reflex is built in the actual flow of development, not in a classroom. And it builds far better collectively: Product Managers, Business Analysts, Software Engineers, and testers progressing together, on the same topic, from their respective angles, develop the shared reference points that ensure lasting adoption. Individual upskilling, without a collective anchor, produces isolated pockets of use that don’t hold over time.
-
Measure, share results and lead by example
Adoption only lasts if teams see results. That requires metrics defined upfront — velocity, test coverage, time spent on repetitive tasks — along with regular transparency about what’s working, including when the data is disappointing. McKinsey confirms it: the main obstacle to scaling isn’t team resistance, but the absence of strategic steering from leadership. (Source: LSE / McKinsey 2025) That steering also comes through example: leaders who join experimentation sessions alongside their teams send a powerful signal — AI isn’t a topic delegated to IT, it’s a shared stake at every level.
Conclusion
The technology is here, and the tools are mature. What remains to be built, in most organizations, is the ability to bring the entire development chain on board, to distinguish what deserves to be delegated from what must remain human, and to create the conditions for real experience rather than top-down training.
AI in software development is not a technical project — it is a human and organizational one.
