Verified as of July 11, 2026. This analysis tracks shifts in developer workflows, agentic coding debates, and software verification practices.
- The Viral Spark: ‘How Do You Measure Success?’
- AI as a Disposable Sketchpad: The Real Workflow
- The Limits of Machine Optimization: The ‘Agent Psychosis’ Warning
- The Spectrum of Code Reading: Three Developer Archetypes
- The Fallacy of the Compiler Comparison
- FAQ
- Sources
Key Takeaways
- The Origin: When questioned on X about how he validates and measures the success of using AI in his projects, Ghostty creator Mitchell Hashimoto replied: “I read the code.”
- The Real Workflow: Rather than relying on multi-model pipelines for production, Hashimoto uses LLMs to write “complete trash” and “fully sloppified demos” to test directions, then rewrites the code by hand from scratch.
- The Agent Psychosis Warning: Hashimoto warned against blindly trusting agentic optimization after an agent cut a renderer’s frame times from 88ms to 2ms and allocations from ~150K to 500. He manually rewrote it in Go to verify the result.
- The Debate: The exchange highlights the shifting role of the software engineer from a writer of code to an editor who must verify probabilistic, machine-generated outputs.
The software engineering community is experiencing a division over how to integrate artificial intelligence into daily workflows. While some advocates promote fully autonomous agents that write and commit code without human oversight, a viral exchange has brought the focus back to the necessity of manual review.
The Viral Spark: ‘How Do You Measure Success?’
The discussion began on X when Mitchell Hashimoto, creator of the Ghostty terminal emulator and co-founder of HashiCorp, responded to questions about his use of large language models in software development. When a user asked what metrics he used to measure the success of using AI models and catch bugs, Hashimoto replied with a simple statement:
“I read the code.”
This two-word response generated widespread discussion across Hacker News, Reddit, and X. For many engineers, it served as a reminder that regardless of how advanced generating models become, final verification remains a human responsibility.
This skepticism aligns with Hashimoto’s prior work calling out automated code submission practices, as detailed in the analysis of how Mitchell Hashimoto exposed the open-source AI slop pipeline.
AI as a Disposable Sketchpad: The Real Workflow
While some online narratives have framed Hashimoto as someone using complex, multi-model pipelines to write production code, his actual approach is far more pragmatic. In a recent interview, Hashimoto described his AI usage not as a structured pipeline, but as a method for rapid, disposable prototyping.
Hashimoto explained that he uses LLMs to quickly build “fully sloppified demos” where the generated code is “complete trash.” The goal is not to ship this output, but to quickly verify whether a specific feature or architectural direction is useful.
If the prototype proves successful, Hashimoto discards the AI-generated code entirely and rewrites the implementation by hand with the care it deserves. This approach treats AI as a digital sketchpad rather than an automated factory, keeping production codebases clean and fully understood by their human maintainers.
The Limits of Machine Optimization: The ‘Agent Psychosis’ Warning
To illustrate the dangers of relying uncritically on machine-generated code, Hashimoto shared an optimization experiment involving a software renderer. He ran an automated coding agent in a loop to optimize his codebase.
The agent reported spectacular metrics, reducing frame times from 88ms down to 2ms (roughly a 44x reduction) and dropping allocations from approximately 150,000 to just 500. However, instead of celebrating the metrics, Hashimoto reacted with explicit skepticism, calling the phenomenon “agent psychosis.”
His post served as a warning about trusting suspiciously good agent-reported metrics without deeply understanding what actually happened under the hood. To verify the agent’s work, he manually rewrote the renderer in Go under the same constraints, ensuring the logic was sound and correct rather than blindly accepting the machine’s telemetry.
This experiment highlights a critical limitation of modern AI coding assistants. While they are highly effective “typing accelerators” that can quickly apply standard optimization patterns, they lack the deep, first-principles reasoning required to design high-performance architectures without producing silent errors or logically incomplete designs.
The Spectrum of Code Reading: Three Developer Archetypes
The developer community’s response to the “I read the code” debate highlights that code verification is not a simple binary. Instead, engineering workflows are organizing around three distinct archetypes:
1. The ‘Vibe Coding’ Exploration
For early-stage prototyping, minimum viable products (MVPs), and internal utility scripts, reading the code is often unnecessary. Developers practicing vibe coding prioritize speed and immediate user feedback. This aligns with Hashimoto’s concept of the “sloppified demo” (using AI to test ideas quickly with the explicit intention of throwing the code away).
2. Manual Verification of Every Line
For core systems, terminal emulators, and safety-critical software, engineers choose to inspect every line. In performance-sensitive environments, introducing unverified, machine-generated code introduces unpredictable behavior that is difficult to debug later. For these systems, human control over memory allocation and execution flow is non-negotiable.
3. The Harness-Driven Middle Ground
A growing number of developers are adopting a hybrid approach: designing software at the interface, type, and API levels. The human engineer defines the structure and the integration logic (the harness), while the AI agent generates the individual function bodies.
This workflow is supported by a multi-model strategy, leveraging premium models for planning and cheaper, faster models to write code, similar to how American developers adopt Chinese AI models to optimize their token budgets.
The Fallacy of the Compiler Comparison
A common argument in defense of not reading AI-generated code is comparing large language models to compilers. Proponents argue that developers do not read the assembly or machine code output by a compiler, so they should not need to read the code output by an LLM.
However, software practitioners point out that this comparison is technically flawed. A compiler is a deterministic tool: it takes structured code and translates it according to strict rules. If the source code is correct, the compiler’s output is guaranteed to be semantically identical.
In contrast, an LLM is a probabilistic engine. It predicts the most likely next token based on patterns in its training data. Because LLMs are prone to hallucinations and can generate incorrect code that appears correct, treating them as compilers introduces significant security and operational risks. As U.S. providers restructure their pricing (such as the recent Claude Fable 5 credits-only pricing shift), developers must weigh whether the speed gains of unchecked AI generation justify the long-term maintenance costs.
FAQ
What is the “I read the code” debate?
It is an industry discussion about the necessity of human engineers manually reviewing and verifying AI-generated code rather than deploying it automatically.
Does Mitchell Hashimoto use AI to write production code?
No. Hashimoto uses AI to write temporary, throwaway prototypes (“sloppified demos”) to test ideas, and then rewrites the final production code by hand.
Why is comparing AI to a compiler incorrect?
Compilers are deterministic tools that translate code according to fixed rules, whereas LLMs are probabilistic engines that can generate incorrect or hallucinated logic.
What was Mitchell Hashimoto’s ‘agent psychosis’ warning?
It was a warning against blindly trusting agentic optimization after an agent reported reducing a renderer’s frame times from 88ms to 2ms. Hashimoto manually rewrote the renderer in Go to verify the result.
Sources
- Developer Workflow Interview: Mitchell Hashimoto Programming Q&A
- OpenRouter and Model Stats: OpenRouter API Statistics
- AI Coding Tool Evaluation: Hunk Review and Refactoring Portal
- Developer Community Discourse: Hacker News AI Code Quality Threads
About the Author
Ether Exter is an AI enthusiast with 5 years of experience testing and experimenting with AI models, breaking down what actually works. Follow on X: @EtherExperiment.
