Taste in the age of AI and LLMs

> 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.

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.

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 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)