No More Slop: Building Trust in an AI-First Organization

The Slop Continuum

Dex framed the current debate as a spectrum that Alex Volkov named at AI Engineer Europe. At one end sits Mario Zechner, who argues you should always read the code a model produces. At the other end sits Ryan LoPopolo of OpenAI, who wraps a model in a thick harness of tests, linters, and browser checks so features come out the other side and you never read code. Where you land depends heavily on the stakes of what you are building: nobody should close their eyes on life-or-death systems, and even boring work in regulated industries can carry real consequences — a logic bug that costs a financial customer millions in fines, for instance.

What SlopCodeBench Measures

Most models now score around 85 percent on SWE-bench, which makes them hard to tell apart, so the field needs fresh benchmarks that are far from saturated. SlopCodeBench fits that description, with GPT-5.5 reaching about a 15 percent strict solve rate and other models scoring lower. What makes it different is that it feeds a model its own code across increments rather than posing one self-contained task. The paper also reports deterministic code-quality measures such as cyclomatic complexity, cognitive complexity, and duplication. Those checks describe what happened to the code — and Dex noted the models will not produce clean design on their own unless you ask them to.

More Lines, More Tests, More Time

When Dex ran the newest models, Opus 5 wrote roughly 30,000 lines on a task where other models wrote fewer than 10,000, and about half of the Opus output was tests. Writing tests is now baked into the model's default behavior, a healthy change — though it also means runs take longer and produce more to review. A full run on the strongest model cost him around $200, which he tracked with an HTML dashboard that Claude built for him while the benchmark ran in the background.

Keep Retuning Your Intuition

Because the models keep improving, Dex recommends Simon Willison's habit of regularly trying tasks you assume the model cannot do — roughly one in every ten things you attempt. Austen described giving himself a little jolt of what he jokingly calls AI psychosis every few months so he doesn't get stuck believing the model is bad at something it can now handle. The same logic applies to your CLAUDE.md and skills files: their job is to hold the knowledge that is not in the model's weights, such as the exact command to run this project's tests, and you should remove instructions the model has since learned to follow on its own.

The Plan Is the Real Review

Dex's team reviews the thinking before the code. They start with a product review, including rough HTML mockups of every screen, then move to system architecture — new endpoints, tables, and how services talk to each other. The step he considers most underrated is program design, which goes one level deeper into function names and call graphs so the structure is clear before implementation. Visual plans with diff-style code blocks make it cheap for a junior engineer to get steering from senior teammates, and they let everyone agree on structure while it is still easy to change.

Making Code Review Humane

The best pull request is one that needs only a small comment or a variable rename, and you get there by agreeing on the plan before coding starts. Dex often asks his co-founder to skim a short design doc for five minutes rather than waiting for feedback after the code is polished and he has grown attached to it. For large changes, his team auto-generates an HTML view of any pull request over 200 lines — an idea a peer shared that they call a diff tree, which orders files by how the feature was built rather than alphabetically. He suggests engineers try building one with Claude, since it takes about 30 minutes of back-and-forth to get something useful.