When AI Writes All the Code, What's Left for Developers? The Case for Taste

A post titled "Taste Is All That's Left" hit the front page of Hacker News this week with 410 points and sparked one of the most honest conversations about AI and software development I've read this year. The argument is simple, and it's not the usual "AI will replace developers" or "AI can't replace developers" binary. It's something more uncomfortable: AI can now generate code that's good enough, and "good enough" is the most dangerous phrase in engineering. The Core Argument The essay's author, writing under the handle notashelf, makes a case that's worth taking seriously even if you're tired of AI hot takes. The premise: for most of software history, the hard part was making something exist at all. You had an idea, and between that idea and working code stood hours of typing, reading manuals, misunderstanding APIs, and slowly grinding the wrong version into a slightly less wrong one. Production was the wall. Everyone hit it. That wall is gone. You can describe what you want and get a plausible version of it faster than you could have typed the first function by hand. The idea-to-artifact distance has collapsed. But here's the part that should make every developer sit up: the value you built by learning to climb that wall doesn't disappear. It moves. And where it moves to is the thing the essay calls "taste." What Taste Actually Means Here This isn't about whether you put braces on the same line. The essay draws on Robert Pirsig's Zen and the Art of Motorcycle Maintenance - specifically the concept of Quality, which Pirsig refused to define because defining it would kill it. The argument is that you recognize Quality before you can explain it. A good mechanic knows the engine is wrong before knowing why. A good editor feels the sentence sag before naming the clause that failed. Taste, in this framing, is the compressed, wordless verdict you reach faster than you can justify. It's the "no, again" you say to yourself with total conviction and no available argument. And it's not soft - it's the hardest thing in the work, because it's the only part that was never mechanical to begin with. Everything downstream of that verdict - the typing, the syntax, the wiring of libraries - was always automatable in principle. The verdict was the thing the machine couldn't do for you. It still can't. It can only make the absence of taste cheaper to ignore. The Uncomfortable Part: Where Taste Comes From This is where the essay gets genuinely useful, and not just as commentary on AI. Taste is built the slow, stupid, humiliating way: you make something bad, you're forced to live with it, it fails in front of you, and some part of you files the failure away. Then you do it again. The palate is an accretion of your own mistakes, sat with long enough to sting. The friction - the cost of making things - was not an obstacle to developing taste. It was the curriculum. Every wall you cursed while climbing it was teaching you which walls were worth climbing. The cost that rationed your output also educated your judgement, because paying the cost over and over is how you learn what's worth paying for. Now remove the friction for the next developer. They can generate fluently from day one. They'll never ship the bad version and be forced to sit in it, because the tool offers a competent version for free. They'll climb no wall, and so they'll learn nothing from the climb. They'll arrive at fluency having skipped the entire apprenticeship that fluency used to require - and they'll be more productive than you were at their stage, by every metric anyone bothers to measure. They'll be able to make anything, and unable to tell whether they should. The Economics Problem Suppose you have taste. You paid the full price. You can feel the sag in the sentence and the wrongness in the function. Congratulations - you now ship at exactly the same speed as the person who can't. That's the quiet cruelty. Taste is slow. It says "no, again." It sends the plausible thing back because plausible is not the same as right, and while it's doing that, the person without taste has already shipped, closed the ticket, and moved on. The market timed you both with the same stopwatch and it didn't see the difference. It can't see the difference. Taste doesn't show up in the diff. It's unmeasurable, uncreditable, and invisible on a dashboard. You can't point to the disasters it prevented, because prevented disasters leave no trace. You carry a cost - the extra hours, the returned work, the refusal to ship the fine thing when the right thing is still reachable - and you carry it alone, against an incentive gradient that runs the other way. What This Means If You're Building Software The essay is heavy on diagnosis and light on prescription, but the implications for working developers are clear: 1. Stop competing on production speed. That race is over. If your value proposition is "I can write code fast," you're competing with tools that write code faster and don't sleep. Your value was never the typing. It was the judgement that decided what to type. 2. Invest in your "no" muscle. The scarce skill is no longer making - it's choosing. Deciding what, out of the endless generated plausible, deserves to exist. Curation was a minor virtue when things were expensive to make. It's the whole game when they're free. 3. Don't skip the friction for juniors. If you're mentoring, don't just hand someone the AI-generated answer. Make them build the wrong thing first. Make them sit in it. The friction was the curriculum, and removing it removes the education. 4. Your mistakes are your portfolio. The senior developers who are most valuable in an AI world aren't the ones who generate the most code. They're the ones who have made the most mistakes, sat with them long enough to learn from them, and developed the judgement to prevent the next ones. That's not a credentials problem. It's an experience problem. 5. The "good enough" trap is real. The essay borrows from Harry Frankfurt's distinction between lying and bullshitting. The liar at least respects the truth enough to work against it. The bullshitter doesn't care about the truth in either direction. AI-generated slop is the bullshit of engineering - it's not wrong, exactly. It's indifferent. It works, it passes, it's fine. And fine, produced without friction and shipped without judgement, is now the most abundant substance in the field. The Real Takeaway The essay ends on a note that's less pessimistic than it sounds. The tools didn't devalue the skill. They stripped away everything that wasn't the skill. All those years developers thought the work was the production - the typing, the wiring, the wall - and production turns out to have been the toll. The tax you paid for the privilege of exercising judgement. Now the tax is close to zero, and what's left standing, exposed, with nowhere to hide, is the judgement itself. The part that was always the point. Taste didn't become less valuable. It became the only thing that was ever scarce. We just couldn't see it, because it was buried under all the labor it used to take to get to it. If you're a developer worried about AI replacing you, the answer isn't to get better at generating code. It's to get better at knowing which code deserves to exist. That's harder, slower, and doesn't show up on any dashboard. But it's the only thing left that matters. Based on "Taste Is All That's Left" by notashelf, published August 6, 2026. The original essay is worth reading in full at notashelf.dev/posts/taste-is-all-thats-left. Top comments (0)