Earlier this year an engineer did something deliberately mundane with a piece of recruitment software. HackerRank had open sourced the Large Language Model (LLM) powered tool it built to score CVs and résumés, so he took a single, unchanged CV and ran it through the scorer a hundred times to see what came back.
The same CV scored anywhere from 66 to 99 out of 100.
Same person. Same document. Same software. Set a sensible pass mark at 85, which plenty of hiring teams would, and that identical candidate was rejected on 65 of the 100 runs. Nothing about them changed between attempts. The tool simply does not give the same answer twice.
I keep this example close to hand because it is the cleanest illustration I have found of a mistake I watch organisations make over and over; reaching for AI before anyone has stopped to ask whether AI is the right instrument for the job. “Just throw AI at it” is not a strategy. The strategy is the thinking you do first; deciding, deliberately, which parts of a process suit automation and which still need a human in the loop.
Non-Determinism Is a Property, Not a Bug
When I describe that result, the first response is almost always a technical one. Surely that is a bug, or a badly set configuration, or a prompt that needs tightening. Lower the temperature, the thinking goes, and the wobble goes away.
It does not, and that is the part worth sitting with.
A large language model predicts a plausible next token; it does not look up a fixed answer in a table. Ask it the same question twice and you are sampling from a distribution of plausible responses, not reading a value from a cell. That is what non-determinism means here; the same input can produce a different output each time, because the model samples rather than retrieves. Turning the temperature down narrows the spread, it does not close it. Swap the underlying model and the range shifts, but the variation remains. So for any task where the same input must produce the same decision every time, a raw LLM is the wrong instrument. Scoring a person’s career is exactly that kind of task.
Look closer at the numbers, drawn from an independent analysis by Dan Kinsky, and it gets stranger. The “experience” score came back as a flat 25 out of 25 on every single run, regardless of the actual background being assessed. The categories that swung hardest were the subjective ones, the parts that supposedly require the most judgement. And roughly two thirds of the overall weighting leaned on public GitHub activity, which quietly penalises every capable engineer whose best work sits behind a company firewall where no public commit history will ever show it.
A tool that can’t differentiate isn’t filtering for quality; it’s just filtering.
To be fair to HackerRank, their own direction of travel is more considered than a single open sourced scorer suggests; their public writing is about changing how technical hiring works for an era of AI fluency, not about handing the final say to a model. The cautionary tale is not really about one company. It is about what happens when any organisation wires a non-deterministic tool into a decision that demands consistency, then reads the number it produces as though it were objective. When clients ask me to help them bolt AI onto their hiring, this is the first conversation we have.
The Same Mistake, Wearing Different Clothes
None of this is really a story about recruitment. It is one outfit worn by a much more common mistake, and once you recognise the shape you start seeing it everywhere.
I wrote a few weeks ago about the case for small, deliberate AI wins rather than the headline moonshot. One of the central ideas in that piece is that AI is a speed multiplier; it accelerates whatever process you point it at, regardless of whether that process was any good to begin with. McDonald’s spent years trialling AI ordering in their drive-thru lanes and pulled the test after a string of public failures, because the underlying ordering workflow had never been redesigned for the kind of constrained conversation a model can actually handle. The technology did not break the drive-thru. It made the existing fragility legible in public.
A little later I looked at the Chipotle Pepper chatbot, a customer support bot that members of the public cheerfully repurposed as a free coding assistant on Chipotle’s bill, because it had been shipped before anyone defined what conversations it was allowed to have or modelled what a motivated user might do with it. Pepper made financial fragility legible in public, where the drive-thru had made operational fragility legible.
Different surfaces, same root cause. AI deployed before the workflow, the scope, and the consequences had been thought through. The CV scorer is that same failure again, this time in the language of hiring; a tool reached for first and interrogated later.
The useful question is never “can AI do this?” Modern models will have a go at almost anything, and will always return something that looks like an answer. The question that actually matters is narrower and harder to answer well; which parts of this process suit automation, and which need a human in the loop?
ℹ️ Note
AI is a speed multiplier, not a judgement engine. Point it at a process you have not thought about, and it will produce more of whatever that process already did, faster and with a more confident finish.
Where the Human Belongs
That question has a more answerable shape than it first appears. Keeping a human in the loop means what the phrase suggests; a person stays accountable for the decision, while the machine handles the supporting work that leads up to it rather than making the call itself. The reason that split works is that AI is genuinely, reliably good at a particular kind of work.
It is excellent at the assisting tasks that sit around a decision. Pulling the structured details out of a CV. Summarising a long and rambling career history into something a busy human can read in thirty seconds. Surfacing the handful of applications that most warrant a closer look, so a person spends their limited attention where it counts. None of that requires the same answer every time; it requires a useful answer, and a useful answer is exactly what these tools are built to produce.
What AI should not be doing is making the final call on its own, unread, and then handing you a number that looks objective and is not. That is the line. On one side sits high-volume, low-judgement work, where a good-enough answer that varies a little from run to run does no harm. On the other sits the decision itself, the accountability for it, and the fairness of it; and those belong to a person.
Picture the difference in practice. A team hiring for an engineering role receives three hundred applications. Handing all three hundred to a model and acting on its scores is the failure we started with; the same candidate would land in or out of the pile depending on nothing more than which run their CV happened to fall in. The version that works keeps the model firmly on the assisting side of the line.
It reads each application and pulls out the structured facts a human would otherwise hunt for; years spent in a relevant language, the shape of recent projects, any obvious gaps worth asking about. It writes a two-line summary of each. It flags the few that clearly fail a hard requirement, a purely mechanical filter such as a role that legally requires a specific certification. What it does not do is decide. A person still reads the shortlist, and still sees the applications the model was unsure about, because the candidate who does not fit the template is often the one worth a conversation. And because a human reads that borderline pile, the engineer whose best work sits behind a company firewall, the one a GitHub-weighted score marked down, still gets seen by someone able to recognise what the model could not measure.
I made a version of this point in the moonshot piece, through the example of an accountant who spent hours each month reformatting data before the real work could begin. The tempting question was whether AI could replace the accountant. The right move was to let AI take the reformatting, the toil, and leave the judgement, the regulatory awareness, and the accountability exactly where they were, with the accountant. They kept the job. What they lost was the drudgery.
Some jobs, or some parts of them, will always need a human in the loop. That is not a temporary state of affairs waiting on better models; it holds because someone has to be answerable for the outcome, and a model cannot carry that accountability. Reading the application the model would have quietly binned is one of those parts.
Think First, Then Automate
If “just throw AI at it” is the mistake, the correction is not “never throw AI at it”. It is to do the thinking first, and to do it in a particular order.
Start by naming what the process is actually for. Not the steps it currently performs, but the outcome it exists to produce. A hiring process exists to find people who will do the job well, and to treat applicants fairly while doing so; a scorer that cannot give the same person the same result twice running fails the second goal before it has even been measured against the first.
Then separate the mechanical steps from the judgement steps. The mechanical ones, the extracting, reformatting, summarising and sorting, are where AI earns its keep. The judgement steps, the ones where someone has to be accountable for the decision, are where you design a deliberate human checkpoint rather than letting the automation run all the way through to a conclusion nobody chose to own.
Done in that order, AI stops being a thing you bolt on and becomes a tool that earns its place. This is not a counsel of caution; I am not arguing for less AI. I am arguing for AI applied with intent, which, across nearly twenty years of advising engineering teams, is the version that actually survives contact with reality.
Over the coming weeks I will be publishing a short series on exactly how I put this discipline into practice in software engineering; what the foundations of agentic development look like, which workflows I reach for depending on the task, and how I harden a setup so it behaves itself. The throughline of all of it is the same as the throughline here. Think about the problem first. Let the tool earn its place second.
Closing Thought
The HackerRank scorer is a small story with a large moral. A piece of software gave the same candidate a different verdict almost every time it looked at them, and presented each verdict as a precise, objective number. The fault was not really in the model. It was in the decision to let a non-deterministic tool make a determination it was never suited to make.
“Just throw AI at it” is not a strategy. The strategy is the deciding; working out which parts of the work suit a machine that is fast, tireless and approximate, and which parts need a human who is slower, accountable, and able to recognise the candidate the model would have thrown away.
If you are working out where AI genuinely fits in your own processes, a consultation might be a useful starting point.