The Brain Sandwich
terriblesoftware.org
October 18, 2026
2 min read
46/100
Summary
Engineer Emily’s “Brain Sandwich” framework places human judgment before and after AI-assisted implementation: understand the work first, delegate coding work to AI, then review and explain the result before seeking peer review. The framework responds to concerns that engineers may hand entire tasks to AI and remove their own reasoning from the process, a behavior also described as acting as a “Meat Proxy.” Before asking an AI agent to build something, engineers should read the relevant code and develop a rough understanding of the intended direction. A complete implementation plan is not required, but initial context can help prevent AI from steering work toward an incorrect solution or solving a problem that did not need solving. AI can then be used to fully delegate the implementation phase. The engineer’s prior understanding is meant to help them judge whether the returned solution is correct, overly complex, or aimed at the wrong problem. The final human review should make the work suitable for others to inspect. Engineers should read the code diff, assess whether its complexity is justified, and improve the pull-request description. Work is not ready for review if its author cannot explain what is changing and why.
Key Takeaways
- The “Brain Sandwich” sequence is human understanding, AI implementation, then human review.
- Engineers should develop a rough understanding of a task before prompting an AI agent, even without a full implementation plan.
- AI can be used to fully delegate implementation, while engineers retain responsibility for judging whether the result solves the right problem.
- Before peer review, engineers should inspect the diff, evaluate complexity, and clearly describe the changes and their rationale.
What the discussion said
The thread treated the Brain Sandwich less as a clever workflow label than as a losing fight against the economic incentives of agentic coding. Its core prescription is straightforward: a person should understand the relevant system before asking an LLM to alter it, then personally validate what comes back. Several commenters called that a critical discipline, especially for security-sensitive or reliability-critical work, because delegating comprehension leaves teams unable to judge failures, architecture, or future modifications. One reader also saw the practice as a way to retain a sense of authorship rather than becoming a passive conduit for model output. But the dominant mood was doubtful that this discipline will survive real workplaces. Faster delivery is the actual promise organizations are buying, commenters argued, and managers often reward output long before they pay the eventual cost of understanding. That creates codebases assembled from plausible explanations and agent-generated changes that nobody can confidently reason about. Reviews may worsen rather than improve: AI produces more unfamiliar code, and verifying it can take longer than reviewing code written by a colleague or oneself. A smaller group pushed back on treating AI as inherently second-rate, arguing that capable models can find stronger designs when given tests, iteration, and room to explore. Others said using agents to locate the relevant code first is a sensible shortcut, not an abdication of responsibility.
Where opinion split
The sharp split is over whether engineers must understand an area before letting an AI change it. Supporters say upfront comprehension is the only defense against opaque, fragile systems and false confidence; critics say it wastes time discovering and reading the wrong parts of a large codebase, where an agent can efficiently narrow the search before the human evaluates the result.
Community Sentiment
Positives
- Human-guided prompting and post-generation verification give engineers a practical guardrail against treating model output as automatically trustworthy.
- For kernels, security work, and other failure-intolerant systems, the workflow offers a way to use AI without surrendering deliberate engineering judgment.
- Well-equipped models can sometimes beat the engineer's first design when tests and iterative feedback let them search rather than merely obey a narrow recipe.
- Using agents to map a large codebase before human review can cut costly exploratory reading while preserving final technical accountability.
Concerns
- AI coding is pulling developers toward passive proxy work, where they transmit requests and accept results without retaining the understanding needed to challenge either.
- Delivery pressure makes careful human comprehension an unlikely norm, setting up organizations to trade short-term velocity for codebases nobody can safely modify.
- Accumulated agent-generated changes risk becoming an opaque system held together by guesses, leaving teams unable to explain architecture or predict consequences.
- LLM output can expand the review burden: reviewers face more code, less familiarity with its origin, and a harder job proving that plausible-looking changes are correct.
