Let's start with the core dilemma, because everything else is downstream of it: how do we guarantee quality at AI code-generation velocity? In other words, how do we preserve our standards for code quality without canceling the speed boost that AI gives us in the first place?
Two opposing positions have started to crystallize in response to this question, and most teams I talk to are pulled between them.
Story of Two Camps
Let's call the first camp the pragmatic radicals. Their thesis is direct: humans are slowing AI down. The way forward is to remove humans from the inside of the loop and focus entirely on the envelope — guardrails, code-quality gates, tests, output expectations, requirements, specs. What's happening inside the code? Nobody really cares. Caring means slowing things down to human speed of comprehension, which cancels the benefits AI brings. Simple!
In the opposite corner is the Proof of Understanding camp. Let's call them for this occasion the Signatories (because what they're really doing is putting their signature of understanding on the code: a personal stamp that says I grasped this, I considered the alternatives, I take responsibility for it even if AI was doing code generation). They are willing to pay a price in delivery speed in exchange for developers actually understanding what AI-generated code is doing. The artifact this camp produces — and the one I want to argue for — is something I'll call Proof of Understanding (PoU for short).
Until now, the traditional process has been: a PR reviewer, some back-and-forth between proposer and reviewer, issues closed, merge. The PoU camp adds something to this. They keep all the existing quality gates: pre-commit and pre-push hooks for security, formatting, and quality checks; roaming AI agents inspecting the codebase for bugs and inconsistencies; specialized AI PR reviewers like CodeRabbit; the human reviewer scanning the diff. But none of this guarantees that anyone on the team actually understands what's going on inside the code.
That's where Proof of Understanding comes in: a human-written document that explains the mechanism, justifies the decisions, and considers the alternatives. It's defended in front of colleagues — with real questions — before merge. Only when the team is satisfied with the defense, and all the automated gates are green, does the merge button get pressed.
The Problem With Both Camps
The pragmatic-radical position fails because tests and guardrails only catch what someone already thought to check. The space of "reliable result" is defined by your imagination of failure — and that imagination is precisely the thing the radical position wants to outsource. Somebody, somewhere, has to know what reliable means in this domain. You can't outsource the shape of the constraint to the thing being constrained.
But the Signatories fail too in their pure form, and they fail for a reason their advocates don't usually admit: nobody has ever fully understood a real production codebase. Google's monorepo, the Linux kernel, any ten-year-old fintech system — these are operated by humans who hold fragments of knowledge and understanding within their imperfect human brains, trust contracts, and hope for the best. Demanding a Proof of Understanding artifact for every PR can turn the practice into ritual, or worse, into something the AI writes too! Now the AI writes the code and the justification, and the human's signature is the only authentically human thing in the loop — and it isn't doing much. Kind of a pragmatic radical, just concealed under a PoU mask.
So we need a third position, and it's the one that eventually can work.
The Third Position: Focused Understanding at the Fault Lines
Understanding is a budget. You can't spend it everywhere. The question isn't whether to understand — it's where and what.
The places worth understanding are what I call fault lines: the load-bearing seams of a system where local changes have non-local consequences. Operationally, fault lines are where:
Fan-out is high. A function called from forty places is a fault line; a function called from two is glue. A wrong decision at high fan-out propagates everywhere.
Trust boundaries sit. Authentication checks, input validation, permission gates — anything crossing from untrusted to trusted territory.
State transitions live. Database writes, queue enqueues, financial transactions, external API calls with side effects. Wrong state transitions are expensive and often silent.
Invariants are asserted. Places where the code claims something will always be true, and downstream code assumes it.
Concurrency meets shared state. Locks, transactions, idempotency keys, retry logic. Famously impossible to test into correctness.
Contracts are defined. API schemas, database migrations, message formats, public function signatures. Once published, expensive to change.
Notice what this list excludes: most CRUD handlers, most serialization, most config wiring, most UI rendering, most one-to-one data transformations. Probably 70-85% of a typical codebase. That's where the machine earns its keep. That's the glue.
The prioritization rule is simple: spend understanding in proportion to blast radius × asymmetry of outcomes. Reversible mistakes rank lower than irreversible ones. The auth system and the database schema are always high priority. A utility called by one handler usually isn't.
This is what PoU actually targets. Not every PR. The PRs that touch fault lines. A change to the JWT refresh logic gets the full treatment: written explanation, defended in front of the team, alternatives considered, tradeoffs documented. A change to a CRUD handler that adds a new optional field gets AI review and a quick human glance. The cost of understanding is paid exactly where it buys you something. The Signatories sign where signing matters; everywhere else, they let the machine work.
This is the synthesis:
Machines write everything; humans understand the seams.
The Deeper Question: Collaboration Mode vs Autopilot
Now let's go one step deeper, to the level where dilemmas of this kind actually surface.
The real question is: are we using AI in collaborative mode, or on autopilot?
In autopilot mode, AI is an autonomous producer. You give it a goal and accept the output. You're not in the loop; you're at the boundary. The pragmatic-radical position implicitly assumes this is where we are, or where we're heading fast.
In collaboration mode, AI is a new colleague at the table. A capable one, but still a collaborator — one that produces its best output when there's a competent human on the other side driving the conversation. This isn't new. Human teams exist precisely because complexity overwhelms individuals; we chunk reality, build specialized expertise, then come together to produce collective intelligence. Today the table has a new digital colleague sitting at it. To get the most from that colleague, you have to be competent enough to challenge it, redirect it, and recognize when it's confidently wrong.
I want to argue that for the next five to ten years, we are squarely in collaboration mode. And that has consequences the radical position doesn't want to acknowledge.
There's a specific epistemic asymmetry between AI and a human colleague that matters here. A human colleague has stake. Their reputation, their standing, their career are on the line. This doesn't mean humans always speak up — they don't. They strategically avoid conflict, defer to hierarchy, swallow objections because disagreement is unpleasant. But when a human colleague does push back, the pushback carries weight precisely because it cost them something to make it. That cost is the signal. AI doesn't have stake. Its agreement is free, its disagreement is free, and even its objections carry no information about conviction. It will quietly shape itself to your frame unless you actively resist that shaping — and when it doesn't shape itself, you have no way to tell whether the disagreement means anything or whether it would have agreed equally fluently with the opposite position five minutes ago. There's something hollow behind the discursive surface that LLMs produce and it look's like an absence of logical principles and real thinking, a fluency without anchoring.
This is the part the autopilot position misses entirely. When you delegate fully, you don't get an autonomous agent producing answers; you get a sophisticated mirror producing fluent versions of your own undefended assumptions. The output looks like reasoning. It isn't. There's nobody behind it.
The only defense against this is for the human to remain the stakeholder. Which means staying competent enough to push back. Which means understanding. Not everything — see the fault-line argument above — but enough at the right places that you can be a real epistemic agent in the conversation.
So is knowledge and understanding still the name of the game in AI-driven programming? For the foreseeable future: emphatically yes. Not because of nostalgia. Because the collaboration only produces good output when one of the two participants is actually present.
Beyond the Window: The Experience Argument
But what about ten years out? What about AGI, or superintelligence, or a moment when AI genuinely is on autopilot and produces better code than any human-AI collaboration could?
Even then — and this is the second emphatic yes — I think humans should resist the temptation to fully delegate.
The reason is simple, and it has nothing to do with utility. People often confuse the instrumental value of physical strength or intelligence with the value those faculties have to the person who possesses them.
Consider physical strength. There was a time when strength was instrumentally vital — you needed it to plow the field with a hand plow. Then tractors arrived, and the instrumental value collapsed. It would be many orders of magnitude more efficient to use the tractor. But this didn't mean humans should abandon physical activity and atrophy into obesity. A fit body, from the human perspective, has value even when it has no practical use. A strong, active body lets you have a fuller life even when you're not fighting lions or plowing fields. It's just better.
The same logic applies to cognitive faculties. Even if we can delegate every cognitive task to a machine that delivers more quality, faster and cheaper, we should not stop thinking. The point isn't moral or virtuous. The point is phenomenological: having faculties is constitutive of a richer experience of being alive, the same way having five senses is richer than having one. Nobody thinks five senses is a moral choice. It's just obviously a fuller way to exist. Cognitive faculties are like that. Remembering, calculating, reasoning through rather than around — these aren't disciplines you impose on yourself. They're modes of being present to your own life.
This cuts against human nature, and that's the difficulty. Our default state is to avoid effort and maximize comfort. The arrival of AI is an enormous temptation to delegate everything and take the path of least resistance. The honest answer is that we'll need to introduce a kind of artificial scarcity — voluntary resistance — to preserve the faculties that make experience rich. Not because we'll need them for output. Because we'll want them for ourselves.
This is the second emphatic yes. In the collaboration window we're in now, knowledge and understanding are professionally load-bearing — they're how the human-AI partnership produces good work. In any future where that partnership becomes unnecessary, knowledge and understanding remain personally load-bearing — they're how being human stays worth being.
Where This Leaves Us
So: two answers to the same question, on two different timescales.
For the next five to ten years, while we're in collaboration mode, the answer is operational. Build PoU into your team's workflow at the fault lines. Concentrate human comprehension where the blast radius justifies it. Let the machine handle the glue. Stay sharp enough to be the stakeholder when the AI's output needs to be challenged, because if you're not the stakeholder, nobody is.
For the longer horizon, when the collaboration window may close, the answer is personal. Resist the comfort of full delegation. Keep the faculties not because you need them, but because having them is part of what makes a life worth having.
In both cases, the conclusion is the same — knowledge and understanding is still the name of the game. The reasons just shift, from professional to phenomenological, as the window changes.
That's the bet I will make. The pragmatic radicals are betting against it. We'll find out who's right soon enough.
Top comments (0)