Should You Hire the Junior Who's Fast With AI Over the Senior?

Which one should you hire?

Neither, on those terms. The binary hides the variable that actually decides it: who can tell when the output is wrong. That is a property of the field and the person, not of years served. Hire the junior where a bad answer surfaces fast and costs an edit. Hire the senior where it stays buried and costs a restatement, and check that the senior verifies anything at all, because seniority does not supply it on its own.

The junior's advantage is real and predictable. In a field deployment to 5,179 customer support agents, an AI assistant raised issues resolved per hour by 14% on average: 34% for the least experienced and least skilled agents, and close to nothing for the most experienced ¹. The tool moved new people up the curve by handing them what the veterans already knew. If your open role looks like that work, the junior is not merely cheaper; they are better this quarter.

The advantage stops where the work stops having a known good answer. Sixteen experienced developers worked 246 real issues in repositories they maintain, randomized issue by issue to allow or forbid AI tools; with the tools allowed they took 19% longer. They had forecast a 24% speedup, and after living through the slowdown they still believed they had been sped up by 20% ². Speed on well-specified work does not carry over to work whose context lives in someone's head, and no self-report catches the difference.

Those two results say the same thing from opposite ends: an assistant substitutes for knowledge that is written down somewhere, and it does not substitute for knowledge that is not. Your decision is really about which kind your work runs on. It is also why the thing worth buying from either candidate is the ability to refuse output rather than output itself. That is the case for hiring for verification rather than production.

Put a price on one undetected error

Take one plausible wrong answer your team could ship this month and answer three questions about it: who catches it, how long before someone outside the team acts on it, and what undoing it costs. Cheap, fast and reversible on all three, and the junior's speed is the cheaper mistake. One expensive answer, and the order flips.

Error cost is set by the worst path a wrong output can take, not by the average one. Most founders who run this find the expensive answer is question one: the check they were counting on does not exist. A test suite that runs on every commit is a check. "I look at everything" is an intention, and it is the first thing to go in a busy month.

The middle column is the one founders skip, and it is where the money is. Wrong ad copy is wrong in public, and the numbers argue with it inside a week. A wrong discount rate is wrong in private, inside a model that formats correctly, and it argues with nobody until a decision has been made on top of it.

The public version of this is a court record. In Mata v. Avianca, a brief cited judicial opinions that did not exist, quotations included, produced with ChatGPT; nothing in the drafting caught it, the fabrication surfaced only when the other side went looking for the cases, and the court imposed a $5,000 penalty jointly and severally on the two lawyers and their firm ⁴. Those were practising attorneys, not interns. The check that mattered sat outside their building and arrived after the filing.

Run the test per artifact rather than per department. The same marketer whose draft copy is cheap to fix is expensive the moment the draft carries a statistic or a compliance claim, which is how you end up asking which roles actually need AI skills and getting a list that ignores your org chart.

What does "fast with AI" actually buy you?

Throughput on work that has a known good answer, and a higher floor on routine work. It does not buy a second opinion. Speed is also the cheaper half to acquire: tool habits move in weeks once a team has one written norm and someone senior working that way in the open, while knowing which claim in a memo is the one to open takes years of watching claims fail.

"The senior who isn't" needs splitting before you decide anything. A senior who has not used the tools is a training question with a short answer. A senior who has decided the tools are beneath the craft is telling you how they meet new evidence, which shows up in places that have nothing to do with AI. The two look identical on a resume and answer differently in ten minutes, and a candidate who says they don't use AI at all is not automatically the second kind.

Do not assume the senior supplies the verification either. In a systematic review of clinical decision support, clinicians over-rode their own correct decisions in favour of erroneous advice in about 6% of cases, and incorrect advice raised the risk of an incorrect decision by 26% ³. Those were experienced professionals inside their own specialty, using systems built for them. The effect sizes will not transfer to your team. Take the mechanism, which is that a fluent wrong answer suppresses judgment the person already had.

So the comparison is not speed against caution. It is this: which of these two people, meeting a confident wrong answer in your own material, would stop? The answer differs by field, often differs from what the resume implies, and it decides whether you hire the skill or train it.

Give both candidates the same case

Run one task from the actual job, 45 to 60 minutes, assistant allowed, with a claim planted in the source material that the model will confidently get wrong. Mark the acts rather than the artifact: what got framed before anything was generated, which claim got a source demanded, what was kept by hand, what got refused, what got checked. The clock is a cap, not a score.

Same case, same material, same marking, both people. A written exercise for the junior and a conversation for the senior is not a comparison. The senior wins that every time, because describing work is the thing experience is best at.

Three results are worth naming in advance, because each one is a finding rather than a disappointment:

• Finished in twenty minutes, clean deliverable, source packet never opened. The early finish and the missed claim are one finding, not two. This is the junior risk, and it is visible in the record rather than in the output.
• Forty minutes of checking, two thirds of the work. Also an answer. Whether it is the answer you want is the error-cost verdict from the section above.
• Never opened the assistant, still missed the planted claim. The tools were never the issue with this candidate, and a training budget would not have fixed it.

If the exercise decides anything (a rejection, a tiebreak, an offer level), it is a selection procedure, and a selection procedure has to be job-related and consistent with business necessity for the job you are using it on ⁵. Write down what each behavior is marked on before either person sits down, and keep the notes. Two finalists who hand back the same quality of deliverable are separated only by the record of how they got there.

What if you can only hire one?

Hire for the gap in the team, not the profile you admire. Where a review habit already runs (a suite on every commit, an editor before publish, a second signature), you can absorb someone fast and unproven, and the speed compounds. Where the deliverable goes straight to a customer or a board, hire the person who stops it; the tools are the part they can pick up afterwards.

The market has been resolving this in one direction, which is not the same as resolving it correctly. In payroll records covering millions of US workers, employment of 22-to-25-year-olds in the most AI-exposed occupations now sits about 19% below where it would be had it kept pace with less-exposed peers, an effect running through reduced hiring rather than layoffs, with no evidence of economy-wide displacement ⁶. That describes what employers did, not whether it paid. The aggregate has a cost: a company that hires only seniors buys its checking capability from a supply it is not replacing, which is the argument for an apprenticeship or a rotation rather than a hiring freeze on the bottom rung.

Both candidates share one failure mode, and it is worth deciding against in advance: the person who demonstrates beautifully and then cannot work inside your systems, your data and your review cadence, which is the shape of a hire who demos well and struggles in the first quarter. A case built from your own material catches more of that than any interview, because your material is where the surprises live.

One honest limit on all of it. None of this comes from a resume, a reference, or asking either candidate how they check a model's output. That question telegraphs its own answer, and both will describe a sensible process they may or may not follow. What decides it is the record of one of them meeting a confident wrong answer, and that record exists only while the work is happening.

See the benchmarks >