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.
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.
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.
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.
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)
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!
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.
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.
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
Not really. The effort required to produce the same result has declined, but it has been on the decline for many decades already. That is nothing new. Of course, in the real world, nobody wants the same result over and over, so expectations will always expand to consume all of your available effort.
If there is some future where your effort has been replaced, it won't be AI that we're talking about.
Effort is still (and probably will always be) the hardest thing to replace.
Any time someone says AI can do this, and do that, and blah blah. I say ok, take the AI and go do that.. the barrier to entry is so low you should be able to do whatever you want. And they say, oh, no, I don't want to do that (or can't, or whatever). But it should be able to be done.. And I just nod, and sip my drink, and ...
.. and I'd like to point out these are seasoned professionals that I've seen put in effort into other things in their careers that have the capacity to literally do whatever is they want to do, especially now.. and they choose not to do so, at least not without someone guaranteeing them a paycheck or telling them they have to do it to survive.
“ 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.”
Are you doing this altruistically for friends - or as a consultant?
Both a) to help a friend out and b) to help non-technical founders I've meet at some Meetups/AI events to launch their product. My short-term goal is to put together a checklist/cheatsheet for all the technical things someone needs to do to launch a business because it's not just having a webapp running on Vercel with Supabase. And if they do have an app, is it a complete mess or not.
I think the solo-founder hype is an overplayed unless the person has the right skills, and even worked at a tech company, and knows what they're getting into. Alerting and monitoring for example is one of like 30 things they should be aware of.
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.
This is an underrated comment. You could have the best product out there, but AI has not only lowered the effort for competitors but has flooded traditional ways to get your product known, from outbound sales to content marketing. Sometimes make you question whether there are customers anymore.
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.
Jensen Huang said he commands thousands of AGIs but still feels pretty useful.
Founders and CEOs are still needed to set direction, bring unique vision to life, and build relationships for long-term partnerships—-as long as humans still control the economy, that is.
> 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].
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.
> 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.
> 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.
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
Test suites don't verify correctness. They just ensure that you haven't broke something so bad the specific instances that the tests assert have turned into a failure. You can have a factorial function and more likely the test cases will only be a few numbers. Which does not guarantee correctness as someone who know about the test cases can just put a switch and return the correct response for those specific cases.
The compromise is worth it in traditional coding, because someone will care about the implementation. The test cases are more like the canary in the coal mine. A failure warrants investigations but an all green is not a guarantee of success.
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.
> 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.
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.
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.
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?
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?
"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.
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.
"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.
> 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.
> 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".
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.
> 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.
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.
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.
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.
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.
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.
It's not a matter of whether it surpasses me. In some respects it already has - I watch Claude Code spitting out long terminal commands that I've never even seen in my 15 year career.
The question is whether AI will ever become good enough to magically infer information where none is provided.
For instance, I've had this startup idea for an itemized physical storage company. We'll never reach a point where I can simply say "Hey AI, create all the software necessary for an itemized physical storage company". It's not because AI won't continue to improve, it's because there's literally not enough detail in that statement to understand what I mean. It's too vague. I'm sure the AI of tomorrow could do a pretty good job in guessing what I mean by it, but the chance of it capturing my vision is literally 0%.
It might have a better vision than you and pursue that vision instead. Why should the AI wait for your impetus when countless founders and CEOs didn’t?
AI has no intrinsic way to align its efforts to solve human problems. In order to solve that problem, you'd need an enormous amount of nearly real-time data feeding into the model. Then the model would need to routinely look for patterns and identify ways to improve human life in some way. It would make today's models look tiny by comparison.
What we're building today isn't even remotely close to that.
> 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).
> 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).
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.
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.
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.
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...
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.
> ...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.
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).
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.
> 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.
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".
> 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.
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.
> 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.
> 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").
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.
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.
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.
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?
* _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."
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.
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.
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.
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?
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.
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.
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.
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_.)
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.
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?
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.
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.
I mean developing taste is what RLHF was supposed to give you. I don't think it's actually a technical problem so much as a social one. The average person _wants_ slop, they don't want to read new yorker articles, they'd much rather read romcoms. A model trained to produce tasteful writing would almost surely have less engagement from the public (considering that engagement and lmarena-maxing is what led to the characteristic punchy style in the first place)
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.
I don't mind when people want to spend a lot of money on clothing. But I mind when they judge other people for caring less.
(And as a pet peeve, I don't really understand why people can spend so much money on off-the-rack clothing and outfits? If you want to spend a lot of money, perhaps go to a tailor? But hey, it's their money, not mine.)
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.
Thanks for explaining. We don't get much of this 'uniform' here in Singapore. It's too hot for tech people to wear long trousers and long sleeves.
I guess it makes sense of a joke. Though I don't think sense in fashion correlates much with sense in technology: the guy might just be wearing what everyone else is wearing, so that his wife doesn't bug him about it and he can concentrate on the hills he's actually prepared to die on?
I don't think any wife has ever asked for this look :-)
Someone just trying to minimally not-stand-out could do so way cheaper. The high cost is part of the point (for signaling).
The other major standard look is rich-hipster: $300 Japanese jeans ("they bought the actual looms Levi's used in the '50s! It's more authentically Levi's than Levi's is now!"), $350-400 work-, jump-, or motorcycle-pattern leather boots, $150+ shirt probably in some variety of rugged wool. Corduroy or denim trucker's jacket, also with some authenticity-story and expensive. Folks adopting this look are probably a little more self-consciously into fashion than the ones who go the "walk into an REI and buy five outfits, choosing the most expensive option for everything" route.
Turns out you can get more-rational-than-thou "screw fashion" tech dorks to spend just as much money on their cookie-cutter work-uniforms as a first-year investment bank employee in lower Manhattan with their week's-worth of HF or BB suits in sober greys and blues, you just have to take a different approach.
(I am 100% guilty myself of being a sucker for "authenticity" and heritage/old-timey-quality marketing, though I do deliberately try to avoid looking like a walking trope by branching out beyond the categories of clothes like those depicted in the original joke-image; the "standard" looks are very real though, you can spot a lot of US tech workers a mile away by knowing them)
> I don't think any wife has ever asked for this look :-)
The wife wouldn't specifically ask, it's just that she doesn't bug him, when he's wearing something 'normal'. And normal is what everyone else is wearing.
> Someone just trying to minimally not-stand-out could do so way cheaper. The high cost is part of the point (for signaling).
Yes and No. You might have to spend so much just to blend in, depending on where you are. And it might not be all that much money, if you make enough.
Here in Singapore people (thankfully!) tend to dress down a lot. It's a big difference from eg Hong Kong. Flip-flops, shorts and t-shirt seem to be the norm.
I'm indulging a bit by wearing the same, but in wool. Eg from https://woolandprince.com/ but that's mostly because it deals with my copious sweat marginally better than cotton.
Btw, looking like a trope can be beneficial. Eg at tech conference, if you look like a techie you often get better treatment than when you look like some kind of influencer or (low level) manager. In normal life, signalling that you are well-off often gets you good treatment, too.
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.
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.
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.
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...
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".
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.
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.
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.
I'm not sure this is only true of LLMs - most corporate sites are very similar. Professional designers learn very quickly not to be too quirky or unique.
I think this is symptomatic of humans - our comfort zone is the "7 out of 10" morass of similarity and blandness. We are herd animals. LLMs are just reflecting this.
And I don't think our tendency to herd will allow us to select the quirky outliers even if that's the only distinguishing characteristic of non-LLM output.
There's perception of value in the quirky outliers, and there's liking a trendy cow, in the herd-mindset signaling kind of way. We definitely have both style of aficionados, each could be said to be appreciating a different kind of taste.
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.
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.
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.
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.
Hmm, I still have some nonrefundable API credits with OpenAI. Maybe I should try to use them for my kernel.
FWIW, this talk[1] from NVIDIA/Meta from March claims that coding agents can often write correct implementations of of CUDA kernels, but that they're usually dog slow, like 100x slower than a kernel optimized by a skilled human.
For me it was able to try out different architectures for perf improvement, then once it's settled on some good architectures, it can do lower level optimizations on them by profiling the code etc.
I get really skeptical when someone says "AI does most of the work just by asking simple prompts."
Don't get me wrong, I use AI too for daily tasks and my job as a programmer, and it definitely helps me get the job done faster (sometimes it's almost instant).
But it still requires a lot of effort for complex or unconventional tasks.
When I hear "AI does most of my job", I think of DOGE employees who use AI to identify "waste of money".
All they do is ask AI with very lazy prompts like "list DEI projects" with the list of government sponsored projects including simple descriptions.
They don't even provide what DEI means.
And they just cut all projects the AI flagged.
I'm sure their "productivity" is very high.
They can "complete the job" that would require days, weeks, or months of investigation with a single prompt.
I also think the results have a strong tendency to flag a project as DEI, because "is this DEI" is a question often asked by racists and misogynists on right-wing websites, and often the answers are "Yes", and that likely causes a strong bias.
> 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.
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).
> 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.
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.
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.
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.
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.
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.'"
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.
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.
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.
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.
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.
Don’t feel bad — most people honestly have no idea what designers really do, and I think developers’ proximity to them instills false confidence in their understanding of it. (I worked in both fields for years, and am also a graphic artist.)
A great example of this understanding gap is people thinking interior designers choose color schemes, sconces, and throw pillows. That is an interior decorator—- someone who’s professionally tasteful. An interior designer has an architecture license and designs the inside of buildings, often including everything from where fire exits are, where utility lines flow, what floors everything is on, and even things like wayfinding signage.
Even the most visual practical design is often more about visual hierarchy, semiotics, using gestalt to convey informational relationships, and conceptual thinking than taste.
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.
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.
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.
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.
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.
But you still need effort, its not only taste. "Only" means you can do it with no effort.
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)
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!
Thinking might even be more difficult: Unfiltered thoughts, intrusive thoughts, people with no inner voice to encode as text...
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.
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.
Could I even remember 1000 versions of a thing and still distinctly know which one is which?
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
That deciding between 1000 things is a lot of effort is so clear that I must wonder if the one you’re responding to was being ironic.
> Effort is what is being replaced here
Not really. The effort required to produce the same result has declined, but it has been on the decline for many decades already. That is nothing new. Of course, in the real world, nobody wants the same result over and over, so expectations will always expand to consume all of your available effort.
If there is some future where your effort has been replaced, it won't be AI that we're talking about.
Effort is still (and probably will always be) the hardest thing to replace.
Any time someone says AI can do this, and do that, and blah blah. I say ok, take the AI and go do that.. the barrier to entry is so low you should be able to do whatever you want. And they say, oh, no, I don't want to do that (or can't, or whatever). But it should be able to be done.. And I just nod, and sip my drink, and ...
.. and I'd like to point out these are seasoned professionals that I've seen put in effort into other things in their careers that have the capacity to literally do whatever is they want to do, especially now.. and they choose not to do so, at least not without someone guaranteeing them a paycheck or telling them they have to do it to survive.
“ 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.”
Are you doing this altruistically for friends - or as a consultant?
Both a) to help a friend out and b) to help non-technical founders I've meet at some Meetups/AI events to launch their product. My short-term goal is to put together a checklist/cheatsheet for all the technical things someone needs to do to launch a business because it's not just having a webapp running on Vercel with Supabase. And if they do have an app, is it a complete mess or not.
I think the solo-founder hype is an overplayed unless the person has the right skills, and even worked at a tech company, and knows what they're getting into. Alerting and monitoring for example is one of like 30 things they should be aware of.
> 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.
It doesn’t really matter how good your taste is if you are drowning in the ocean of crap.
Customers can’t find you
This is an underrated comment. You could have the best product out there, but AI has not only lowered the effort for competitors but has flooded traditional ways to get your product known, from outbound sales to content marketing. Sometimes make you question whether there are customers anymore.
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.
> 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.
Jensen Huang said he commands thousands of AGIs but still feels pretty useful.
Founders and CEOs are still needed to set direction, bring unique vision to life, and build relationships for long-term partnerships—-as long as humans still control the economy, that is.
> 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...
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.
> 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.
Yep, for sure. Restarting is the right choice IMO, it's way easier than trying to untangle from a previous iteration.
> 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.
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
Test suites don't verify correctness. They just ensure that you haven't broke something so bad the specific instances that the tests assert have turned into a failure. You can have a factorial function and more likely the test cases will only be a few numbers. Which does not guarantee correctness as someone who know about the test cases can just put a switch and return the correct response for those specific cases.
The compromise is worth it in traditional coding, because someone will care about the implementation. The test cases are more like the canary in the coal mine. A failure warrants investigations but an all green is not a guarantee of success.
Regardless that is why most people are moving faster than writing by hand
Moving faster towards what? The biggest diff? The most tickets closed? Or a working software?
Working software/new features.
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
> 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.
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.
> 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.
> 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.
Yeah. The UI will still be there, but it'll be a guy.
A little guy who lives in your phone and who's really good at APIs. (And, by that point, hopefully good at keeping track of things, too!)
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?
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?
"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.
Can infinite monkeys produce Shakespeare?
It was the best of times. It was the blurst of times.
That approach leads you to products like instagram.
> ... 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.
"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.
> 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.
> 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".
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.
> 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.
> 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.
> 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.
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.
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.
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.
Do you believe a junior developer now will never surpass you?
Why couldn’t AI do the same?
It's not a matter of whether it surpasses me. In some respects it already has - I watch Claude Code spitting out long terminal commands that I've never even seen in my 15 year career.
The question is whether AI will ever become good enough to magically infer information where none is provided.
For instance, I've had this startup idea for an itemized physical storage company. We'll never reach a point where I can simply say "Hey AI, create all the software necessary for an itemized physical storage company". It's not because AI won't continue to improve, it's because there's literally not enough detail in that statement to understand what I mean. It's too vague. I'm sure the AI of tomorrow could do a pretty good job in guessing what I mean by it, but the chance of it capturing my vision is literally 0%.
It might have a better vision than you and pursue that vision instead. Why should the AI wait for your impetus when countless founders and CEOs didn’t?
AI has no intrinsic way to align its efforts to solve human problems. In order to solve that problem, you'd need an enormous amount of nearly real-time data feeding into the model. Then the model would need to routinely look for patterns and identify ways to improve human life in some way. It would make today's models look tiny by comparison.
What we're building today isn't even remotely close to that.
> 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
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).
> 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).
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.
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.
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.
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...
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.
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.
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.
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).
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.
> 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
Not really the case; you're misunderstanding the term second system effect.
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".
> 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.
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.
> 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.
[flagged]
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.
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.
[flagged]
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.
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
I got to the second section before I decided to scan how long it was, saw a wall of text, and decided that this article was low taste.
Moreover, the submitter of this article (probably not the author) spams ~4 submissions per day.
Every fucking time.
I hate this timeline.
It is profoundly ironic that this article is AI generated.
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?
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
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.
I don't think any human would make that table in the middle
I almost never use semicolons, and heavily use colons and hyphens (AKA em-dashes - not hyphenated words).
TIL I'm an AI :-)
There must be a table with three columns and 4-6 rows.
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.
Seriously. Very Claude-y vibes from this post. I guess the value of human effort doesn’t extend to writing your own blog posts
Looks like the comments on this article are too.
Roncesvalles' law: Bad posts have bad comments.
Does this imply that good posts do not have bad comments?
It's more about the average quality of comments.
No
I assume the author's first language is not English and they are using AI to punch up their English.
I don't mind an article with weird but readable grammar, as long as typos are checked. At least that's an honest article.
Was looking for this comment. How can people still read AI slop like this?
He has taste. The LLM knows that and creates a tasteful article. /s
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)
Didn't PG write a post about this like a month ago?
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?
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.
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.
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.
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_.)
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.
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?
At least in part because some of Taste is fashion.
Isn't part of fashion trends? AI is good at recognizing trends.
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.
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.
most (all?) models are fundamentally a regression toward the mean. Good taste is rarely, if ever, residing in the mean.
I mean developing taste is what RLHF was supposed to give you. I don't think it's actually a technical problem so much as a social one. The average person _wants_ slop, they don't want to read new yorker articles, they'd much rather read romcoms. A model trained to produce tasteful writing would almost surely have less engagement from the public (considering that engagement and lmarena-maxing is what led to the characteristic punchy style in the first place)
https://x.com/netcapgirl/status/2024140332963705342?s=46
evergreen.
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.
I don't mind when people want to spend a lot of money on clothing. But I mind when they judge other people for caring less.
(And as a pet peeve, I don't really understand why people can spend so much money on off-the-rack clothing and outfits? If you want to spend a lot of money, perhaps go to a tailor? But hey, it's their money, not mine.)
usually when you call something "evergreen" it's not 2 months old
I think it's just an internet trope at this moment.
[dead]
Is the joke that the guy is drinking bad coffee?
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.
Agree but arcteryx is from vancouver
Gah, you're right of course. I was thinking of Fjällräven in particular (not that that's the only one) and got it mixed up.
The original article was written by an LLM.
Thanks for explaining. We don't get much of this 'uniform' here in Singapore. It's too hot for tech people to wear long trousers and long sleeves.
I guess it makes sense of a joke. Though I don't think sense in fashion correlates much with sense in technology: the guy might just be wearing what everyone else is wearing, so that his wife doesn't bug him about it and he can concentrate on the hills he's actually prepared to die on?
I don't think any wife has ever asked for this look :-)
Someone just trying to minimally not-stand-out could do so way cheaper. The high cost is part of the point (for signaling).
The other major standard look is rich-hipster: $300 Japanese jeans ("they bought the actual looms Levi's used in the '50s! It's more authentically Levi's than Levi's is now!"), $350-400 work-, jump-, or motorcycle-pattern leather boots, $150+ shirt probably in some variety of rugged wool. Corduroy or denim trucker's jacket, also with some authenticity-story and expensive. Folks adopting this look are probably a little more self-consciously into fashion than the ones who go the "walk into an REI and buy five outfits, choosing the most expensive option for everything" route.
Turns out you can get more-rational-than-thou "screw fashion" tech dorks to spend just as much money on their cookie-cutter work-uniforms as a first-year investment bank employee in lower Manhattan with their week's-worth of HF or BB suits in sober greys and blues, you just have to take a different approach.
(I am 100% guilty myself of being a sucker for "authenticity" and heritage/old-timey-quality marketing, though I do deliberately try to avoid looking like a walking trope by branching out beyond the categories of clothes like those depicted in the original joke-image; the "standard" looks are very real though, you can spot a lot of US tech workers a mile away by knowing them)
> I don't think any wife has ever asked for this look :-)
The wife wouldn't specifically ask, it's just that she doesn't bug him, when he's wearing something 'normal'. And normal is what everyone else is wearing.
> Someone just trying to minimally not-stand-out could do so way cheaper. The high cost is part of the point (for signaling).
Yes and No. You might have to spend so much just to blend in, depending on where you are. And it might not be all that much money, if you make enough.
Here in Singapore people (thankfully!) tend to dress down a lot. It's a big difference from eg Hong Kong. Flip-flops, shorts and t-shirt seem to be the norm.
I'm indulging a bit by wearing the same, but in wool. Eg from https://woolandprince.com/ but that's mostly because it deals with my copious sweat marginally better than cotton.
Btw, looking like a trope can be beneficial. Eg at tech conference, if you look like a techie you often get better treatment than when you look like some kind of influencer or (low level) manager. In normal life, signalling that you are well-off often gets you good treatment, too.
What's an REI?
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.
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.
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.
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.
Sounds like I’d better run out and buy an Arcteryx vest.
I was expecting a circa 1993 rambling essay, pal.
What's evergreen about it?
It's an Americanism that means 'it's always green' or 'always relevant'.
[dead]
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.
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...
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".
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
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.
Ever since Rick Rubin has been on his book tour, he has become the patron saint of Product Manger Tech Twitter.
Related: https://blog.kinglycrow.com/no-skill-no-taste/
Discussion: https://news.ycombinator.com/item?id=47089907
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.
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.
Not only is the article AI generated, it's recycling a shallow pov that hundreds of other people are just copying.
Just google "taste is the new moat"
Doesn't deserve to be on the front page.
Taste shows up in three places:
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.
I'm not sure this is only true of LLMs - most corporate sites are very similar. Professional designers learn very quickly not to be too quirky or unique.
I think this is symptomatic of humans - our comfort zone is the "7 out of 10" morass of similarity and blandness. We are herd animals. LLMs are just reflecting this.
And I don't think our tendency to herd will allow us to select the quirky outliers even if that's the only distinguishing characteristic of non-LLM output.
There's perception of value in the quirky outliers, and there's liking a trendy cow, in the herd-mindset signaling kind of way. We definitely have both style of aficionados, each could be said to be appreciating a different kind of taste.
> Good Taste the Only Real Moat Left > YC startups are doomed
This is a great point. I'm really concerned about it. Most people seem to have poor taste and like what is most generic because generic is familiar.
And if anybody knows about good taste, it's techies, right?
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.
[dead]
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.”
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.
Ah, Steve Jobs vs Bill Gates. Designer vs 41 shades of blue. This is nothing new. There's space for everybody.
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!
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.
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.
>AI and LLMs have changed one thing very quickly: competent output is now cheap.
Already wrong.
Reminds me of PG's classic essay, "Taste for Makers" (2002): https://paulgraham.com/taste.html
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.
> 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.
Or cars, or apartment buildings, or houses, or....
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.
Rick Rubin said it best.
https://youtu.be/jg1WUOxY6Cg?si=0ajVvgKnyuSz0e2Y
no share Id link: https://youtu.be/jg1WUOxY6Cg
I'm sure this can be solved by A/B tasting. ;)
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.
I had a very complex cuda kernel and codex cli managed to improve the throughout 20x.
Hmm, I still have some nonrefundable API credits with OpenAI. Maybe I should try to use them for my kernel.
FWIW, this talk[1] from NVIDIA/Meta from March claims that coding agents can often write correct implementations of of CUDA kernels, but that they're usually dog slow, like 100x slower than a kernel optimized by a skilled human.
[1] https://www.nvidia.com/en-us/on-demand/session/gtc26-s81653/
For me it was able to try out different architectures for perf improvement, then once it's settled on some good architectures, it can do lower level optimizations on them by profiling the code etc.
I get really skeptical when someone says "AI does most of the work just by asking simple prompts."
Don't get me wrong, I use AI too for daily tasks and my job as a programmer, and it definitely helps me get the job done faster (sometimes it's almost instant). But it still requires a lot of effort for complex or unconventional tasks.
When I hear "AI does most of my job", I think of DOGE employees who use AI to identify "waste of money". All they do is ask AI with very lazy prompts like "list DEI projects" with the list of government sponsored projects including simple descriptions. They don't even provide what DEI means. And they just cut all projects the AI flagged. I'm sure their "productivity" is very high. They can "complete the job" that would require days, weeks, or months of investigation with a single prompt.
I also think the results have a strong tendency to flag a project as DEI, because "is this DEI" is a question often asked by racists and misogynists on right-wing websites, and often the answers are "Yes", and that likely causes a strong bias.
[1] https://www.9news.com/article/news/politics/doge-chatgpt-dei...
worse is better wins again.
there's a reason people prefer aged products - they gain a character of their own, similar to art or works produced under constraints.
I get very bad results for frontend. The results look boring and obviously made by ai.
> 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.
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).
> 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.
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.
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.
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
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.
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".
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.
Page title is "Good Taste the Only Real Moat Left"
The only real moat is care. It was, it is, it will be.
Extremely ironic piece of slop.
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.
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.'"
The rest of that is also still gold https://www.youtube.com/watch?v=tHEOGrkhDp0
Yeah I feel like we’re getting pranked here
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.
Indeed, no taste.
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.
> 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.
Taste comes from childhood imo. It is not something that magically appears in adulthood.
It was always there, albeit laying dormant until one does something that requires it.
I would... actually maybe agree with this. I'm not certain it can be taught!
I dont buy the authors argument. Not much has changed imo. Mediocre slop has always been the easiest thing to generate.
The new world order is what not to build...
It has been for a while. Hollywood and other outlets didn’t need AI tools to create abysmal slop.
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.
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
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.
[flagged]
Don’t feel bad — most people honestly have no idea what designers really do, and I think developers’ proximity to them instills false confidence in their understanding of it. (I worked in both fields for years, and am also a graphic artist.)
A great example of this understanding gap is people thinking interior designers choose color schemes, sconces, and throw pillows. That is an interior decorator—- someone who’s professionally tasteful. An interior designer has an architecture license and designs the inside of buildings, often including everything from where fire exits are, where utility lines flow, what floors everything is on, and even things like wayfinding signage.
Even the most visual practical design is often more about visual hierarchy, semiotics, using gestalt to convey informational relationships, and conceptual thinking than taste.
Edit: Not sure why your comment was flagged?!
The job isn't about visual judgement, but composition. Judgement/taste is the responsibility of directors and executives.
I maintain the opinion that courage is the only moat and always will be
Courage with consequences, yes.
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.
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.
[flagged]