> if your employees do not care (they are optimising for salary & time spent not code quality)...

From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.

Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.

I'd love to be wrong, very wrong about this, actually.

One way to get workers to care about the quality of the product they are being paid to build (for someone else's profit) is for the management to show some loyalty and build trust over the course of a decades-long career by treating them fairly and avoiding layoffs.

>The trillion dollar question is how you do this, if your employees do not care (they are optimising for salary & time spent not code quality)

Sounds like there is a compensation problem then.

You pay someone and give them the explicit responsibility for code quality in your system, empowering them to gate check-in with any static analysis and adversarial agent review they feel like. It’s not a silver bullet but you absolutely can do better than just giving up.

> Before AI there was at least some way to tell apart good programmers from bad

There were only bad ways, and the best way was to just find people who were both good programmers and cared about quality to keep an eye on the rest. Nothing much has changed in that respect.

> The trillion dollar question is how you do this

I don't think it's that hard of a question to answer. I've noticed on my team, our thinking has shifted from how do you directly solve a problem, to how you get an agent to effectively solve the problem and not produce slop in the process.

One thing that we have done that's probably made the biggest impact is alot more upfront architecture with the knowledge that pretty soon agents will be running wild all over the code. Having worked with these agents for a while now, you get a very good sense of how they will go about solving a problem and the various footguns they will encounter along the way. Editing an AGENTS.md file or building a skill is not nearly as fun as coding by hand but it will pay dividends over and over if you do it right.

Another big thing is doing refactoring passes. Early on in our projects our agents generated ALOT of slop and we had to go back and fix alot of it. But every time we did one of these passes, a major aspect was improving agent instructions / skills / etc so it doesn't happen again. It can be a painful process at first but I found that over time, the amount of slop the agent produces goes down by orders of magnitude.

I feel like we're still very much programming, but we're now doing it at a "higher level" where we are not writing the code ourselves but instructing the agent to. And IMHO, properly instructing an agent on a production codebase is not a trivial task.

There is still lots of human effort involved. If there isn't, you've found the bad programmer

> and you have no way of telling apart AI slop vs. good maintainable code. (If you could you would just train the AI.)

I know how to distinguish good maintainable code from garbage. I have known for quite a few years. But knowing how to train someone, or an AI? I'm a good coder, not necessarily a good teacher. And there are things about code that I _feel_, not that I can rationally explain.

> you have no way of telling apart AI slop vs. good maintainable code

SonarQube

> Before AI there was at least some way to tell apart good programmers from bad

That's why companies were interviewing people on tasks that had nothing to do with writing maintainable software. /s

I understand the concern and it should be addressed and researched. But, simply saying "humans were writing code themselves" doesn't provide any evidence for better quality.