There is a running joke in hiring right now: we use AI to write resumes, then feed them into an ATS that uses AI to read them.

A perfectly optimized closed loop of noise.

The resume hasn’t disappeared. Its signal-to-noise ratio has.

Anyone can generate a polished summary of what they should be able to do. Anyone can rewrite their experience and present themselves better than ever before.

I don’t blame candidates. I’d do the same. The problem is production doesn’t care what should work.

Anyone who has been paged at 3 AM knows that systems don’t fail politely. You don’t get a neatly packaged LeetCode question. You get a cascading failure because someone assumed a dependency would never timeout, a database lock nobody planned for, or a deployment that quietly corrupts data.

Those are judgment problems, not syntax problems.

AI Writes Code. Humans Make Decisions.

A few days ago, Matthew McGowan and I were discussing engineering evaluation in an AI-heavy world. He said something that perfectly captures where we are today:

“I don’t care if AI writes 90% of the code. You still need to see the judgment behind the choices, the infra, how it was done. Don’t build stupid.”

That’s the real issue. Not whether AI wrote the code. Whether the engineer understood what they were building.

AI can generate an API. It can’t decide whether the boundary is correct.

AI can scaffold infrastructure. It can’t decide whether Kubernetes makes sense for a product with ten users.

AI can generate retry logic. It can’t decide which failures deserve retries and which should fail fast.

Code is getting cheaper. Decisions aren’t.

Don’t Build Stupid

Historically, resumes, years of experience, and shipped projects were decent proxies for competence.

AI didn’t eliminate those signals. It compressed them.

Today, more candidates can build more things faster than ever before. Which creates a strange problem: two engineers can ship the same outcome while exercising completely different levels of judgment.

One carefully defines boundaries, understands tradeoffs, plans for failure, and makes constraints explicit.

Another accepts every default, copies patterns they don’t understand, and hopes nothing breaks.

The outcome looks identical. The engineering quality isn’t.

That’s why completed projects alone are becoming harder to evaluate. Not because projects stopped mattering, but because understanding what happened underneath them matters more than ever.

Finding Signal in Proof-of-Work

If resumes are increasingly noisy and code generation increasingly cheap, where does signal come from?

The answer is usually hiding inside the work:

  • Architecture choices. Did they pick the simplest system that fit the constraints, or add complexity because it looked impressive?
  • Failure handling. Did they think beyond the happy path?
  • Pull requests. What tradeoffs were discussed? What concerns were raised?
  • System boundaries. Do abstractions solve real problems or just create layers?
  • Consistency. Do good patterns show up repeatedly across the codebase?

These details reveal far more about an engineer than a technology checklist ever will.

The New Bottleneck

The challenge is that this kind of evaluation is expensive.

A good engineering leader can often identify these signals quickly. The problem is doing it across fifty repositories. Or a hundred. Or two hundred.

That’s the bottleneck hiring teams are running into. The problem is no longer obtaining proof-of-work. Candidates are producing more proof-of-work than ever before.

The problem is understanding it. This is the rabbit hole that led me to build Clyris (clyrisai.com).

Can engineering judgment be surfaced before the interview instead of discovered three rounds later?

Can we understand the decisions underneath a project without asking every engineering leader to manually review hundreds of repositories?

Because ultimately, the code is just text. The judgment is what keeps the system online.