Comment by CodingJeebus | Hacker News Reader

Comment by CodingJeebus | Hacker News Reader

Parent Full thread

I don't think it's possible either. DHH pointed out in the most recent episode of Rework that AI removes a lot of the barriers to shipping code, therefore making it possible to build in lots of different directions in ways that was prohibitive to many organizations in the past. But this isn't necessarily a good thing, companies still need to understand what to build in order to ship a cohesive product. AI is great for prototyping and refining use cases in ways that are far superior to static figma designs, etc., but it is not a replacement for taste and execution.

But a slop machine that haphazardly shoots features against the wall to see what sticks still isn't a winning product strategy in 2026. And the problem I see increasingly is that so much energy is being focused on how to deliver with AI internally and externally that is not being expended to advance a company's product. I believe more and more in the idea that for many startups and companies, the actual "customers" are the investors and the product-market fit that companies seek is the product of the company itself, because this is all being driven from the top down, not by customers and users in the market asking for AI features.

> I believe more and more in the idea that for many startups and companies, the actual "customers" are the investors and the product-market fit that companies seek is the product of the company itself

In many respects this reflects the growing K-shaped nature of our economy. Average consumers don't matter because you really just need a small cohort of wealthy individuals to be hyper-invested in your product, 'regular' consumption is therefore just a way to keep things relatively on rails rather than the actual economic driver.

All of these AI-first companies don't actually have any market fit, so what they're doing is selling an imaginary product so that they can get investments and loans. As you said the company is the product.

The bottleneck wasn't the coding, but previously it had the second order effect of slowing product development decisions enough to improve product cohesion.

It also created a cargo cult though.

"What can we get rid of for MVP" as a design strategy vs a way to iterate fast, for instance. Cutting things isn't a way to product cohesion, especially if you never go back to do the full-featured version.

Sometimes I wonder how many features or products flopped because the MVP dropped the things that would've actually taken off, and the business "smartly" pivoted away.

There's still a limit to how many new features you could shove in front of your users per month. But what if they were all much more baked out of the gate?

(See also: "data driven" product management as an excuse to not have your own vision for the product. If three competitors build a lot more in the span of six months, but have to depend more on their own skills and instincts vs A/Bing every little detail, maybe more of them will ship more bold and interesting new things.)

the opposite can also be true, feature bloat can destroy products by making it unclear for users what they should expect.

But that's the nature of the beast isnt it? A probabilistic token predictor will all always have some errors from a human perspective, more and more energy, money and resources will always be needed to control and direct towards desired outcomes.

Reply on news.ycombinator.com