Take-home coding assignments hit a 48% AI-cheating rate. Live coding fixes the wrong half of it.

The number that ended a thousand hiring processes

In early 2026, CodeSignal published a number that made most engineering hiring teams sit up: 35% of proctored technical assessments now show signs of AI-assisted cheating, up from 16% in 2024, a 119% year-over-year jump. Split it by role and it gets worse. Fabric's assessment platform flagged 38.5% of roughly 19,000 AI-conducted interviews for cheating behaviour. Narrow that to pure technical and engineering roles and the rate climbs to 48%, close enough to one in two candidates that it stops being an edge case and starts being the default assumption.

The tools doing this work are cheap, purpose-built, and mostly undetectable. Cluely runs $20 a month and renders an invisible overlay that doesn't appear in a screen share. Interview Coder is a one-time $100 purchase built for exactly one job: solving take-home problems in real time while looking like normal typing. There's an open-source tier underneath that too, forks like OpenCluely and Pluely that rename their own processes to dodge the crude scanners some applicant-tracking vendors ship. Every documented detection method, keystroke-dynamics analysis, perplexity scoring, process-name checks, has a documented bypass, usually one that surfaced within months rather than years.

The response from most engineering organisations has been to declare the take-home assignment dead and move back to live, camera-on coding sessions. That's a sane reaction to a real problem. It's also fixing the wrong half of it.

The signal take-home coding assignments were never good at

Take-home tests existed for a reasonable reason: they let a candidate produce real code without the stage fright of a whiteboard, on their own schedule, without an interviewer staring over their shoulder. Long before anyone had heard of Cluely, engineers like Kitty Giraudel were pointing out the format's original sin. A multi-hour unpaid assignment doesn't measure coding ability so much as it measures who can afford to spend three unpaid hours on a job application, a filter that quietly excludes candidates with caregiving duties, health constraints, or a second job, independent of how well any of them can code.

Put plainly, the signal a take-home returned was never a clean read on "can this person write correct code." It was closer to "will this person spend real, uncompensated time to get this job," which conflates diligence and desperation with competence. AI cheating didn't corrupt a pristine signal. It made a signal that was already marginal cheap enough to fake at scale.

Why the cheat rate isn't the real story

The more revealing number in the 2026 data isn't the 48%. It's that 83% of candidates surveyed by TestPartnership said they'd use AI assistance on an assessment if they believed the odds of getting caught were low, while only 14% currently admit to having done so. Correct for the obvious underreporting and the estimated actual usage lands around 35-42%. That gap between "would, if safe" and "already have" tells you the behaviour isn't bounded by any shared sense that it's unfair. It's bounded by fear of getting caught.

That's not a population split neatly into honest and dishonest candidates. It's a mismatch between an assessment format that assumes zero tool access and a job that will hand the same candidate full tool access on day one. Most working engineers in 2026 don't think of an LLM as a cheating device any more than they think of Copilot as one; it's the tool they're expected to already have folded into how they write code. A take-home built around the fiction that it doesn't exist was always going to get gamed once the tooling got good enough.

The live-coding rebound, and the signal it trades in for

Live coding under observation solves the specific problem of "did an LLM write this submission instead of the candidate." It doesn't solve the broader problem of measuring engineering ability, and in some documented cases it makes that measurement worse. A 90-minute timed session with a camera on and an interviewer watching conflates "can code while being watched under pressure" with "can code," a distinction that mostly turns into noise once you're evaluating senior or staff-level candidates who haven't sat a cold whiteboard round in a decade.

There's a sharper version of the same problem: live, tool-free coding actively penalises the exact AI-fluency the job will require, while rewarding candidates who spent months grinding LeetCode without ever touching a model, a skill with a weak correlation to real production output. Run that filter across a large enough pool and you risk selecting for the wrong end of the distribution, exactly the candidates least prepared for a job that will hand them Copilot on day one.

The stakes of getting that wrong aren't abstract. A bad junior engineering hire is commonly estimated to cost $42,000 to $125,000 once you count recruiting, salary, onboarding, and lost productivity. A bad VP or director-level hire runs $200,000 to $750,000 or more, roughly two to five times annual salary. Swapping one flawed proxy for another isn't a neutral move when the cost of a false read is that high; it just changes who gets rejected for the wrong reason.

What OpenAI and Microsoft's split-round experiment gets right

A more interesting response is showing up at two of the companies you'd expect to have thought hardest about this. OpenAI now allows AI tools during its own coding rounds, on the condition that the candidate shares their screen and narrates their reasoning out loud. Microsoft's SWE Applied AI/ML track runs a two-round structure instead: round one is fully AI-assisted, round two bans AI outright, and the interviewer compares the same candidate's judgment across both conditions.

The emerging consensus among engineers writing about this in 2026 frames the durable signal for senior and IC hiring as something closer to: how does a candidate break down an ambiguous problem, where do they push back on a model's suggestion instead of accepting it, and how do they verify an answer that looks fluent but might be wrong. That's a judgment call an LLM cannot make on the candidate's behalf, because it's a judgment about the model's own output, not a demonstration of fluent output.

Building a pipeline for a candidate who always has a model at the keyboard

None of this requires a new vendor or a new proctoring product. It requires rewriting what the rubric is actually scoring, given that every candidate now has a model at the keyboard, and so will every hire.

• Stop banning tools and design around that assumption. Build problems around ambiguity, verification, and decomposition instead of syntax, so the model being present doesn't remove the thing you're trying to measure.
• Where an async screening step survives, treat a pass as "didn't fail obviously," not as "is qualified." It's a coarse filter, not a hiring decision, and it never was anything more even before AI made that obvious.
• Move the real signal-gathering into a live, AI-allowed pairing session where the interviewer's job is to interrupt at least three times and ask why the candidate accepted a specific suggestion.
• For senior and staff roles, consider replacing the coding round entirely with a code review or an architecture walkthrough of the candidate's own past work, one of Kitty Giraudel's original alternatives, and the format least sensitive to any of this, because there's no code to write in the room, only judgment to demonstrate.

What to change this quarter

Most engineering organisations don't need a procurement cycle to fix this. They need one working session with their strongest interviewers to agree on what "good" looks like now that the candidate, and the interviewer, both have a model available. The take-home assignment isn't coming back in its old form, and it shouldn't. The more useful question for the rest of 2026 is whether the replacement actually measures judgment, or just measures who's better at performing for a camera.