i think that we need to start rethinking some of our best-practices. For instance, does DRY matter? If i have a server that serves a bunch of endpoints, and if each one reimplements some fetching function, is that bad? As you said, if all of the code is local, and we need to fix one of the endpoints, we can just fix that endpoint, and not break anything else in the process. If we need to make changes across the endpoints, we can tell it to do so.
I’m not sure about this though. Right now, I don’t think that’s the right call—mostly because humans still have to read and understand the code—but I expect that in the very near future we won’t be reading much of the code anyway.
it’s a weird time we’re living in right now as software engineers.
I think that DRY still matters. Code repetition usually means that a change in one place will need to be reflected in the copies. You (or the LLM) needs to be aware of this implicit constraint, in order to ensure that the changes are made in all the necessary places. With enough intelligence & time/compute, you can handle this kind of extra difficulty, but it makes things harder. When enough of these extra difficulties stack up, eventually it will be enough to harm development speed/quality.
I think that we will discover an important distinction in what we now consider the pool of good coding practices: on one side what makes code generally evolvable, on the other what make it maintainable and evolvable by humans.
I suspect that even without too much explicit design, a lot of evolvability will come for free when cumbersome implementations that just happen to pass all tests will start being adopted at a massive scale. I actually have a longer form of this argument here
i think that we need to start rethinking some of our best-practices. For instance, does DRY matter? If i have a server that serves a bunch of endpoints, and if each one reimplements some fetching function, is that bad? As you said, if all of the code is local, and we need to fix one of the endpoints, we can just fix that endpoint, and not break anything else in the process. If we need to make changes across the endpoints, we can tell it to do so.
I’m not sure about this though. Right now, I don’t think that’s the right call—mostly because humans still have to read and understand the code—but I expect that in the very near future we won’t be reading much of the code anyway.
it’s a weird time we’re living in right now as software engineers.
I think that DRY still matters. Code repetition usually means that a change in one place will need to be reflected in the copies. You (or the LLM) needs to be aware of this implicit constraint, in order to ensure that the changes are made in all the necessary places. With enough intelligence & time/compute, you can handle this kind of extra difficulty, but it makes things harder. When enough of these extra difficulties stack up, eventually it will be enough to harm development speed/quality.
I totally believe it does not!
I think that we will discover an important distinction in what we now consider the pool of good coding practices: on one side what makes code generally evolvable, on the other what make it maintainable and evolvable by humans.
I suspect that even without too much explicit design, a lot of evolvability will come for free when cumbersome implementations that just happen to pass all tests will start being adopted at a massive scale. I actually have a longer form of this argument here