Why the coding bottleneck is disappearing
Imagine a VP of Engineering telling the board that AI now drafts most of the boilerplate on the platform team, and a director asking the obvious follow-up: so what do we actually pay senior engineers for? That question is why AI-first engineers have become a real hiring conversation, not a buzzword, and the honest answer has less to do with typing speed than with judgment.
According to DORA's 2025 State of AI-assisted Software Development report, based on a survey of nearly 5,000 technology professionals, 90% now use AI at work and most say it has made them more productive. That's a belief people hold about their own output, not a measured productivity gain, which matters whenever adoption numbers get treated as proof of results.
Anthropic's analysis of roughly 400,000 Claude Code sessions, covering usage from October 2025 to April 2026, found a clear split in who does what: people still make about 70% of the planning decisions, while the model carries out most of the execution steps.
Domain understanding of the problem, not coding training, was what predicted whether a session actually succeeded. Nathen Harvey, DORA's Lead at Google Cloud, frames AI's role in the organization's report this way:
“AI’s primary role in software development is to amplify.”
— Nathen Harvey, DORA Lead, Google Cloud, as stated on the page · Source: https://services.google.com/fh/files/misc/2025_dora_ai_capabilities_model.pdf
We think the '90% of engineers use AI' headline is the wrong number for a hiring conversation. What decides whether that code ships safely is whether someone understood the problem behind it, and that's a judgment question, not a tooling question.
Sources: https://services.google.com/fh/files/misc/2025_dora_ai_capabilities_model.pdf, DORA | Balancing AI tensions: Moving from AI adoption to effective SDLC use, How Claude Code is used in practice \ Anthropic
From codebase mastery to product judgment
The AI coding-tool vendor Augment Code rebuilt its own hiring criteria around this shift and wrote on its blog that coding ability is no longer the primary differentiator of engineering talent, though it still matters. In its account, the engineers delivering the most leverage stood out for product taste and architectural judgment, not raw output.
FDE Academy, a career-education company covering AI engineering roles, makes a similar argument in its own materials: as AI tooling shrank the time engineers spend on execution, judgment about what's worth building became the scarcer resource. The traditional bottleneck, it writes, simply stopped being engineering execution. For managers, that reshuffles what 'senior' means: less about owning the trickiest algorithm, more about owning what the team builds and why.
| Skill area | Traditional emphasis | AI-first emphasis |
|---|---|---|
| Code writing speed | Core differentiator | Baseline expectation, not a differentiator |
| Debugging and verification | One skill among many | Central to trusting AI output |
| Product and user understanding | Nice to have | A primary differentiator of impact |
| Review and architectural judgment | Secondary to shipping output | The scarce, decisive skill |
Sources: How we hire AI-native engineers now: our criteria | Augment Code, AI Product Engineer Role Explained | FDE Academy
The new hierarchy, not a dismissal of skill
None of this means technical depth stops mattering. DORA's AI Capabilities Model names a focus on user needs as one of seven capabilities needed to keep AI-accelerated teams moving in the right direction, not just faster, which only works if engineers still understand the systems they're accelerating.
The shift asks engineers for product thinking about AI output, not just syntax fluency: reading a pull request for whether it solves the right problem, not only whether it compiles.
Sources: https://services.google.com/fh/files/misc/2025_dora_ai_capabilities_model.pdf
Why deep technical skill still matters
DORA's qualitative research describes what it calls an 'expertise paradox': AI can let engineers skip the productive struggle that normally builds deep skill, risking skill degradation over time. The same report finds that 30% of developers report little to no trust in AI-generated code, which is exactly the kind of verification skill a hiring process still needs to test for.
Two controlled studies make the risk concrete. In one, participants who used AI completed more of a coding task but answered questions about their own just-written code correctly 12.5% less often than those who worked unassisted.
In Anthropic's randomized trial, developers who used AI to learn an unfamiliar library scored 17% lower on a follow-up comprehension quiz than those who coded by hand, with the largest gap on debugging questions.
We're skeptical of any hiring framework that treats product judgment as a replacement for technical depth rather than a layer on top of it. The engineers who catch a subtly wrong AI suggestion are usually the ones who still know how the system works underneath.
- Reviewing AI-suggested changes for correctness, not just plausibility
- Debugging when AI-generated code fails in production
- Judging when AI output touches a security- or data-sensitive path
- Owning and explaining a system's behavior to auditors or new hires
Sources: DORA | Balancing AI tensions: Moving from AI adoption to effective SDLC use, More Code, Less Understanding? On the Impact of AI Assistants on Developers’ Productivity and Code Ownership, How AI assistance impacts the formation of coding skills \ Anthropic
Hiring AI-first engineers and AI-first managers
In our view, the practical hiring question isn't whether a candidate can write an algorithm from scratch, it's whether they show engineers' product thinking, AI fluency and the judgment to catch a bad suggestion. That question applies just as much to AI-first managers deciding what to reward in performance reviews.
A recruiting guide from recruiter.daily.dev advises hiring managers to look for candidates who combine product-engineering skill with AI or LLM expertise, rather than defaulting to pure ML researchers, warning that pure ML engineers often lack the product instincts the role needs.
The same guide notes senior AI product engineers in the US are commanding salaries in the $180,000 to $230,000-plus range, a market signal worth watching even without a verified benchmark behind it.
Sources: https://recruiter.daily.dev/roles/ai-product-engineer/
Interview signals that reveal product judgment
Treat the following as starting questions to adapt, not a validated assessment. Augment Code's own hiring framework, for instance, evaluates 'Ownership & Leadership' by asking whether a candidate drives outcomes, not just tasks, a useful prompt for probing whether someone thinks past the ticket.
Sources: How we hire AI-native engineers now: our criteria | Augment Code
What changes for juniors versus seniors
This skills shift AI coding brings hits juniors and seniors differently. Seniors are asked to own more: reviewing AI output, making architectural calls and being accountable for what ships, close to what one longitudinal study calls 'supervisory engineering work,' directing, evaluating and correcting AI rather than writing every line themselves.
Juniors face a harder problem: how do you build judgment about code you didn't struggle to write? A qualitative synthesis of practitioner accounts, coded from 57 developer videos, flags exactly this concern, describing erosion of foundational problem-solving skills and insufficient preparation for entry-level engineers under AI-heavy workflows.
Sources: The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study, Coding with AI: From a Reflection on Industrial Practices to Future Computer Science and Software Engineering Education
Training and evaluating AI-first teams
Most organizations can describe this shift in a hallway conversation. Far fewer can say, with evidence, whether their AI-first engineers have actually moved from code output to product judgment, or whether training budgets are reaching the teams that need it most.
That's a measurement gap, not just a training gap. AI Adoption Score's assessment maps every person, team and department against five maturity levels across skills, usage, culture, impact, vision and governance, so you can see whether AI-first engineers are building judgment or just logging more AI usage.
Because skill gaps aren't evenly spread, the platform's Individual Skills Distribution view maps each person's expertise so training gets allocated by actual gap rather than assumption. Imagine, for example, two teams that are already well advanced while the rest of the org is still getting started: that view would flag the gap instead of funding a blanket rollout.
Track downstream signals alongside survey results: review turnaround time, defect rates and production incidents, not just how often someone says they used an AI tool this week. Usage and confidence are a starting point, not the finish line.
Guarding against skill atrophy and knowledge debt
There's a name now for what happens when engineers stop understanding the AI-written changes running in their own systems. A peer-reviewed paper on AI-assisted development calls it 'Knowledge Debt,' a developer-level analogue to technical debt, incurred whenever an agent makes a change nobody on the team could fully explain.
The same paper cites an industry estimate that roughly 42% of committed code is already AI-generated or AI-assisted, projected to reach 65% by 2027, a secondhand figure worth treating as directional rather than precise, since the paper didn't collect it itself.
A qualitative synthesis of practitioner accounts describes development bottlenecks shifting toward code review as AI-based coding scales, alongside growing concern about code quality and maintainability. That matches what the skill-hierarchy shift predicts: once writing code gets cheap, reviewing it becomes the scarce, valuable skill.
Our bet is that knowledge debt will matter more to engineering leaders over the next few years than model benchmarks do. A team that can't explain its own system is a governance risk no matter how fast the code got written.
Sources: Agents That Teach: Towards Designing Incidental Learning Back into AI-Assisted Software Development, Coding with AI: From a Reflection on Industrial Practices to Future Computer Science and Software Engineering Education
Evaluate engineers by problems solved, not code shipped
The coding bottleneck isn't gone, it's moved. It used to sit at the keyboard; now it sits in the judgment calls before and after the AI writes anything: what to build, whether the output is right, and who's accountable when it isn't.
Hire, train and evaluate for that judgment without pretending technical depth stopped mattering. The AI-first engineers worth hiring are the ones who can still catch a wrong answer, not just produce more answers faster.
Start by measuring where your people actually stand, not where the org chart assumes they are.
Frequently asked questions
Does this mean we should stop testing candidates on algorithms?
No. Algorithm screens still catch weak baseline skills, but weight them as a small share of the process rather than the deciding factor. Reserve most of the interview time for exercises that test judgment about product fit, architecture and when to override AI output.
How do we keep junior engineers from losing coding fundamentals?
Sequence it by seniority: require more hand-coding and manual debugging early in a junior's tenure, then loosen the requirement as they show they can explain AI-generated decisions unprompted. You'll know it's working when juniors can debug production issues without first asking an AI tool what's wrong.
How often should we re-check engineers' AI skills and confidence?
Treat it as a recurring check, not a one-time audit; a quarterly or twice-yearly baseline lets you see whether training actually moved skills and confidence rather than relying on a single snapshot. Re-measure after any major training push or tooling change, not just on a fixed calendar.
Who should own redesigning hiring criteria for AI-first roles?
Engineering leadership should own the technical bar, with L&D or People teams involved on assessment design and rollout, since this spans hiring, training and performance review. Treat it as a joint decision rather than something HR imposes on engineering or vice versa.
Sources: How AI assistance impacts the formation of coding skills \ Anthropic
