Earlier quoted context omitted.
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. Whi…
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 St…
Taste in the age of AI and LLMs
171–180 of 230 posts
Re: Taste in the age of AI and LLMs
#172Re: Taste in the age of AI and LLMs
#173Earlier quoted context omitted.
But you still need effort, its not only taste. "Only" means you can do it with no effort.
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.
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.
Re: Taste in the age of AI and LLMs
#174Re: Taste in the age of AI and LLMs
#175Earlier quoted context omitted.
> I don't think there's perfect code Note I used "perfect" in my text. In this context, meaning it passes human PR reviews following our standard guidelines with minimal feedback/correction required. > So as long as code meets or exceeds the human output, it's "good enough" and meets expectations. That's what a typical customer cares about. Why settle for this when "perfect" is "free"? I understand this dichotomy whe…
> 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 "pe…
> 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").Re: Taste in the age of AI and LLMs
#176Earlier quoted context omitted.
> I don't think there's perfect code Note I used "perfect" in my text. In this context, meaning it passes human PR reviews following our standard guidelines with minimal feedback/correction required. > So as long as code meets or exceeds the human output, it's "good enough" and meets expectations. That's what a typical customer cares about. Why settle for this when "perfect" is "free"? I understand this dichotomy whe…
> 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 "pe…
Re: Taste in the age of AI and LLMs
#177Earlier quoted context omitted.
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 f…
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 deve…
Why couldn’t AI do the same?
Re: Taste in the age of AI and LLMs
#178Re: Taste in the age of AI and LLMs
#179> 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 eng…