Comprehension Debt: The Bill Comes Due Alone

I use AI coding agents almost every day. I am not writing this as someone who tried Copilot once, got spooked, and stepped away. I am writing as a solo founder who has leaned into these tools enough to see where the real risk begins.

The code often compiles. It passes the tests and looks clean in the diff. The dangerous gap is between what the system can now do and what I can still explain, debug, and safely change.

That gap is comprehension debt. It accumulates whenever code enters the system faster than a reliable mental model forms around it. On a solo project, there is no independent reviewer who automatically absorbs the missing context. I remain responsible for both the speed and the understanding.

In short

• Comprehension debt is not a synonym for messy code. Clean, tested code can still be poorly understood.
• AI does not create the problem by itself. Accepting changes without building or recording the reasoning does.
• Working alone does not prove the risk is greater than in every team, but it removes the natural chance of a second person carrying an independent mental model.
• My response is to make intent explicit, keep changes small, explain them before accepting them, and stop when verification has moved beyond my understanding.

The Debt That Code Quality Cannot Reveal

Technical debt usually lives in design and implementation choices. Comprehension debt lives in the mismatch between what a system demands from its maintainer and what that maintainer understands. The two can overlap, but they are not the same.

A tangled module may be familiar enough to change safely. A polished module generated in one long agent session may pass every check while leaving no one able to name its assumptions. A dashboard cannot show the difference. The cost appears when the next change requires judgment that was never built or recorded.

There are a few warning signs:

• I need to ask the agent what a recent change does before I can continue working on it.
• The tests pass, but I cannot name the behavior they protect or the failure modes they miss.
• A small change feels risky because I do not know the blast radius.
• The only explanation for a decision is another AI-generated summary.
• I can describe the output, but not why this implementation belongs in this part of the system.

None of these means the code is necessarily wrong. They mean ownership is weaker than the code volume suggests.

What the Evidence Can and Cannot Tell Us

Current research supports taking the risk seriously, but it does not justify one universal verdict about AI-assisted development.

Security. Veracode's 2025 GenAI Code Security Report evaluated more than 100 models across over 80 coding tasks and reported a known security flaw in 45% of its tests.

That figure describes generated solutions in a defined evaluation. It does not mean that 45% of production changes made with AI are vulnerable. The finding supports verification for high-risk code; it does not justify treating every AI completion as dangerous.

Maintainability signals. GitClear analyzed 211 million changed lines from 2020 through 2024. It reported that copy-pasted lines rose from 8.3% to 12.3% while changed lines associated with refactoring fell from 25% to below 10%.

This is a broad observational trend across repositories and years. It does not isolate AI as the cause of every change or predict what will happen in a particular codebase.

Learning and immediate comprehension. In Anthropic's randomized trial, 52 mostly junior developers learned an unfamiliar Python library. The AI-assisted group averaged 50% on a quiz taken shortly after the task, compared with 67% for the hand-coding group. Participants who used AI to ask conceptual questions or request explanations tended to perform better than those who delegated the work.

The relationship between those interaction patterns and the results is a qualitative observation, not causal proof. The study does not settle questions about long-term learning or today's agentic workflows.

Productivity depends on the setting and the moment. METR's early-2025 randomized trial found that 16 experienced open-source developers working in repositories they knew well took 19% longer with the AI tools available at the time. They nevertheless believed they were faster.

METR presents that result as a snapshot of a particular period, not a verdict on software development. Its February 2026 update says participant and task selection problems in the newer data prevent a reliable current estimate. METR also says newer tools probably create more speedup than the early study measured.

A separate Copilot adoption preprint found that productivity gains in the open-source projects it studied were concentrated among less-experienced contributors. After adoption, core developers reviewed 6.5% more code and produced 19% less original code.

That result belongs to the projects and method studied. It does not show that all senior engineers experience the same change in output.

Together, these studies support a narrower conclusion: generation speed, code quality, learning, and review capacity do not move together automatically. The workflow determines where the cost appears.

Why Working Alone Changes the Risk

A team can distribute understanding through design discussion, review, pairing, and incident response. That does not guarantee shared comprehension, but it creates more opportunities for someone to challenge an assumption or retain context independently.

