Buying AI for your developers?

The real challenge is making that investment show up in software delivery.

AI coding tools are quickly becoming part of everyday software development. For many organizations, the first phase of adoption has already happened: developers have access to tools such as GitHub Copilot, Cursor or Claude Code.

The benefits can be very tangible at an individual level. Developers use AI to generate tests, explore unfamiliar codebases, prepare documentation or automate repetitive work. Early adopters can often point to tasks that take considerably less time now.

For CIOs, CTOs and engineering leaders, however, those examples only answer part of the question. The investment ultimately needs to show up at team and organizational level: in development capacity, software quality, delivery speed or more time for complex engineering work. That is much harder to assess than whether developers are actively using an AI tool.

Individual productivity gains don't always improve software delivery

Software development is a connected process. Code needs to be understood, reviewed, tested, integrated and deployed, while teams continue to make architectural and technical decisions around it. AI can make individual activities significantly faster without improving that entire flow to the same degree.

Faster code generation can shift effort toward review. AI-generated tests still need to be assessed for quality and relevance. In other situations, reducing repetitive work genuinely frees up capacity elsewhere in the team. The effect depends on where AI is applied and what happens in the rest of the development process.

This makes adoption a poor proxy for productivity. A more useful view is to understand where AI changes the development process as a whole: which activities take less time, whether that creates new bottlenecks elsewhere and whether the gains eventually translate into faster delivery, better quality or additional capacity.

For technology leaders, that also changes the conversation around AI investment. The question becomes less about how many developers are using a tool and more about which ways of working are demonstrably improving engineering performance.

What works in one team doesn't automatically scale

Most AI adoption starts organically, and that is useful. Developers need room to discover where the technology helps and where it does not. The difficulty is that successful practices rarely spread by themselves.

One developer may have found an effective way to explore a legacy application, while another team has developed a strong workflow for test generation or is using agents for repetitive engineering tasks. Without a way to compare and share those experiences, other teams often start the same learning process again.

Over time, this can create plenty of AI activity but relatively little organizational learning. Different tools and workflows emerge, teams solve similar problems independently and it becomes difficult to distinguish between approaches that consistently create value and those that work well only in a specific context.

The goal is therefore not to prescribe one way of working for every developer. It is to create enough shared practice to learn from what is already happening. Useful experiments can become reusable workflows or guidelines, while teams retain room to keep testing new capabilities.

Tool selection becomes more nuanced for the same reason. The best answer is not necessarily one universal AI platform, nor complete freedom for every team. Different tools may suit different engineering activities, but those choices should be informed by the development environment, security requirements, costs and the value teams are actually getting from them.

More structure shouldn't mean less experimentation

As AI becomes part of everyday development work, organizations also need to decide where more structure is necessary. Security, privacy, intellectual property, code quality and vendor dependencies quickly become part of the discussion.

Too little structure creates unnecessary risk and fragmentation, while too much centralization can slow down the experimentation needed to understand where AI adds value. A workable approach provides clear boundaries for responsible use and enough consistency to build on successful practices, without defining every workflow centrally.

This is particularly important because both the technology and the way developers use it are evolving quickly. Practices that make sense today may need to change as tools become more capable or new approaches emerge. Governance therefore needs to support learning as well as control.

AI agents make ad hoc adoption harder to sustain

That balance becomes more important as development moves toward more agentic ways of working. Coding assistants mainly support individual activities. Agents can increasingly take on larger sequences of work, such as exploring a codebase, preparing changes, generating tests or producing documentation. As the scope of that work expands, questions about access, review and responsibility become more closely connected to the design of the development process itself.

This makes a purely ad hoc approach harder to sustain. Organizations need to understand not only whether a tool is safe to use, but also which activities it is suited to, where human judgment remains essential and how agentic workflows affect the work around them.

A static policy built around today's tools will only go so far. Teams need a practical way to evaluate new capabilities as they emerge and decide which ones are useful and mature enough to adopt more widely.

The real capability is learning what works

The longer-term capability is therefore not mastery of one particular AI tool. It is the ability to keep identifying, testing and spreading better ways of working as the technology develops.

That starts with understanding what developers are already doing and where the biggest opportunities lie. New approaches can then be tested in real projects and codebases, making it possible to see whether they genuinely improve the work rather than simply performing well in a demo.

Practices that prove useful also need a route beyond the original team. Internal experts can help colleagues apply what has already been learned, while an engineering community creates a place to exchange workflows, discuss new tools and evaluate new experiments. This avoids every team having to rediscover the same lessons and makes progress less dependent on one-off training or a handful of enthusiastic early adopters.

Over time, the organization develops its own ability to assess new tooling, improve existing practices and decide where further investment in AI-assisted development is worthwhile.

Turning AI experimentation into a way of working

This is the starting point for Yuma's AI-Assisted Software Development approach. We work with development teams to understand how AI is already being used, where it can improve real engineering work and which tools fit the team's environment and objectives.

Those opportunities are tested within existing projects and codebases. Developers build experience by applying AI to their own work, while the practices that genuinely improve the development process can be translated into shared workflows and practical guidelines.

The approach is designed to build lasting capability within the organization. Coaching, internal experts and an active engineering community help teams share what works, build on it across the organization and adapt as tools and capabilities evolve.

The focus throughout is on improving software development, rather than increasing AI adoption for its own sake. The real value comes from understanding where AI helps teams work more effectively and making those improvements part of the way software is built and delivered.