Comment by jll29
16 hours ago
The inertia argument is real, and I would compare it to the mistaken believe of some at IBM in the 1970s that SQL would be used by managers to query relational databases directly, so no programming was needed anymore.
And what happened? Programmers make the queries and embed them into code that creates dashboards that managers look at. Or managers ask analysts who have to interpret the dashboards for them... It rather created a need for more programmers.
Compare embedded SQL with prompts - SQL queries compared to assembler or FORTRAN code is closer to English prose for sure. Did it take some fun away? Perhaps, if manually traversing a network database is fun to anyone, instead of declaratively specifying what set of data to retrieve. But it sure gave new fun to people who wanted to see results faster (let's call them "designers" rather than "coders"), and it made programming more elegant due to the declarativity of SQL queries (although that is cancelled out again by the ugliness of mixing two languages in the code).
Maybe the question is: Does LLM-based coding enable a new kind of higher level "design flow" to replace "coding flow"? (Maybe it will make a slightly different group of people happy?)
This echoes my sentiment that LLMs are higher level programming languages. And, as every layer of abstraction, they add assumptions that may or may not fit the use case. The same way we optimize SQL queries by knowing how the database makes a query plan, we need to optimize LLM outputs, specially when the assumptions given are not ideal.