> Calling the technology "text auto complete" is not productive to the discussion.

If pointing out the flawed approach to making something more productive isn't productive, then what do you consider to be productive?

> Less than a decade ago the idea that a computer could take a fuzzy human-readable description and turn it into executable code was science fiction

Cobol was sold to people on the idea that anyone could create something with fuzzy human readable description that would result in executable code. That was back in the 60s.

What lessons did we learn?

1) Leaving things to the people who make fuzzy human readable descriptions turns out to be a terrible way to have things implemented.

2) Slowly and deliberately thinking things through before, during, and after implementation always leads to better results.

It's a lesson that keeps needing to be re-learned by people who don't/can't look at things through a historical lens.

It was the same with cobol, as it was with programming in spreadsheets in the 80s, as it was with the nocode movement in the 00s, as it is now again with LLMs in the 20s, and it will be again with a future generation in the 40s.

---

> As is the ability to write long form text, and be so hard to distinguish from real that placing an em dash in your text will cause an uproar on this forum.

Long form text generation that is hard to distinguish from human authored text also goes back to the 60s.

That's when we got the first instances of the Eliza effect.

> You can describe things by their fundamental functions and make many things sound elementary but I find it counter productive given the capabilities we've seen from this technology

The capabilities we've seen are:

- Text prediction/generation

- Inducing the Eliza effect