The Standard Didn't Change. The Author Did.

Engineers have been using code they didn't write for as long as software has existed. NPM packages with hundreds of transitive dependencies for a single job. Stack Overflow answers pasted directly into production. Terraform modules pulled from the registry or a blog post without reading every resource they create. And it goes deeper than that: ORM output, protobuf generation, OpenAPI codegen, framework scaffolding. We've been removing handwritten code from the process for ages. Nobody audited every line and nobody called it slop. For most engineering decisions, the question was always: does it work, and can I maintain it?

That line of thought held for a long time. Then agents started producing the code and the question changed. It's no longer "does it work" but "who wrote it." The same engineers happily shipping code they copied from a stranger on the internet, pulling in codegen they'd never read, started rejecting code because an agent produced it. The bar didn't just move, a completely different bar appeared, and that tells you something about what "slop" actually means.

What slop actually is

There is absolutely agent-generated code I'd call slop. Massive files with no structure, duplicated logic everywhere, abstractions that don't survive the next requirement. That's slop. But it's slop because it's badly engineered, not because an agent produced it.

A junior engineer without guidance produces the same kind of output. A Stack Overflow paste dropped into a codebase without understanding the context around it produces the same risk. The problem was never the authoring of the code, it's the absence of engineering around it.

"Slop", as most people use it, collapses that distinction. It takes "this specific output was bad because there were no guardrails" and turns it into "all agent-generated code is bad." The first one you can fix. The second just ends the conversation.

The only criteria that matter

I wrote in The Vibes Don't Scale that a well-architected system with mediocre code outperforms a poorly-architected one with brilliant code, every time. That was about building the process that makes agents produce good work. This is the other side of that argument: how you evaluate the output.

I think those are the only questions that matter in this new era of engineering that is forming. Does it fit the architecture? Is it easy to change? Does it solve the problem? If the answer is yes, I don't particularly care whether it came from me, another engineer, or an agent.

Architecture matters because it determines whether future changes are local or systemic. That's what makes software expensive. Not the initial implementation — the cost of every change after it.

We hit this recently with data.latest() in swamp. We use CEL expressions to query data items in Swamp. The agent built the first implementation of data.latest(), we shipped it, it worked. Was the code beautiful? No. Did it need to be? No. It did exactly what we needed. And more importantly, it got us to the point where we understood the real requirements. We didn't know we needed SQL check-first when we started. We learned that by shipping the first version and hitting scale.

When the requirement changed, we refactored. The agent planned the approach, ran experiments, and we landed a scoped walk with SQL check-first that took query times from 1,459ms down to 27ms at 5,000 data items. 54x improvement on the cold path. The SQL check-first path hit 32,656x at scale because most queries resolve before the walk even starts. Cold runs went from 16.2s to 3.8s, warm runs from 14.0s to 1.7s.

Is that code beautiful? I don't really care - I presume it will have some flaws in it for sure. But it follows the architecture we put in place. So when the requirements changed, we changed it. The numbers speak for themselves. The first implementation wasn't valuable because it was perfect code, it was valuable because it got us to the next understanding. That's how software actually works.

Style matters. Style isn't quality.

Style matters because humans read code. That's different from saying style determines software quality.

A duplicated method isn't a defect if the code is easy to change and the architecture is sound. A verbose function isn't a problem if it's clear and does what it needs to do. They don't affect outcomes, they offend style. Style has become one of those areas that really divides teams... cough tabs vs spaces cough.

The engineering community has been conflating the two [style vs outcomes] for years. Code review culture, "clean code" orthodoxy, style wars that burn hours of senior engineering time. For most of software history, implementation dominated the cost of delivery. Writing code was slow and changing it was slower. Naturally we optimised for beautiful implementation because we were going to live with it for years. We ended up mistaking the implementation for the craft.

Agents invert that economics. When implementation becomes cheap, when refactoring takes an afternoon, the cost of code that offends your style drops to near zero. The scarce resource becomes judgment: defining problems clearly, designing systems that hold up under change, knowing when something is good enough and when it isn't.

The real problem with "slop"

If your experience of agents is mostly producing slop, I'd first look at the engineering process around them. Poor prompts, no architectural constraints, no evaluation loop, no iteration - I could go on and on here!

The output reflects the process. This is more true now that it has ever been. The speed at which we can create code now means we get to see the pain in our process so much faster than we have ever done before.

Software exists to change. Code that can evolve with changing requirements is more valuable than code that looks perfect on day one. If an agent can produce code that fits the architecture, is easy to change, and delivers the outcome, then it's meeting engineering criteria. If you can then refactor it to a 32,000x improvement in an afternoon, that says something important about where the value really was. It wasn't the code, it was the judgment behind it. "Slop" has become shorthand for evaluating authorship instead of engineering. Same pattern I described in The Gap Is Already Wider Than You Think: teams treating bad output as evidence the technology isn't ready, rather than as an engineering problem to solve.

AI-generated code doesn't need to be beautiful. It doesn't need to be authored by a human. It needs to fit the architecture, be easy to change, and solve the problem. If it does those things, it's good engineering. If it doesn't, it isn't.

That's why AI isn't devaluing engineering. It's forcing us to evaluate software on engineering criteria instead of authorship. The implementation was never the scarce skill. It was just the most visible one.