When I work alone, the person accepting the suggestion and the person expected to question it are the same. After an hour of moving quickly with an agent, I must somehow return with fresh eyes and review the result. There is no second person who missed the shortcut and can therefore see it clearly.

This does not prove that solo developers carry more comprehension debt than every team. The failure mode is simply different. In a team, missing understanding may be redistributed or hidden across people. Alone, it compounds in one place. If I cannot explain the system during a production incident, there is no other mental model in the room.

That is distinct from the team review-capacity problem I discuss in AI Made Code Cheap. Verification Is Still Expensive. The bottleneck there is whether a team can verify a growing volume of output. The problem here is whether the person ultimately responsible still understands the system they are verifying.

What I Do While Still Using the Tools

I am not trying to use less AI. I am trying to keep the work inside the boundary of what I can own.

Write Intent and Acceptance Criteria First

Before the agent changes code, I want a plain-language account of the problem, the constraints, and the behavior that must remain unchanged. Code is still the implementation and must remain readable, but it should not be the only surviving record of why a decision exists.

If I cannot state what success means before generation starts, a passing test suite afterward will not create that missing clarity for me.

Keep Changes Smaller Than My Comprehension Window

A large autonomous run can be efficient, but it can also cross several architectural boundaries before I notice the first wrong assumption. Smaller changes make it easier to review the reasoning, test the behavior, and reverse course.

My stop rule is simple: if I can no longer explain the current change without asking the agent to reconstruct it for me, the change is too large or I have moved too fast.

Use AI for Inquiry, Not Only Delegation

I ask the agent to compare options, identify assumptions, explain unfamiliar paths, and challenge my understanding. Before accepting the result, I restate the decision in my own words. An AI-generated explanation can help build a mental model, but it is not evidence that I have one.

Treat High-Risk Changes as Untrusted Until Verified

Authentication, authorization, payments, user data, and system boundaries deserve a more skeptical path. I review the implementation, derive tests from the requirement rather than the generated code, run static and security checks where appropriate, and make sure the change is observable and reversible.

Using a second model to review the first can add another signal. It does not create independent accountability. Both models can share the same blind spot, and I still own the decision to ship.

Use Types as One Guardrail

A type-constrained code-generation study found that, in its TypeScript benchmark, 94% of compilation errors in generated code resulted from failed type checks. Its proposed decoding method reduced compilation errors by more than half. That is a useful result within a specific benchmark. It does not mean type systems catch 94% of all AI mistakes.

Types can reject many mechanically invalid states before runtime. They cannot prove that the requirement is correct, the authorization rule is appropriate, or the business behavior matches the intended outcome. They are a guardrail, not a reviewer.

Build Layered Verification and Know When to Stop

Tests, type checks, linters, dependency checks, security analysis, logs, and rollback paths each catch a different class of failure. I trust the combination more than any single check, including my own tired judgment.

The final gate is still comprehension. If the checks pass but I cannot explain the change, its assumptions, and its likely failure modes, it is not ready. Automation should make skepticism repeatable, not make responsibility disappear.

Governance Is Not Evidence of a Universal Ban

Some open-source projects draw strict boundaries around AI-generated contributions. Zig prohibits LLM-generated content in its governed community spaces. NetBSD treats LLM-generated code as tainted unless core gives prior written approval. QEMU currently declines AI-generated contributions because of provenance, copyright, licensing, and Developer Certificate of Origin concerns.

Those policies are real, but they are not proof that every product team should reject AI or that comprehension debt is their only reason. They show that accountable software work includes knowing where code came from, what rules govern it, and who can stand behind it.

The Bill Comes Due When the System Must Change

A more capable model may explain or refactor unfamiliar code better than today's tools. What neither a model nor a human can reliably recover from implementation alone is undocumented intent: why a constraint mattered, which alternative was rejected, what customer behavior shaped the decision, and which tradeoff the system was supposed to preserve.

If that reasoning never existed outside a transient conversation, asking another model to clean up the code may only place new assumptions on top of old ones.

The scarce skill is no longer producing every line by hand. It is being able to vouch for what ships: why it exists, what it protects, how it was verified, and when it is wrong.

For a solo founder, that is not an optional layer of polish. It is the job. Speed without understanding is not free productivity. It is a loan, and there is no one else to receive the bill.