Generation Is Cheap, Review Is Expensive: How to Stop Shipping AI Slop — Gabriel Martinez, G2i
Gabriel Martinez of G2i argues that slop is not AI-written code but work that looks finished before the thinking behind it is done. He connects it to missing judgment, code as a liability, misaligned incentives that reward merging speed over review, oversized PRs and documents that push understanding onto reviewers, and the case for conventions, diagrams as review surfaces, and small changes. He closes by explaining why G2i built ORC to keep humans in control of agent-generated work.
Gabriel “Gabo” Martinez, an engineering manager at G2i who calls himself the resident slop warden, opens with an admission that he is angry about this topic. He notes that the word “slop” has been beaten to a pulp, but the thing it points at has existed for a long time. AI has only made it happen at warp speed. His core definition is that slop is what happens when generation outruns judgment. Slop is not AI-generated code. It is output that looks finished before the thinking behind it is finished, where ambiguity was cleared with guesses, trade-offs were left to chance, and ownership was never taken.
Missing judgment, not AI
Martinez is careful to say he is not an AI purist. AI is not bad, but he argues the industry needs to “sober up” after the rapid advances since late 2025. The real danger he describes is not simply that a machine made a bad choice. It is that the engineer never noticed a choice existed. They never hit the ambiguity, never felt the constraint, and never discovered the edge case that would have changed the design. The work arrives smoothed over, and the unknown unknowns stay unknown.
He frames software as a record of technical, product, operational, and user-facing choices. If engineers do not see those choices, they cannot own them, and if they cannot own them, “we are not really engineering. We are just accepting output.” He is blunt about the resulting role: “a code monkey hitting the merge button.”
He also lists what agents cannot replace: deciding what matters, understanding what is being built, interpreting ambiguity, owning the system over the long haul, exercising architectural restraint, and, arguably most important, knowing what not to build.
Code is a liability
Martinez returns often to the idea that every line of code is a liability and the best code is no code at all. The cost of creating code is falling, but the cost of understanding a program is not. He is explicit that nobody needs to personally read and bless every line. Large systems have always exceeded any individual’s working memory. What must be understood are the main flows, the boundaries, the data model, and the product behavior.
He argues that good software has practical harmony: the code reflects the shape of the domain. An agent works far better inside a codebase with structure, patterns, clear boundaries, and documented rationale. But if the system is already a “big ball of mud,” the agent does not rescue you from the mud. It “just builds the ball bigger, faster.” Just because you can generate another component does not mean the product needs one.
He credits Dijkstra with the line that if we counted lines of code, we would think of them not as lines produced but as lines spent. AI makes it easier to spend lines on files, abstractions, and complexity, and “at the end of the day, you own the bill.” That bill shows up as confusion, brittle flows, features nobody wants to touch, and bloated B2B-style products where every screen has a dozen escape hatches and nobody can say whether the complexity serves users or just accumulated over time.
Accountability and the prototype illusion
He argues teams should be accountable for the work they produce, and that knowing someone else will review your work makes engineers more meticulous. He suggests making accountability metrics visible for each chunk of work.
He also describes the prototype illusion. Anyone can now produce a clickable prototype in an hour, and this has changed expectations. Prototypes can be valuable for exploring ideas, but stakeholders often treat them as evidence that the hard part is finished. They do not see the integration work, the requirements clarification, the manual testing of expected behavior, or the UX polish. The “last mile” is where judgment lives: reading the code, testing behavior, owning trade-offs, noticing missing requirements, and deciding whether the thing deserves a place in the system.
He quotes the creator of SQLite on pull requests: “You say, ‘Oh, it’s free.’ No, it’s not free. What you’re doing is asking me to maintain it for you, to document it for you, to test it for you… for the next 25 years. That is not free.” Martinez says he could not have said it better. It is easy to submit a PR, but someone must own it and live with its consequences.
Incentives and performance anxiety
External pressure from stakeholders, combined with competition from peers who merge quickly, produces a lot of slop. He observes that the engineers who merge the most are not always the ones doing the most valuable work. The detail-oriented engineers who refine specs and review carefully can look slower. This creates performance anxiety, where teams pressure engineers to merge faster than they can judge. Short-term throughput wins over long-term code health.
Martinez admits he has felt this himself. Watching colleagues merge at an incredible pace, he felt constant anxiety about not moving fast enough, and it led him to merge code without the review detail he normally applies. He argues rewards should be tied to producing value: elegant, well-factored, pragmatic design and clear test and evaluation harnesses.
Thousand-line PRs and 20-page documents
He is visibly frustrated by thousand-line PRs. No human can fully understand all the important parts of a change that large. Engineers should decompose needs into the simplest chunks, which makes code easier to understand and control.
He also criticizes AI-generated design documents. In one example, a request for lightweight scope, about ten bullets with a few user journeys, came back as a 20-page polished document that took hours to evaluate. It did not clarify the problem; it expanded it and pushed unresolved ambiguity onto other stakeholders. In code, a vague task becomes a large PR, and a small feature becomes a pile of files. The output has the shape of completion, but the real work has moved to the reviewer.
His central formulation: “Generation is cheap, but evaluation is expensive.” If AI produces more than humans can evaluate, it has not accelerated the team. It has created a bottleneck. He notes that AI is said to be replacing engineers while engineers are expected to match token production, which produces “more characters that eat more human time.”
Hype and enduring principles
Martinez is critical of social media hype. He cites the “Ralph loop,” presented as an agentic breakthrough, which he says is just a while loop. He also points out that lines of code are a poor productivity metric, yet teams sometimes treat the engineer who burns the most tokens as the most productive.
He argues that sixty years of software wisdom have not been invalidated by AI. Composable code, good patterns, and solid practices remain essential. Features should still be broken into small atomic pieces that can be reasoned about and reviewed.
Abstraction, diagrams, and the review surface
Answering a colleague who asked why code shape matters if agents write the code, Martinez agrees that implementation detail will eventually be abstracted away, as it always has been. He traces the lineage from machine code to assembly to C to Java to Ruby, where programmer happiness was the goal. AI is the next abstraction, removing the imperative bits, but it does not remove the need to understand how a system fits together.
This is why he values diagrams, not as decorative after-the-fact documentation, but as a way to make systems legible. When agents generate thousands of lines, humans need a compressed review surface: service boundaries, data flows, state transitions, and failure modes. Diagrams reveal a system’s shape in ways code obscures. The main workflow should be the reviewable surface, with implementation details pushed to the leaves. He favors declarative code and architectural patterns that create layers humans can reason about. The goal is “human knowledge, human understanding, and human review.”
Cognitive overhead, conventions, and Rails
Cognitive overhead is the tax engineers pay before making a meaningful change: figuring out where code belongs, which pattern to follow, and what correct implementation means. AI does not remove this tax and, unless tamed, makes it worse. An agent can produce five plausible patterns in five styles, forcing reviewers to reverse-engineer intent.
His answer is conventions, documented flows, small reviewable surfaces, clear ownership boundaries, and definitions of done. “The more obvious the path, the less room there is for slop to hide.”
He gives special credit to Rails, which he argues shows what happens when a framework aggressively reduces decision surface. Rather than ten ways to structure one concept, you get one, which may not be everyone’s favorite but is understood and works. He describes returning to Rails after a four-year gap and immediately understanding the codebases because the patterns were unchanged. Convention reduces ramp-up time and makes it easier for engineers to move laterally between projects. He ties this to Rails doctrine: optimize for programmer happiness and convention over configuration, eliminating recurring decisions. He also argues that ecosystems with a single prevailing way of doing things are better for agentic development, since agents are not confused by competing approaches.
Why G2i built ORC
Martinez explains that G2i built ORC not because more agents are the answer, and not because engineering judgment can be automated. They kept seeing the same failure pattern: AI could generate code, but the surrounding discipline of planning, review, adversarial checks, and context management was missing. Their teams repeatedly performed the same human processes to fight slop: breaking down work, managing context, weighing options, and ensuring output enters the codebase in a form the team can still reason about. ORC bakes those lessons into the workflow.
ORC is not a magic box that removes human responsibility for correctness. It is a system for preserving that responsibility while letting agents do more of the lifting. The goal is software that remains coherent, tested, maintainable, and owned after generation. In his words, “the future is not vibe coding better, faster. The future is orchestration with judgment.” He closes with a reminder: “don’t get sloppy.”