The Take-Home Test Didn't Get Cheated. It Stopped Measuring You.

A founder said some of his most effective employees are AI-pilled, and that his company changed its entire engineering interview. The internet turned this into "juniors are replacing seniors." Before you build a career decision on that, ask a dumb question: effective at what?

There's no denominator in that sentence. Effective compared to whom, measured how, at a company that's about two years old? "Most effective employee" with no metric and no time-on-job is a founder describing his culture, not reporting data. So drop the anecdote. The interesting thing isn't whether any particular hire is magic. It's that a lot of companies really did rebuild their interviews. That part is real. The question is why.

Start with what an interview is for. It's a signal. It's only worth anything if it correlates with how someone performs on the actual job. The take-home and the whiteboard worked for years because producing correct code from a spec was scarce. Few people could do it cleanly, and the ones who could tended to do well once hired. The test discriminated. That's the whole game.

Now watch what AI did. People say candidates started cheating. That's not it. Even honest candidates submit model output now, because that's how the job is done. When everyone hands in roughly the same quality of generated code, the scores bunch up. The spread between candidates collapses. And when the spread collapses, the correlation with real performance drops toward zero. The test didn't get gamed at the edges. It stopped measuring the human. That's a decorrelation problem, not a cheating problem, which is why "add a proctor" or "detect the AI" misses the point. Detecting honestly-produced, uninformative output doesn't make it informative.

So the signal had to move. When producing code becomes free, the scarce skill jumps up one level, to verification and steering. Here's the mechanism, because this is the part that matters.

A language model produces the statistically likely continuation of whatever is in its context window. That gives it three structural blind spots. First, context-boundary blindness: it only knows what's in the window. It writes an N+1 query inside a loop because it saw the ORM layer but never saw the call site, so it can't see the cost. It writes a duplicate utility function because it never looked at the rest of the repo. Second, confident interpolation: it fills gaps with plausible tokens, so you get a hallucinated API called by name as if it exists, or an exception handler that reads defensive but silently swallows the error. Third, on its own it has no verification loop. It doesn't check the code against reality unless something makes it.

Here's the caveat the panic skips. By mid-2026 the agentic coding tools have partly closed the third blind spot. They can grep the repo, run the tests, execute commands, read the failure, and iterate. So the loop exists now. But that just moves the scarce skill, it doesn't remove it. The remaining question is whether the candidate knows how to design that loop and inspect it: which tests are worth running, whether a green suite actually proves the thing you care about, and when a passing run is passing for the wrong reason. An agent that runs tests you never wrote gives you confidence you didn't earn.

So the human's remaining value is the complement of all this. Manage what goes into the window. Design and inspect the loop that checks what comes out. That's it. The surviving interview signal is simple to state: does the candidate read the model's diff and interrogate its checks, or blind-accept them? Hand someone a model-generated PR that looks correct, passes an eye test, and quietly fails one property test, and you learn more in ten minutes than a whole take-home used to tell you. Verifiers pass. Trusters don't. Call it verifier versus truster. That distinction, not how new someone is to the field, is what the new interview is chasing.

Now the part both the hype and the panic skip: none of this is fixed. It's a function of codebase size.

The context window is finite. On a small-to-mid codebase with good test coverage, the relevant context fits. The model sees enough, and the tests catch its interpolation errors before they ship. There, an AI-native engineer's velocity is genuinely real. They'll run six agent loops while someone cautious runs two, and the debt stays bounded because the tests hold the line.

Push that same person onto a two-million-line payments monolith and the picture inverts. The invariants that keep that system alive aren't written down anywhere. They're tribal. "Never call this without holding that lock." "This field is nullable in prod but nobody remembers why." The relevant context doesn't fit in any window that exists, and the tests don't encode the invariants because nobody wrote them as tests. So the model's blind spots convert straight into a postmortem. The problem isn't age or attitude; it's that the thing you'd need to catch the mistake was never text.

So "the AI-native hire is the best hire" and "the AI-native hire is a debt machine" aren't opposing claims. They're the same function evaluated at different codebase sizes. The velocity you can safely extract is gated by how well someone senior already carved the work into safe pieces.

Imagine a founder who hands a new engineer forty leaf-node features instead of the consensus module, and points to the output as proof his hires are unstoppable. He's proving the opposite without noticing. Those forty features are safe to hand off because someone already drew the boundaries that made them leaf-nodes. The decomposition is the work. The typing is what's left over.

One more thing that's real, and it cuts the other way. AI-natives have close to zero unlearning cost. People who internalized "writing code is the expensive step" back when it was true tend to hoard and defend code. Someone who never learned that treats code as disposable and rewrites fearlessly, which is the correct stance now that generation is cheap. That's a genuine edge. But it's orthogonal to systems judgment. Fearless rewriting is a gift inside a boundary and a liability across an unmarked invariant. Same trait, opposite sign, depending on where they're standing.

If you're a senior worried about being out-shipped, here's the honest read. Your typing speed is gone as an advantage; don't defend it. What's not gone is the boundary-drawing. The reason someone can safely ship forty features is that someone turned a tangled system into forty safe features first. That work doesn't fit in a context window, which is exactly why it's still scarce. The move isn't to out-code the model. It's to become the person who decides what's a leaf-node.

If you're hiring, stop testing artifacts. Test steering.

Three things to do tonight. One: take a real 400-line piece of your codebase the model likely hasn't trained on, write a plausible-but-wrong implementation plan into it, and make that your new take-home. You're scoring whether the candidate catches the wrong plan, not whether they produce code. Two: build one exercise where you hand over a model-generated PR that passes the eye test but fails a single property test, then watch whether they read the diff, run the checks, and ask which check would have caught it, or just accept it. That one behavior separates verifier from truster faster than anything else. Three: for your own repo, spend twenty minutes writing down one invariant that currently only lives in someone's head, and turn it into a test. Every invariant you make explicit is one less landmine for anyone, human or model, and it's also how you find out how big your context-window problem really is.

One question worth sitting with: on your codebase, where exactly does the line fall, how many lines, how much coverage, before a fearless rewrite stops being a feature and starts being an incident? If you actually know that number for your system, you're already ahead of most of the people arguing about this. What's your number?