Yes, this. 100% this. The goal is for a program to serve a goal/purpose with the least a amount of code possible. AI does the exact opposite. Now that code generation is easy, there is no more natural constraint preventing too much liability.
An answer to the productivity paradox (https://en.m.wikipedia.org/wiki/Productivity_paradox) could be that increased technology causes increased complexity of systems, offsetting efficiency gains from the technology itself.
But if code can be easily replaced, why it needs to be a liability? If something goes wrong, the next generation of "programmers" will ask the ai to generate the code again.
Code can't easily be replaced. It's "soft"ware sure, but why do you think banks are still using Cobol? Why do you think my old company is still running a deprecated version of Zend (PHP framework)?
Also the reason the term technical debt has been used. Every decision you enforce with the code you write is something that you may need to revert later. And the cost of doing so can be really high. So high that in the parent comment, you just don’t bother.
Because, until recently, it was very costly to replace the code. AI "programmers" will create completely new code in a few minutes so there's no need to maintain it. If there are new problems tomorrow, they'll generate the code again.
> If there are new problems tomorrow, they'll generate the code again.
What's the difference (from an LLM point of view) between code generated one week ago and code generated now? How does the LLM know where or how to fix the bug? Why the LLM didn't generate the code without that particular bug to begin with?
Tomorrow the "programmer" will tell the AI what the bug was or what change needs to be made and it will generate new code considering this added requirement.
> Because, until recently, it was very costly to replace the code. AI "programmers" will create completely new code in a few minutes so there's no need to maintain it. If there are new problems tomorrow, they'll generate the code again.
In order for the programmer to know what change needs to be made to fix the bug, the programmer needs to debug the code first. But if code is costly to replace (and we'll use LLMs to regenerate code from scratch in that case), code is also costly to debug (reason for code being costly to replace is that code has grown to be an unmaintanable mess... that's the very same reason debugging is also costly).
Also, it doesn't make sense to ask programmers to debug and tell LLMs to code. Why not tell directly the LLM to debug as well?
So, your scenario of generating "new code" every time doesn't really sustain itself. Perhaps for very tiny applications it could work, but for the vast majority of projects where usually ~100 engineers work, it would lead to an unmaintainable mess. If it's unmaintainable, then no programmer can debug it efficiently, and if no programmer can debug it, no one can tell the LLM to fix it.
If you have for example a sorting routine, coded slightly differently, in 50 different files, which one should you use? It's better to have a single file with a sorting routine that you trust.
Such a great quote. Mostly true if viewed especially from a business standpoint. I for one also see code as creative expression, a form of art. I like coding because I can express a solution in a way that is elegant and nice to read for myself and others. A bit shallow but If you've read code that is written elegantly, you'll know that immediately.
My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
Yes, this. 100% this. The goal is for a program to serve a goal/purpose with the least a amount of code possible. AI does the exact opposite. Now that code generation is easy, there is no more natural constraint preventing too much liability.