5 ms·

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 deprec

by dakiol 1y ago

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)?

skydhash 1y ago
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.
coliveira 1y ago
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.
- dakiol 1y ago
  > 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?
  - coliveira 1y ago
    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.
    - dakiol 1y ago
      This goes against what you said above: > 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.
      - coliveira 1y ago
        > 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. AIs can debug code too. And the "programmer" doesn't need to know how to fix, only describe what error is happening.
- bpicolo 1y ago
  It's still very costly to replace code. The hard part of migrations isn't usually the churning out of code.

by dakiol 1y ago

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)?

skydhash 1y ago

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.

coliveira 1y ago

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.

dakiol 1y ago
> 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?
- coliveira 1y ago
  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.
  - dakiol 1y ago
    This goes against what you said above: > 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.
    - coliveira 1y ago
      > 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. AIs can debug code too. And the "programmer" doesn't need to know how to fix, only describe what error is happening.
bpicolo 1y ago
It's still very costly to replace code. The hard part of migrations isn't usually the churning out of code.