It’s popped up on LinkedIn and Reddit with hundreds, sometimes thousands, of likes.1 A coworker mentioned it to me in passing a few days ago.

I’ve decided to test it out.

First working run: 90/100. Felt pretty good!

I had some debug prints scattered around from troubleshooting the setup, so I cleaned those up and ran it again.

74/100.

Same resume. Same command. The only thing I changed was deleting print statements.

I disabled DEVELOPMENT_MODE and put it in a loop to run a hundred times.

The scores range from 66 to 99.

If your company’s cutoff sits at 85, I fail 65% of the time. Same exact resume, different luck.

Here a quick rundown on how the tool works:

Your PDF gets parsed into text. An LLM is called six times to extract structured information — your basics, work history, education, skills, projects, awards. It pulls your GitHub profile, scans your top repos, appends them as extra context. Then everything gets fed into the LLM at once to be graded.

The scoring is out of 100, with up to 20 bonus points on top:

• 35 points for open source contributions

• 30 for personal projects

• 25 for work experience

• 10 for technical skills

• Up to 20 bonus points for startup experience, a portfolio site, a technical blog, etc.

The default model is gemma3:4b, running at temperature 0.1 — low, supposedly nudging the model toward deterministic outputs.

Here’s what I found when I looked at those individual categories.

Look at technical skills: I scored 8/10 in 98 out of 100 runs. Nearly perfect consistency. How come? Because technical skills are a checklist. You either know React or you don’t. There’s nothing for an LLM to judge — a five year old could match that check-list.

Now look at projects — there’s HUGE variation.

LLMs struggle to make a judgment call like that consistently. Sometimes my projects “lack architectural complexity”, sometimes they “demonstrate real-world deployment”. Which one the LLM spits out is a roll of the dice.

Temperature 0.1 is already low, but even going down to temperature 0 doesn’t fix this. Someone opened a GitHub issue back in October showing scores of 27, 34, 32, 34, 34, 30 across six consecutive runs at temperature 0.2 This non-determinism isn’t a bug you can just fine-tune away, it’s a fundamental design flaw.

I was worried part of this might be the model. After all, gemma3:4b was a local model running on my machine.

Gemini resulted in a tighter distribution — scores clustered between 48 and 64. But if your cutoff is 60, you’re still failing 28% of the time through no fault of your own.

The Open Source scores have become consistent — that’s a legit improvement. But project scores are still all over the place.

Experience has me the most concerned.

25/25.

Every single run.

I went back and pulled up an old resume — one internship on it.

Also 25/25.

The clue is in the prompt…

### Production (0-25 points)
- Analyze the 'work' and 'volunteer' sections for real-world, internship, or production experience
- **SPECIAL CONSIDERATION**: Give extra points for founder roles, co-founder positions, or early-stage engineer roles (first 10-20 employees) at startups

The entire thing is two lines long.

No rubric. No examples. No anchors for what earns a 15 versus a 25.

A junior engineer with one internship gets 25/25. A principal engineer with a decade of distributed systems gets 25/25. I get 25/25. Experience has two lines and no anchors — consistent, but useless. Projects has a detailed rubric with examples but it’s the noisiest category — inconsistent, also useless. There are some things that LLMs just can’t do well, no matter how you prompt.

Use an LLM to parse a resume into structured data — great, that’s what they’re good at. Use one to check whether someone knows Python — amazing. Use one to judge whether a candidate’s experience is worth 18 points or 24 points? You get a vibe-check. Something HR teams, bar raisers, and a dozen other initiatives have spent decades trying to avoid.

The 65% weighting on open source + projects doesn’t help either. I’d take the engineer with 30 years of experience who built S3 over someone with two internships and an open source project — but this tool wouldn’t. Some of the best engineers I know have built things that never ended up on GitHub. That’s over half of their score gone before any human looks their way.

If you’re an engineer with any say in how your company handles resume screening: please be very careful with AI-screening tools. A tool that can’t differentiate isn’t filtering for quality — it’s just filtering. You might as well throw out half the resumes and tell the the applicants you don’t fuck with bad luck.

Correction (June 28): A reader flagged that the resume_evaluation_criteria.jinja template says “Software Intern” on line 1 — nowhere documented, nowhere else referenced in the repo. The same template that later gives bonus points for “founder roles, co-founder positions, or early-stage engineer roles.” I re-ran with an explicit Senior SWE prompt and got identical results — the scoring dimensions are position-agnostic.

Update (June 30): This blew up on Hacker News, if you’re curious to see that thread — here it is.

A few people noted that frontier models do not have this problem. I checked out one of the GitHub PRs that introduced support for Claude and ran Opus 4.8 in a loop until my credits ran out.

