The conversation about AI coding assistants in enterprise software teams has shifted in 2026. Two years ago the question was “do they work”. One year ago it was “what’s the productivity uplift”. In May 2026 the question is “what is the operating model for using them well at scale”.

The headline observations from the field through 2025 into mid-2026.

Adoption has crossed a threshold inside most enterprise engineering organisations. The share of developers using a coding assistant daily is well above 60% at most large Australian engineering teams. The arrangement at most large employers is now an enterprise licence to one of GitHub Copilot, Cursor, or a few smaller specialist players — sometimes two of them in parallel for different parts of the developer population.

Productivity numbers have stopped being the main reporting metric. The early productivity studies showed wide ranges and the field has lost confidence that productivity-per-developer is the right unit of measurement. The metrics moving forward are cycle-time-to-merge, pull-request review time, and time-from-ticket-to-deployed-code. The improvements on these are real but smaller than the early productivity numbers suggested — typically in the 10–25% range on the parts of the engineering workflow that the assistant directly touches.

Code quality concerns are not what most teams thought they would be. The early worry that AI-assisted code would be of lower quality has not played out clearly. The more interesting effect is that less-experienced engineers ship a different kind of code with assistance — typically more readable on the surface but with more subtle structural issues that come out in review. The senior engineering effort has shifted slightly from writing code to reviewing AI-assisted code.

Where teams are getting the most lift in May 2026.

Test scaffolding and test generation. Once a team has invested in good prompting patterns for test generation, the productivity lift on test coverage is meaningful. Several Australian engineering teams reported coverage gains in the 15–30% range over twelve months.

Documentation. AI-assisted documentation has been the quiet productivity win. The legacy code that nobody wants to document is now being documented at a much faster rate. The documentation quality is mid-tier but it is enormously better than no documentation.

Refactoring across a codebase. Pattern-based refactoring at scale is one of the strongest use cases. A senior engineer driving a coding assistant through a large refactor is much faster than the same engineer working alone. The catch is that the senior engineer is the critical input — the junior engineer driving the same refactor produces a worse outcome.

Greenfield prototype work. Standalone prototype and proof-of-concept work is dramatically faster with AI assistance. The trade-off is that prototype code makes it into production more often than it should, and the technical debt cost is real.

Where teams are getting smaller-than-expected lift.

Production-grade backend service work. The complex, context-heavy backend code in mature codebases is the hardest area for assistants to help on. The lift here is real but modest. The model is helping with boilerplate, type definitions, and common patterns more than with the genuinely difficult work.

UI development in complex design systems. The assistant helps but the design-system-specific context required is hard to put into the model reliably. Teams running tight design systems report frustration with assistants generating off-system components.

The operating model question in May 2026 is more interesting than the tooling question. Enterprise engineering leaders have moved past the licence-purchase decision and into the harder questions — what does code review look like when most code is AI-assisted, how do you preserve senior-engineering capability when juniors lean on the assistant for fundamentals, and how do you measure and manage the productivity of teams whose individual outputs are increasingly indistinguishable from each other.

A few practical recommendations from the field:

Treat the AI coding assistant as part of the engineering platform, not as an individual productivity tool. The team that defines shared prompts, shared review patterns, and shared usage guidelines gets dramatically more lift than the team that lets every engineer use the tool their own way.

Invest in onboarding. The teams that put two to three weeks of structured onboarding into how to work with the assistant well are still seeing productivity uplift twelve months later. The teams that just bought the licence and walked away have plateaued.

Watch the junior engineer development pipeline carefully. The data is early but the engineering managers I rate most highly are flagging concern about how to develop senior engineering judgement when the early-career engineer is being assisted on the fundamentals.

The next twelve months in this category are about specialisation. The generic coding assistant is being challenged by domain-specific tools — assistants tuned for SQL workloads, for cloud infrastructure work, for security-sensitive code, for low-code platform development. Enterprise engineering leaders should expect the licence-purchasing conversation to move from “one assistant for everyone” to “the right assistant for the right job”, and to budget review cycles accordingly.