idk, code was always written only once, but it will always be read many times. Writing code with LLM centric way and just focusing the high level gets hazardous pretty quickly, since somebody actually needs to understand the codebase deep down (or at least the relevant part) when something goes wrong. When you have 100k+ line codebase with multiple contributors with LLM it can very quickly turn into a black box, which nobody understand anything deep down anymore and everybody are more and more incentivized to use LLMs to interact with the thing to get anything real done. Then it’s couple hallucinations away from turning into a fragile mess, where things break unexpected and nobody knows why.
What universe do you live in? My whole life has been modifying code. I may spend 20% of my time on “greenfield” writing of new code, but the rest is modifying other people’s code, modifying my own code, explaining to people how my and other peoples’ code works so they might modify it.
Writing code with LLM centric way and just focusing the high level gets hazardous pretty quickly, since somebody actually needs to understand the codebase deep down (or at least the relevant part) when something goes wrong.
In my industry we spend a significant amount of effort to ensure that “something goes wrong” before we ship, rather than after. Of course, we’re only human, bugs do ship, but they’re relatively rare - and field fixes get 10x the scrutiny of the already heavily scrutinized greenfield code.
For the past 6 months or so, I have come to respect LLMs’ ability to find more bugs earlier in the process - doesn’t matter if the code is written by people or LLMs, bugs happen. LLMs don’t find them all, but people find even fewer.
The other thing LLMs are starting to excel at is verifying that the documentation says what the code does, and the code does what the documentation says. Docs out of sync with code has been the bane of my past 3 decades, and before that I just didn’t write a lot of docs.
idk, code was always written only once, but it will always be read many times. Writing code with LLM centric way and just focusing the high level gets hazardous pretty quickly, since somebody actually needs to understand the codebase deep down (or at least the relevant part) when something goes wrong. When you have 100k+ line codebase with multiple contributors with LLM it can very quickly turn into a black box, which nobody understand anything deep down anymore and everybody are more and more incentivized to use LLMs to interact with the thing to get anything real done. Then it’s couple hallucinations away from turning into a fragile mess, where things break unexpected and nobody knows why.
What universe do you live in? My whole life has been modifying code. I may spend 20% of my time on “greenfield” writing of new code, but the rest is modifying other people’s code, modifying my own code, explaining to people how my and other peoples’ code works so they might modify it.
In my industry we spend a significant amount of effort to ensure that “something goes wrong” before we ship, rather than after. Of course, we’re only human, bugs do ship, but they’re relatively rare - and field fixes get 10x the scrutiny of the already heavily scrutinized greenfield code.
For the past 6 months or so, I have come to respect LLMs’ ability to find more bugs earlier in the process - doesn’t matter if the code is written by people or LLMs, bugs happen. LLMs don’t find them all, but people find even fewer.
The other thing LLMs are starting to excel at is verifying that the documentation says what the code does, and the code does what the documentation says. Docs out of sync with code has been the bane of my past 3 decades, and before that I just didn’t write a lot of docs.