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.
Followed by an entire AI generated fluff piece https://www.pangram.com/history/347cd632-809c-4775-b457-d9bc...
Flagged
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.
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
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.
- 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.
Already wrong.
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.
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!
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.
If one disagrees with that's statement, there is nothing of value to extract from this article.
Words are cheap, bullet point are cheap.
What you notice
What you reject
How precisely you can explain what feels wrongI 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.
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.
you already see it on facebook with all the ai generated meme sharing... taste is being eroded there
> 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.
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).
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.
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.
Distribution, Data (Proprietary) and Iteration Speed.
Very successful companies have all three: Stripe, Meta, Google, Amazon.
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.
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.
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.
My experience is that once you have these two, it does amazing kernel work (Codex-5.4).
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".
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.
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.
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.
Data and iteration speed aren't moats. I don't know what you mean by "distribution".
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.
Now, figuring out those words? That's the hard part.
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.
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...
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
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.
I think this goes against what a lot of developers want AI to be (not me, to be clear).
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.
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.
“Bangers” being roughly equivalent to garbage mass marketed radio pop? Or “We are Charlie Kirk” lol
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".
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.
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.
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.
> 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)
Suggest that you re-read what Brooks meant by "second system effect".
- 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?
> 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.
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.
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.
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.
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.
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.
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.
So its ironic that these same people are talking about "taste" when they ostensibly have very little.
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.
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 mean, some of those people undoubtedly like Rush ... make of that what you will.
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.
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.
Apr 3, 2026
AI and LLMs have changed one thing very quickly: competent output is now cheap.
A landing page can be generated in minutes. A product memo can appear in a single prompt. A pitch deck can look polished before anyone has done the hard work of deciding what the company actually believes.
That is why taste has become a serious topic in tech. When everyone can produce something that looks decent, the advantage shifts to judgment. The people who stand out are no longer just the ones who can produce. They are the ones who can tell what is generic, what is true, and what is worth pushing further.
But there is a second point that matters just as much: taste is not the final answer. If humans reduce themselves to selecting from AI outputs, they risk becoming reviewers of a machine-led process instead of builders with real stakes in the outcome.
The real opportunity in the age of AI and LLMs is not to become a better selector. It is to combine taste with context, constraints, and the willingness to build something that could not have emerged from the average alone.
In this context, taste is not about luxury, status, or personal aesthetic branding. It is about distinction under uncertainty.
Most meaningful work does not come with perfect data. 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. You still have to decide.
Taste shows up in three places:
That last part matters more than it first appears. Many people can say, "this feels off." Far fewer can say, "this fails because it sounds like every other SaaS product," or "this explanation collapses a regulatory constraint into marketing language and will confuse the customer."
Taste becomes useful when it moves from vibe to diagnosis.
LLMs are extraordinary pattern-compression engines. They absorb huge volumes of language, design patterns, and interfaces, then recombine them at speed. That is their strength. It is also their default bias.
By design, these systems are much better at producing statistically plausible output than at originating something deeply specific to your exact context. Left alone, they tend toward the safe center of the distribution.
That is why so much AI-generated work feels familiar:
This is not a failure in the catastrophic sense. It is a success at average. The problem is that average used to be hard enough that it still created some separation. Now it is abundant.
The result is a crowded 7 out of 10 world. The middle is full.
Before AI, mediocre work often reflected a lack of time, resources, or execution skill. Today mediocre work often means something else: the person stopped at the first acceptable draft.
That is the economic shift AI introduces. It compresses the cost of first drafts, which means the value moves downstream.
The scarce part is now the ability to say:
In other words, the scarce skill is not generation. It is refusal.
One of the most useful things about AI is also one of the most humbling: it reveals how clear your own judgment actually is.
Ask an LLM to produce ten versions of a homepage hero, onboarding flow, support email, or product pitch. You will usually see a pattern:
The interesting question is not, "Which one should I pick?" It is, "Why are most of these still wrong?"
Your answer to that question is the quality of your taste.
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.
A practical way to think about it is this:
| Layer | AI and LLMs do well | Humans still need to do |
|---|---|---|
| Generation | Produce many plausible variations quickly | Decide which direction matters |
| Pattern matching | Recombine common structures and phrasing | Spot what is too generic for this situation |
| Optimization | Improve toward a stated target | Decide whether the target itself is right |
| Scaling | Turn one idea into many assets | Carry the real context, stakes, and consequences |
The system can generate options. It cannot supply ownership.
Taste improves through repeated exposure, critique, and shipping. AI can accelerate that loop if you use it correctly.
A simple method looks like this:
The goal is not to let AI choose for you. The goal is to build a sharper rejection vocabulary.
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.
This is where the conversation gets more interesting.
There is a strong version of the "taste matters" argument that quietly pushes humans into a narrow role. In that version, AI generates many outputs and the human stands at the end of the pipeline selecting the best one.
That is a useful role, but it is also too small.
Historically, important work did not emerge from detached selection alone. It emerged from co-creation under constraint. Builders argued with reality, with collaborators, with budgets, with materials, with timelines, and with the consequences of getting things wrong.
That friction matters. It is where depth comes from.
Once you see that, the risk becomes clearer: if human value is reduced to curation, the human becomes a discriminator in a mostly machine-driven loop.
The analogy to machine learning is imperfect but useful. In generative adversarial setups, the discriminator exists to help the generator improve. Once the generator is good enough, the discriminator is not the part that ships.
The warning is not that taste has no value. It does. The warning is that taste without authorship, stake, or construction can become a narrow and eventually fragile role.
AI can generate. It can recombine. It can optimize against prompts. What it cannot own in the human sense are the parts of work that carry real consequence.
Three examples matter:
Real products operate under consequences that do not fit neatly inside a prompt. Trust, regulatory exposure, outage risk, team capacity, customer confusion, brand damage, and on-call pain all live here.
A model can suggest copy for a payments feature. It cannot hold responsibility when that copy obscures a regulatory limitation and support tickets spike.
Genuinely new ideas often look wrong at first because they do not resemble the training set. They feel awkward, incomplete, or suspiciously non-standard.
Humans can sit with that discomfort. They can protect something early and fragile long enough for it to become legible.
The biggest decisions are not formatting decisions. They are directional decisions.
What problem is worth solving? What trade-off is acceptable? What kind of company, product, or writing do you want to be responsible for? What do you refuse to optimize for?
These are not post-processing tasks. They are authorship.
This conversation matters beyond any single market because the temptation is now universal: settle for competent surface area and mistake that for meaningful work.
The tools are widely accessible. Small teams and solo builders can now ship what previously required much larger organizations.
That is the good news.
The risk is that teams everywhere start using AI to produce products that are globally polished but contextually shallow. A fintech interface can sound sophisticated while still failing to explain timing, settlement behavior, or support expectations clearly. A B2B SaaS site can look world-class while saying almost nothing a real buyer would recognize as grounded. A devtool can have excellent marketing language and still ignore the practical pains of understaffed teams dealing with on-call load, compliance pressure, and cost constraints.
AI makes it easier to sound sophisticated. It does not make it easier to be specific.
That specificity is where the advantage is.
For builders, taste should mean moving closer to real context, not farther away from it. That includes:
What the market does not need is more competent clones. It needs builders who can use AI speed without surrendering the specifics that make a product trustworthy and useful.
If the bad use of AI is passive selection, the better use is active shaping.
That looks like:
A useful question to ask whenever AI output feels polished but hollow is:
What am I adding here that the model could not have added on its own?
Good answers include:
If you cannot name that addition, you may still be in consumption mode.
The most useful conclusion is also the least glamorous. Taste is not a separate identity. It is a side-effect of paying close attention to reality.
It grows when you:
AI and LLMs make the first draft cheap. They do not make judgment automatic. They do not remove the need for ownership. They do not replace the work of choosing what should exist in the first place.
That is why taste matters more now.
It is also why taste, by itself, is not enough.
The real edge in the age of AI is not having better vibes than the model. It is using the model to strip away average output faster, then applying human judgment where it matters most: direction, specificity, consequence, and the courage to build something that could not have emerged from the statistical middle alone.
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.
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...
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
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.