Should Developers Stop Reading Code? GPT 5.6 Era
With advanced AI models like GPT 5.6 and Fable, the debate over whether developers should read code has intensified. While not reading code entirely is impractical, developers already skip most code (OS, databases, frameworks). The real issue: AI is non-deterministic and makes architectural mistakes humans wouldn't—like duplicating code instead of making it reusable. The future isn't about reading less code, but building better systems and delegation structures so AI fills in gaps responsibly.
The Current State: We Already Don't Read Most Code
Layers of Code We're Not Responsible For
Developers already skip reading vast amounts of code: operating systems, database engines, language runtimes, libraries, frameworks, and component libraries. Most shipped code comes from these layers, yet individual developers are responsible for only a small portion of what they deploy.
Human vs. AI Code: Different Trust Models
There's a critical distinction between not reading AI-generated code versus not reading code written by other humans. With human-written libraries and frameworks, developers establish trust through community oversight and reputational risk—thousands of people ensure quality. This safety net doesn't exist for AI code.
Developer Roles and Responsibility Levels
The Spectrum of Developer Responsibilities
Developer roles exist on a spectrum. Junior developers primarily implement code. Mid-level developers design and implement. Senior/tech leads design, delegate, and make architectural choices (frameworks, databases). Managers and directors rarely write or read code. Each level has overlap with adjacent levels, but design is always the most critical responsibility because implementation depends on it.
Where AI Models Fall Short
The Duplication Problem: AI Lacks Architectural Sense
A concrete example: when duplicating functionality across pages, an AI model duplicated thousands of lines of code instead of making components reusable—something no human developer would do. Humans understand the long-term pain of duplication and maintenance costs. AI requires heavy steering from developers to make good architectural choices, even with advanced models like Fable.
Non-Determinism: Same Input, Different Output
AI models like Fable are non-deterministic. Given identical conditions (same branch, same app state), the model might decide to test a port in one chat and spawn a new instance in another. This unpredictability means AI cannot work like a compiler—which abstracts away complexity reliably. Developers must constantly steer and verify.
The Leaky Abstraction Problem
Abstractions like compilers work reliably most of the time. AI doesn't. Developers want to operate at a high level without understanding implementation details, but AI's non-determinism and architectural blind spots force them to drop down and steer constantly. This is why even advanced models require significant developer involvement.
The Real Future: Systems Over Micromanagement
Ownership vs. Hands-On Reading
A CEO is technically responsible for code a junior writes, but cannot read every line. The solution isn't micromanagement—it's building systems: least-privilege permissions, static typing, automated checks, and culture. The same principle applies to AI code. Developers can own outcomes without reading every line if systems are in place.
Loops Engineering and Software Factories
The emerging approach isn't about developers reading less code—it's about setting up systems (permissions, type safety, architecture patterns) so AI can fill in gaps responsibly. This requires thought and design work upfront, not just delegating to models. The Bun rewrite from Zig to Rust exemplifies this: language choice is a system-level decision, not a skill issue.
The Speed vs. Correctness Trade-Off
There's a balance between going fast (risk of slop) and going slow (never ship). Moving toward higher-level design and delegation is the goal, but the industry isn't there yet. Most developers still need to operate at lower levels for complex work. The key is knowing when to push forward and when to slow down and verify.
Current Practice: Still Steering AI Models
Even the video creator, working with advanced models, still uses faster models for smaller-scoped tasks and doesn't see that changing soon. They operate below the ideal delegation line, steering AI constantly. This suggests that for most real-world use cases, developers will remain deeply involved in code review and direction for the foreseeable future.
The Nuanced Answer
When It's Okay Not to Read Code
The creator admits to shipping code they didn't closely read in recent months. This is acceptable when systems and ownership structures are in place—similar to how a CEO doesn't read every line. The question isn't binary (read everything vs. read nothing), but about where on the spectrum responsibility and trust are appropriately distributed.
Why Developers Resist Full Delegation
Many developers operate at implementation levels even when they could delegate, often because they don't want to give up control. This is a human preference, not a capability issue. Technical people are often more capable of higher-level work than non-technical managers, but many choose hands-on coding instead.
Notable quotes
The design part is really always been the most important part of software development. — NeetCode
LLMs are machines. They can write tons of code quickly. But they also just do dumb things. — NeetCode
It requires a lot of steering, a lot of steering that only a developer could do. — NeetCode