You rolled out AI coding tools across the engineering organisation. Adoption hit 90%. The metrics look great. But the same rollout shifted your bottleneck. Like a production line, tuning one stage just exposes the next constraint, and this one could be landing on your senior engineering leaders, the 10x multipliers you can't afford to lose. Check in with them. They may need protecting. The traits of a strong senior engineer (knowledge sharing, iterative process, sound architecture, objective measurement) are ones I've written about before in Five tenets of an early-stage startup engineer. Your most experienced engineers, the ones who design the systems, mentor the team, and make the decisions that compound over years, may be the least likely to use AI. But when they do, they save more time than anyone else. We know what good looks like. So why are they under-utilising AI?
The adoption inversion
DX's Q4 2025 report across 135,000 developers paints a clear picture. Junior engineers have the highest daily AI usage at 41.3%. Staff+ engineers have the lowest adoption levels across all seniority bands. But Staff+ engineers who use AI daily report saving 4.4 hours per week, compared to 3.3 hours for monthly users.1 The people getting the most value from AI are using it the least. This pattern shows up in DORA's research too. Laura Tacho and Nathen Harvey discussed it on the Engineering Enablement podcast: junior engineers adopt AI with much more intensity than their senior counterparts, but staff engineers save more time than juniors when they do use it.2 The reason matters. A junior developer saving three hours writes more boilerplate. A Staff+ engineer saving 4.4 hours has time for the work that actually moves the business: architecture decisions, system design, mentoring, threat modelling, and customer proximity. Those activities compound. They shape what gets built, how it scales, and whether it survives contact with production. DX put it directly: understanding the adoption barriers for senior engineers and removing them frees significant time, especially as these engineers have wide scope of influence and can apply AI to higher-impact work where the effect compounds.1
Why the tools don't fit senior work
It's tempting to write this off as resistance to change. The legacy engineers clinging to their vim configs and refusing to try new things. That framing is wrong, and it leads to the wrong interventions. Faros AI published a detailed analysis of what's actually happening. Senior engineers operate in a fundamentally different problem space. As seniority increases, engineers spend less time coding. Their work involves stakeholder collaboration, API design for dozens of teams, architectural decisions with multi-year implications, and query optimisation handling millions of requests.3 Current AI tools are optimised for the wrong part of that workload. They're brilliant at generating syntax, writing boilerplate, and scaffolding new features. That's junior-shaped work. When senior engineers try to apply AI to system-level thinking, cross-cutting architectural concerns, or nuanced trade-off decisions, the tools fall short. The mismatch between the tool's strengths and the senior engineer's actual work creates a rational decision to not bother. Then there's trust. The 2025 DORA report found that around 30% of developers have little or no trust in AI-generated code.4 For senior engineers who've watched enough hype cycles come and go, scepticism isn't stubbornness. It's pattern recognition. The METR study found experienced developers were measurably slower with AI on tasks they already knew well.5 They've seen technologies that were going to change everything and didn't. They've cleaned up after junior developers who adopted the latest shiny thing without understanding the trade-offs. Faros AI found that most AI usage across all levels remains surface-level, with developers primarily using autocomplete features, while advanced capabilities like context-aware review or agentic execution remain largely untapped.3 Senior engineers look at this and correctly identify that the current value proposition is thin for the kind of work they do.
Shifting bottleneck sands
Junior developers are generating more code, faster. PR volumes are up 60% for daily AI users.6 But junior developers don't review their own code. That load lands on senior engineers. The people who were already the constraint in your system now have a bigger queue of AI-generated code to validate, and they're not using AI tools to help them do it. Gergely Orosz captured this dynamic in The Pragmatic Engineer: junior engineers are opening more PRs while senior engineers slow down because they spend more time reviewing.7 Harvey and Tacho discussed the same pattern: organisations that started with a broken code review process or a weak testing strategy now find those problems magnified by AI flooding more code into exactly those bottlenecks.2 Faros AI's telemetry quantifies it: PR review times increased 91% in teams with high AI adoption.8 Your senior engineers are spending their reclaimed hours (the ones they were supposed to use on architecture and mentoring) checking AI-generated code from juniors. Net gain: zero. Possibly negative, because the code under review is 154% larger on average and carries a 9% higher bug rate.8 Juniors got a code accelerator. Seniors became the quality gate. The constraint moved from writing code to reviewing it, and it landed on the people with the least spare time to absorb it.
My read here is a lag between old process and new reality. Any human review process has to be iterated on to optimise your talent's time. If your reviews are still catching syntax, that's misallocated attention. Linters automated that over a decade ago; human review time should go to design, contracts, and trade-offs. As it gets cheaper to rewrite, fix, or replace code, the motivation to spend hours on review weakens. Couple that with good automated review and there is a clear way to reduce the burden. The organisations stuck at this bottleneck usually share a "we've done it this way for years, why change" mindset, or they are large enterprises that adopt slowly by default.
Beyond the tool mismatch and the trust gap, three things commonly block senior adoption:
- The review burden is real. Senior time is being consumed by reviewing AI-generated code rather than creating AI-assisted work. The tools created a demand on their time before demonstrating value to them.
- Cultural inertia disguised as pragmatism. In organisations locked into a single ecosystem ("we're a C# shop" or "we're all-in on Java"), any new approach gets filtered through the existing identity. AI adoption requires a willingness to experiment that some engineering cultures have quietly killed.
- No structured enablement. Most organisations rolled out licences and assumed adoption would follow. That works for juniors who are naturally experimental. Seniors need to see AI applied to their actual workflow: design documents, architecture reviews, knowledge extraction, onboarding documentation. Not just autocomplete.
Help your leaders
The fix isn't buying more seats or mandating usage. It's meeting senior engineers where they work and showing them the value proposition for their problems, not the junior developer's problems.
- Start with champions, not mandates. Faros AI found that senior engineers are most influenced by credible voices they trust, people whose usual scepticism makes a positive endorsement stand out.3 Identify the respected technical leads inside your organisation and give them space to experiment publicly. A single staff engineer sharing a real use case in a Slack channel does more than any top-down directive.
- Apply AI to senior-shaped problems. Design doc generation from requirements. Architecture review against known patterns. Knowledge extraction from undocumented legacy systems. Onboarding documentation that captures tribal knowledge. These are the problems that eat senior time and compound when unsolved. Show that AI helps with these and adoption follows naturally.
- Fix the review bottleneck first. If senior engineers are spending their time reviewing AI-generated code, that's the constraint. Invest in AI-assisted code review tooling (like CodeRabbit or Copilot for PRs), automated linting, and stricter quality gates earlier in the pipeline. Reduce the review burden before asking seniors to add AI to their own workflow.
- Make time visible. DX's data shows the time savings are real when seniors adopt. 4.4 hours a week is meaningful.1 But that time has to go somewhere intentional. If reclaimed time gets absorbed by more review queues, meetings, or firefighting, the value disappears. Track where the saved time goes. Protect it for architecture, design, and mentoring.
- Run innovation days, not training sessions. Structured experimentation works better than courses. Hackathons, champion weeks, and dedicated spike time let senior engineers explore AI on their own terms, applied to problems they care about. The goal isn't to teach them prompting. It's to let them discover where AI fits into system-level work.
The DORA capabilities model makes it clear: organisations with a clearly communicated AI policy see dramatically better outcomes than those with ambiguity.9 Senior engineers don't need permission to use AI. They need clarity on expectations, safety nets when experiments fail, and evidence that the tools solve their problems, not someone else's. Juniors adopted AI on day one. The constraint has already moved to your senior engineers. The teams that get the next year right are the ones that see the shift early, give those engineers AI that fits their work, and protect the time it frees for architecture, design, and review.
The next bottleneck?
Step back and the pattern repeats. Code is becoming free, output is up, senior engineers have been optimised, your team embodies Kaizen. Where does the bottleneck move now? Steve Yegge said it best in The Future of Software with Steve Yegge and Ajit Banerjee: the longer arc keeps moving it upstream. More of the build is getting automated, and the work that still needs a human sits in the specs, the designs, and the guardrails. Those are the new code. Call it the singularity or just the trend line: the marginal cost of writing code is falling toward zero, and when code is close to free the scarce input stops being engineering hours and becomes judgement about what to build and why. The teams that run dry next won't run short of code. They will run short of ideas worth building, which is why the ideas pipeline is the next bottleneck to get ahead of. To stay ahead of the game write specs for the features the current model can't complete and re-test on every new model. With good ideas you can stay ahead of the competition.
Footnotes
-
GetDX, AI-assisted engineering: Q4 impact report. Staff+ engineers save 4.4 hrs/week (daily users) vs 3.3 hrs (monthly). Lowest adoption across seniority bands. Junior engineers at 41.3% daily usage. ↩ ↩2 ↩3
-
GetDX, DORA's 2025 research on the impact of AI. Harvey and Tacho on junior vs senior adoption patterns, review bottlenecks, and how AI amplifies existing dysfunction in code review. ↩ ↩2
-
Faros AI, Driving AI Adoption in Senior Software Engineers. Analysis of why senior engineers hold back from AI, the mismatch between tool capabilities and senior work, and the champion-based enablement model. ↩ ↩2 ↩3
-
Google Cloud, Announcing the 2025 DORA Report. 30% of developers report little or no trust in AI-generated code despite near-universal adoption. ↩
-
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Experienced developers 19% slower with AI on familiar tasks. AI least effective when developers had high prior exposure. ↩
-
GetDX, AI-assisted engineering: Q4 impact report. Daily AI users merge 2.3 PRs/week vs 1.4 for non-users, a 60% increase. ↩
-
Gergely Orosz, How tech companies measure the impact of AI. Junior engineers opening more PRs; senior engineers slowing down due to review load. ↩
-
Faros AI, DORA Report 2025 Key Takeaways. PR review times up 91%, PR size up 154%, bugs up 9% in teams with high AI adoption. ↩ ↩2
-
Google Cloud, Introducing DORA's inaugural AI Capabilities Model. Clear and communicated AI stance identified as foundational capability amplifying positive AI outcomes. ↩