# Generation Is Cheap, Review Is Expensive: How to Stop Shipping AI Slop — Gabriel Martinez, G2i

## Executive summary

Gabriel Martinez argues that the current AI-driven development cycle is prone to 'slop'—work that appears finished but lacks deep human judgment, ownership, or understanding. He asserts that while generation is cheap, evaluation and maintaining system coherence are expensive. The core message is that engineers must slow down, prioritize clear conventions, and shift the review surface from massive code blocks to high-level diagrams and defined boundaries to prevent the codebase from becoming an unmanageable 'ball of mud.'

## Key takeaways

- Defining Slop: Slop is not AI-generated code, but rather work product where ambiguity was cleared with guesses, trade-offs were left to chance, and ownership was not taken. The danger is that the engineer never noticed the choice or constraint that needed to be addressed. (0:37)
- Code as a Liability: The cost of understanding a software program is not falling, even as the cost of writing code decreases. Good software must reflect the shape of the domain, and AI cannot magically give a messy system coherence. (3:06)
- The Review Bottleneck: External pressures and the speed of AI generation lead to massive PRs and bloated documentation, shifting the cognitive burden to the reviewer. Generation is cheap, but evaluation is expensive. (8:45, 10:14)
- Optimizing for Human Judgment: To combat slop, teams must adopt conventions, use diagrams as the primary review surface (showing service boundaries, data flows, and state transitions), and establish clear ownership boundaries. (12:34, 14:13)
- The Role of ORC: The speaker's company, G2i, built ORC to address the failure pattern: AI can generate code, but the surrounding discipline (planning, review, context management) is still required. ORC aims to preserve human responsibility while leveraging AI's generation capabilities. (15:43)

## Technical details

- Slop Definition: Output that looks finished before the thinking is finished; characterized by unaddressed ambiguities and lack of clear ownership. (0:37)
- Codebase Coherence: The code should reflect the shape of the domain. A system that is already a 'big ball of mud' will not be rescued by an agent; it will just build the ball bigger, faster. (4:01)
- Review Surface Optimization: Instead of reviewing thousands of lines of code, focus on diagrams that illustrate service boundaries, data flows, state transitions, and failure modes. (12:34)
- Framework Conventions: Frameworks like Rails succeed by aggressively reducing the decision surface and lowering cognitive overhead through conventions, allowing engineers to move laterally between projects easily. (14:13)
- ORC System: A system designed to manage the workflow by baking in human processes like planning, review, and adversarial checks, ensuring the output remains coherent and owned. (15:43)

## Practical implications

- Shift focus from lines of code (a garbage metric) to the clarity of system shape and domain boundaries.
- Implement mandatory review processes that focus on high-level diagrams and architectural flows, rather than deep implementation details.
- Establish clear ownership and accountability metrics for every chunk of work product to force meticulous review.
- Adopt strong conventions and standards (like those found in Rails) to reduce cognitive overhead and make the system more legible for both humans and agents.

## Topics

AI Development, Software Architecture, Code Review, Technical Debt, System Design, Process Engineering, ORC by G2i, G2i

Source: https://www.youtube.com/watch?v=6qkzlT962es