Hacker News Reader

Comment by extr | Hacker News Reader

I like the way you put this. I agree this is where the frontier of software development is right now. You can have LLM chug and bug fix all day long but in the end most real issues are in this layer of intent. I don't think this problem is particular to DB/programming language codebase either - it happens a lot in product design it just doesn't surface in code review. "Everything is working perfectly" yet the resulting workflow or UI is not truly making the user's life easier, or has grown grotesque with additions/modifications.

I will say, if the problem is purely code you occasionally see "sparks of AGI" where the model will step back and say "hold on, there is a massive simplification we can make here...". This started happening with Fable-class models. But rarely if ever will the model push for a huge simplification at the product level.

View on HN

In my experience it's the opposite - the model's design decisions always try to add complexity, even when it's not necessary.

So you get permission flags and multilayered data structured with complex interfaces, and there is never any sense of "Wait a minute - we don't need this."

It's much like the way AI art looks meaninglessly busy with too many random lines or other elements, and AI writing is always exactly, precisely, specifically, unnecessarily adverbial.

>> In my experience it's the opposite - the model's design decisions always try to add complexity, even when it's not necessary.

This happens if the model does not have good context regarding what is being built, why and for whom.

For one of my side projects, my CLAUDE.md has a line that says "the users of this product will be non-technical people who find technology scary." And you know what? Claude always steers me away from complexity when working on that project.

Yes > real issues are in this layer of intent

This is why code is going to be automated, and the software engineer is a link between organizational intent and the code. This is what I’m working on.

How does this differ from what I'm doing today? Want to say any more on the topic? This is a bit vague.

The difference is that instead of spending half your time understanding the business requirements and half your time writing code, you'll spend half your time understanding the business requirements, 5% of your time typing these requirements into a chatbot, and the rest of your time doing... ????

Some of the rest of the time can be spent making it look like your ratios are the same but in reality you just take the saved time and do whatever you want with it. The decision making and reviews aren’t happening any faster anyway so just take it easy and coast a bit

I guarantee there will not actually be saved time - the bullshit will increase to more than compensate, as everyone actually fixing things will be drowned out by bullshitters just pretending to fix things and creating more actual problems.

Design, writing specs: Same amount of time.

Finding the holes in your specs under automation: time spent is returned 10x

Writing code: Human 15 lines per minute. LLM: 600+ lines per minute

Functional Validation: same time per iteration. Fewer bugs with LLM when properly specified => fewer iterations. Increased awareness of LLM escaping specification boundaries feeds back into increasing quality of spec writing => fewer bugs.

Reply on news.ycombinator.com