3 ms·

> LLMs don't just make it easy to accumulate code - they make it easy to throw code away and start again. To throw away code you have to understand it, so no i

> LLMs don't just make it easy to accumulate code - they make it easy to throw code away and start again. To throw away code you have to understand it, so no its the opposite. Code you don't understand is the hardest to get rid of, so it stays the longest in your codebase. > if there's a bug and it can't be trivially solved, trash that bit of the code and write it again How do you know where the bug is if you don't understand the code? There is no known algorithm to take a bug description and return the place in the code the bug is, otherwise bug fixing would be trivial. Edit: Not to mention that in real production systems your bugs will corrupt the database, and if you haven't set up a logging system etc you will likely not realize for a while forcing you to do a rollback to a very old state losing so much data. You wont last long doing that.

TeMPOraL 2y ago
> To throw away code you have to understand it, so no its the opposite. Code you don't understand is the hardest to get rid of, so it stays the longest in your codebase. No, you don't. > How do you know where the bug is if you don't understand the code? There is no known algorithm to take a bug description and return the place in the code the bug is, otherwise bug fixing would be trivial. Yes, there is. At worst, the bug is somewhere in the entire project. But you probably have a more narrow idea where the bug is, or when it was introduced. "In module X", "In feature Y", "In the last N days/weeks". Not to mention, for most bugs, `git bisect` is enough to precisely narrow down the problematic change, and doing that doesn't actually require understanding anything about the code. It all boils down to costs. Even if it takes AI a whole day and 1000 attempts to do what would be a relatively simple fix for an experienced developer, if those 1000 attempts cost less than the developer's work-hours, the business will soon learn to prefer AI over people. If and when we get to that point, is mostly just a function of LLM performance and cost. If they get cheap enough, it'll make as much sense to have human developers fix bugs in code, as it makes sense for you to mend holes in your socks instead of buying them in bulk on-line. > Not to mention that in real production systems your bugs will corrupt the database, and if you haven't set up a logging system etc you will likely not realize for a while forcing you to do a rollback to a very old state losing so much data. This really depends on the kind of system you're doing, and the kind of data you're storing.

TeMPOraL 2y ago

> To throw away code you have to understand it, so no its the opposite. Code you don't understand is the hardest to get rid of, so it stays the longest in your codebase. No, you don't. > How do you know where the bug is if you don't understand the code? There is no known algorithm to take a bug description and return the place in the code the bug is, otherwise bug fixing would be trivial. Yes, there is. At worst, the bug is somewhere in the entire project. But you probably have a more narrow idea where the bug is, or when it was introduced. "In module X", "In feature Y", "In the last N days/weeks". Not to mention, for most bugs, `git bisect` is enough to precisely narrow down the problematic change, and doing that doesn't actually require understanding anything about the code. It all boils down to costs. Even if it takes AI a whole day and 1000 attempts to do what would be a relatively simple fix for an experienced developer, if those 1000 attempts cost less than the developer's work-hours, the business will soon learn to prefer AI over people. If and when we get to that point, is mostly just a function of LLM performance and cost. If they get cheap enough, it'll make as much sense to have human developers fix bugs in code, as it makes sense for you to mend holes in your socks instead of buying them in bulk on-line. > Not to mention that in real production systems your bugs will corrupt the database, and if you haven't set up a logging system etc you will likely not realize for a while forcing you to do a rollback to a very old state losing so much data. This really depends on the kind of system you're doing, and the kind of data you're storing.