The range has tightened slightly — the score has gone down from 48-64 to 49-63, and projects from 12-25 down to 13-23. At its core, the point is the same: projects inconsistent, skills perfect.

Specifically epsilon delta proofs. If you’ve done them, you know. If you haven’t: you’re given a limit and asked to prove, rigorously, that it exists. No formula. No method to reach for. You construct the argument from nothing, scouring for a path through the logic.

I’d graduated high school with 98% in advanced functions and 97% in calculus. I thought I was good at math.

I wasn’t.

I was good at stamping.

Every problem I’d ever solved had an instruction book. A known path someone else had already walked. You learn the method, apply the method, get the mark. University math didn’t work that way.

People started dropping. A couple months in, a student asked the prof something like: how do you even come up with this? The proof makes sense when you put it on the board, but sitting down and producing it from nothing? I can’t seem to do it.

“Think outside the box.”

I’d heard that phrase a hundred times. I never knew what I was supposed to do with it. This time the box was right there in front of me. I could see exactly what it was. And the proof didn’t fit inside it.

More people dropped. Then so many dropped they closed our lecture section entirely and merged us with another.

I spent more time on that course than my other four combined. It just didn’t click like the other courses did. It was hours. Days. Hundreds of abandoned proofs, multiple notebooks worth of scrap. And then, slowly, without a moment I could point to — I started solving them. Finding new angles nobody had shown me. Paths I’d built myself.

That was the first time I had ever felt that. I didn’t have a word for it then.

The word is creativity.

In middle school art class I’d sketch mountains and classmates would stop and look. My teacher was impressed. I was proud — because it felt like the eye and the hand were finally working together.

But I was stamping. I’d learned one peak. One way to draw a mountain. Stretch it, warp it, tilt it — at the core it was always the same piece. Same angle. Same mountain. Good at seeing. Not finding anything new.

I didn't know the difference yet. I thought creativity lived in art class — obviously.

It was novelty. And novelty is cheap — every bad idea is technically novel. Creativity is finding an angle on something that was already there, but one that nobody else was able to see.

Newton didn’t invent gravity. Gravity was there, dropping apples, moving planets, completely indifferent to whether anyone understood it. What Newton did was find a way of seeing it that nobody had managed before. The angle was new. The thing being seen was ancient.

Cantor didn’t invent infinity. Mathematicians had been tripping over it for centuries. What he did — the diagonal argument — was stand somewhere new and look at it differently. The proof that some infinities are larger than others. Same territory everyone else was working. Different angle.

That’s the whole game. That’s all it ever was.

Which means my middle school mountains weren’t creative. Not because they weren’t good. Because the angle was borrowed. I was seeing mountains the way mountains get seen. Nothing new was found.

People say AI isn’t creative because it’s just pattern matching. Just remixing what came before.

But go back and look at what Newton was doing. What Cantor was doing. They were working from the same inputs as everyone around them — same papers, same problems, same mathematical tradition. The insight wasn’t delivered from outside. It was latent in everything they’d read and thought and tried and failed at, until suddenly it wasn’t latent anymore.

The question was never about the inputs. It was always about the angle.

Go is a 3,000-year-old strategy game, simpler in rules than chess but so vast in possibility that mastering it was considered one of the hardest problems in AI. AlphaGo was Google DeepMind's attempt to crack it.

And in 2016, AlphaGo played Move 37 in Game 2 against Lee Sedol. Placed a stone where no professional would. Wrong position, wrong timing, wrong by every convention the game had built over centuries. The commentators went quiet. Then: “I think we’re seeing an original move here.”1

Centuries of Go. Millions of human games. We thought we’d mastered it. We thought every angle worth finding had been found.

That day, AlphaGo was creative.

There used to be a social cost to laying off people. Not a legal one — a reputational one. The kind that made engineers think twice about joining you, and recruiters nervous about representing you. For a long time, Big Tech understood this — Google went decades without a mass layoff. It was part of the brand. Not just the free lunch and the 20% time1, but the implicit promise underneath all of it: if you’re good enough to get in, you’re good enough to stay.

A whole generation of engineers made real decisions based on that promise. They took the equity over the salary. They turned down less exciting jobs at less exciting companies. They optimized their entire careers for a shot at the logo — because the logo meant something beyond compensation. It meant you’d won a kind of stability that the rest of the market couldn’t offer.

Then, in 2022, Meta cut 11,000 people and called it the “year of efficiency”2.

What happened next matters more than the cuts themselves. Meta’s net income went from $23 billion to $60 billion in two years3. The stock went up. And every board in Silicon Valley took notice. The lesson learned was simple: you can do this, the market will reward you for it, and the reputational costs you were afraid of don’t actually exist.

Amazon watched.

