Sorta like how in the 90s UML & all the new modeling tools were going to replace the need for actual coding!

i’d rather be the detective of my own murder than another’s. i already struggle to figure out people’s thoughts from the strictures of whatever programming language they express it in. programming languages aren’t symbols of thought, neither do they enjoy the ubiquity of, for example, math notations, unfortunately.

New programmers who did not have chance to learn "properly" might not be able of "intervening".

That's probably what every generation of "older" programmers said - new programmers who did not do assembly will never be able to code etc.

> new programmers who did not do assembly will never be able to code etc

I see the results from programmers who never learned assembly.

Just like repairing and building cars from the ground up makes me a better driver. For example, the clutch in my car lasts a lot longer than it does for other drivers.

Then again, there is no clutch in an EV

I'm sure batteries and electric motors have their own quirks. For example, battery performance is dependent on temperature.

You are arguing against your point. Everything has its own quirks and no one has it easy or tough.

It doesn’t have it because it doesn’t need it, not because it somehow built abstraction around it. That’s not the case with modern computers, anything is built on top of everything.

1) false equivalence.

2) I am an old fart and had never said anything even remotely approaching "who did not do assembly will never be able to code". One can learn programming using any language. However some experience with the languages of multiple level definitely does not hurt.

In order to evaluate generated code you have to know how to program.

If you look at the mountains of crap that have been written in JS, for instance, those old programmers have been proven right.

Having no knowledge about assembly doesn’t stop me intervening with my JavaScript apps :)

Intervening can be done via LLM in some way I reckon

That’s not really a fair comparison here — A more fitting metaphor would be whether or not you could intervene on assembly code not knowing assembly.

Who said you need to know assembly.

>"Intervening can be done via LLM in some way I reckon"

This inspires much confidence

Thank you, you're the first person seeming to understand this in this whole darn section. Why does a human need a model of the program in their head when the LLM will be able to fire off 1500 test/debug/fix loops and wait for them to all resolve, then vote on the best answer?

For years we've been saying "computer time is cheaper than developer time."

Well, that's about to come back to bite us, in a big way.

Yes. Like it or not, the days of “typing code” is coming to an end. In fact, may be cheaper for companies to just nuke all existing software and start over

Test/debug/fix against what? Writing code is fundamentally not about tests or debugging, it's about formalising informal requirements into hard constraints. To do that, you need to understand business, human, and technical contexts. Without that understanding, you get over engineering, Google Cloud Console, and poor code lacking mechanical sympathy respectively. What's more, often those contexts have competing/incompatible requirements that you need to either evaluate using your idea of your team's values, or escalate, being aware of your own limitations.

None of those problems are amenable to modern LLMs. The moment you try to be formal enough to be unambiguous, you start writing code.