When the code is low-quality, you can’t reason well about it, can’t reason well about what changes to apply and what their effects will be, can’t reason about what the outcome will be when making changes to the context (inputs, environment) the code is run it. Instead everything becomes an experiment on a black box or gray box, whose behavior you can’t well predict in advance.

Engineering is the task of making things behave predictably and reliably. Because software is malleable and rarely “finished”, this applies to changing software as well.

I’m pretty sure that there is more than one divide regarding AI among developers, but one of the dividing lines concerns the predictability and reason-ability of the tools and the code. AI fundamentally lacks these qualities.

> Most enterprise code involves lots of exploring and fast iteration.

And when the code base is 250,000 lines of garbage all the way down, this is impossible. The projects where I’ve had free rein to kill tech debt and SDLC footguns with impunity have all been the ones where velocity maintained or increased over time. All the rest have ground to a halt.

There’s value in customers believing you’ll get there soon and the code will actually work. They can be patient if you have an air of competence. But they will switch to some other clown car if it’s cheaper than your clown car.

> Code quality doesn’t matter that much. No one else is going to see it.

You seem to be claiming that enterprise shops never adopted code reviews. Interesting if true.

> Code quality doesn’t matter that much. No one else is going to see it.

This is just false for anyone who has worked in the industry for any meaningful amount of time. Do you seriously never encountered a situation where a change was supposedly easy on the surface, but some stupid SoB before you wrote it so bad that you want to pull your hair out from trying to make it work without rewriting this crap codebase from scratch?

I think your target is the wrong target myself. Now what?