Hey hey,

In October 2025, Andrej Karpathy released nanochat — a small, working ChatGPT clone, about 8,000 lines of code. He wrote it almost entirely by hand.

That's the strange part. Karpathy is the person who coined "vibe coding" — handing your project to the AI and forgetting the code exists. He uses these tools more than almost anyone. And he still said this about nanochat:

He isn't anti-agent. He just knew, before he started, exactly where the agent would not help.

That is the whole skill. Not prompting, not knowing the latest model. Knowing when to let the AI run, and when to close the laptop and think.

For most of software history, features were expensive. Every one cost you engineering weeks, so you cut most of them, because you had no choice. Cost was your filter.

Now the budget is gone. When the agent can build any feature in an afternoon, you can afford all fourteen. So you build all fourteen, and ship a bloated v1 that does everything badly instead of one thing brilliantly.

That's the trap. The tools got cheap, so everyone builds more. The scarce skill is judgement. And here's the part nobody says: judgement is almost always subtraction, not addition. Anyone can add features. The AI adds faster than you can. Deciding what not to do is the job.

The good news is that this is a learnable skill, not a gift. Paul Graham made the case years ago in "Taste for Makers": taste isn't just preference, it sharpens with reps, as you make more, your old taste turns out to have been genuinely worse, not just different. The whole industry has now caught up to why this matters: when anyone can make anything, the differentiator is what you choose to make. OpenAI's president calls taste "a new core skill."

Judgement isn't one big decision. It shows up in six moments while you build.

Before you write a prompt, finish one sentence: "It [does one thing] for [one person] so they can [get one outcome]." If you need the word "and," you have two products. Pick one.

Then write the harder list: what your v1 does not include. Minimum five. The first three are easy and fake. Four and five are the real ones, the features you want to build and shouldn't. Every line on that list is something the AI could have built, and every one is a "no" that keeps the product sharp.

This is the oldest move in good product work. When Steve Jobs returned to Apple in 1997, a year from bankruptcy, he cut the product line by roughly 70%. His line on it has been quoted forever: "deciding what not to do is as important as deciding what to do." The AI has removed the one force that used to make you subtract by default — cost. You have to supply that discipline yourself.

Look at Stanley, the LinkedIn AI agent two founders built in a 14-day sprint under a brutal deadline that forced them to cut everything inessential. By day five they were sending creators a personalised analysis.The launch post did $200K; it crossed $1M in annual recurring revenue within seven months. Not because they built more. Because they built one thing and refused the rest.

Once the agent can do anything, it quietly starts doing everything. Calling the AI is the easiest thing in the room. It always works, so you never ask whether it should.

Take counting words. The model will usually get it right. But a word count is arithmetic, not a creative act, and routing it through the AI means a network round trip, real money, and an answer that might change next time. A word count should never be creative.

So find the seam: the line between what the AI does and what plain code does. One question settles it: is this a rule, or is this judgement? Rules have one correct answer — counting, formatting, sorting, checking a limit. Give those to code: faster, free, identical every time. Judgement has no single right answer — writing the reply, choosing the tone, weighing whether a customer is upset. Give those to the AI. Ask that question and the architecture designs itself.

You type a 50-word prompt, Claude produces 5,000 lines, and it feels like progress. But you made no real decisions — you just ran the loop and hoped.

Before any code, answer four questions:

Paste these into plan mode and make the AI argue with your answers first. If it can't tell you how you'll know it worked, your plan is a wish, not a spec. And the fourth question catches more bugs than the first three combined — the thing that breaks your build is almost never the thing you planned for.

The model doesn't know what you don't tell it. Ask it to "plan a 3-day Tokyo trip for my family" and you get a generic itinerary — because it didn't know your kids are 2 and 6, that it's Golden Week, or that your budget is £200 a day.

Your job is to feed it exactly what it needs and nothing more — and "nothing more" is itself a judgement call. Too little and it guesses; too much and the five facts that matter get buried under thirty that don't. Deciding which five matter for this task is the scope decision again, one level down. Give it the handful that count, and clear the context between tasks so old junk doesn't poison the new one.

How do you know it worked — not "looks fine," actually worked? Before you call anything done, write one pass-or-fail check:

That last line is a judgement call too. A word count check is a line of code; "is this reply empathetic?" needs a second AI or your own eyes. Without a pass-or-fail line, "done" just means "the AI stopped" — and the gap between those two is where broken products live.

The first five make one feature good. This one makes you better at the next.

Two tiny habits. After something works, add three lines to your CLAUDE.md — the file the agent reads every session — from what actually went wrong. And every day, write one line in a decisions log: what you decided, and whether it held.

That log is the important half, and it's a judgement-training tool. It's a version of the decision journal that Shane Parrish at Farnam Street built on Kahneman's work: write the call and the reasoning, then check it against what happened. Without the record, hindsight rewrites the past and you learn nothing. With it, you find out which instincts were right and which only felt right. That feedback loop is, mechanically, how judgement gets built.

Scope, the seam, the plan, context, verification, compounding. Six moments — and in five, the move is to remove, refuse, or narrow. Only the last asks you to add, and even then you're recording what you subtracted.

That isn't a coincidence. That is judgement: in a world where the model will build anything, the winner keeps asking not "can we build this," but "should we."

Which is where Karpathy has landed too. He now calls "vibe coding" passé and the next thing "agentic engineering": you're not writing the code, you're orchestrating fallible agents and doing oversight. Orchestration and oversight are just other words for judgement. The tools kept getting better. The skill that matters stayed exactly the same — and unlike the model, it's the one thing you actually own.

— Sid