The Working Nemo for The Career Theorem

Posted on Sep 28 AI-assisted

Engineering didn't get easier. It got honest.

#ai #opensource #softwaredevelopment #career

Your IDE suggested the rest of the function. You accepted it.

Could you explain it, line by line, to someone who asked?

If you hesitated, you just found the job.

An engineer was never someone who types code.

That's just the part that used to take the longest, so everyone mistook it
for the job.

The job was always this: understand a system you didn't build, decide what
should change, know what your change will break, and answer for it when
someone asks why.

For fifty years, typing came bundled with all of it. You couldn't produce
working code without understanding something, so speed at the keyboard was
a decent proxy for judgment.

Autocomplete broke the proxy.

The receipt nobody expected

In February 2026, Science published a study that trained a classifier to detect AI-generated Python across 30 million GitHub commits by 160,097 developers.

AI now writes an estimated 29% of Python functions in the US. Fine. We knew that.

Here's the part that should stop you:

The productivity gains went to experienced, senior developers. Early-career
developers showed no significant benefit at all.

Read it twice. The tool that was supposed to flatten the hierarchy handed
its winnings to the people already at the top of it.

Not because seniors are smarter. Because AI multiplies judgment, and they
had some.

Give a machine that produces plausible code to someone who can evaluate it, and they move faster. Give it to someone who can't, and they produce volume nobody can trust.

95 and 55

Two numbers from Veracode's testing of 150+ models:

95% — how often AI code is syntactically correct.

55% — how often it passes security checks. Unchanged in two years, while the first number kept climbing.

Roughly 44% of code-generation tasks produced a known vulnerability.

The machine learned to write. It did not learn to be right. Those were always different skills; we just never had to separate them before.

Writing got cheap. Judging didn't. Follow the money.

"But the studies say AI makes you slower"

You'll see that one going around — a 2025 METR trial where experienced
developers took 19% longer with AI while believing they were 20% faster.

METR's own follow-up reversed it. Their late-2025 data shows a speedup, and they think it's a lower bound.

Speed was never the argument. The half that still holds is stranger: those
developers were wrong about their own work, in their own codebases, by 39
points. METR also notes the finished work differed in quality between the
two conditions — so faster was never the same as better.

Nobody is measuring whether what comes out is right.

That part is still on you. It always was.

What companies are actually buying

Not code. Code is the cheap part now.

They're paying for someone who can be handed a system they didn't build and not break it. Someone who reads plausible output and says this is wrong, and here's why. Someone whose work doesn't become someone else's work.

Watch how the interviews changed. Swiggy said on the Codebasics podcast that it stopped using LeetCode for AI hiring.

Recruiters now hand candidates AI-generated code with a subtle bug buried in it and ask them to review it.

Think about what that screens for. Not whether you can write it. Whether you can catch it.

The juniors getting hired are the ones who can explain generated code line
by line. Not the ones who produce it fastest.

Where you practise something you can't practise alone

Reviewing your own work in a project nobody else touches teaches you exactly what you already believe.

You need someone who doesn't care about your feelings reading your code.

Open source is the only place outside a job where the whole thing is
demanded at once:

What you face	Where else you get it
A codebase you didn't write	Nowhere until you're hired
A decision you must justify	Nowhere
Someone who asks why	Nowhere
Consequences that are public and permanent	Nowhere
Your name on it forever	Nowhere

Not a course. Not a portfolio project. Not a LeetCode problem.

You don't go there to prove you can code. You go there to become someone who can judge code.

The merge is just the receipt.

The part almost everyone gets backwards

Here's the mental model that ruins first contributions:

Submit it → the maintainer finds the problems → fix what they catch

That's not contributing. That's outsourcing your review to a volunteer.

And it's why the doors started closing this year.

curl, a tool running on billions of devices, ended its bug bounty
programme in January 2026. It had paid for security reports since 2019. AI-generated submissions arrived faster than volunteers could triage them, and the share that turned out to be real fell below one in twenty. Maintainer Daniel Stenberg shut the programme rather than keep reading them.

tldraw went further. In the same month, the team began automatically
closing pull requests from outside contributors. Their stated reasons: submissions arrived with incomplete or misleading context, they showed a misunderstanding of the codebase, and their authors rarely followed up after review.

Ghostty restricted AI-assisted contributions to pre-approved issues and existing maintainers.

Then GitHub named the pattern: the Eternal September of open
source. The cost to create dropped. The cost to review did not. The contributor gets the credit; the maintainer gets the burden.

Notice tldraw's third reason. Not bad code — no follow-up. People opened
pull requests they weren't willing to stand behind.

The correct model:

Review it yourself → then submit → the maintainer is the last check, not
the first

A pull request is what you send after the review. Not so somebody else can do it for you.

That single flip is the whole thing. It's also exactly what a company is
buying.

Seven habits that make a contribution count

1. Reproduce it before you touch it.
Haven't seen the bug happen? You don't understand it yet.

2. Read the last five merged PRs first.
The real conventions live there. CONTRIBUTING.md is what the project
intended; the merges are what it does.

3. Use AI, then review its output like it came from a stranger.
Because it did.

4. Ask yourself the reviewer's questions before you open the PR.
What breaks. What's the edge case. Why this approach and not the obvious
one. Can't answer? You don't have a contribution yet.

5. Write the why in the description.
The diff already shows the what.

6. Reply within 48 hours when challenged.
Vanishing after the first review comment is the most common failure there
is. It's also the one companies read most clearly.

7. If you can't defend it, don't open it.
You're spending someone else's unpaid time.

Notice that six of the seven happen before anyone else sees your code.