By mid-2026, every major code editor ships with AI assistance built in. GitHub Copilot has over 1.8 million paid subscribers. Claude, GPT-4, Gemini, and a growing constellation of specialised coding models are a browser tab away. A competent engineer can go from a problem statement to a working implementation in a fraction of the time it took three years ago.
This has created an existential problem for technical hiring. The foundational assumption of most coding assessments—that the code a candidate submits reflects their individual ability—is no longer reliably true. And the industry's response has been, generously, confused.
The tools have changed. The assessment hasn't. And the gap between the two grows wider every quarter.
Strategy 1: Ban it#
The instinct is understandable. If AI can write code, and you want to assess a human's ability to write code, then the simplest solution is to remove AI from the equation. Lock down the browser. Disable clipboard. Monitor keystrokes for suspiciously fast typing. Use proctoring software to watch candidates through their webcam.
This is the approach adopted by most legacy assessment platforms, and it fails on three fronts.
Enforcement is a losing battle. Determined candidates can use a second device, a separate monitor, or AI tools embedded in IDEs that proctoring software can't detect. Browser lockdowns introduce false positives—candidates flagged for switching to a calculator or reading the problem statement in another tab. The arms race between proctoring tech and circumvention techniques is expensive, adversarial, and ultimately unwinnable.
It destroys candidate experience. Being watched through a webcam, having your keystrokes monitored, and being flagged for suspicious behaviour creates an atmosphere of distrust. Top candidates—the ones with options—will simply opt out. A 2025 survey by Blind found that 71% of senior engineers described webcam proctoring as a dealbreaker, ranking it above algorithm-only assessments as a reason to abandon an interview process.
It creates a false environment. If your engineers use Copilot, Claude, and ChatGPT every day—and by 2026, virtually all of them do—then assessing candidates without these tools tells you how they perform in an environment that doesn't exist at your company. It's like evaluating a carpenter's skill by taking away their power tools and handing them a hand saw.
The fundamental problem with banning AI is that it optimises for the wrong thing. You're not trying to find candidates who can work without AI. You're trying to find candidates who can do the job—and the job now includes AI.
Strategy 2: Ignore it#
The opposite approach: don't mention AI, don't try to detect it, and evaluate the output the same way you always have. If the code passes the tests, the candidate passes the assessment. Whatever tools they used to get there are their business.
This approach has the advantage of simplicity. No proctoring infrastructure, no adversarial dynamics, no false positives. It treats candidates as adults and avoids the surveillance problem entirely.
The problem is that it also avoids the assessment problem entirely.
When a state-of-the-art model can solve 85–92% of standard coding challenges correctly on the first attempt—including many "hard" algorithm problems—the assessment stops measuring engineering ability and starts measuring prompting skill plus the ability to click "accept" quickly enough.
This isn't hypothetical. Internal data from three major assessment platforms (shared anonymously at a 2025 hiring-tech conference) showed that average assessment scores increased 34% between 2023 and 2025, while on-the-job performance ratings for the same cohort showed no improvement. The scores went up because the assessments got easier—not because the candidates got better. AI inflated the signal until it became noise.
Ignoring AI also creates a fairness problem in reverse. Candidates who use AI heavily and uncritically may produce code that works but is poorly integrated, inconsistent with existing patterns, or subtly fragile in ways that only emerge in production. If your assessment can't distinguish between "wrote a thoughtful solution" and "pasted AI output that happens to pass tests," you've lost the ability to differentiate candidates.
Strategy 3: Evaluate it#
The third approach is the hardest to implement and the only one that produces reliable signal in 2026. Instead of banning or ignoring AI, you explicitly allow it—and design the assessment so that AI usage is part of what you're evaluating.
This requires a fundamental shift in assessment design. The challenge can't be something an AI can solve end-to-end, because then the assessment just measures who's faster at prompting. But it also can't be artificially restricted to problems AI can't handle, because that creates the same artificial-environment problem as banning it.
The goal isn't to test whether candidates can use AI—everyone can. The goal is to test whether they can use it well: selectively, critically, and in service of a coherent engineering outcome.
What this looks like in practice#
The key insight is that AI is powerful at generating code from specifications, but weak at understanding context it doesn't have. A real codebase has implicit constraints: architectural decisions, naming conventions, performance requirements, business logic buried in helper functions, and patterns that aren't documented but are obvious to a human reading the code.
When you place a candidate in a real codebase and ask them to accomplish a task that requires understanding this context, AI becomes a useful tool rather than a replacement for thought:
- The candidate who uses AI well reads the existing code first, understands the patterns and constraints, then uses AI to accelerate implementation of the parts that are routine—boilerplate, standard patterns, syntax they don't have memorised. They review and adapt the AI's output to fit the existing codebase. They're faster without sacrificing quality.
- The candidate who uses AI poorly prompts the AI with the task description, gets back code that technically works in isolation, and pastes it in. The result passes basic tests but clashes with existing architecture, duplicates functionality that already exists, ignores project conventions, or introduces subtle bugs that the AI didn't have enough context to avoid.
- The candidate who doesn't need AI for this task works through it directly, producing clean code that integrates naturally. Their approach might be slightly slower, but the output demonstrates deep comprehension.
All three approaches are visible in the assessment. All three produce different—and evaluable—signal.
AI proficiency is an engineering skill#
This is the point most hiring teams haven't fully internalised. Using AI tools effectively is no longer a nice-to-have. It's a core competency. The ability to collaborate with AI—knowing when to delegate to it, when to override it, when to step back and think from first principles—separates productive engineers from unproductive ones.
A study published in early 2026 by Microsoft Research tracked 2,400 engineers across 16 companies over six months and found that the top quartile of performers wasn't defined by whether they used AI tools (virtually everyone did), but by how they used them. The top performers used AI for roughly 30% of their coding time, focused on routine tasks and boilerplate, and spent significantly more time reviewing and adapting AI output. The bottom quartile used AI for over 60% of their coding time and spent less time reviewing—resulting in more bugs, more reverts, and more incidents.
An assessment that bans AI can't measure this skill. An assessment that ignores AI can't measure it either. Only an assessment that's designed with AI in the picture can evaluate whether a candidate has the judgment to use it well.
The design principles#
Building AI-aware assessments isn't about clever tricks. It's about designing for context-dependence: tasks where the right answer depends on understanding something the AI can't see.
- Use a real codebase, not a blank slate. Existing code creates context that AI tools don't have unless the candidate provides it—and providing it well is a skill worth evaluating.
- Evaluate integration, not just correctness. Does the solution fit the existing architecture? Does it follow the project's patterns? Or does it look like it was transplanted from a different project?
- Assess comprehension explicitly. The task should require understanding existing code, not just adding new code. Bug fixes and feature extensions within existing systems are ideal.
- Give candidates a real environment. Full IDE, terminal, git, AI tools. Let them work the way they'd work on the job.
- Make the evaluation holistic. Not just "does it pass tests" but "how did they get here, and does the result demonstrate understanding?"
The difficulty isn't in any one of these principles. It's in building the infrastructure to deliver them at scale—real codebases in cloud environments, with AI tooling baked in, evaluated against rubrics that go beyond "did it compile." That's an infrastructure problem, not a philosophy problem. And it's solvable.
Where this leaves hiring teams#
If you're still banning AI in assessments, you're fighting a losing battle against technology while alienating the best candidates. If you're ignoring AI, your assessment scores are becoming less meaningful every quarter. Both strategies are converging on the same outcome: noise.
The path forward is harder. It requires rethinking assessment design from first principles: not "how do we prevent AI from helping?" but "how do we design a challenge where AI is a tool, not a shortcut, and where the signal we care about—engineering judgment—is visible in the outcome?"
It's more work to build. It's worth building. Because the alternative is a hiring process that's expensive, adversarial, and increasingly unable to tell you what you actually need to know: can this person do the job?