AI Lazyslop and Personal Responsibility

I have been on both - actually on all three - sorry, make that four - sides.

1. I tried to ship crap and complained to my manager for being blocked. I was young, dumb, in a bad place and generally an asshole. 2. I was the manager being told that some unreasonable idiot from X blocked their progress. I was the unreasonable manager demanding my people to be unblocked. I was without context, had a very bad prior relationship with the other party and an asshole - because no prior bad faith acts were actually behind the block - it was shitty code. 3. I was the manager being asked to help with unblocking. I asked to understand the issue and to actually try to - based on the facts - find a way towards a solution. My report had to refactor. 4. I was the one being asked. Luckily I had prior experience and did this time manage to not become the asshole.

I am glad I had the environments to learn.

Edit: Format.

Lazyslop PRs offload the work to code reviewers while keeping all the benefits to the PR creator.

Now creating a 1600 loc PR is about ten minutes, reviewing it at the very least an hour. Mike submits a bunch of PRs, the rest of the team tries to review it to prevent the slop from causing an outage at night or blowing up the app. Mike is a hero, he really embraced AI, he leveraged it to get 100x productivity.

This works for a while, until everyone realizes that Mike gets the praise, they get reprimanded for not shipping their features fast enough. After a couple of these sour experiences, other developers will follow suit, embrace the slop. Now there is nobody that stops the train wreck. The ones who really cared, left, the ones who cared at least a little gave up, and churn out slop.

It’s a prisoner’s dilemma, too. The person who commits to giving code review its due diligence is going to end up spending an inordinate amount of time reviewing others’ changes, leaving less time to completing their own assignments. And they’re likely to request a lot of changes, too. That’s socially untenable for most people, especially ones who clearly aren’t completing as many story points as their teammates. Next thing you know your manager is giving you less than stellar performance reviews, and the AI slopcoders on your team are getting the promotions and being put into position to influence how team norms and culture evolve over time.

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.

I actually had someone like "Mike" in my most recent job (though he wasn't uncooperative, just didn't seem to care about writing proper code). He made some tool using AI and i took it over to clean it up and improve it, but he still worked on it too. He got occasionally annoyed when i suggested changes and sometimes i felt i was talking to ChatGPT (or whatever AI he used, i don't know) via a middleman. He didn't put any 1600 line PR (that i remember anyway) but he did add extra stuff to his PRs which were often related to other tasks and the code submitted was often much larger in "volume" than needed.

As an example there was a case where some buttons needed a special highlight based on some flag, something that could be done in 4-5 lines of code or so (this was in Unreal Engine, the UI is drawn each frame), but the PR was adding a value indicating if the button would need to be highlighted when the button was created and this value was passed around all over the place in the up to the point where the data that was used to create the UI with the buttons would be. And since the UI could change that flag, the code also recreated the UI whenever the flag changed. And because the UI had state such as scrolling, selected items, etc, whenever the UI was recreated, it saved the current state and restored it after it was recreated (together with adding storage for the state). Ultimately, it worked, but it was too much code for what it needed to do.

The kicker was that the modifications to pass around the value for the flag's state wasn't even necessary (even ignoring the fact that the flag could have been checked directly during drawing) because a struct with configuration settings was already passed through the same paths and the value could have been added to said struct. Not that it would have saved the need to save/restore the UI state though.

The AI velocity comes from large PRs that no-one reviews.