Slop is work that looks finished before the thinking is finished, whether or not AI produced it.
2
AI lowers the cost of generating code while leaving the cost of understanding, reviewing, testing, and owning software in place.
3
Teams should keep humans in control with conventions, diagrams, small reviewable changes, clear ownership, and explicit definitions of done.
Summary
Gabriel Martinez defines slop as output produced before the judgment behind it is complete. The problem is not simply bad AI code. It is that ambiguity gets resolved with guesses, trade-offs go unnoticed, and engineers fail to see the choices they are accepting. AI makes code and documents cheap to produce, but it does not reduce the human work of understanding system behavior, testing features, reviewing trade-offs, or owning maintenance. Martinez describes how prototypes, productivity pressure, token counts, large pull requests, and polished AI documents push that work onto reviewers. His response is to preserve software structure and human review through conventions, architectural patterns, diagrams, small changes, and clear ownership. He points to Rails as an example of reducing repeated decisions through convention. G2i built ORC around the same concern, adding planning, context management, review, and adversarial checks around agent-generated work rather than trying to automate engineering judgment away.
Martinez says slop is not the same as AI-generated code. It is output that looks finished before the thinking is finished. Ambiguity has been cleared with guesses, trade-offs have been left to chance, and nobody has taken ownership of the decision. The danger is that an engineer may never notice there was a choice to make. Software records technical, product, operational, and user-facing choices, so accepting output without seeing those choices means accepting work without really engineering it.
Agents cannot replace the human decisions around a system
Agents can write code, scaffold screens, and build whole features or systems with the right tuning. Martinez says they still cannot decide what matters, understand what is being built, interpret ambiguity, own a system over time, or apply restraint at the architecture level. They also cannot decide what not to build. For him, slop comes from the absence of judgment, rather than from AI being inherently bad as a tool.
Every line of code adds to the cost of understanding
Martinez argues that the cost of creating code is falling while the cost of understanding a software program is not. Engineers do not need to read every line in isolation, but they do need to understand the main flows, boundaries, data model, and product behavior. AI can work more effectively in a structured codebase with clear patterns and rationale. In a messy system, it makes the ball of mud bigger and faster. Extra files, abstractions, and components create future confusion, brittle flows, and product surfaces that are hard to change.
Fast prototypes make stakeholders mistake appearance for completion
A few prompts can produce screens and a clickable prototype quickly. Martinez says this changes expectations because stakeholders may treat the prototype as evidence that the hard work is over. They do not see the work outside the happy path, such as clarifying requirements, integrating a feature coherently, manually testing behavior, and checking whether the user experience works. The remaining work includes reading the code, testing it, owning trade-offs, finding missing requirements, and deciding whether the feature belongs in the system.
Pressure to merge turns speed into a misleading performance measure
External stakeholder pressure and competition with people who produce quickly can push engineers to merge pull requests faster than they can judge them. Martinez describes the resulting performance anxiety from seeing other engineers merge at an incredible pace. He admits that this pressure led him to merge code without the level of review he normally should have applied. Large pull requests make the problem worse, so he argues for decomposing work into simple chunks that people can understand and review.
Generation creates a bottleneck when humans cannot evaluate the output
Martinez's central economic claim is that generation is cheap while evaluation is expensive. A small scope can return as a polished 20-page document that takes hours to inspect for actual thinking. A vague task can become a large pull request, and a small feature can become a pile of files. The artifact has the shape of completion, but the unresolved work has moved to the reviewer. If AI produces more than humans can evaluate, the team has not accelerated. It has created a bottleneck.
Diagrams and conventions give humans a smaller surface to review
Martinez argues that diagrams should make systems legible rather than act as decorative documentation. They can show service boundaries, data flows, state transitions, and failure modes while implementation detail moves into the leaves. He also favors declarative code, architectural patterns, documented flows, small reviewable surfaces, clear ownership boundaries, and definitions of done. These choices reduce cognitive overhead, which includes figuring out where code belongs, which pattern to follow, and what the intended implementation is.
Rails shows how conventions reduce repeated decisions
Martinez points to Rails as an example of aggressively reducing the decision surface. When conventions provide one understood way to structure a concept, engineers spend less time choosing among competing approaches. He describes returning to Rails after four years and being able to understand a codebase quickly because its patterns and libraries were still familiar. He connects this to the Rails doctrine, including convention over configuration and optimizing for programmer happiness. He argues that similar consistency helps agents avoid producing many plausible patterns in different styles.
ORC keeps human responsibility around agent-generated work
G2i built ORC after seeing that code generation was improving while the surrounding discipline remained missing. Martinez names planning, review, adversarial checks, and context management as repeated human processes for fighting slop. ORC puts those lessons into a workflow that breaks down work, manages context, weighs options, and helps output enter the codebase in a form the team can still reason about. He describes it as a way to let agents do more work without making correctness disappear as a human responsibility.
