What really bugs me is that today, it is easier than ever to do this (even the LLM can do this!) and people still don't do it.

I automatically block PRs with LLM-generated summaries, commit messages, documentation, etc.

There is very little accountability in the upper echelons these days (if there ever was) and less each day in our current "leadership" climate.

This implies that managers will do both of the following in response to the aforementioned breakage:

1. Understand that their own managerial policies are the root cause.

2. Not use you as a scapegoat.

And yet, if you had managers that were mentally and emotionally capable enough to do both of the above, you wouldn't be in this position to begin with.

Just because management asks doesn't mean they're siding with Mike.

The suffering is self inflicted for this particular person. The organization doesn’t value code review.

At the end, I spent a lot of time sitting down with Mike to explain this kinds of things, but I wasn't effective.

Also, now LLMs empower Mike to make a 1600 line PR daily, and me needing to distinguish between "lazyslopped" PRs or actual PRs.

> Mike comes up with 1600 lines of code in a day instead of in a sprint

It seems like you do have an idea of at least one thing that AI changes.

So now instead of reviewing 1600 lines of bad code every 2 weeks, you must review 1600 lines of bad code every day (while being told 1600 lines of bad code every day is an improvement because just how much more bad code he's "efficiently" producing! Scale and volume is the change.

Which is extremely relevant, as it dramatically increases the probability that other people will have to care about it.

This thinking that we must avoid blaming individuals for their own actions and instead divert all blame to an abstract system is getting a little out of control. The blameless post-mortem culture was a welcome change from toxic companies who were scapegoating hapless engineers for every little event, but it's starting to seem like the pendulum has swung too far the other way. Now I keep running into situations where one person's personal, intentional choices are clearly at the root of a situation but everyone is doing logical backflips to try to blame a "system" instead of acknowledging the obvious.

This can get really toxic when teams start doing the whole blameless dance during every conversation, but managers are silently moving to PIP or lay off the person who everyone knows is to blame for repeated problems. In my opinion, it's better to come out and be honest about what's happening than to do the blameless performance in public for feel-good points.

Using AI adds a non-deterministic layer in between, and a lot of code now is there that you probably didn't need.

The prompt is helpful to figure out what is needed and what isn't.

It makes a lot more sense to review and workshop that into a better prompt than to refactor the derived code when there are foundational problems with the prompt.

Also, we do do this for human-generated code. It's just a far more tedious process of detective work since you often have to go the opposite direction and derive someone's understanding from the code. Especially for low effort PRs.

Ideally every PR would come with an intro that sells the PR and explains the high level approach. That way you can review the code with someone's objectives in mind, and you know when deviations from the objective are incidental bugs rather than misunderstandings.

…yes? If someone dumps a PR on me without any rationale I definitely want to understand their thought process about how they landed on this solution!

It doesn't take a company policy for an ai-enabled engineer to start absolutely spewing slop. But it's instantly felt by whatever process exists downstream.

I think there's still a significant quantity of engineers who value the output of AI, but at the same time put the effort in to avoid situations like what the author is describing. Reviewing code, writing/generating appropriate tests (and reviewing those too). The secret is those are the good ones. These are the ones you SHOULD promote, laud, and set as examples. The rest should be made examples of and be held accountable.

Id hope my usages of AI are along these lines. I'm sure I'm failing at some of the points, and always trying to improve.

The worst part is, this isn’t me speculatively catastrophizing. I’m just observing how my own organization’s culture has changed over the past couple of years.

It’s hitting the less senior team members hardest, too. They are generally less skilled at reading code and therefore less able to keep up with the rapid growth in code volume. They are also more likely to get assigned the (ever growing volume of) defect tickets so the more senior members can keep on vibecoding their way to glory.

That’s not just a process error. At some point you just have to feed back to the right person that someone isn’t up to the task.