Then Amazon cut 27,000 people4 — a company that had largely avoided mass layoffs since the dot-com crash, a company that posted $59 billion in profit the year after5. The justification was familiar: efficiency, streamlining, investing in the future. The stock went up.

The taboo didn’t erode gradually. It died over one winter.

None of this required malice. That’s the thing that’s hard to sit with. No one had to lie, or scheme, or decide to betray anyone. It’s just what happens when a company runs a play, gets rewarded, and other companies notice. The promise wasn’t broken so much as it quietly expired — somewhere between the press release and the earnings call, with no announcement and no acknowledgement that it had ever existed.

I watched a principal engineer get laid off recently. Sixteen years at the same company. Started his career there. Smart, productive, the kind of person who just makes things work. But he’d been on the wrong side of an internal argument — backed a project that lost, in an org where losing that particular argument turned out to matter. He got an email. I found out through LinkedIn. That’s just how it goes now.

He didn’t fail. The company didn’t fail. Someone ran the numbers, and the numbers included things that were never in the job description.

FAANG companies were never a different type of company. They were regular companies that had an unusually long run of growth, and the promise was implicit — which made it easy to keep, and easy to let expire. When it became expensive, they did what companies do.

Stop holding them to a standard they invented for recruiting purposes and have now quietly retired. They’re often still good places to work, they pay well, and the problems are interesting. But they’re not a covenant. They’re an employer.

The free lunch is probably still there. The promise isn’t.

In 2002, Jeff Bezos issued a now infamous mandate:

1. All teams will henceforth expose their data and functionality through service interfaces.

2. Teams must communicate with each other through these interfaces.

3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.

5. All service interfaces, without exception, must be designed from the ground up to be externalizable.

6. Anyone who doesn’t do this will be fired.

7. Thank you; have a nice day.1

Bezos’s insight wasn’t really about AWS, or even about external consumers. It was simpler than that: you can never predict what your engineers will build when they have access to each other’s capabilities. And you don’t need to. Build the interface for any consumer. Let them run loose.

Now think about what’s happening inside your company right now.

Engineers are using AI to write code, debug issues, draft documents. And every time one of those agents needs to touch an internal tool — your deployment pipeline, your ticketing system, your internal docs — it hits a wall. That’s assuming it even knows those resources exist.

Most times the tool will have no interface accessible to an agent at all. Sometimes someone will have hacked together a wrapper that returns a wall of HTML. But HTML is not made for agents. It has padding declarations and cookie banners and a thousand other things that exist only to look nicer for human eyes. Your agent doesn’t have eyes. It doesn’t care. What it does have is a context window. And your garbage HTML is filling it up.

If you have internal tooling that an agent can’t reach — or can’t use effectively — you’re not just slowing down your engineers. Your AI is stuck asking you to copy and paste internal docs while your competitor’s is shipping.

So why not just have the agent call the API directly?

Because APIs weren’t designed for agents. They were designed for developers. The mental model is that a human reads the docs, understands the intent, writes the integration once, and it runs forever. The human is load-bearing.

Agents don’t work that way. An agent needs to discover what a tool does at runtime, decide whether to use it based on a description, and handle weird results without a human in the loop. There’s no one to read the docs. The description is the docs.

MCP isn’t a better API — it’s a different primitive, built for a different consumer. An API says “here’s how to talk to me.” An MCP says “here’s what I can do for you.”

And if your company is anything like mine, someone’s already building it. Not the team that owns the service — some engineer two teams over who needed it for themselves, built something scrappy, and shipped it while they were at it.

The rogue builder.

And don’t get me wrong, sometimes that’s great. Sometimes it isn’t. But either way it’s done, and we’ve all seen how this goes — the temporary shell script that became load-bearing infrastructure. Ten engineers who’ve already configured their environment around it and are not switching.

There’s a demand gap, and someone’s going to fill it. It’s up to you whether that fill is any good.

So here’s my mandate:

1. Every internal service must expose an MCP interface. If a human can use it, an agent must be able to use it.

2. It doesn’t matter how old the service is, what language it’s written in, or how much you hate touching it. Wrap it. That’s the job.

3. Every MCP must be registered in a central registry — discoverable by humans, queryable by agents. If it can’t be found, it doesn’t exist.

4. Every MCP must be designed for agent consumption. Not a wrapper around your HTML. Not a raw dump of your REST response. The agent doesn’t have eyes. Give it the juice, not the packaging.

5. Anyone who doesn’t do this will be fired.

6. Thank you; have a nice day.

Most companies haven’t done this yet. And unlike Bezos’s mandate, nobody is going to force them to.

But the insight still holds: give your agents the full toolbox, let them run loose, and see what happens. The teams that do are going to pull ahead fast. The teams that don’t are going to wonder what happened.