HN Debrief

Taste Is All That's Left

  • AI
  • Programming
  • Developer Tools
  • Product Design

The post claims that cheap AI output changes where human value sits. When anyone can generate passable code, prose, and design quickly, the scarce thing is no longer production effort but the ability to reject the wrong thing, insist on a better shape, and recognize quality before you can fully justify it. The author calls that “taste” and frames old technical friction as the training ground that used to develop it.

If you use AI heavily, treat judgment as operational work, not a vague personal virtue. Build review loops, architecture standards, and quality checks that force “no, again” decisions before fast output turns into long-lived maintenance debt.

Discussion mood

Mixed but engaged. Many agreed that AI shifts value toward human judgment, yet the dominant mood was skeptical of the essay’s grand framing and especially its fuzzy, overworked use of “taste.” Commenters were more concrete than the post. They kept pulling the conversation back to maintainability, architecture, security, review burden, and the gap between a convincing demo and software that still works months later.

Key insights

  1. 01

    Quality shows up late in software

    Deep software quality is expensive to evaluate because the failure modes arrive long after the first impression. Reliability, scalability, and security can look fine on day one and then break at the 1000th record, under rare workflows, or months later through a bad endpoint. That reframes the whole “good enough” claim. Fast AI output is not competing against polished craftsmanship at the moment of generation. It is creating more systems whose true cost only appears after adoption.

    Do not judge AI-built systems from the demo or first week. Extend evaluation windows, test growth limits early, and budget for architecture review before shipping turns hidden defects into product strategy.

      Attribution:
    • socketcluster #1
  2. 02

    Agents often replace writing with reading

    Heavy AI use can turn coding into a documentation and review tax. The complaint was not just bad code. It was bloated explanations, generic module structure, and too much low-signal prose wrapped around ordinary decisions. That matters because a midsize AI-assisted codebase can shift the bottleneck from authoring to deciphering what the model thought it was doing. Even users who like agents said the software only gets good when they obsess over the details the model keeps smoothing over.

    Measure whether AI is actually reducing cycle time after review, not just generating more output. If teams are drowning in verbose modules and explanations, add strict output constraints or a second pass that compresses and normalizes what the model writes.

      Attribution:
    • boron1006 #1
    • nemomarx #1
    • mshafir #1
  3. 03

    Taste can become a prestige dodge

    Several commenters punctured the romance around taste by pointing out how convenient it is as a skill claim. It is vague, hard to prove, and easy to move into the spotlight whenever older markers of expertise get automated. That criticism does not kill the underlying idea, but it does expose a risk. If teams talk about taste without naming observable consequences, they are probably defending status rather than improving products.

    When someone invokes taste, force it into concrete checks like readability, recovery paths, latency, security posture, or ease of future changes. If it cannot be translated into review criteria, it is not usable management language.

      Attribution:
    • brap #1
    • chasd00 #1
    • SpicyLemonZest #1
  4. 04

    Good taste can be framed as future change cost

    James Shore’s "Quality With a Name" was used to give the slippery term a harder edge. On this view, what people call taste is really design that minimizes the expected engineering time needed to make likely future changes while keeping the product good enough. That turns taste from mystique into a practical prediction problem about maintenance and evolution. It also weakens any claim that AI can never learn it in principle.

    Use likely future changes as the lens for design review. Ask which approach will be cheapest to adapt over the next year, not which one merely looks cleaner in the present.

      Attribution:
    • akoboldfrying #1
  5. 05

    Scarcity may train taste better than abundance

    The more persuasive side of the scarcity argument was that constraints force prioritization, and prioritization is where judgment gets sharpened. When you cannot afford endless output, you learn what is essential and what can be cut. Cheap generation removes that training pressure. The opposing claim was that abundance creates room to explore, but it did not answer the practical problem of how teams learn restraint when generation is nearly free.

    Introduce deliberate constraints into AI-heavy workflows. Limit iterations, cap context size, or require explicit tradeoff notes so teams still practice choosing rather than endlessly generating.

      Attribution:
    • jdzikowski #1
    • scotty79 #1
    • devin #1
  6. 06

    Judgment is broader than taste

    The philosophy references to Kant and Hume were not just name-dropping. They sharpened an important distinction. Taste is only part of the story. The job is not merely sensing what feels right. It is also making judgments that connect aesthetics, usefulness, ethics, and consequences. That broader frame fits software better than the article’s slogan because architecture, safety, and maintainability are judgment calls even when they have no obvious stylistic dimension.

    Do not organize teams around taste as a standalone virtue. Hire and evaluate for judgment across product, technical risk, and long-term consequences, because those are the decisions AI still does not own.

      Attribution:
    • DiscourseFan #1 #2 #3
    • eudamoniac #1

Against the grain

  1. 01

    Models already exceed many developers on design defaults

    For everyday systems design, the latest models often know the standard solution space better than an individual engineer. They have absorbed common patterns across domains, so their first-pass architectural suggestions can surpass a developer’s personal baseline. That does not mean they are autonomous architects, but it does cut against the idea that AI is stuck at shallow implementation while humans retain the higher-order work untouched.

    Benchmark your own design instincts against model suggestions instead of assuming superiority. You may get better results by using the model as a pattern library and spending your effort on exception cases and tradeoffs.

      Attribution:
    • bluegatty #1
    • catigula #1
    • bijowo1676 #1
  2. 02

    Taste may be another temporary gatekeeping story

    This view treats the whole taste discourse as a moving defense mechanism. First coding skill was the moat. Then prompting. Now taste. If models keep improving, each supposedly human-only layer gets rebranded until the market simply accepts machine-led software creation as normal. That argument is harsher than most of the discussion, but it is a useful warning against building identity around whichever capability automation has not crossed yet.

    Do not build strategy on the assumption that one fuzzy human advantage will stay exclusive. Invest in distribution, customer trust, domain access, and integration depth, because those moats survive capability shifts better than craft narratives.

      Attribution:
    • onion2k #1
  3. 03

    Users and buyers often do not care

    A blunt commercial counterpoint ran through several comments. Most customers care about surface behavior, price, and whether the task gets done. They are not rewarding artisan internals, and many executives will happily accept buggy or inelegant systems if the visible outcome is good enough. That undercuts any neat story where superior taste naturally wins the market.

    Separate product quality from market selection in your planning. If your advantage is deep technical quality, make sure it becomes visible through reliability promises, faster iteration, lower support burden, or compliance wins that customers can actually perceive.

      Attribution:
    • swat535 #1
    • lugoues #1
    • Hasz #1
    • jatora #1

In plain english

architecture ↩
The high-level structure of a software system, including how major components are organized and interact.
compliance ↩
Meeting formal rules or standards imposed by laws, regulators, customers, or internal policy.
Hume ↩
David Hume, a philosopher whose work includes influential writing about taste and judgment.
legacy code ↩
Older existing code that a team must keep working with, often despite messy structure or outdated design.
vibe coding ↩
Using AI to generate software mainly from prompts and intuition, often with little or no direct inspection of the code.

Reference links

Philosophy and tacit knowledge

Essays and articles on software quality

  • Quality With a Name
    Used to give a more concrete definition of taste by tying it to expected future engineering cost.
  • good taste
    Offered as another essay on the same theme for comparison.

Social posts and examples

  • Apenwarr Bluesky post
    Quoted for the line that every slow prototype starts out as a fast prototype, reinforcing the role of iteration and constraint.
  • McDonald's CEO burger clip discussion
    Used in an analogy about whether sellers of mass-market products use their own products and whether that says anything about AI coding tools.