Building Projects with AI: Learn to Code First? Uncle Bob Says No—Skip Reading the Code, Define the Standards

From "Bookmarking Courses" to "Never Starting": A Common Dilemma

When many people want to build something with AI, their first instinct is to bookmark an entire set of programming courses, planning to learn the frameworks and deployment before getting started. As a result, the bookmarks pile up while the project never begins. Behind this path dependency is a default assumption: you must first learn programming before you can direct AI to do the work.

But that assumption is being broken. Robert Martin (known to everyone as Uncle Bob) has been writing code for decades and wrote Clean Code. His current approach is this: he doesn't read the code his agent writes—he relies on a strict ring of automated checks, with pass criteria defined in advance. It's a controversial approach, but what he's swapping out is worth a look.

Uncle Bob's "Don't Read the Code" Experiment: Trusting the Evidence

What lets Uncle Bob dare not to read the code isn't that he "learned less"—it's that he "swapped what he learns": from reading every line to defining standards and reviewing evidence. This sounds like laziness, but it actually shifts cognitive load from "process monitoring" to "result acceptance."

The controversy is: without reading the code, how do you guarantee quality? His answer is the automated verification loop. This isn't just running a few tests casually—it means writing "what counts as correct" as executable criteria in advance. The agent's output must pass through this filter; if it doesn't, it starts over.

For people who don't write code, this shift is actually good news. You don't need to learn to read every line first; what you need to learn is "what counts as correct" and "what proves it." And "what counts as correct" is something you already have a yardstick for in your own field.

Automated Verification Loop means writing "what counts as correct" as machine-executable criteria—unit tests, type checks, static analysis, integration tests, etc.—that all code must pass before merging. What distinguishes it from "running a few tests casually" is that the criteria are defined in advance and exhaustively, rather than validated after the fact against a hand-picked handful of cases. For people who don't read code, the value of this mechanism is that it converts quality assurance from "human reading comprehension" into a "repeatable, auditable pass/fail signal"—you don't need to understand the implementation, only confirm the chain of evidence is complete.

Two Costs: Effort Cost and Cognitive Cost

Not reading the code doesn't mean knowing nothing. For the work you hand off, you need to have a clear picture of what goes in, what comes out, and what counts as correct—otherwise, even with the evidence in front of you, you won't understand it. There are two costs to minimize here:

• Effort cost: You don't have to do every step yourself, only step in at key points. Once the verification ring is set up, it checks the work for you every time.
• Cognitive cost: You don't need to learn everything, but the interface's inputs and outputs and the acceptance criteria must be clear. This is the minimum bar for "understanding the evidence."

There's a clear line between "don't need to learn everything" and "know nothing": the former is giving up procedural skills, the latter is giving up judgment. Uncle Bob's approach works because he externalizes judgment into executable checks.

Procedural skills vs. judgment is the key distinction here. Procedural skills are the operational abilities needed to personally complete an implementation—writing syntax, calling APIs, configuring deployment. Judgment is the ability to assess whether output meets the goal—defining input/output contracts, identifying failure modes, distinguishing "it runs" from "it runs correctly." What AI lowers is the marginal value of the former; what it raises is the scarcity of the latter. Giving up procedural skills isn't giving up judgment—on the contrary, it requires you to make judgment explicit and executable, or you won't be able to interpret the evidence even when it's in front of you.

How Non-Programmers Can "Read the Evidence"

For non-programmers, this logic boils down to concrete actions. You don't need to know how APIs are called, but you need to know: what this feature takes as input, what it outputs, and under what conditions it counts as a failure. You don't need to know how to deploy, but you need to be able to tell the difference between "it ran" and "it ran correctly."

The evidence can take very plain forms: a set of test cases, a side-by-side output comparison, a reproducible checklist. The key is that this evidence must be defined before you start, not patched together afterward.

A reproducible checklist is a practical tool that lets non-programmers participate in acceptance: break the feature into items of "given input X, output Y should result; if Z appears, it's a failure," each independently executable with results you can compare. Its purpose is to turn a vague "feels right" into a binary judgment, so people who don't read code can decide to accept or reject based on evidence. The key is that the checklist must be defined before starting—a checklist patched together afterward tends to accommodate whatever results already exist, losing its value as acceptance.

What to Learn, What Not to Learn

The traditional path requires learning syntax, frameworks, and deployment first, then building. The new path requires defining standards first, then building checks, then letting the agent do the work—with humans stepping in only at acceptance. The fork between the two paths is this: do you spend your time on "being able to do it yourself" or on "being able to judge whether it's done right"?

Uncle Bob's choice doesn't apply to everyone, but it reveals a transferable principle: once AI lowers the cost of execution, the scarcity of judgment rises. For people who want to build projects with AI, learning to code first is no longer the only entry point. Learning to define standards and read evidence first may be a shorter path.

One-line Summary

Uncle Bob doesn't read code and relies on automated checks for acceptance—showing non-programmers they should learn to define standards and read evidence rather than learn to code first.

Paragraph Summary

The article starts from the common dilemma of "bookmarking courses but never starting" and points out that the assumption "you must learn programming before directing AI" is being broken. Using Robert Martin (Uncle Bob) as an example—he doesn't read his agent's code and relies on an automated verification loop with pass criteria defined in advance—it shows that trust can shift from "process monitoring" to "result acceptance." For non-programmers, this means you don't need to learn to read every line; you need to learn "what counts as correct" and "what proves it." The article further proposes minimizing two costs: effort cost by stepping in at key points, and cognitive cost by giving up procedural skills while retaining judgment, and offers plain forms of evidence such as test cases, side-by-side output comparisons, and reproducible checklists. The conclusion: as AI lowers execution costs, the scarcity of judgment rises—defining standards and reading evidence first may be a shorter entry point.