In 2018 I opened a ten-thousand-line file with a changelog stapled to the top and ten sets of initials on it. No Copilot. No agents. Just us.
Everybody has a favorite screenshot of AI writing garbage code. The hallucinated method, the deleted null check. We post them, we feel better, we move on.
Here’s the file I think about instead.
The first real codebase I ever touched was an SAP system, back when I was hunting for internships and would say yes to anything. SAP lets you customize almost everything, which sounds like freedom until you see what freedom does to people over a decade. I opened one file. Ten thousand lines, hand-written, with a changelog stapled to the top: dates, initials, one-line descriptions of what changed and why. About ten different people had signed their names to it over the years.
That was 2018. No Copilot. No ChatGPT. No agent quietly appending functions at 3am. Ten humans, presumably employed, presumably paid, presumably passing code review, built something no single person on earth could hold in their head. I’d bet money it’s still in production, still growing.
We call that „historically grown.“ Beautiful phrase. It means nobody is willing to say out loud that it’s slop.
That’s the thing about the slop discourse. It assumes a baseline, some other thing called human code that the machine output is falling short of. That baseline is almost never measured. It’s remembered. Fondly. By the person doing the comparing.
So when someone tells me AI writes worse code than humans, I have one question. Which humans?
Because I think the answer changes the argument completely, and it ends somewhere more interesting than „candidates are bad.“ Something happened to the shape of this profession in the last few years, and the slop fight is people reacting to it without naming it.
which humans
This is where the argument usually goes when I bring it up in person. Someone points at a company with real style guides, real code review culture, real staff engineers who will block your PR and explain why. And they’re right, those places exist. I’ve read their public style guides. They’re good.
But that’s the top one percent of the industry, and we’ve somehow all decided it’s the average. It isn’t. Most of us work at small tech companies, or at the insurance company, the logistics company, the manufacturer, the bank, places where software is a cost center and the person who wrote the critical service left three years ago.
I hear these stories every month from friends across every industry you can name, and they all rhyme. The undocumented job that runs at midnight. The stored procedure nobody dares touch. The service with a name that describes what it did in 2019.
That’s the real baseline. Not Google.
nobody can tell me why they chose it
That’s the code. Now the people writing it, when you get them in a room and ask.
We give candidates a small task. Build a little REST API. Take a request, validate it, write it to a database, read it back out. That’s the whole job. Then we sit down and talk about it. How would you deploy this. What does the infrastructure look like. And then my favorite part, the part I care about.
Why did you structure it this way?
Why vertical slices and not horizontal ones? Why is there complexity in here at all, given that this thing does four things total?
I’m not trying to trap anyone. There are good answers to every one of those. I’ve heard maybe a handful of them.
The answer I get, over and over, is some version of: „That’s how I’ve always done it.“ Or „that’s how I was taught.“ And that’s it. That’s the whole reasoning. They picked up a shape from somebody who picked it up from somebody else, and at no point in that chain did anyone stop and ask whether the shape fit the problem. It’s cargo cult architecture. Layers because layers. Interfaces because interfaces. A repository pattern wrapping a single ORM call because a blog post in 2019 said repositories are good.
These aren’t bad people. Most of them are perfectly competent at getting things working. They just have never been asked to defend a decision, so they never made one.
And those are the candidates who structured something. The weirdest submission I’ve seen had paths like /action1/action2/action3. Not a joke, not a placeholder they forgot to rename. That was the design. Another one returned the same status code for every single outcome. Success, validation failure, server on fire, all identical. The client had to crack open the body and go looking for the truth.
People still submit work like this today, with an internet full of documentation and a chat window one keystroke away that would have told them exactly how to do it properly if they’d bothered to ask.
consistent is not the same as good
So what is the machine actually competing on, against people who can’t defend a decision?
Not brilliance. It’s read more code review feedback than any of us will give or receive in a career, and it applies that evenly, on a Friday afternoon, on the fourteenth endpoint, at 3am. None of that makes it good. It makes it consistent, which is more than the median commit manages.
Does it screw up? Constantly. It builds four abstractions where zero were needed. Now and then it designs an interface that makes me want to close the laptop and go outside. It has no idea what your business does, and it will happily write beautiful, well-factored code that solves the wrong problem.
But „sometimes over-engineers“ is a different category of failure from „ten thousand lines with a changelog on top.“ One of those you fix in a review comment. The other one outlives the people who wrote it.
Which means the interesting question isn’t whether the output is good. It’s what happened to the distribution.
the floor came up, the ceiling didn’t
The average piece of software being written right now is better than the average piece written in 2018, and a lot of that is because a machine that has read every style guide ever published is sitting in the editor making suggestions.
The floor coming up is not the same as the ceiling moving. Average is still not good. Most software is still mediocre, still under-tested, still held together by one person’s tribal knowledge.
And the gap between the top and the bottom is getting wider, not narrower, which is the part I think people are reacting to when they yell about slop. AI in the hands of an engineer who knows what they want multiplies them by an absurd factor. They can hold a design in their head, describe it, get it back, review it like they mean it, and throw out the parts that are wrong. The judgment is theirs. The typing isn’t. That person is now doing in an afternoon what used to be a sprint.
AI in the hands of someone who has never been asked why they chose vertical slices produces exactly what you’d expect. More of what they were already producing, faster.
A fool with a tool is still a fool. The tool just doesn’t slow them down anymore.
Here’s the part that worries me, and I don’t have a clean answer to it. The engineer who can throw out the parts that are wrong can only do it because they spent years being made to defend decisions. If the floor is high enough that nobody has to argue for a design anymore, where does the next one of those come from? The machine raises the floor and quietly removes the pressure that used to build the ceiling. I think that’s a real cost, and I think it lands on people who are three years into their career right now.
go check the blame
So ask it why it structured things that way. It’ll tell you, which is more than I can say for most of the candidates I interview.
And if you’re worried the machine writes worse code than you do, go open the oldest file in your repo. Scroll to the bottom. Check who’s on the blame. You’ll find initials, and a date, and a one-line description of what changed and why.
It probably wasn’t a model.