Let me pose a hypthetical conversation of a 1:1;
Manager: "You need to review Alice's code faster, you're blocking her amazing huge feature Foo that will get us a million new customers." Bob: "I'm trying to review it, but it's five stacked 10,000 line PRs." Manager: "That reminds me, why has your feature, Bar, taken so long?" Bob: "I try to only use LLMs for simple tasks, you know, tests, docs --" Manager: "You're not leveraging your LLM hard enough, you need to be more like Alice, she's getting things done." Bob: "I guess I'll just skim these PRs faster and have my LLMs make Bar while I do that" Manager: "That's the spirit, Dot, doordash me some lunch!"
We have an alignment problem once again. Management wants things done fast, engineering wants things done well. This is not a new vs old argument, it's a matter of rewards. Prioritizing for feature speed has won over maintainability, after all, if there's a bug just assign Claude to it, he'll (it'll?) fix it. LLMs have essentially introduced a no-win decision for senior developers; you embrace the LLM and produce hard-to-maintain slop, or you remain an "artisinal" developer and get outperformed by a factor of three by those utilizing the new technology. Engineers can continue to espouse maintainability and quality, however at some point management will replace them with the LLM that "just works" and doesn't complain about how shit your codebase is to work with. John Henry might have beat the machine, but at what cost.
The problem with what LLMs produce isn't as much the code itself, it's the decisions within the code. LLMs love making functions that call functions that call functions. At some level, I'm sure that this made sense from a single concern principle, but it has no taste as to when to apply it. It's like the developer that just learned about functional programming, and suddenly everything needs to be written in haskell, and everything needs to be pure.
So it is a little funky with its design decision, it's architecture is pretty solid, you might say. The problem is that reviewing the code that those design decisions produce is a nightmare. Constantly jumping between functions, finding references, inconsistent between model versions, when it was written, everything. Even with a large coding convention file, you can't cover everything, and writing good software is so much more a judgement call than we as computer "scientists" ever care to admit. When you have a bug to resolve, if you've ever tried working with a code base that spans the pre and post LLM era, it becomes clear which sections you're dealing with, and it becomes very apparent what is slop.
It's draining as a senior engineer. You know what good code looks like, you know how it should work. You know what is a pleasure to work with and what is a disaster. Why has your codebase turned sour so quickly? Surely even the AI code has been reviewed by a human?
I suppose I don't have an answer here, tools need to change, perhaps models need to change, perhaps nothing needs to change. Perhaps developers are still just dinosaurs looking at the pretty fireball hurtling towards them. Perhaps we're all just swinging as fast as we can, waiting for our hearts to give out, and hoping that we make it through the mountain before they do.