AI Now Writes the Code; Taste Is the Job That Survives
June 20, 2026 · Paul Graham, Hackers and Painters~4 min read
You ask the model for a function. Thirty seconds later it hands you three versions. All three compile. All three pass your tests. The first is clever and dense, the second is verbose but obvious, the third quietly fires a database query inside a loop. The machine is done. Now the only question left is the one it can't answer: which one ships? That pause — that flicker of "hmm, not that one" — is the entire job now.
The half that just got commoditized
Twenty years ago Paul Graham, in Hackers and Painters, described great work as a pair: rigorous taste, plus the ability to realize that taste. A hacker, he argued, is a maker like a painter — and "programs are written for people to read, and only incidentally to run." For two decades the second half of that pair, the ability to realize, was where most of the sweat went. Learning the syntax, wiring the framework, chasing the off-by-one. AI has now absorbed almost all of that. The realize half — the part that took years to build — has collapsed toward free. What remains standing, unhelped, is the taste half. And taste was always the rarer one.
From writer to chooser
The whole shape of the job has flipped. Through 2026, engineers argued about this in the open and mostly landed in the same place: the work is no longer "I write the code." It's "I decide what should be built, I direct the machine to build it, I check it ruthlessly, and I own whatever ships." Writing code and choosing code are not the same muscle. Writing rewards fluency; choosing rewards a trained eye that can look at three passing solutions and feel which one will rot in eighteen months. Call the surviving skill Taste-Ops — the discipline of judging, directing, and verifying machine-made work. It is less typing and more deciding.
As AI commoditizes the ability to make working code, the scarce skill is taste — judging which passing solution is actually good. Marks of good design (simple, solves the right problem, redesign) become a review checklist. Framework: Paul Graham, Hackers and Painters.
What good actually looks like
Graham listed the marks of good design, and they read like a checklist for reviewing AI output. Good design is simple — so when the clever dense version arrives, your instinct should be suspicion, not applause. It solves the right problem, not a flashier adjacent one. It is redesign: you almost never get it right the first time, so the model's first answer is a draft, not a verdict. And it is daring when daring is earned. Think of taste as a sommelier's palate. A robot can pour ten glasses in a minute; it still takes a trained tongue to say which one is corked. The N+1 query, the leaky abstraction, the interface that will betray its caller next quarter — those are the cork. Graham's makers sweat invisible details, the way Da Vinci painted background leaves no viewer would ever notice. That sweat is now the differentiator.
The worry I won't paper over
Here is the uncomfortable part, and it deserves an honest answer rather than a slogan. Taste only grows from reps. Graham was blunt that taste improves with practice — you build it by making bad things, noticing they're bad, and making them less bad. But if a junior lets the machine do all the reps, never wrestles a tangled function into a clean one, never feels the regret of a design that aged badly — where does their taste come from? You can't review what you've never had to write. This is a genuine open problem, not a settled one. The optimistic read is that reading and judging is itself a rep. The honest read is that we don't yet know if it's enough, and anyone who tells you otherwise is selling something.
What this means for you
If you write software, the leverage just moved. The market is about to be flooded with code that works — abundant, cheap, instant — and starved for code that is good. As software gets cheaper, judgment gets more valuable, not less; scarcity sets the price, and the scarce thing is now the eye, not the hands. Your career insurance is no longer how fast you type. It's whether, handed three passing solutions, you reliably reach for the right one and can say exactly why. The good news, the same one Graham gave twenty years ago: this is trainable. Taste is not a gift you're born with. It is reps, and you can choose to keep doing them on purpose.
AI commoditized the ability to build. What's left to sell is knowing what's worth building.
The bottleneck for great software was never the typing — it was the taste.
Source: Paul Graham, Hackers and Painters. Reflections on engineering judgment as it stood in mid-2026; the junior-taste question remains genuinely unresolved.
当 AI 把「写出能跑的代码」白菜化，稀缺的本事是品味——判断哪个通过的方案才真的好。好设计的特征（简单、解决对的问题、重新设计）成了一份审查清单。框架：保罗·格雷厄姆《黑客与画家》。
"好"到底长什么样
格雷厄姆列过好设计的几条特征，读起来简直就是一份审 AI 产物的清单。好设计是简单的——所以当那个聪明密集的版本递上来时，你的直觉该是警惕，而不是鼓掌。它解决对的那个问题，而不是旁边那个更花哨的。它是重新设计出来的：你几乎从来不可能一次做对，所以模型的第一版只是草稿，不是定论。该大胆时它大胆。把品味想成品酒师的舌头：机器一分钟能倒十杯，但要尝出哪一杯坏了，仍得靠一条训练过的舌头。那句 N+1 查询、那层会漏的抽象、那个下个季度就会出卖调用方的接口——就是坏掉的那口。格雷厄姆笔下的创造者，会为没人会注意的细节较劲，就像达·芬奇会去画背景里无人留意的树叶。这份较劲，如今成了你和别人的差距。