When you actually talk to people about what they do there are often many, many nuances, micro-events, micro-decisions and micro-actions in their work. This is why it can take days/weeks/months to completely train a new person for a job.

This level of detail is barely documented - anywhere. There is a huge amount of information buried in workflows that AI has barely had access to for training. A lot of this is more in the realm of world models, rather than LLMs.

So imagine trying to use AI to improve these workflows it knows so little about. Then imagine AI trying to reinvent them across an organization.

We find these use cases where AI provides great value - totally true - but these barely scratch the surface of what goes on.

Rather than converging on optimal code (Occam's Razor for both maintainability and performance) they are just spewing code all over the scene. I've noticed that myself, of course, but this technique helps to magnify and highlight the problem areas.

It makes you wonder how much training material was/is available for code optimization relative to training material for just coding to meet functional requirements. And therefore, what's the relative weight of optimizing code baked into the LLMs.

uhhh, not sure even the best people or teams are very good at this either. Condemning AI for not being capable of something we're not capable of, ok...

“If it takes longer to explain to the system all the things you want to do and all the details of what you want to do, then all you have is just programming by another name.”

This is called the specification process, which hopefully is already occurring today.

There's so much self-serving bias in articles like this, as well as the comments on HN, Reddit, etc. It's good to critique AI, but that self-serving line is frequently crossed by many people.

haha, well said, I've got to remember that one. HN is a smelly place when it comes to AI coping.

Side note of interest, from Wikipedia: "Flying Machines Which Do Not Fly" is an editorial published in the New York Times on October 9, 1903. The article incorrectly predicted it would take one to ten million years for humanity to develop an operating flying machine.

A chunk of the objections indicate people trying to shoehorn in their old way of thinking and working.

I think you have to experiment and develop some new approaches to remove the friction and get the benefit.

This subject always reminds me of something someone said, possibly Professor Alain April, "software is the only system where maintenance tends to degrade it."

But - why is the most important information, the title, in such a light, hard to read, font? The title should stand out, not the comments count etc. See... Hackernews! :-)

Having done lots of both greenfield and maintenance work over four decades, I can unquestionably say that software maintenance is way, way more difficult.

I heard this first from Joel Spolsky, "it's easier to write a program than read it."

Which led me to write an article on the subject, "How To Read A Program," about the cognitive aspects of trying to learn unfamiliar code. https://www.itjungle.com/2009/01/28/fhg012809-story01/

The article uses AS400 applications as an example, but is general enough that it applies to applications in most languages.

This is a field begging for help from AI.

Some people, not many, take software maintenance seriously and conduct studies on it - in the study at the link below they point out that comprehending existing code took on average 57% of developer's time. Actual editing consumed 5%.

And software maintenance is no different - think again.

https://www.researchgate.net/publication/318811113_Measuring...

However, these generative AI tools are surely on the path to cover our digital world in gray goo.

The direction seems to be that virtually everything digital will collapse to a zero value.

Says it all