[HN Gopher] Taste in the age of AI and LLMs
___________________________________________________________________
Taste in the age of AI and LLMs
Author : speckx
Score : 207 points
Date : 2026-04-07 15:54 UTC (7 hours ago)
(HTM) web link (rajnandan.com)
(TXT) w3m dump (rajnandan.com)
| dk970 wrote:
| The new world order is what not to build...
| furyofantares wrote:
| Extremely ironic piece of slop.
| echelon wrote:
| No - at face value, our work has diminished value. The entire
| supply and demand economics of our careers is changing in the
| blink of an eye.
|
| There are people trying to figure out what this means and where
| to create value. "Taste is the only moat" is one such
| hypothesis. "Senior engineers will be fine" is another.
|
| Everything is super frothy right now and we're in for a wild
| 2026.
| dinkleberg wrote:
| Yeah I feel like we're getting pranked here
| twoodfin wrote:
| Indeed, no taste.
| scared_together wrote:
| It's also possible this is the first iteration of the loop
| described in the "A practical loop for training taste"
| section. Which would be less of a "prank" and more of "using
| the HN audience to feed the machine".
|
| The loop (some points snipped for brevity):
|
| > 1. Pick one high-leverage artifact from your week. A
| paragraph...
|
| > 2. Generate 10 to 20 versions with an AI model.
|
| > 3. For each version, write one sentence that starts with
| "fails because..."
|
| > 4. Rewrite the strongest version with a hard constraint...
|
| > 5. Ship the final version somewhere real and observe what
| happens.
| _dwt wrote:
| It's getting bad here; I've seen at least three obviously AI-
| written "anti-AI" or "AI critical" pieces hit and remain on the
| front page in the last week. I can't help but think about Bill
| Hicks on marketing: "Everyone here who's in marketing is now
| thinkin' the same thing: 'Oh, cool. Bill's going for that anti-
| marketing dollar. That's a huge market.'"
| elcapitan wrote:
| The rest of that is also still gold
| https://www.youtube.com/watch?v=tHEOGrkhDp0
| scared_together wrote:
| I agree.
|
| For those who didn't read the article...
|
| There are subheadings every 3 paragraphs and enough bullets to
| reload a machine gun.
|
| There are also neither any sources nor any personal anecdotes.
| Everything feels generic.
|
| > Over time, this changes how you work. You stop admiring
| polish for its own sake. You get faster at spotting empty
| specificity, borrowed tone, and fake confidence.
|
| "Empty specificity, borrowed tone and fake confidence" describe
| the article itself.
| gmaster1440 wrote:
| If you're properly bitter-lesson-pilled then why wouldn't better
| models continue to develop and improve taste and discernment when
| it comes to design, development, and just better thinking
| overall?
| sparker72678 wrote:
| At least in part because some of Taste is fashion.
| charcircuit wrote:
| Isn't part of fashion trends? AI is good at recognizing
| trends.
| ux266478 wrote:
| Not in the sense you mean. These are trends with concrete
| origins, not a root of statistical aggregate. They only
| look that way if you aren't into fashion and don't follow
| the handful of fashion houses that decide essentially
| everything.
| wavemode wrote:
| I think that would imply the creation of AGI (i.e. something as
| intelligent or more intelligent than mankind), which many
| consider to be science fiction at this point.
|
| > bitter-lesson-pilled
|
| The "bitter lesson" doesn't imply that AGI is coming, all it
| says is that letting AIs learn on their own yields better
| results than directly teaching them things.
| pa7ch wrote:
| I think the author addresses this in saying that since AI
| output is statistically plausible by design its unlikely to
| improve in this area. Why do you think AI will get better in
| this way?
| relativeadv wrote:
| most (all?) models are fundamentally a regression toward the
| mean. Good taste is rarely, if ever, residing in the mean.
| nonameiguess wrote:
| Regardless of how good the tools get, third-party tooling can
| never be a product differentiator unless you somehow manage to
| have exclusive access. Otherwise, everyone else out there can
| and will use the same tools you are. It's more a hedonic
| treadmill than a moat.
| gwern wrote:
| They do improve, but the general creativity and sparkle we see
| with increasing scale comes mostly from scaling up
| pretraining/parameter-size, so it's quite slow and expensive
| compared to the speed (and decreasing cost) people have come to
| take for granted in math/coding in small cheap models. Hence
| the reaction to GPT-4.5: exactly as much better taste and
| discernment as it should have had based on scaling laws, yet
| regarded almost universally as a colossal failure. It was as
| unpopular as the original GPT-3 was when the paper was
| released, because people look at the log-esque gains from
| scaling up 10x or 100x and are disappointed. "Is that all?!
| What has the Bitter Lesson or scaling done for me _lately_? "
|
| So, you can expect coding skills to continue to outpace the
| native LLM taste.
| gmaster1440 wrote:
| I think we're basically agreeing here. Your point (if I'm
| reading it right) is that taste and discernment do scale, but
| the gains come through pretraining/parameter scaling, which
| is slow and expensive compared to the fast, cheap wins in
| math/coding from smaller models. So taste is more of a
| lagging indicator of scale. it improves, but it's the last
| thing people notice because the benchmarkable stuff races
| ahead. Which also means taste isn't really a moat, just late
| to get commoditized.
| gwern wrote:
| My point is more that since you can expect taste's
| commoditization to lag behind for deep fundamental reasons,
| then taste _does_ serve as a moat. Just perhaps a weaker
| one than one would naively expect, and where you will have
| to frantically keep investing in it to stay ahead of the
| LLMs slowly catching up, as opposed to a permanent lock-in
| you can lazily monopolistically coast on indefinitely. (I
| 'm reminded of Neal Stephenson's La Brea tarpit analogy for
| open source vs proprietary software in _In The Beginning
| was the Commandline_.)
| gmaster1440 wrote:
| Fair enough. I really like the tarpit analogy, wasn't
| familiar with it. You can keep pulling your feet out
| faster than the tar rises, as long as you're willing to
| keep spending the energy, possibly with diminishing
| returns over time.
| allears wrote:
| And if anybody knows about good taste, it's techies, right?
| echelon wrote:
| Some of the worst taste and worst opinions.
|
| Lots of techies hate things that are popular with the rest of
| humanity. You see lots of nagging, complaining, and
| disconnected from reality takes. Hate for Instagram, "Dropbox
| will never work", "pop culture sucks", etc.
|
| I'll make a mean joke: a lot of y'all better learn a trade.
| Plumbing, perhaps. I kid, of course, but I also wonder if it
| might turn out to be the eventual reality.
| ibero wrote:
| https://x.com/netcapgirl/status/2024140332963705342?s=46
|
| evergreen.
| nwsm wrote:
| usually when you call something "evergreen" it's not 2 months
| old
| abkolan wrote:
| I think it's just an internet trope at this moment.
| abkolan wrote:
| What's evergreen about it?
| all2 wrote:
| It's an Americanism that means 'it's always green' or 'always
| relevant'.
| eru wrote:
| Is the joke that the guy is drinking bad coffee?
| TheGRS wrote:
| The joke is that all of the engineers that came before AI
| were also just following established patterns, right down to
| everyone wearing the same outfit to work despite our tech
| workplaces usually being very business casual. Implication
| that taste was not something these engineers had either.
| lamasery wrote:
| The joke is that the person "saying" this is wearing their
| "I'm a rational, independent thinker!" tech uniform
| (expensive Nordic outdoors wear, so practical, so smart, so
| active, Vimes' boot theory, et c, not like those _clowns_ in
| business wear, I 'm interested in _practicality_ not
| signaling, that 's why I'm spending so much money signaling
| so hard about how rational I am).
|
| They are visibly displaying a complete lack of personal
| taste, instead wearing the SV equivalent of an outdated-cut,
| off-the-rack navy blue (or even black, LOL) business suit.
|
| The joke is that the message "good taste is what matters now"
| is being delivered by someone apparently, in a specifically
| SV sort of way, with a deficit of good taste.
| adammarples wrote:
| Agree but arcteryx is from vancouver
| lamasery wrote:
| Gah, you're right of course. I was thinking of Fjallraven
| in particular (not that that's the only one) and got it
| mixed up.
| doctorpangloss wrote:
| The original article was written by an LLM.
| morkalork wrote:
| Of course, it's John VP of Product. Did he tell you about
| that triathlon he did last weekend? Don't worry, if he
| hasn't already, he will.
| boshalfoshal wrote:
| The joke is that "taste" usually implies you have some strong
| personal sense of self and style, but if you walked into tech
| offices in the bay area everyone looks like that and
| acts/talks the same.
|
| So its ironic that these same people are talking about
| "taste" when they ostensibly have very little.
| switchbak wrote:
| That seems a bit judgy though, no? As if you can tell about
| a person's internal sense of taste by their business-casual
| clothing choices?
|
| I mean, some of those people undoubtedly like Rush ... make
| of that what you will.
| wincy wrote:
| Sounds like I'd better run out and buy an Arcteryx vest.
| IncreasePosts wrote:
| This seems more telling on the artist who, I guess, believes
| that if you have taste in any field, it will manifest itself as
| wearing stylish clothes. I see their most recent blog post is
| analyzing luxury brands, so I think I'm on point here.
| mememememememo wrote:
| I was expecting a circa 1993 rambling essay, pal.
| CharlieDigital wrote:
| > One of the most useful things about AI is also one of the most
| humbling: it reveals how clear your own judgment actually is. If
| your critique stays vague, your taste is still underdeveloped. If
| your critique becomes precise, your judgment is stronger than the
| model output. You can then use the model well instead of being
| led by it.
|
| Something I find that teams get wrong with agentic coding: they
| start by reverse engineering docs from an existing codebase.
|
| This is a mistake.
|
| Instead, the right train of thought is: "what would _perfect_
| code look like? " and then meticulously describe to the LLM what
| "perfect" is to shape every line that gets generated.
|
| This exercise is hard for some folks to grasp because they've
| never thought much about what well-constructed code or
| architectures looks like; they have no "taste" and thus no
| ability to precisely dictate the framework for "perfect" (yes,
| there is some subjectivity that reflects taste).
| sodapopcan wrote:
| > Instead, the right train of thought is: "what would perfect
| code look like?" and then meticulously describe to the LLM what
| "perfect" is to shape every line that gets generated.
|
| I think this goes against what a lot of developers want AI to
| be (not me, to be clear).
| CharlieDigital wrote:
| I'm looking at it from a team perspective.
|
| With the right docs, I can lift every developer of every
| skill level up to a minimum "floor" and influence every line
| of code that gets committed to move it closer to "perfect".
|
| I'm not writing every prompt so there is still some
| variation, but this approach has given us very high quality
| PRs with very minimal overhead by getting the initial
| generation passes as close to "perfect" as reasonably
| possible.
| sodapopcan wrote:
| Oh I agree with you, I'm just saying a lot of developers
| don't want to use it like that. AI has liberated them from
| the drudgery of reading and writing code and they won't
| accept that they should still be doing a bit of both, if
| not a lot of reading.
| aaaronic wrote:
| It does amaze me when colleagues refuse to read what I
| (personally, deliberately) wrote (they ask AI to
| summarize), but then tell AI to write their response and
| it's absolutely bloated and full of misconceptions around
| my original document.
|
| If they aren't willing to read what I put effort into,
| why should I be expected to read the ill-conceived and
| verbose response? I really don't want to get into a match
| of my AI arguing with your AI, but that's what they've
| told me I should be doing...
| sodapopcan wrote:
| Ya, I can't stand that. Asking a question and being hit
| with "this is what claude said" gives me a new kind of
| rage.
| Izkata wrote:
| Yeah, this happened to me recently and the advice could
| have caused data corruption (yay old systems). I only
| caught it because they asked before making changes and I
| had a vague memory of it from having investigated the
| same thing almost a decade ago (and found the note and
| explanation with a link to a bugtracker in my personal
| wiki).
| switchbak wrote:
| I've been having ongoing issues with a manager who
| responds in the form of Claude guided PRs. Undoubtedly
| driven from confused prompts. Always full of issues,
| never actually solving the problem, always adding HEAPS
| of additional nonsense in the process.
|
| There's an asymmetry of effort in the above, and when
| combined with the power asymmetry - that's a really bad
| combo, and I don't think I'm alone.
|
| I'm glad to see the appreciation of the enormous costs of
| complexity on this forum, but I don't think that has
| ascended to the managerial level.
| CharlieDigital wrote:
| > ...a manager who responds in the form of Claude guided
| PRs
|
| I think the job of a dev in this coming era is to produce
| the systems by which non-engineers can build competently
| and not break prod or produce unmaintainable code.
|
| In my current role, I have shifted from lead IC to
| building the system that is used by other IC's and non-
| IC's.
|
| From my perspective, if I can provide the right
| guardrails to the agent, then anyone using any agent will
| produce code that is going to coalesce around a higher
| baseline of quality. Most of my IC work now is aligned on
| this directionality.
| forgetfulness wrote:
| Also a lot of middle managers. Many organizations
| enthusiastically adopting AI are doing so because they want
| to appeal to the authority of the bots and bludgeon
| colleagues with it.
| Shorel wrote:
| It doesn't matter, one way or the other. The overall market
| share will decide. In some cases, I think good code will be a
| decisive factor. Think Steam launcher Vs Epic. Epic doesn't
| have good code. Their performance suffers in consequence. In
| other cases the users are so trapped it makes no difference.
| MS Outlook and Teams is the prime example of this.
| dist-epoch wrote:
| > Instead, the right train of thought is: "what would perfect
| code look like?"
|
| That's the classic 2nd-system effect - "let's rewrite it from
| scratch, now that we know what we want". And you throw away all
| the hard-learned lessons.
|
| https://en.wikipedia.org/wiki/Second-system_effect
| CharlieDigital wrote:
| Not really the case; you're misunderstanding the term second
| system effect. > The general tendency is to
| over-design the second system, using all the ideas and frills
| that were cautiously sidetracked on the first one. The
| result, as Ovid says is a "big pile". For example, consider
| the IBM 709 architecture, later embodied in the 7090. This
| is an upgrade, a second system for the very successful and
| clean 704. The operation set is so rich and profuse that
| only about half of it was regularly used. (p.55) >
| > The second-system effect has another manifestation somewhat
| different from pure functional embellishment. That is a
| tendency to refine techniques whose very existence has been
| made obsolete by changes in basic system assumptions. (p.56)
|
| It's the exact opposite: by explicitly dictating what is
| correct, perfect, and standard in _this_ codebase, we achieve
| very high consistency and quality with very little
| "embellishment" and excess because the LLM is following a set
| of highly curated instructions rather than the whims of each
| developer on the team.
|
| Suggest that you re-read what Brooks meant by "second system
| effect".
| aaaronic wrote:
| I've worked in too many large codebases where no one can point
| to any _single file or class_ and label it "correct," ("the
| right way") yet management is amazed when the lack of a "North
| Star" means the codebase is full of overlapping, piecemeal
| patterns that are lucky to work together at all.
| CharlieDigital wrote:
| That's why the team needs someone with "taste" to dictate the
| idiomatic way to do it and why LLMs (when used this way) can
| raise the floor of quality and baseline of consistency.
| subhobroto wrote:
| > Instead, the right train of thought is: "what would perfect
| code look like?" and then meticulously describe to the LLM what
| "perfect" is to shape every line that gets generated.
|
| I don't think there's perfect code.
|
| Code is automation - it automates human effort and humans
| themselves have error, hence not perfect.
|
| So as long as code meets or exceeds the human output, it's
| "good enough" and meets expectations. That's what a typical
| customer cares about.
|
| A customer will happily choose a tent made of tarp and plastic
| sticks that's available at their budget, _right now_ when it 's
| raining outside, over an architectural marvel that will be
| available sometime in the future at some unknown pricepoint.
|
| Put another way, I don't think if you built CharlieAI
| CharlieGPT _today_ , where the only differentiating factor over
| ChatGPT was that CharlieGPT was written using _perfect code_ ,
| you would have any meaningful edge.
|
| I am yet to see _any_ evidence where everything else being
| equal, one company had an edge over another simply due to
| superior code.
|
| Infact, I have overwhelming evidence of companies that had
| better code succumb and vanish against companies that had very
| little, _if any_ code, because those dollars were instead
| invested in better customer discovery, segmentation and
| analytics ( "what _should_ we build? ", "if we did _one_ thing
| that would give our customers an unfair advantage, what would
| be _that_ thing? ")
|
| Software history is full of perfect OS, editors, frameworks,
| protocols that is lost over time because a provably inferior
| option won marketshare.
|
| You are using a software controlled SMPS to power your device
| right now. You have 0 idea what the quality of that code is.
| All you care about is whether that SMPS drains your battery
| prematurely and heats up your device unnecessarily. It's
| extremely unlikely that such an efficient, _low overhead_
| control system was written using well abstracted modules. It 's
| _more likely_ that control system is full of _gotos_ and
| repeated violations of DRY that would make a perfectionist
| shudder and cry.
| CharlieDigital wrote:
| > I don't think there's perfect code
|
| Note I used "perfect" in my text. In this context, meaning it
| passes human PR reviews following our standard guidelines
| with minimal feedback/correction required.
| > So as long as code meets or exceeds the human output, it's
| "good enough" and meets expectations. That's what a typical
| customer cares about.
|
| Why settle for this when "perfect" is "free"? I understand
| this dichotomy when writing "perfect" code requires more
| expensive, more experienced human resources or more time so
| you settle for "good enough"; but this is no longer the case,
| is it? The cost of "perfect" is only perhaps a few fractions
| of a cent higher than shitty.
|
| You only need to accurately describe what "perfect" is to the
| LLM instead of allowing it to regress to the mean of its
| training set. There really is no cost difference between
| writing shitty code and "perfect" code now; its just a matter
| of how good you are at describing "perfect" to the LLM.
|
| For example, we very specifically want our agents to write
| code using C# tuple return types for private methods that
| return more than 1 value instead of creating a class. The
| tuple return type is a stack allocated value type and has a
| default deconstructor. We also always want to use named tuple
| fields every time because it removes ambiguity for humans and
| increases efficiency for agents when re-reading the code.
|
| We want the code to make use of pattern matching and switch
| expressions (not `switch-case`) because they help enforce
| exhaustive checks at compile time and make the code more
| terse.
|
| If we simply tell the agent these rules ahead of time, we get
| "perfect", consistent code each time. Being able to do so
| requires "taste" and understanding why writing code one way
| or using a specific language construct or a specific design
| pattern is the "right" way.
| subhobroto wrote:
| > There really is no cost difference between writing shitty
| code and "perfect" code now; its just a matter of how good
| you are at describing "perfect" to the LLM.
|
| The consequent is at odds with the antecedent. It's a
| performative contradiction (if the output were truly
| "free", the skill of the operator would be a zero-value
| variable - yet, by requiring skill, you acknowledge a cost)
| as I prove below
|
| > The cost of "perfect" is only perhaps a few fractions of
| a cent higher than shitty.
|
| Is your cost model accounting for the cost of
| specification, of review and additional cycles required if
| review fails or the specification itself needs to be
| adjusted?
|
| > If we simply tell the agent these rules ahead of time, we
| get "perfect", consistent code each time
|
| No, in the simplest case, your cost of perfection is simply
| moving up the chain of abstraction from implementation
| (coding) to design and specification. In reality it also
| splits and moves a part of that cost downstream to
| verification.
|
| This isn't some special, magical insight I have, I'm
| reiterating Tesler's Law right back to you.
|
| I also encourage you to read software history - for decades
| it has been trivial to split out perfectly working CRUD
| from an ER and UML diagram, no LLM necessary. The insight
| is understanding why we continue to hire cheap human labor
| to spit out CRUD instead of using those tools.
|
| The cost of software is, and always has been, in the
| figuring out the intent, not the generation of syntax.
|
| I wish pg was more active on HN - I expect this is one of
| the reasons why he wanted founders to have and share the
| painpoints of their (potential) customers. Figuring out the
| intent is expensive. Mistake the intent and the best case
| scenario is a pivot.
| CharlieDigital wrote:
| > I wish pg was more active on HN - I expect this is one
| of the reasons why he wanted founders to have and share
| the painpoints of their (potential) customers. Figuring
| out the intent is expensive. Mistake the intent and the
| best case scenario is a pivot.
|
| Your mistake is that you think the point is that only
| engineers participate in the production of code. In fact,
| the point is that the product team and the people closest
| to the customer can generate the code. And for that
| reason, the goal is to produce a framework on top of
| which "perfect" code can be produced with relative ease
| and consistency regardless of whether the user is part of
| engineering or product. > Is your cost
| model accounting for the cost of specification
|
| This is the same cost no matter what. The LLM does not
| generate code on its own; some operator must provide some
| instruction and specification regardless so you might as
| well give it good ones. But here, I would point out that
| there is a high level of broader general instructions
| that incur a one-time cost of specification ("Always
| write _this code this way_ ").
| bambushu wrote:
| This matches my experience exactly. I built a tool that sends
| code to three different AI models for review because the model
| that wrote the code can't critique it honestly. It has all the
| context and actively suppresses objections. The second model,
| with zero context, immediately finds things the first one
| rationalized away. Taste isn't just knowing what good looks
| like, it's being willing to say "this isn't it" to your own
| work. AI can't do that to itself yet.
| wallstop wrote:
| I don't think you really need a tool for that, you can just
| add something like "after the task is finished, have a
| subagent review the work in an adversarial fashion. If any
| defects, no matter how small are found, have another subagent
| implement the findings. Repeat this in a loop until all
| subagents achieve consensus that the product is of
| exceptional quality with no defects" or similar to each
| prompt. Each subagent gets its own, fresh, context window. No
| tooling required.
| hackerman70000 wrote:
| This reads like cope. If taste were a real moat, designers and
| art directors would be the highest paid people in tech. They
| arent. Execution speed, distribution, and capital are moats.
| Taste is a tiebreaker at best. The market consistently rewards
| "good enough, shipped fast" over "exquisite, shipped late".
| ata_aman wrote:
| I maintain the opinion that courage is the only moat and always
| will be
| jrm4 wrote:
| Courage with _consequences,_ yes.
| DrewADesign wrote:
| It's not that straightforward. Art directors and designers get
| paid to visually communicate things the business wants to
| communicate-- anything from brand vibes, to directing people to
| click on a "buy me" button, to the state of an interface. Most
| designers in tech companies aren't even the ones that design
| things like branding -- that's done by specialists in extremely
| well-compensated studios, and corporate designers are stuck
| following their guidelines. Taste is nearly irrelevant to an
| interface designer, for example.
| hackerman70000 wrote:
| Fair point. I was conflating taste with design, which is a
| different thing. But I think this actually strengthens the
| argument. If even the people whose entire job is visual
| judgment are mostly executing within constraints set by
| someone else, then "taste" as an individual moat is even
| weaker than the article claims. The leverage is in setting
| the constraints, not in having better judgment within them
| ux266478 wrote:
| The job isn't about visual judgement, but composition.
| Judgement/taste is the responsibility of directors and
| executives.
| hackable_sand wrote:
| I guess so
|
| If your goal is to turn a profit
|
| If you want to make something that is true then you can't fail.
| You don't need any defensive structures because the everyone
| else just spins in lies.
|
| People only need moats when they are insecure, by definition
|
| The most truthful artists don't need that.
| rvz wrote:
| Well, nope. There are _three_ real moats left in software:
|
| Distribution, Data (Proprietary) and Iteration Speed.
|
| Very successful companies have all three: Stripe, Meta, Google,
| Amazon.
| wavemode wrote:
| The moat of all four of those companies is simply
| infrastructure, partnerships, and plain-old name recognition.
|
| Data and iteration speed aren't moats. I don't know what you
| mean by "distribution".
| anonyfox wrote:
| In fact proprietary data IS a moat in certain circumstances.
| Example: German law, in order to create anything proper a
| lawyer NEEDS to read up specific commentary (,,Beck") that
| requires a paid access and the data never was party of any
| LLM corpus since it only exists behind a paywall and
| otherwise is defended by lawyers. Therefore any german legal
| advice given from chatbots always (>80%) is flat out wrong
| even harmful at times if things would go to court.
| verdverm wrote:
| Related: https://blog.kinglycrow.com/no-skill-no-taste/
|
| Discussion: https://news.ycombinator.com/item?id=47089907
| dlev_pika wrote:
| Rick Rubin said it best.
|
| https://youtu.be/jg1WUOxY6Cg?si=0ajVvgKnyuSz0e2Y
| dietr1ch wrote:
| no share Id link: https://youtu.be/jg1WUOxY6Cg
| everyone wrote:
| I dont buy the authors argument. Not much has changed imo.
| Mediocre slop has always been the easiest thing to generate.
| dist-epoch wrote:
| Ah, the classic "we'll ship production to China and just do
| design and marketing in US, because we have taste on what to
| build, and China doesn't". That worked really well...
| ValentineC wrote:
| If you replace "China" with some other countries with large
| offshore engineering centres, your statement would still hold
| true today.
|
| China managed to copy, improve, and localise for their Chinese-
| reading market, then oust competition through good use of the
| Great Firewall (though I wonder if that specifically was an
| unintended consequence).
|
| Many other countries, especially the English-speaking ones that
| don't have a great firewall to keep their market buying
| locally, still need to compete with US tech giants for "taste".
| anonzzzies wrote:
| I use AI for code and we review that code and write tests
| ourselves first which the AI cannot touch. For writing we hardly
| ever do, unless we know the requester of something is incompetent
| and will never read it anyway; then it is a waste of time to do
| anything, but they expect something substantial and nice looking
| to tick a few boxes. It is great for that; a large bank with 40
| layers of management, all equally incompetent, asked for a 'all
| encompassing technical document vault'; one of them sent an
| 'expectation document' which contained so much garbage as to show
| they did not even know what they were asking, but 1000s of pages
| was the expectation. So sure, claude will write that in an hour,
| notebooklm will add 100 slidedecks for juiceness. At first sight
| it looks amazing; its probably mostly accurate as well, but who
| knows; they will never ever read it; no one will. We got the 20m+
| (with many opportunities to grow much larger) project. Before
| that was only in reach of the huge consultants (where everyone in
| those management levels worked before probably) who we used to
| lose against. Slop has its purpose.
| inerte wrote:
| Ah, Steve Jobs vs Bill Gates. Designer vs 41 shades of blue. This
| is nothing new. There's space for everybody.
| danielvaughn wrote:
| Disagree with the overall argument. Human effort is still a moat.
| I've been spending the past couple of months creating a codebase
| that is almost entirely AI-generated. I've gotten way further
| than I would have otherwise at this pace, but it was still a lot
| of effort, and I still wasted time going down rabbit holes on
| features that didn't work out.
|
| There's some truth in there that judgement is as important as
| ever, though I'm not sure I'd call it taste. I'm finding that you
| have to have an extremely clear product vision, along with an
| extremely clear language used to describe that product, for AI to
| be used effectively. Know your terms, know how you want your
| features to be split up into modules, know what you want the
| interfaces of those modules to be.
|
| Without the above, you run into the same issue devs would run
| into before AI - the codebase becomes an incoherent mess, and
| even AI can't untangle it because the confusion gets embedded
| into its own context.
| taude wrote:
| I feel like you're pretty strongly agreeing that taste is
| important: " I'm finding that you have to have an extremely
| clear product vision...""
|
| Clear production vision that you're building the right thing in
| the right way -- this involves a lot of taste to get right.
| Good PMs have this. Good enginers have this. Visionary leaders
| have this....
|
| The execution of using AI to generate the code and other
| artifacts, is a matter of skill. But without the taste that
| you're building the right thing, with the right features, in a
| revolutionary way that will be delightful to use....
|
| I've looked at three non-engineer vibe-coded businesses in the
| past month, and can tell that without taste, they're building a
| pretty mediocre product at best. The founders don't see it yet.
| And like the article says, they're just setting themselves up
| for mediocrity. I think any really good PM would be able to
| improve all these apps I looked at almost immediately.
| arnorhs wrote:
| The way I understood it, the original article is saying the
| _only_ remaining differentiator is taste and the comment you
| replied to is saying "wrong, there are also other things,
| such as effort".
|
| I don't necessarily interpret the comment you replied to as
| saying that "taste is not important", which seems like what
| you are replying to, just that it's not the only remaining
| thing.
|
| I agree that taste gets you far. And I agree with all the
| examples of good taste that you brought up.
|
| But even with impeccable taste, you still need to learn, try
| things, have ideas, change your mind etc.. putting all of
| that in the bucket of "taste" is stretching it..
|
| However, having good taste when putting in the effort, gets
| your further than with effort alone. In fact, effort alone
| gets you nowhere, and taste alone gets you nowhere. Once you
| marry the two you get somewhere.
| hellisothers wrote:
| Aren't you just making their point stronger? Effort is what
| is being replaced here, with some taste and a pile of AI
| (formerly effort) you can go to the moon.
| Jensson wrote:
| But you still need effort, its not only taste. "Only"
| means you can do it with no effort.
| theowaway213456 wrote:
| In other words, it requires a tremendous amount of effort
| to fully communicate your tastes to the AI. Not everybody
| wants to expend the time or mental effort doing this!
| (Once we have more direct brain/computer interfaces, this
| effort will go down, but I expect it will not be
| eliminated fully)
| Shog9 wrote:
| This is the second time in two days I've seen a subthread
| here with folks seemingly debating whether or not
| defining and communicating requirements counts as work if
| the target of those requirements is an LLM system.
|
| I'm confused as to why this is even a question. We used
| to call this "systems analysis" and it was like... a
| whole-ass _career_. LLMs seem to be remarkably capable of
| using the output, but they 're not even close to the
| first software systems sold as being able to take
| requirements and turn them into working code (for various
| definitions of "requirements" and "working").
|
| I'm also skeptical that direct brain interfaces would
| make this any less work; I don't think "typing" or
| "english" are the major barriers here, anymore than
| "drafting" is the major barrier to folks designing their
| own cars and houses... Any fool _thinks_ they know what
| they need!
| Izkata wrote:
| Thinking might even be more difficult: Unfiltered
| thoughts, intrusive thoughts, people with no inner voice
| to encode as text...
| freediddy wrote:
| At some point, just an idea will be enough for your
| Neurolink to spawn an agent to create 1000 different
| versions of your idea along with things that mimic your
| tendencies. There will be no effort, only choice.
| skydhash wrote:
| Deciding between 1000 different versions is a lot of
| effort IMO. With manual coding, you're mostly deciding
| one decision point at a time, which is easier when you
| think about it. It just require foresight which comes
| from experience
| ToucanLoucan wrote:
| As both a software engineer and a creative, I absolutely
| do not want 1,000 versions of what I am trying to make
| generated for me. I don't care if it's free or even
| cheap. I want to _make things._
|
| I know this is a concept deeply alien to a lot of HN's
| userbase but I did not get into programming or making art
| to have finished products; that's a necessary function
| that is lovely when it's reached, but ultimately, I
| derive my enjoyment from The Process. The process of
| finding a problem a user has, and solving it.
|
| And yes I'm sure Claude could do it faster than me (and
| only at the cost of a few acres of rainforest!) but
| again, you're missing the point. I _enjoy_ the work. That
| is not a downside to me.
| andai wrote:
| I think you're missing the point. Effort is a moat now because
| centaurs (human+AI) still beat AIs, but that gap gets smaller
| every year (and will ostensibly be closed).
|
| The goal is to replicate human labor, and they're closing that
| gap. Once they do (maybe decades, but probably will happen),
| then only that "special something" will remain. Taste,
| vision... We shall all become Rick Rubins.
|
| Until 2045, when they ship RubinGPT
| monknomo wrote:
| do you need taste if you can massively parallel a/b test your
| way to something that is tasteful? say like you take your
| datacenter of geniuses and have a a rubin-loop supervising
| testing different directions. shouldn't that be close enough?
| all2 wrote:
| "taste" here is an intractable solution. Just take a look
| at how architecture has varied throughout the history of
| mankind, building materials, assembly, shape, flow, all of
| it boils down to taste. Some of it can be reduced to
| 'efficiency' -- like the 3 point system for designing
| kitchens, but even that is a matter of taste.
|
| Find three professional chefs and they will give you three
| distinct visions for how a kitchen should be organized.
|
| The same goes for any professional field, including
| software engineering.
| skejeke wrote:
| That approach leads you to products like instagram.
| timacles wrote:
| Can infinite monkeys produce Shakespeare?
| pegasus wrote:
| > but that gap gets smaller every year (and will ostensibly
| be closed)
|
| As long as you build software for humans (and _all_ software
| we build is for humans, ultimately), you 'll need humans at
| the helm to steer the ship towards a human-friendly solution.
| boshalfoshal wrote:
| The thing is, do humans _need_ most software? The less
| surfaces that need to interact with humans, the less you
| need humans in the loop to design those surfaces.
|
| In a hypothetical world where maybe some AI agents or
| assistants do the vast majority of random tasks for you,
| does it matter how pleasing the doordash website looks to
| you? If anything, it should look "good" to an ai agent so
| that its easier to navigate. And maybe "looking good" just
| amounts to exposing some public API to do various things.
|
| UIs are wrappers around APIs. Agents only need to use APIs.
| 9rx wrote:
| _> And maybe "looking good" just amounts to exposing
| some public API to do various things._
|
| Maybe, but you still need humans to make that call. The
| software is still built for humans no matter how much
| indirection you add.
|
| There is a conceivable day where that is no longer true,
| but when you have reached that point it is no longer AI.
| pegasus wrote:
| > do humans _need_ most software?
|
| Yes, if it's not redundant software. The ultimate utility
| is to a human. Sure, at some point humans stopped writing
| assembly language and employed a compiler instead, so the
| abstraction level and interfaces change, but it's all
| still there to serve humans.
|
| To use your example, do you think humans will want to
| interact with AI agents using a chat interface only? For
| most tasks humans use computers today, that would be very
| unwieldy. So the UI will migrate from the website to the
| AI agent interface. It all transforms, becoming more
| powerful (hopefully!), but won't go away. And just how
| the advent of compilers led to an increase of programmers
| in the world, so will AI agents. This is connected with
| Javon's paradox as well.
| koe123 wrote:
| I imagine that the gap with current work can largely be
| closed, but are we really confident that this will hold with
| the new work that pops up? Increasingly I think we're lacking
| imagination as to what work can be in a post AI world. I.e.
| could an abacus wielder imagine all the post computer jobs?
| abadar wrote:
| You make a really salient point about having a clear vision and
| using clear language. Patrick Zgambo says that working with AI
| is spellcasting; you just need to know the magic words. The
| more I work with AI tools, the more I agree.
|
| Now, figuring out those words? That's the hard part.
| gopher_space wrote:
| > Now, figuring out those words? That's the hard part.
|
| To be clear, this is the hard part for comp sci majors who
| can't parse other disciplines. Language isn't a black box for
| everyone.
| crystal_revenge wrote:
| > ... for AI to be used effectively.
|
| I'm continually fascinated by the _huge_ differences in
| individual ability to produce successful results with AI. I
| always assumed that one of the benefits of AI was "anyone can
| do this". Then I realized a lot of people I interact with _don
| 't_ really understand the problem they're trying to solve all
| that well, and have some irrational belief that they can get AI
| to brute force their way to a solution.
|
| For me I don't even use the more powerful models (just Sonnet
| 4.6) and have yet to have a project not come out fairly
| successful in a short period of time. This includes graded live
| coding examples for interviews, so there is at least some
| objective measurement that these are functional.
|
| Strangely I find traditional software engineers, especially
| experienced ones, are generally the _worst_ at achieving
| success. They often treat working with an agent _too_ much like
| software engineering and end up building bad software rather
| than useful solutions to the core problem.
| alfalfasprout wrote:
| > Strangely I find traditional software engineers, especially
| experienced ones, are generally the worst at achieving
| success. They often treat working with an agent too much like
| software engineering and end up building bad software rather
| than useful solutions to the core problem.
|
| This feels a bit like a strawman. How do you assess it to be
| bad software without being an engineer yourself? What
| constitutes successful for you?
|
| If anything, AI tools have revealed that a lot of people have
| hubris about building software. With non-engineers believing
| they're creating successful work without realizing it's a
| facade of a solution that's a ticking time bomb.
| crystal_revenge wrote:
| > without being an engineer yourself?
|
| When did I say I'm not a software engineer? I have a
| software engineering background (I've written reasonably
| successful books on software), I've just done a lot of
| other stuff as well that people tend to find more valuable.
|
| > What constitutes successful for you?
|
| The problem I need to solve is solved? I'm not sure what
| other measure you could have. Honestly, people really
| misunderstand how to use agents. If you're aim is to "build
| software" you're going to get in trouble, if your aim is to
| "solve problems" then you're more aligned with where these
| tools work most effectively.
| QuadmasterXLII wrote:
| If every project you have tackled has come out successful,
| then you are managing to never tackle a problem that is
| secretly literally impossible, which is a property of
| whatever prefilter you are applying to potential problems.
| Given that your prefilter has no false positives, the main
| bit of missing information is how many false negatives it
| has.
| gopher_space wrote:
| > I always assumed that one of the benefits of AI was "anyone
| can do this". Then I realized a lot of people I interact with
| don't really understand the problem they're trying to solve
| all that well
|
| I've been through a handful of "anyone can do this"
| epiphanies since the 90s and have come to realize the full
| statement should be "anyone can do this if they care about
| the problem space".
| lamasery wrote:
| "AI" tools I've got at work (and am mandated to use, complete
| with usage tracking) aren't a wide-open field of options like
| what someone experimenting on their own time might have, so
| I'm stuck with whatever they give me. The projects are brown-
| field, integrate with obscure industry-specific systems, are
| heavy with access-control blockers, are already in-flight
| with near-term feature completion expectations that leave
| little time for going back and filling in the stuff LLMs need
| to operate well (extensive test suites, say), and _must not_
| wreck the various databases they need to interact with, most
| of which exist only as a production instance.
|
| I'm sure I could hack together some simple SaaS products with
| goals and features I'm defining myself in a weekend with
| these tools all on my own (no communication/coordination
| overhead, too!), though. I mean for an awful lot of potential
| products I could do that with just Rails and some gems and no
| LLM any time I liked over the last 15+ years or whatever, but
| now I could do it in Typescript or Rust or Go et c. with
| LLMs, for whatever that's worth. At work, with totally
| different constraints, the results are far less dramatic and
| I can't even feasibly _attempt_ to apply some of the
| (reputedly) most-productive patterns of working with these
| things.
|
| Meanwhile, LLMs are making all the code-adjacent stuff like
| slide decks, diagrams, and ticket trackers, incredibly
| spammy.
|
| [EDIT] Actually, I think the question "why didn't Rails'
| extreme productivity boost in greenfield tiny-team or solo
| projects translate into vastly-more-productive development
| across all sectors where it might have been relevant, and how
| will LLMs do significantly better than that?" is one I'd like
| to see, say, a panel of learned LLM boosters address. Not in
| a shitty troll sort of way, I mean their exploration of why
| it might play out differently would actually be interesting
| to me.
| crystal_revenge wrote:
| > The projects are brown-field, integrate with obscure
| industry-specific systems, are heavy with access-control
| blockers
|
| These are cases where I've seen agentic solutions perform
| the _best_. My most successful and high impact projects
| have been at work, getting multiple "obscure industry-
| specific systems" talking to each other in ways that
| unblocks an incredible amount of project work.
| pegasus wrote:
| > graded live coding examples for interviews
|
| Yeah, for those you can just relax and trust the vibes. It's
| for complex software projects you need those software
| engineering chops, otherwise you end up with a intractable
| mess.
| crystal_revenge wrote:
| If it's for a complex software project the first question
| you need to ask is "does this really need to be _software_
| at all? "
|
| Honestly this is where most traditional engineers get
| stuck. They keep attacking the old problem with new tools
| and being frustrated. I agree that agents are not a great
| way to build "complex software projects" but I think the
| problem space that is best solved by a "complex software
| project" is rapidly shrinking.
|
| I've had multiple vendors try to sell my team a product
| that we can build the core functionality of ourselves in an
| afternoon. We don't _need_ that functionality to scale to
| multiple users, server a variety of needs, be adaptable to
| new use cases: we 're not planning to build a SaaS company
| with it, we just need a simple problem solved.
|
| But these comments are a treasure trove of anecdotes
| proving exactly my point.
| rvz wrote:
| > Without the above, you run into the same issue devs would run
| into before AI - the codebase becomes an incoherent mess, and
| even AI can't untangle it because the confusion gets embedded
| into its own context.
|
| We have a term for this and it is called "Comprehension Debt"
| [0] [1].
|
| [0] https://arxiv.org/abs/2512.08942
|
| [1] https://medium.com/@addyosmani/comprehension-debt-the-
| hidden...
| danielvaughn wrote:
| I'm not sure I agree the term applies. Comprehension debt, as
| I understand it, is just the dependency trap mentioned in
| that arxiv paper you linked. It means that the AI might have
| written something coherent or not, but you as a human
| evaluator have little means to judge it. Because you've
| relied on it too much and the scope of the code has exceeded
| the feasibility of reading it manually.
|
| When I talk about an incoherent mess, I'm talking about
| something different. I mean that as the codebase grows and
| matures, subtle details and assumptions naturally shift. But
| the AI isn't always cleaning up the code that expressed those
| prior assumptions. These issues compound to the point that
| the AI itself gets very confused. This is especially
| dangerous for teams of developers touching the same codebase.
|
| I can't share too much detail here, but some personal
| experience I ran into recently: we had feature ABC in our
| platform. Eventually another developer came in, disagreed
| with the implementation, and combined some aspects of it into
| a new feature XYZ. Both were AI generated. What _should_ have
| happened is that feature ABC was deleted from the code or
| refactored into XYZ. But it wasn't, so now the codebase has
| two nearly identical modules ABC and XYZ. If you ask Claude
| to edit the feature, you've got a 50/50 shot on which one it
| chooses to target, even though feature ABC is now dead,
| unreachable code.
|
| You might say that resolving the above issue is easy, but
| these inconsistencies become quite numerous and unsustainable
| in a codebase if you lean on AI too much, or aren't careful.
| This is why I say that having a super clear vision up front
| is important, because it reduces this kind of directional
| churn.
| all2 wrote:
| > This is why I say that having a super clear vision up
| front is important, because it reduces this kind of
| directional churn.
|
| I'm on my 6th or 7th draft of a project. I've been picking
| away at this thing since the end of January; I keep
| restarting because the core abstractions get clearer and
| clearer as I go. AI has been great in this discovery
| process because it speeds iteration much more quickly. I
| know its starting to drift into a mess when I no longer
| have a clear grasp of the work its doing. To me, this
| indicates that some mental model I had and communicated was
| not sufficiently precise.
| danielvaughn wrote:
| Yep, for sure. Restarting is the right choice IMO, it's
| way easier than trying to untangle from a previous
| iteration.
| stronglikedan wrote:
| > I've gotten way further than I would have otherwise at this
| pace, but it was still a lot of effort, and I still wasted time
| going down rabbit holes on features that didn't work out.
|
| By the time I'm done learning about the structure of the code
| that AI wrote, and reviewing it for correctness and
| completeness, it seems to be as much effort as if I had just
| written it myself. And I fear that will continue to be the
| reality until AIs can be trusted.
| edgyquant wrote:
| Well that is not how anyone is doing agentic coding though.
| That sounds like just a worse version of traditional coding.
| Most people are building test suites to verify correctness
| and not caring about the code
| zer00eyz wrote:
| > Disagree with the overall argument.
|
| It's leaning in a good direction, but the author clearly lacks
| the language and understanding to articulate the actual
| problem, or a solution. They simply dont know what they dont
| know.
|
| > Human effort is still a moat.
|
| Also slightly off the mark. If I sat one down with all the
| equipment and supplies to make a pair of pants, the majority of
| you (by a massive margin) are going to produce a terrible pair
| of pants.
|
| Thats not due to lack of effort, rather lack of skill.
|
| > judgement is as important as ever,
|
| Not important, critical. And it is a product of skill and
| experience.
|
| Usability (a word often unused), cost, utility, are all the
| things that people want in a product. Reliability is a
| requirement: to quote the social network "we dont crash". And
| if you want to keep pace, maintainability.
|
| > issue devs would run into before AI - the codebase becomes an
| incoherent mess
|
| The big ball of mud (https://www.laputan.org/mud/ ) is 27 years
| old, and still applies. But all code bases have a tendency to
| acquire cruft (from edge cases) that don't have good in line
| explanations, that lack durable artifacts. Find me an old code
| base and I bet you that we can find a comment referencing a bug
| number in a system that no longer exists.
|
| We might as an industry need to be honest that we need to be
| better librarians and archivists as well.
|
| That having been said, the article should get credit, it is at
| least trying to start to have the conversations that we should
| be having and are not.
| socalgal2 wrote:
| Isn't this a temporary situation though.
|
| Today: Ask AI to "do the thing", manual review because don't
| trust the AI
|
| Tomorrow: Ask AI to "do the thing"
|
| I'm just getting started on my AI journey. It didn't take long
| before I upgraded from the $17 a month claude plan to the $100
| a month plan and I can see myself picking the $200 a month plan
| soon. This is for hobby projects.
|
| At the moment I'm reviewing most of the code for what I'm
| working on, and I have tests and review those too. But, seeing
| how good it is (sometimes), I can imagine a future where the AI
| itself has both the tech chops and the taste and I can just say
| "Maybe me an app to edit photos" and it will spit out a user
| friendly clone of photoshop with good UX.
|
| We already kind of see this with music - it's able to spit out
| "Bangers". How long until it can spit out hit rom-coms, crime
| shows, recipes, apps? I don't think the answer is "never". I
| think more likely the answer is in N years where N is probably
| a single digit.
| guzfip wrote:
| > We already kind of see this with music - it's able to spit
| out "Bangers"
|
| "Bangers" being roughly equivalent to garbage mass marketed
| radio pop? Or "We are Charlie Kirk" lol
| danielvaughn wrote:
| No, I don't think it is temporary. As AI becomes more
| powerful, we'll simply ask it to do more difficult things.
| There's a level of complexity where "do the thing" is
| insufficient. We'll never be at a place where AI can infer
| vast amounts of nuance from simple human requests, which
| means that humans will always need to be able to describe
| precisely what they want. This has always been the core skill
| for software developers, and I just don't see that changing.
| drivebyhooting wrote:
| Do you believe a junior developer now will never surpass
| you?
|
| Why couldn't AI do the same?
| risyachka wrote:
| It doesn't really matter how good your taste is if you are
| drowning in the ocean of crap.
|
| Customers can't find you
| jrm4 wrote:
| It buried the more important point, one tech hasn't learned yet.
|
| Taste may be kind of important because it helps toward the truly
| important thing, which is skin-in-the-game.
|
| But also, with the right skin-in-the-game, you don't even need
| "taste." You just need real life consequences, which we don't do
| enough in tech.
| ben8bit wrote:
| > A practical loop for training taste
|
| Taste is cheap. Taste (or a rudimentary version of it at least)
| is something you start with at the beginning of your career.
| Taste is the thing that tells you "this is fucking cool", or "I
| don't know why but this just looks right". LLM's are not going to
| replicate that because it's not a human and taste isn't something
| you can make. Now - MAKING something that "looks right" is hard,
| and because LLM's are churning out the middle - the middle is
| moving somewhere else. Just like rich people during the summer.
| LurkandComment wrote:
| Think about moats in long term vs short term:
|
| Speed and distribution aren't a long-run moat because they are
| something AI can canabalize in a platform. Eventually they will
| coexist on your distribution base and offer it at a lower cost
| than you. Its a mote if it holds up before you exit at a high
| valuation... which a lot are setup to do.
|
| Taste: that's interesting. There is an argument there. It's hard
| to keep in the long-run and requires a lot of reinvestment in new
| talent
|
| Proprietary data: Yes, very much so.
|
| Trade Craft: Your new shiney system will still have to adhere to
| methods of of old clunky real world systems. Example, evidence
| for court. Methods for investigations. This is going to be
| industry specific, but you'd be surprised how many there are.
| This is long-term.
|
| Those who have the moat should focus on short burts of meaningful
| changes as they will rely heavily on gaining trust in established
| systems. In those places its more about trusting whats going on
| than doing it faster and better, so you want trust + faster
| and/or better.
| tayo42 wrote:
| > That is why so much AI-generated work feels familiar:
|
| This was already a complaint people had before Ai. Like when
| logos and landing pages all used to look the same. Or coffee
| shops all looking the same.
| SoftTalker wrote:
| Or cars, or apartment buildings, or houses, or....
| boshalfoshal wrote:
| I think "taste" is definitely an overused meme at this point, its
| like tech twitter discovered this word in 2024 and never stopped
| using it (same with "agency", "high leverage", etc).
|
| Having read the article, I think I see the author's argument (*).
| I think "taste" here in an engineering context basically just
| comes down to an innate feeling of what engineering or product
| directions are right or wrong. I think this is different from the
| type of "taste" most people here are talking about, though I'm
| sure product "taste" specifically is somewhat correlated with
| your overall "taste." Engineering "taste" seems more correlated
| with experience building systems and/or strong intuitions about
| the fundamentals. I think this is a little different from the
| totally subjective, "vibes based taste" that you might think of
| in the context of design or art.
|
| Now where I disagree is that
|
| 1. "taste" is a defensible moat
|
| 2. "taste" is "ai-proof" to some extent
|
| "Taste" is only defensible to the extent that knowing what to do
| and cutting off the _right_ cruft is essential to moving faster.
| Moving faster and out executing is the real "moat" there. And
| obviously any cognitive task, including something as nebulous as
| "taste," can in theory be done by a sufficiently good AI. Clarity
| of thought when communicating with AI is, imo, not "taste."
|
| Talking specifically about engineering - the article talks about
| product constraints and tradeoffs. I'd argue that these are
| actually _data_ problems, and once you solve those, tradeoffs and
| solving for constraints go from being a judgement call to being a
| "correct" solution. That is to say, if you provide more
| information to your AI about your business context, the less
| judgement _you_ as the implementer need to give. This thinking is
| in line with what other people here have already said (real moats
| are data, distribution, execution speed).
|
| I think there's something a bit more interesting to say about the
| user empathy part, since it could be difficult for LLMs to truly
| put themselves in users shows when designing some interactive
| surfaces. But I'm sure that can be "solved" too, or at least, it
| can be done with far less human labor than it already takes.
|
| In general though, tech people are some of the least tasteful
| people, so its always funny to see posts like this.
| micromacrofoot wrote:
| taste isn't a moat at all because it's so variable, in fact this
| stuff will start dictating what taste is through broad
| proliferation
|
| you already see it on facebook with all the ai generated meme
| sharing... taste is being eroded there
| johnfn wrote:
| It is profoundly ironic that this article is AI generated.
| paganel wrote:
| Was looking for this comment. How can people still read AI slop
| like this?
| abkolan wrote:
| Looks like the comments on this article are too.
| roncesvalles wrote:
| Roncesvalles' law: Bad posts have bad comments.
| janalsncm wrote:
| Does this imply that good posts do not have bad comments?
| phainopepla2 wrote:
| No
| jdpigeon wrote:
| Seriously. Very Claude-y vibes from this post. I guess the
| value of human effort doesn't extend to writing your own blog
| posts
| Yokohiii wrote:
| He has taste. The LLM knows that and creates a tasteful
| article. /s
| bspammer wrote:
| It's an unbelievable lack of self awareness. I tried to give it
| the benefit of the doubt because surely no one would stoop to
| that level, but 5 paragraphs in and I'm certain it is AI
| written.
| everybodyknows wrote:
| Trying to bring my nose for AI up to standard -- care to share
| what you're smelling? For me it's:
|
| - Short, declarative sentences, stating grandiose yet vague
| claims, in a high school vocabulary: "Taste becomes useful when
| it moves from vibe to diagnosis."
|
| - Absence of references (let alone web links) to real-world
| examples.
|
| - Em-dashes, gone. No semicolons, but 23 full colons. As
| instructed by prompt?
| jdauriemma wrote:
| To that I'd add:
|
| * an abundance of ordered and unordered lists
|
| * paragraphs are <= 3 sentences
|
| * _it's not X, it's Y_: "The goal is not to let AI choose for
| you. The goal is to build a sharper rejection vocabulary."
| "The biggest decisions are not formatting decisions. They are
| directional decisions."
|
| * a lot of <h2> breaking up the prose, if you can call it
| that
|
| * setup statement, then a colon, then a punchline: "AI and
| LLMs have changed one thing very quickly: competent output is
| now cheap."
|
| AI-generated essays are listicles at heart
| janalsncm wrote:
| The "Here's where things get interesting" sentence gave it
| away for me.
|
| The LLM is desperately trying to keep your attention. It
| has been tuned with millions of examples graded by
| contractors. How do you spice up a fairly bland topic?
| Start by telling people that what follows will be
| interesting. Then, bloat a fairly obvious point into
| several sentences so that it is paragraph-shaped.
| BeetleB wrote:
| I almost never use semicolons, and heavily use colons and
| hyphens (AKA em-dashes - not hyphenated words).
|
| TIL I'm an AI :-)
| evdubs wrote:
| There must be a table with three columns and 4-6 rows.
| amiantos wrote:
| I assume the author's first language is not English and they
| are using AI to punch up their English.
| fg137 wrote:
| I don't mind an article with weird but readable grammar, as
| long as typos are checked. At least that's an honest article.
| JSR_FDED wrote:
| Designers and product managers were showing Steve Jobs all the
| fancy things the new app for writing DVDs could do.
|
| Steve Jobs stopped them, drew a square on the whiteboard and said
| "anything the user drags into this square gets written to the
| DVD" - that is taste!
| codemog wrote:
| This cope is insane. Even simple projects generated by Claude are
| riddled with bugs. And there's no way in hell it could generate a
| larger scoped project without a lot of manual human intervention.
| But yea, TODO apps and trivial calculators are effectively
| "solved". Same with leetcode. I guess that's probably the limit
| of many people's imagination these days.
| simianwords wrote:
| I agree with the author and I think this is turning everyone into
| an investor. How I view (financial) investing as a career is that
| it is less manual and more taste oriented. You put your stake in
| the things you feel will work out and taste here just means the
| judgement required to make good calls. A person with good taste
| would have a better idea of capital allocation.
|
| What AI is doing is making all of us investors instead of doers.
| "Doing" is no longer something praiseworthy - what will become
| praiseworthy is how your taste has turned out in hindsight.
|
| I'm seeing this at work. More or less everyone can do tasks well.
| But what's harder now is the more subtle task of taking bets and
| seeing it work over a few months or years.
| elmean wrote:
| > Good Taste the Only Real Moat Left > YC startups are doomed
| abkolan wrote:
| Ever since Rick Rubin has been on his book tour, he has become
| the patron saint of Product Manger Tech Twitter.
| nayuki wrote:
| Reminds me of PG's classic essay, "Taste for Makers" (2002):
| https://paulgraham.com/taste.html
| yawnxyz wrote:
| Good judgment and effort has always been the "real moat" - in
| arts, music, science, food, product...
|
| There's always been ways to "flatten the middle" - by
| outsourcing, by using pre-packaged goods, with
| industrialization...
|
| So yeah we've always loved handcrafted, exquisite things; there's
| never been a "moat" in middle
|
| It doesn't mean you can't make a good living without a moat
| though
| dfxm12 wrote:
| _Taste shows up in three places: What you
| notice What you reject How precisely
| you can explain what feels wrong
|
| _
|
| I think it's just as important, if not more, to be able to
| explain what is right and what you accept. Having a well defined
| acceptance criteria also fits into existing project management
| frameworks. These criteria are generally based on asking users.
| The article mentions, _You do not get a spreadsheet that tells
| you which sentence will make a customer care, which feature is
| worth a month of engineering time, or which design crosses the
| line from polished to forgettable._ And this is why you talk to
| your customers.
| AlexCoventry wrote:
| Try using a coding agent to write an efficient GPU kernel. I
| guess they might get good at it soon, but they definitely aren't
| there yet.
| osti wrote:
| I had a very complex cuda kernel and codex cli managed to
| improve the throughout 20x.
| lostathome wrote:
| I already disagree with the first line: competent output is not
| cheap. At least if defined as a final product.
|
| - Just think about scientific research. Lots of data analysis
| results are not cheap to get.
|
| - Even vibe coding is difficult: you need to think very hard
| about what you want.
|
| What is cheaper now are some building blocks. We just have a new
| definition of building blocks. But putting the blocks is still
| hard.
| roncesvalles wrote:
| >AI and LLMs have changed one thing very quickly: competent
| output is now cheap.
|
| Already wrong.
| periodjet wrote:
| It has been for a while. Hollywood and other outlets didn't need
| AI tools to create abysmal slop.
| drob518 wrote:
| IMO, taste has always been one of the strongest moats because we
| struggle to define what good taste even is. We know it when we
| see it, but other than pointing to examples, we can't really
| describe it in general terms. I still remember a line from Paul
| Graham's Hackers and Painters where he was describing the
| difficulty of hiring software engineers. He says he was talking
| with a colleague after an interview and remarked (I'm
| paraphrasing), "I know he can write code. But does he have
| taste?" Taste is something we all want our colleagues and
| products and services to have, but defining it is really
| difficult. And yes, I fully agree with the writer that it's
| important more than ever in this age of AI where generation is
| cheap.
| heliumtera wrote:
| Article assumed as absolute truth, without explanation, that
| competent systems can be effortlessly implemented.
|
| If one disagrees with that's statement, there is nothing of value
| to extract from this article.
|
| Words are cheap, bullet point are cheap.
| jatins wrote:
| Title: Good Taste the Only Real Moat Left
|
| Followed by an entire AI generated fluff piece
| https://www.pangram.com/history/347cd632-809c-4775-b457-d9bc...
|
| Flagged
| 30minAdayHN wrote:
| I think there is a parallel to what happened to watch market with
| Quartz crisis. The same way Quartz has led to decline of Swiss
| movements, LLMs are going to have a huge effect on developer
| market. I hypothesize that in future there will be a micro
| segment which care about quality, taste, exclusivity etc the same
| way the luxury watch makers found a niche. My perspective is that
| this "taste" or "quality" will not be a moat. Instead, it will be
| a niche where only a small segment would care about it.
|
| (edit: typos)
| mkw5053 wrote:
| Didn't PG write a post about this like a month ago?
| acuozzo wrote:
| > AI and LLMs have changed one thing very quickly: competent
| output is now cheap.
|
| If you're working on something not truly novel, sure.
|
| If you're using LLMs to assist in e.g. Mathematics work on as-
| yet-unproven problems, then this is hardly the case.
|
| Hell, if we just stick to the software domain: Gemini3-DeepThink,
| GPT-5.4pro, and Opus 4.6 perform pretty "meh" writing CUDA C++
| code for Hopper & Blackwell.
|
| And I'm not talking about poorly-spec'd problems. I'm talking
| about mapping straightforward mathematics in annotated
| WolframLanguage files to WGMMA with TMA.
| liuliu wrote:
| I am not sure you set it up right. Did you have a runnable
| WolframLanguage file so it can compare results? Did you give it
| H100 / H200 access to compile and then iterate?
|
| My experience is that once you have these two, it does amazing
| kernel work (Codex-5.4).
| acuozzo wrote:
| > Did you have a runnable WolframLanguage file so it can
| compare results?
|
| Yes.
|
| > Did you give it H100 / H200 access to compile and then
| iterate?
|
| Yes via Lambda.ai. Also, FWIW, I run claude with
| --dangerously-skip-permissions and codex with the equivalent
| flag.
|
| > it does amazing kernel work (Codex-5.4)
|
| Specifically with WGMMA + TMA?
|
| ---
|
| Once TMA gets involved both Claude and Codex spin endlessly
| until they dump TMA for a slower fallback.
|
| I've observed this with Claude-Code having Opus 4.6 reasoning
| set to medium, high, and max; "adaptive thinking" enabled and
| disabled; and I've made sure to max-out thinking tokens.
|
| I've also observed this with Codex GPT-5.4 in addition to
| GPT-5.3-Codex with reasoning efforts from medium to xhigh.
|
| ---
|
| I've also observed this on the web, as mentioned in my OP,
| with GPT-5.4pro (Extended Pro), Gemini3-DeepThink, and Opus
| 4.6.
| liuliu wrote:
| That is informative, thanks! Yes, I observe the same thing
| as the model tends to give up (like you said, "dump TMA for
| a slower fallback") and needs active steering to get good
| results. But it indeed works further than one-shot from
| Chat interface and knows much more about profiling / kernel
| coding than these.
| ux266478 wrote:
| It doesn't have to be anything so extreme as novel work. The
| frontier of models still struggle when faced with moderately
| complex semantics. They've gotten quite good at gluing
| dependencies together, but it was a rather disappointing
| nothingburger watching Claude choke on a large xterm project I
| tried to give him. Spent a month getting absolutely nowhere,
| just building stuff out until it was so broken the codebase had
| to be reset and he'd start over from square 1. We've come a
| long way in _certain_ aspects, but honestly we 're just as far
| away from the silver bullet as we were 3 years ago (for the
| shit I care about). I'm already bundling up for the next
| winter.
| rickcarlino wrote:
| Does anyone remember this quote by Why the Lucky Stiff: "When you
| don't create things, you become defined by your tastes rather
| than ability."
| skejeke wrote:
| lol the unfortunate truth is that hundreds of billions and
| trillions will be spent to learn a single truth: Taste cannot
| simply be bought nor can you bring products that add value into
| the world through sheer will of training machines.
| layer8 wrote:
| I'm sure this can be solved by A/B tasting. ;)
| crabsand wrote:
| The only real moat is care. It was, it is, it will be.
| jryio wrote:
| No one was discussing 'taste' until pg's article.
|
| After a decade with tech people I can confidently say that most
| of them have zero taste because they have little to no exposure
| to the world outside of their bubble.
|
| It's frankly pathetic to see how techno-optimists think that
| innovations like driverless cars will simply be happy pills to be
| swallowed by the masses who make a fractional amount of money to
| them.
|
| As a species we have quite literally killed each other for less.
| xnx wrote:
| Page title is "Good Taste the Only Real Moat Left"
| coolThingsFirst wrote:
| I get very bad results for frontend. The results look boring and
| obviously made by ai.
___________________________________________________________________
(page generated 2026-04-07 23:00 UTC)