Hacker News Reader

Comment by stickfigure | Hacker News Reader

> Fall behind what? Able to produce "as much" what?

Customer meaningful features that move the needle on the business.

I think this is strictly true. And not because LLMs can write code faster. I think it's true even if you're still writing most of your code by hand and using the LLM as an assistant.

My anecdotal but decades-long observation is that most of the time=cost of a project comes not from writing code, but from dealing with "issues". Weird bugs, surprising behaviors, spec ambiguities, library defects, mysterious test failures, etc. Stuff that requires intense debugging and building out a mental map of code that might not even be yours. LLMs excel at this kind of thing, freeing you up to spend most of your time working on business logic.

This has certainly been my experience.

View on HN

I think people are making a bad assumption that features = profit, and that we're going to be trapped in a red-queen race to move in place while shipping features at an astonishing rate. I don't think this is going to happen.

Before subscription services, you needed to add features because you had to justify to people why they should buy an upgrade. So yeah, it made sense to make as many features as possible to try to cast a wide net.

I think with software as a service, making features is not really the most important thing. Realistically, people buy software for what it does right now, not its future potential. Further, changing things out from underneath users tends to annoy them (pretty much EVERY time a service introduces a redesign, even if it's a good one, people initially hate it -- you're asking them to relearn a thing that was working perfectly fine).

Anyway, I think new software is going to win the same way it's always won, based on its utility, not based on shipping features at some sort of frantic rate.

Realistically, has the volume of code that can be produced ever been the bottleneck? In every job I’ve ever had, it was never that the devs couldn’t write enough code fast enough, it was everything else that slowed them down, mostly other people.

7 years ago my biggest bottle-neck was waiting for a tester to test my code. Fast forward to now, my biggest bottle-neck is waiting for a tester, and my team-mates using AI to generate mega-patches that they don't bother testing is just making it worse.

n=1 but every job i've ever been at was time to code was like 10 or 15% of available time; its all the useless meetings/busywork caused by corporate structure and bad specs etc

llm's cant solve your organization issues...

And I am gradually coming to the conclusion that "needle" isn't even features. In a world where everyone has AI access, moving the needle in an existing product space can readily be done by whoever. The real game changers will be those who redefine their market segment entirely rendering existing offering completely out of customer demand. And the only way to migrate the business to the new model from the ground up in say four to six months will only economically be able to be done by AI.

My hobby AI projects feature wise match existing company offerings in about a week of turn around. But this alone is valueless. The new thing that didn't exist before 2026 will remain the hard moat. But these moats will dissolve as fast as OpenAI can scrape your public marketing. It's going to be like releasing Meccha Chameleon as a break out hit but a month later the clones on Roblox having greater player numbers. This is the turn around times we're going to have to live with in general for business pivots to the "next" business logic that makes sense in the market.

Closer to the AI world it's going to be as fast as the transition from prompt engineering and MCPs to loop engineering and harnesses. I'm pretty confident popular commentators will see "loops" as old hat by December by raw function of what speed of evolution we're dealing with here now.

> My hobby AI projects feature wise match existing company offerings in about a week of turn around.

Another thing that LLMs are particularly good at is instilling their users with a false sense of confidence.

> Weird bugs, surprising behaviors, spec ambiguities, library defects, mysterious test failures, etc. Stuff that requires intense debugging and building out a mental map of code that might not even be yours. LLMs excel at this kind of thing

I've noticed that too. And I think it's no surprise we see lots of "728 security exploits found by LLMs in project X" posts.

They excel at what you mention.

I also think that, as of 2026, they suck fat balls at writing code.

And those issues often appears because no one had the "time" to properly design a solution before rushing to code. Saving one hour of planning by spending weeks on debugging.

Reply on news.ycombinator.com