Written by: Wiktor Stefański, Head of People & Operations, Digital Colliers
Every candidate passes the take-home now. That's not a candidate problem, it's an assessment problem. When the constraint was producing a correct solution, the take-home worked. Now producing a correct solution is the easy part, and we've been grading the wrong thing for at least eighteen months.
The question isn't whether someone can ship working code with an AI assistant. Almost everyone can. The question is whether they can tell when the assistant is lying to them, whether they'll catch the subtle bug it introduced, and whether they'll push back on a bad architectural suggestion instead of accepting it because the diff looked confident. That's what you're hiring for in 2026. Your interview loop has to actually measure it.
Why the take-home stopped working
The take-home was always a proxy for two things: can you write correct code, and will you invest effort. Both signals collapsed. Correctness is table stakes. Effort is unmeasurable when the tool does most of the typing.
Worse, the take-home now selects against the trait you want. A candidate who prompts an assistant, accepts the first plausible output, and submits it in forty minutes looks identical to one who read every line, ran adversarial tests, and rejected two suggestions. On paper, same submission. In production, wildly different engineers.
And production is where this matters. Research on AI-generated code found that more than 15% of commits from every major coding assistant introduce at least one issue, rising to 29.1% for Gemini. Unresolved technical debt from AI-generated code jumped from a few hundred surviving issues in early 2025 to over 100,000 by February 2026. The people who don't catch bad AI output aren't hypothetical. They're already shipping.
What actually correlates with senior AI-augmented performance
The pattern from teams that are shipping AI features into production, as opposed to the 95% of enterprise GenAI pilots that deliver zero measurable P&L impact, comes down to three habits.
- Reading more than writing. One study found experienced developers using AI assistants review 6.5% more code and produce 19% less of their own original code. That's not a productivity loss, that's a role shift. The best engineers on AI-augmented teams are doing more review, not less.
- Refusing plausible output. The tell is a candidate who says "that looks right but I don't trust it yet" and then goes to verify. Juniors accept. Seniors verify.
- Explaining what the tool got wrong. Not in the abstract. In the specific diff, right now.
You don't get any of these signals from a take-home.
The replacement: a live, AI-permitted, time-boxed review session
The format that works looks nothing like the old assessment. It's a two-hour session, AI tools fully allowed, ideally required. You give the candidate a small existing codebase with a real bug and a feature request. Both have been partially attempted by an AI assistant, and both attempts are subtly wrong in a way a careful reader would catch.
The candidate's job isn't to write the fix from scratch. It's to review the AI's work, decide what to keep, what to throw out, and ship the correct version. You watch them do it. You ask why they trusted this line and not that one. You ask what they'd add to the PR description before merging.
What you're grading:
- Did they catch the bug the AI didn't catch
- Can they articulate why the AI's approach was wrong, not just that it was wrong
- Do they push back when you defend the AI's suggestion
- Would you let them merge to your main branch on Friday afternoon
That last one is the whole interview compressed into a sentence.
The hard deadline nobody's planning around
Here's the part most hiring managers are missing. EU AI Act Article 50 transparency obligations apply from 2 August 2026. High-risk system obligations follow on 2 December 2027. If you're building anything that touches those categories, the engineers you hire between now and mid-2026 are the ones who'll carry your compliance posture through both deadlines.
That's roughly two hiring cycles. If your loop still can't distinguish an engineer who catches bad AI output from one who ships it, you're going to inherit the second kind. And the cost of that shows up not in your hiring metrics but in the audit that lands eighteen months later.
Redesign the loop now. The take-home isn't coming back.