Author’s note: Drawing on Addy Osmani’s ideas of “cognitive surrender” and “understanding debt,” this article offers a pre-merge self-checklist and prompt templates. It also compares LobeHub’s acceptance-report-based review approach to help you match review intensity to risk.
If you use Claude Code, Cursor, or Cline to ship code every day, you’ve probably had this experience: an agent delivers a PR hundreds of lines long in minutes. The naming is consistent, the structure is clear, and all the tests pass, so you click “Approve.” A few weeks later, someone asks why a piece of logic was written that way—and you can’t explain it. This article focuses on practical checks, like asking AI to quiz you, to help you stay accountable for every change you approve without reviewing every line.
This isn’t an article urging you to go back to writing code by hand. Claude Code engineer Addy Osmani has made it clear that no one expects engineers to memorize an entire codebase. The question isn’t whether you read every line—it’s whether you know what you understand and what you don’t.
What you’ll take away: You’ll understand the progression from “cognitive offloading” to “judgment delegation” to “cognitive surrender,” get a ready-to-copy list of pre-merge questions and prompt templates, and learn how to choose your review intensity based on the risk of a change.
Don’t Rubber-Stamp Your Agent: Understanding Debt at a Glance
According to QbitAI, in a report republished by 36Kr, former Google engineer Addy Osmani, who now works on Claude Code, has written about an uncomfortable problem: the more reliable AI-generated work becomes, the less carefully people check it. He breaks this process into several stages and identifies two new kinds of “debt.” The concepts below come from media coverage; refer to Addy’s original article for his exact wording.
| Concept | Meaning | Typical example |
|---|---|---|
| Cognitive offloading | You delegate specific work to AI but still understand the task and can evaluate the result | You ask an Agent to write boilerplate code and know what it’s doing |
| Judgment delegation | AI’s answers gradually become the default basis for what happens next | The second time around, you skim the output and proceed with whatever the Agent suggests |
| Cognitive surrender | You hand over even the judgments you should make yourself | “The AI must have a good reason,” so you merge as soon as the tests pass |
| Understanding debt | Code and system complexity grow faster than developers’ understanding | When it’s time to change a feature, nobody can make sense of the internals |
| Intent debt | AI makes decisions for you about goals, constraints, and trade-offs that weren’t made clear in the requirements | You haven’t figured out what you want, but the Agent delivers a polished result anyway |
How Cognitive Surrender Leads to Understanding Debt
Cognitive surrender doesn’t happen overnight. At first, you’re just “offloading” specific work, and there’s nothing wrong with that—it’s like using a compiler instead of writing assembly by hand. The danger comes in the second stage: when an Agent’s output has been reliable several times in a row, its conclusions quietly become your default assumptions, and you start skipping verification. By the third stage, the “Approve” button has become a rubber stamp, and your role has shifted from engineer to rubber-stamper.
Addy gives a typical example: an Agent submits 600 lines of code in one go. The structure is clear, the tests pass, and the developer merges it with confidence. But the Agent may have changed the order of transaction processing in an inconspicuous place or adjusted an edge case. Those changes don’t cause errors at the time. Only when something goes wrong does the developer realize they can’t explain why the code behaves the way it does. That’s the “interest” on understanding debt, and it always comes due at the worst possible time.
Intent debt arises further upstream. Today’s Agents are so good at filling in requirements that they can deliver something that looks reasonable even when you haven’t thought things through. The problem is that AI has quietly made decisions for you about the goals, scope, and trade-offs you left unclear. Intent debt and understanding debt often pile up together: you’re not sure what you originally wanted, and you don’t understand what the Agent ultimately built.
6 Ways to Pay Down Understanding Debt
Addy shares plenty of practical advice in his long-form article. We’ve organized it into six methods, noting which kind of debt each one addresses and where it fits in your workflow.
| Method | When to use it | Primarily addresses | Action in a nutshell |
|---|---|---|---|
| 1. Have the Agent quiz you | After a major change, before merging | Understanding debt | Have it summarize the changes and reasons, then quiz you; merge only when you get every answer right |
| 2. Write a requirements checklist before you start | Before writing a prompt | Intent debt | Specify who it’s for, what problem it solves, what’s out of scope, and what counts as done |
| 3. Ask about unauthorized decisions | At the end of a long-running task | Understanding debt, intent debt | Ask what decisions it made without your authorization and what assumptions it relied on |
| 4. Ask what wasn’t tested | When reviewing test results | Understanding debt | Check the tests actually run and their output before reading the AI summary |
| 5. Keep the original materials | When running multiple Agents in parallel | Understanding debt | Keep the original materials and verification evidence for important tasks; reduce parallel work if you can’t review it all |
| 6. Practice offline regularly | Weekly and monthly | Skill degradation | Code without an Agent once a week, and review which skills you’ve outsourced each month |
Have AI Quiz You: The Most Important Understanding Debt Check
This is the most interesting technique in the set. After an Agent completes a major change, don’t rush to approve it. Instead, have it play the examiner: ask it to summarize what changed and why, then quiz you on those changes. Set a rule that you’ll merge only if you answer every question correctly. This turns the vague feeling of “I think I understand it” into something you can actually test. Any question you can’t answer pinpoints a gap in your understanding.
Ask About Unauthorized Decisions and What Wasn’t Tested
During long-running tasks, an Agent may choose default parameters, adjust the implementation scope, or even make trade-offs when requirements conflict. Those decisions may not make it into the final summary because they seemed “too natural” to mention. So instead of just asking, “Is it done?”, follow up: What decisions did you make that I didn’t explicitly authorize? Where did you rely on your own assumptions? What hasn’t been verified? Which changes might affect other functionality?
The same goes for testing. Addy emphasizes that passing tests only prove that the conditions covered by those tests passed. If edge cases weren’t included, the report can still look great. Start by checking which tests actually ran and what results they returned, then read the AI-generated summary. For high-risk changes, you can also have another Agent independently look for problems from a different angle.
Pre-Merge Self-Check: 5 Steps to Avoid Rubber-Stamping an Agent’s Work
Put the methods above together, and you have a workflow you can run before merging any PR. You don’t have to review every line, but each step should show that you’ve actually thought through the work.
- Write down your expectations before starting: Describe the requirements and what you expect to happen in your own words. If you’re still unhappy after two rounds of prompt revisions, revisit the requirements instead of piling on more prompts.
- Ask the Agent to explain its decisions: Once the task is done, ask the Agent to list any decisions you didn’t authorize, assumptions it made, and things it hasn’t verified.
- Check the actual tests: Review the test commands that were run and their output. Ask which edge cases weren’t covered.
- Have the Agent quiz you: Ask it to create a quiz based on the diff. For any questions you get wrong, go back to the code and make sure you understand it.
- Find one thing it missed: After the Agent hands in its work, proactively identify at least one thing it might not have checked.
A Minimal Prompt for Checking Understanding Debt
Here’s the most common “quiz me” prompt. You can paste it directly into a Claude Code, Cursor, or Cline conversation:
在我合并这次改动之前，请先做两件事：
1. 用不超过 10 条要点总结本次改了哪些文件、每处改动的原因。
2. 根据本次 diff 给我出 5 道题，重点覆盖：事务/调用顺序、
边界条件、错误处理、对其他模块的影响。
先只给题目，等我作答后再批改，并指出我答错的地方对应哪段代码。
规则：我没有全部答对之前，不要建议合并。
See the full pre-merge question prompt template
# 阶段 A：开工前（偿还意图债，由我先填写）
需求说明：
- 面向谁：
- 要解决的问题：
- 明确不做的事：
- 完成标准（做到什么程度算完成）：
- 我预期的改动范围和结果：
# 阶段 B：任务结束后（请 Agent 逐条回答）
1. 你做了哪些我没有明确授权的决定？请列出决定内容和理由。
2. 哪些地方依赖了你自己的假设？假设不成立时会发生什么？
3. 还有哪些内容没有验证？
4. 哪些改动可能影响其他功能或模块？
5. 你实际运行了哪些测试命令？请贴出原始输出，而不是总结。
6. 哪些边界情况没有写进测试？
# 阶段 C：出题考核（偿还理解债）
请根据本次 diff 出 5 道题，先只给题目。
我作答后请批改，答错的题请定位到具体代码行。
我未全部答对前，不要建议合并。
# 阶段 D：高风险改动追加（可交给另一个独立会话）
请你作为独立审查者，不参考上一个会话的总结，
只基于原始需求和 diff，找出最可能出问题的 3 个地方。
🎯 Tip: Always fill out Phase A yourself before starting—don’t have the Agent do it for you. For Phase D, start a new session so the independent reviewer isn’t influenced by the previous Agent’s summary. This also echoes Addy’s warning about information loss when multiple Agents pass messages along.
Pre-Merge Question Checklist
| Stage | Questions to ask | Warning sign |
|---|---|---|
| Before starting | Can I explain the requirements and completion criteria in my own words? | I can’t write down what’s out of scope |
| After delivery | What unauthorized decisions did the Agent make? | The answer is “none,” but the diff clearly exceeds the scope |
| Testing | Which tests actually ran? What wasn’t tested? | There’s only a summary, with no raw output |
| Assessment | Can I answer all the quiz questions correctly? | I get questions about transaction order or edge cases wrong |
| Wrap-up | Can I identify one thing it failed to check? | I can’t think of a single thing |
AI Quizzes vs. Acceptance Report Reviews
A very different approach comes from LobeHub, an open-source Agent collaboration platform with around 84,000 GitHub stars. According to Baijing Lab, the team says it “almost never looks at code anymore,” focusing instead on the Agent’s multimodal acceptance report. They use Acceptance, a tool they developed in-house and open-sourced in September this year. Before delivery, the Agent breaks the requirements into directly observable checks, runs them one by one in the actual product, and compiles screenshots, recordings, and logs into an online report. A reviewer can approve the whole report or send back individual items.
| Dimension | AI quiz | Acceptance report review |
|---|---|---|
| Focus | Internal code logic, unauthorized decisions, assumptions | Observable external product behavior |
| Evidence | Questions and answers, grading results | Screenshots, recordings, logs, command history |
| Problems it can uncover | Transaction order, edge cases, implicit trade-offs | Whether the interface, interactions, and functionality meet requirements |
| Problems it can miss | Questions you didn’t think to ask | Invisible internal logic and architectural risks |
| Prerequisites | The developer is willing to invest time in understanding | Requirements can be broken into observable checks, and an automated execution environment is available |
| Human role | Understand and take responsibility for specific changes | Define acceptance criteria and make the final judgment |
Comparing the Two Review Approaches
Acceptance report reviews are highly efficient at verifying observable behavior, and reviewers can send back individual checks. In the test described in the report, the reviewer sent back only the dark background item. The Agent changed just one line of CSS, leaving all other files untouched. But this approach depends on requirements being divisible into observable checks. The report also notes that, for more complex tasks, humans still need to judge security, architecture, and final quality, and parts of the feedback process still require manual handling. The claim that the team “almost never looks at code” is self-reported and hasn’t been independently verified.
AI quizzes are better at exposing issues that aren’t visible in the interface, such as transaction order and edge cases, covering a blind spot in acceptance reports. But their effectiveness depends on the quality of the questions, and developers need to invest time in understanding the changes. The two approaches aren’t mutually exclusive: a practical combination is to use acceptance reports to confirm “Was it done correctly?” and quizzes to confirm “Do I understand why it was done this way?”
Match Understanding Debt Review to the Risk of the Change
Not every PR needs the full process. Addy also warns that when you’ve generated more content than you can responsibly review, you’re no longer reviewing it—you’re betting that it’s fine. The table below offers a risk-based guide; adjust the thresholds to fit your team.
| Risk level | Typical changes | Recommended review intensity |
|---|---|---|
| Low | Copy, styling, standalone scripts, prototypes | An acceptance report or manual spot check is enough; document the expected behavior |
| Medium | Standard business features, new API endpoints | Question unauthorized decisions + check actual test output |
| High | Transactions, permissions, payments, data migrations | Full 5-step process + quiz + independent Agent review |
| Beyond capacity | Parallel output from multiple Agents that reviewers can’t keep up with | Add automated checks or reduce the number of parallel Agents |
💡 How to choose: If your team already has mature automated acceptance checks, you can reserve quizzes for high-risk changes. If not, at least enforce “answer correctly before merging” for PRs involving data consistency and permissions.
Frequently Asked Questions
Q1: What is comprehension debt, and how is it different from technical debt?
Comprehension debt builds up when code and systems grow more complex, but developers’ understanding doesn’t keep pace. Technical debt usually involves poor code quality. Comprehension debt can arise even when the code is well written: the problem is that people don’t understand it, and that gap becomes apparent when changes are needed.
Q2: How is having AI quiz you different from asking it to explain the code?
When AI explains code, you’re receiving information passively, which can easily give you the illusion that you understand it. A quiz requires you to answer actively. Mistakes can be traced back to specific code, turning a vague sense of understanding into something you can test.
Q3: Does “don’t rubber-stamp the Agent” mean reviewing AI-generated code line by line?
No. According to reports, the Claude Code team doesn’t require engineers to memorize the entire codebase. When they need to change a part of it, they use Claude to get up to speed on the relevant logic. The key is knowing what you do and don’t understand, then choosing how deeply to review based on the risk.
Q4: What development scenarios is this approach suited to?
It’s especially useful for:
– **Long-running Agent tasks**: These can lead to unauthorized decisions, making a follow-up question checklist useful
– **Backend changes involving transactions and edge cases**: Quizzes can help test your understanding
– **Parallel development with multiple Agents**: Preserve the original materials and limit the number of parallel tasks
– **Team Code Reviews**: Add a question checklist to the PR template
Q5: How can you put this comprehension debt self-check into practice in Claude Code, Cursor, or Cline?
The approach isn’t tied to a specific tool. What matters are the prompts and the workflow:
1. Save the complete prompt templates from this article as reusable team snippets
2. Write out Phase A by hand before starting, then paste in Phases B and C after the task is complete
3. For high-risk changes, open a separate session for Phase D
You can also add “merge only after answering correctly” to your team’s PR review guidelines.
Q6: What are the known limitations of these methods?
It’s important to keep their limitations in perspective:
– **Evidence of effectiveness**: There’s currently no public data showing how much these methods reduce defect rates or improve efficiency
– **Time cost**: The full process lengthens the merge cycle and isn’t suitable for every PR
– **Quiz blind spots**: An Agent may avoid asking about problems it hasn’t recognized itself, so don’t skip the step of finding one thing it missed
– **Source note**: Addy’s views come from media coverage; check the original wording yourself
Q7: Is weekly offline coding practice really necessary?
Addy’s reasoning is that skills can gradually deteriorate when you don’t use them. Occasionally completing a task on your own, without an Agent, helps you gauge your actual ability. Taking stock once a month of which skills you’ve handed over to AI and which you need to retain doesn’t take much effort, but it can help prevent cognitive surrender from creeping in.
Don’t Rubber-Stamp Your Agent: Key Takeaways on Understanding Debt
- Cognitive surrender is gradual: It starts with cognitive offloading, moves to delegating judgment, and ends with handing over judgment entirely.
- Understanding debt collects interest later: The faster code gets written, the more the parts you don’t understand can come back to haunt you when it’s time to make changes.
- Intent debt starts upstream: Write your own requirements checklist before work begins. If you’re still unhappy after two rounds of prompting, revisit the requirements.
- The key move is to get quizzed: Have the Agent summarize its changes and quiz you. Merge only when you can answer every question correctly.
- Passing tests don’t mean there are no problems: First check the output of the tests that actually ran, then ask what wasn’t tested.
- Acceptance reports and quizzes complement each other: One verifies external behavior; the other checks your understanding of the internal logic.
- Review according to risk: If you can’t keep up with reviews, add automation or reduce parallel work. Don’t rely on luck.
Summary
The essentials of avoiding an Agent rubber stamp:
- Recognize the shift: Watch for the slide from “letting AI do the work” to “letting AI make the judgments.” Understanding debt and intent debt are both byproducts of that process.
- Take action: Write down your expectations before work begins, ask about unauthorized decisions and untested areas at delivery, and have AI quiz you before merging.
- Review by risk: Use an acceptance report or spot checks for low-risk changes. For high-risk changes, follow the full process and add an independent review.
AI will keep getting faster at writing code, but the person who approves a change is still responsible for it. Before you click “Approve” next time, ask the Agent to quiz you with five questions and see how many you can answer correctly.
📚 References
- QbitAI: The Complete Guide to Claude Engineering Agents (republished by 36Kr): Covers Addy Osmani’s views on cognitive surrender, understanding debt, and intent debt, along with practical methods.
- Link:
36kr.com/p/4056027738116995 -
Note: The source for this article’s main methodology; it’s a media account.
-
Addy Osmani’s original post: The original source cited in the report.
- Link:
x.com/addyosmani/status/2117512471930167377 -
Note: Refer to the original for exact wording. The link should be verified independently.
-
Beluga Lab: An AI Company with 80,000 Stars Decides to Let AI Take Over (republished by 36Kr): Covers LobeHub’s supervisor Agent architecture and Acceptance report practices.
- Link:
36kr.com/p/4056040123945860 - Note: A comparison source for acceptance-report-based reviews. The claim that the team “almost never looks at code” comes from the team itself.
Author: APIYI Technical Team
