[Octoth0rpe]

I think Kernighan said something along the lines of "Because debugging code is twice as hard as writing it, only write code half as smart as you are or you'll never be able to fix it later". AI-assisted code generators seems to make this problem much worse as I can now write code 2x, or 3x as smart as I am. What hope will there ever be in debugging this?

A more optimistic take is that maybe such tools will let us write competent code in languages we do NOT specialize in, and in the future either a more competent version of ourselves or some actual expert can fix it if it breaks? That doesn't sound a whole lot better :/

[hobs]

The optimistic take is a feedback loop that makes them both better and more capable, writing code you can't debug is bad, but it could help you understand and build your own skills to a point that you can.

The pessimistic and more likely outcome is that people just want shit done and so they will slap any half working garbo together as they have done for the last 20 years I have been in the industry.

[AnimalMuppet]

And AI-assisted code is almost certainly code that AI can't debug...

[ozim]

What if I told you that one can write code again from scratch instead of fixing broken one?

Writing replaceable code instead of maintainable code seems to be already working for a lot of projects. With LLMs and all that fast computing we have it seems it will be more of replaceable code in the future.

Of course there are always projects where it will never work.

It already works for infrastructure as nowadays servers are not fixed and treated like important things but you spin up fresh one.

[rezonant]

> Writing replaceable code instead of maintainable code seems to be already working for a lot of projects.

I contend that these two concepts aren't different. If you have the ability to easily replace a small part of the code and have everything still work, then that's very maintainable. Unless you are talking about throwing out the whole codebase and replacing it, which for sufficiently complex codebases will inevitably lead to the second system effect. If replacing the whole thing is easy, it was probably not that valuable or complex to begin with, but that's not the kind of code where maintainability is paramount.

> It already works for infrastructure as nowadays servers are not fixed and treated like important things but you spin up fresh one.

For that metaphor to work, the programmer would have to be patching the binary output instead of fixing the source code and recompiling.

[ozim]

> If replacing the whole thing is easy, it was probably not that valuable or complex to begin with, but that's not the kind of code where maintainability is paramount.

Yes I think even as far as 70%-80% of code - IMHO - is not complex/valuable.

Most of code is replaceable CRUD not controls systems for flying and landing Falcon 9. So it is people problem not a technical problem, people pretend that they need "button more to the left and different shade" just to feel more important. Where we end up with loads of systems that do slightly different thing.

[rezonant]

This is a very extreme take to something far more nuanced... It's possible for code to be complex and valuable without meeting the extremes of "is a literal rocket control system" and "is some buttons on a form".

When I say valuable, I mean provides value to a business. When I say complex, I mean not buttons on a form.

[mumblemumble]

You spin up a fresh server from a cookie cutter image that lets you create a practically unlimited number of identical servers.

That's not even remotely like how rewriting code works. Rewriting code is more comparable to what spinning up a fresh server was like a quarter century ago. So, back in the days where they were important things because spinning up a new one was an unholy PITA and literally never went off without a hitch.