The job of an engineer has absorbed new tools before. At various points in the last thirty years the same conversation has happened about Google, about IDE autocomplete, about Stack Overflow, about version control, about containerisation. Each time a new tool moved from "controversial edge practice" to "bonus skill" to "baseline competency" to "assumed" — usually faster than the industry's hiring practices were ready to adapt.
AI collaboration is somewhere in the middle of that arc right now. It's past controversial; the engineers who refuse to use it are increasingly rare, and the companies that officially ban it usually don't enforce the rule. It's past "bonus skill" in most roles, because the candidates who've never used AI meaningfully are at a productivity disadvantage against peers who have. What it isn't quite, yet, is "assumed." A lot of hiring processes still treat AI fluency as a differentiator rather than a baseline.
That timing gap is worth paying attention to, because the history of similar gaps says they close fast once they start to.
What "core" actually means
When we say a skill is core to engineering, we don't mean engineers can't get work done without it. Plenty of engineers produce real work without strong Git fluency. We mean a few specific things.
The skill is assumed to be present at the level of basic professional competence. Nobody advertises "version control experience" as a differentiator in a job post anymore, because assuming an engineer can use Git is about as defensible as assuming they can use a keyboard.
A candidate who lacks the skill will have to be trained in it, at cost to the team. Onboarding time compounds. If you hire three engineers who can't work effectively with modern AI tools, the productivity gap against three engineers who can is meaningful — and the gap is measured in quarters, not weeks.
The skill shows up as part of other skills. You don't test for "can this candidate use a debugger" as a standalone round. You test debugging competence inside larger tasks, because the tool is how a competent engineer engages with the problem. AI collaboration is now the same. Testing for it as a separate thing is like testing separately for "can this candidate open a terminal."
Why hiring is slow to adapt
Hiring practices lag technical reality by years, and not for lazy reasons. The shape of an interview process has to hold up across candidates of wildly different backgrounds, under legal and compliance scrutiny, with hiring decisions being reviewed for bias and consistency. You can't move fast without creating comparison problems between candidates on either side of the change.
There's also the small factor that most interview rounds were designed by engineers who are now senior enough not to have learned AI fluency in their formative years. The skill being tested implicitly is the skill the tester happens to have. It takes work to get past that.
None of that makes the lag defensible forever. But it explains why most interview processes in 2026 still treat AI use as a suspicious edge behaviour rather than assumed competence.
What changes when you accept the frame
If AI collaboration is a core engineering skill, a few things follow for a hiring process.
The "no AI" clause on async rounds becomes indefensible. You don't ban the debugger in a debugging interview. Banning AI in the rounds where a candidate would obviously use AI on the job measures artificial conditions, and that measurement was already producing weaker signal than the unrestricted version.
The rounds you keep have to make space for the skill to show. That means tasks deep enough that evaluating AI output matters, prompts realistic enough that the candidate would actually reach for the tool, and submissions that capture the conversation and not just the result.
The things you hire for shift subtly. Framing, evaluation, judgement, authorship — the competencies that surround AI use — become more central than raw implementation speed. Candidates who are strong at those but slow at pure typing used to be easy to miss. They're harder to miss when the process is shaped to surface the surrounding work.
The awkward middle
The teams most exposed to the gap are the ones that aren't sure where they stand. They've quietly decided AI is probably fine, they've updated their internal engineering practices to assume it, and they've left their interview process untouched. Candidates pick up on this very quickly — a job description that talks about AI-forward engineering, a take-home with a "please don't use AI" clause, and a live coding round with no external tools. The team's stated position and their implicit position diverge, and the candidates most worth hiring tend to read the implicit one as the real one.
If your company's position is "AI is a core skill", the process has to say so. At CriticCode we build the async round around the assumption that AI is in the room, because the job is. Whatever tool you use, the test is whether a candidate reading your process for the first time can tell what you actually think.
The practical move
Write one paragraph describing how your team uses AI in daily work, honestly. Then read your current interview process against it. Any round where the treatment of AI contradicts the paragraph is a round to redesign. That's usually the whole to-do list, and it takes less time than any of the interviews you're quietly running with the contradiction still in them.