The uncomfortable truth about AI coding and senior engineers

This keeps coming up in hiring conversations. Teams adopt AI copilots expecting faster delivery, but their strongest engineers quietly say they feel slower, not faster.

A recent CIO opinion piece by Cay Zhang (Jan 2026), referencing a METR randomised trial, put numbers behind what many teams are already sensing. Senior engineers working on their own production codebases took around 19% longer when using AI tools. Despite that, they still felt more productive.

That disconnect matters.

AI is excellent at generating code that looks right. The problem is that in complex systems, “almost right” is often worse than obviously broken. It compiles. It passes tests. But it misses context, edge cases, or business rules that only surface later.

For experienced engineers, the work shifts from building systems to reverse-engineering AI output. That breaks flow, increases cognitive load, and quietly taxes delivery speed.

The issue isn’t the technology. It’s where organisations are applying it.

High-performing teams are starting to move AI up the stack. Instead of using it to type faster, they use it inside heavily constrained environments. Strong schemas. Strict types. Clear architectural boundaries. When AI output doesn’t fit, the system rejects it automatically.

That changes the role of senior engineers. Less code writing. More constraint design. Less review. More prevention.

From a hiring and resourcing perspective, this is already visible. Demand is shifting toward staff and principal engineers who can design internal platforms, not just ship features. Short-term contract architecture support is replacing generic “AI-enabled” development capacity.

AI doesn’t replace senior engineers. It exposes whether an organisation knows how to use them properly.

What to watch next

Teams that measure outcomes rather than output will adapt fastest. The rest may look busy, but move slower.