Live data from Hacker News

Eight Myths on Software Engineering and GenAI

queue.acm.org

91–100 of 269 posts

Re: Eight Myths on Software Engineering and GenAI

#91

>On my visits to the Bay Area, I would ask AI researchers or interns why they are doing their current research or projects, when in a year or three agentic LLMs could probably do them; This is such a weird point to make that doesn't become correct just because everyone makes it, all the time. Why clean the ocean if some magic future tech will clean them? Why save the world now if some benevolent AI is 'just around th…

It reminds me of Richard Hamming’s notorious question. I like the summary at https://bestjelly.substack.com/p/hamming-questions (which starts out with a quote from another site):

> > Mathematician Richard Hamming used to ask scientists in other fields "What are the most important problems in your field?" partly so he could troll them by asking "Why aren't you working on them?" and partly because getting asked this question is really useful for focusing people's attention on what matters.

> I imagine someone being asked this question, and how they should respond. I think like so - ‘Fuck off Richard’.

> This is partly because I imagine this question being asked in a kind of snarky, gotcha kind of way, with some sort of nerdy superiority. Like ‘ha your behaviour is inconsistent with your implied preferences, you idiot, do you even von Neumann–Morgenstern?’

Re: Eight Myths on Software Engineering and GenAI

#92

Earlier quoted context omitted.

In some number of cases, the business partner who would have passed you the requirements will just generate the code themselves.. I’m shocked shin some engineers don’t see a massive disruption coming..

Oh, some of us see a massive disruption coming, just maybe not in the way you think. Talented, experienced devs leaving the field out of disgust would be pretty disruptive. Crumbling, faulty technical infrastructure with unmanageable heaps of AI slop that no one understands would definitely disrupt businesses. Skill atrophy, and an entire generation of "developers" that have never actually written code will be disrup…

> Crumbling, faulty technical infrastructure with unmanageable heaps of AI slop that no one understands

Replace "AI slop" with "legacy code", and you've got basically any large enterprise today.

The timescales are different though: it takes years if not decades to accumulate classic legacy cruft, while LLMs can spew up huge amounts of incomprehensible spaghetti in seconds.

Re: Eight Myths on Software Engineering and GenAI

#93
post #55

Earlier quoted context omitted.

I felt the same and why didn’t the authors look over METR’s recent material? https://metr.org/blog/2026-05-11-ai-usage-survey/

The whole point of the 2025 one is that they found the self-reporting to be significantly inflated, which is why self-reported surveys like this one are hard to trust.

Yes, but their newer write-up discusses that (and shows that the self-reported numbers have gone up radically, in a way that suggests that even if there is some inflation, the numbers are almost certainly positive if you deflate).

They also have an update -- linked from the original study! -- explaining that it's out of date and no longer reliable, and explaining why they had to cancel a follow-up study because it was understating productivity gains (but also was showing wins for the people who carried over from their previous study): https://metr.org/blog/2026-02-24-uplift-update/

The authors of this paper decided to ignore all of METR's follow-up data and discussion, and to report only the ancient number from early 2025 (a time when Windsurf was state of the art). And then, rather than apologizing for it, and caveating it as a number not to be taken seriously, they described it as a study done "recently."

That's either shockingly dishonest or incredibly out-of-touch.

Re: Eight Myths on Software Engineering and GenAI

#94
Some experience from my work:

- In biz development, a dev usually spends 30-40% time on coding, and more time on requirement discussion, integration testing (especially when the tests involves mobilephone or car)

- coding time can be reduced to 30%, which means reduce 20%-30% time of the full pipeline

- meanwhile, every phase and role is using LLM now, for example, product manager can produce longer requirement doc easily (we can use LLM to read it anyway:) Meeting sometimes is more than before, because more document output leads to more reading and discussion.

- I hope to find new ways to express biz requirements, in a more efficient and automatic manner.

- Shorten the requirement-dev-test-deploy loop is very important. OUTPUT is not OUTCOME. It is equal when we can see the final result, instead of intermediate metric.

- Agentic infra is extremely useful, or every one will find a way to access the database, report and ops system, in some weird fragile method.

Re: Eight Myths on Software Engineering and GenAI

#95

Earlier quoted context omitted.

> That meeting that you spent an hour in to understand the requirements? You don't need that meeting if you're not writing the code. How are you going to prompt the LLM or validate its output if you don't understand the requirements?

In some number of cases, the business partner who would have passed you the requirements will just generate the code themselves.. I’m shocked shin some engineers don’t see a massive disruption coming..

Sure, but why doesn't said business partner just give a requirement to the AI to do the business partner's own job? Since it is hypothetically superhuman at fulfilling requirements at such a point...

PMs seem pretty easy to replace. In fact, given any single role to fixate on, it's probably replaceable

Re: Eight Myths on Software Engineering and GenAI

#97
post #44

Like many others in the comments, I feel there are a lot of assumptions in this piece. Before, coding is only 14% therefore, small slice. I think that's a very superficial assumption. That was because coding was expensive and we needed to be sure we didn't code the wrong thing. If code is as cheap as it is now, we will optimize differently, we will structure around it. Instead of so many meetings we will code 5 diffe…

> That was because coding was expensive and we needed to be sure we didn't code the wrong thing. Coding has never been expensive as it is nothing more than a reification of a solution to a problem as it is understood at that time. It is the underlying understanding of the problem which has always been expensive and remains so.

Coding was expensive in the sense that once you decided what to do, it took a few engineers months / years to do moderately complex projects. That's not true anymore. Therefore the risk of "coding the wrong thing" is less.

Re: Eight Myths on Software Engineering and GenAI

#99
post #54

Earlier quoted context omitted.

Okay. Show me the evidence that AI has an impact on productivity when doing design work. Or reducing meeting load. My own experience is that AI doesn't tighten the design cycle, and in fact might extend it by encouraging gold plating.

> Or reducing meeting load. Well, I expect when you've vibed too much and lost track of the code, and can't answer questions in meetings anymore, you'll stop getting invited to them.

How often do you talk about low code details in the meetings? It is mostly about requirements and goals (IMHO) and "architecture"/design, and now I wouldn't even bother my peers with questions about the code as I can let AI tell me how things work exactly as written in the code, not some thing that someone remembers or thinks how it works (in large codebases, most developers only know in detail the things they are working on currently or from recent history)

Re: Eight Myths on Software Engineering and GenAI

#100
post #44

Like many others in the comments, I feel there are a lot of assumptions in this piece. Before, coding is only 14% therefore, small slice. I think that's a very superficial assumption. That was because coding was expensive and we needed to be sure we didn't code the wrong thing. If code is as cheap as it is now, we will optimize differently, we will structure around it. Instead of so many meetings we will code 5 diffe…

So you're suggesting that coding will take more of the PRD phase?

Basically yes, there will be more coding in that phase, more prototyping, the PRD phases will be shorter too, there will be more pressure to deliver quickly and the PRDs will be under more pressure to move more quickly. This is what I'm already seeing to be honest.
Post reply on HN