comprehension-gap

Source Metadata

Original cangjie-skill frontmatter from the distillation run:

name: comprehension-gap
description: |
  识别和管理 Loop 系统的认知风险: 自动化程度越高,你真正理解的部分越少。
  当用户发现"仓库里有很多代码但我看不懂"、"loop 产出很多但不确定对不对"、或需要向团队警示 AI 使用风险时使用。
  不适用于: 纯技术调试、或产出完全可客观验证的场景。
  关键 trigger: "AI 生成的代码我看不懂"、"产出太多理解不过来"、"AI 使用风险"。
source_book: "Loop Engineering 视频合集"
source_chapter: 视频3 (小木头) / 视频4 (Idoos Money)
tags: [risk, cognition, understanding, safety, human-in-the-loop]
related_skills: [loop-worthiness-test, maker-checker, three-stage-evolution]

Cognitive Gap Warning — The Hidden Risk of Loop

R — Reading (Original Text)

"The faster the loop delivers, the more code you didn't write yourself and didn't read yourself, and the greater the gap between what's in the repository and what you truly understand in your head. Another even more piercing fact is that the most dangerous posture is comfortably accepting everything the loop spits out; this is very dangerous. In AI-generated content, the more content we don't understand, the greater the risk to us." — Xiaomutou (Video 3)

"A loop with no one watching is also a loop with no one watching it make mistakes. So verification is always in your own hands." — Xiaomutou (Video 3)

I — Interpretation (Self-Account)

Core insight: The degree of automation is negatively correlated with depth of understanding.

The faster the Loop delivers → the more code you didn't write/read yourself → the greater the gap between what is in the repository and what you truly understand → the higher the risk.

The most dangerous attitude: Comfortably accepting everything the Loop outputs without scrutiny.

Key principle: Verification is always in your own hands. Even if the loop has a self-verification step, humans still need to review regularly.

A1 — Past Application (Cases in the Book)

Case 1: Ralph Loop failure (Video 3)

A notorious loop: persistent, never gives up
Failure mode: A loop with no one watching keeps making mistakes, turning small fixes into disasters
Lesson: A loop without human supervision creates an "understanding gap"

Case 2: Boris's codebase (Video 2)

Code produced by the Loop accounts for a large proportion of the repository
Boris emphasizes that "the codebase must be readable to the agent" — but readable ≠ understood by humans
Implicit risk: The agent can modify code ≠ the team can understand why it was modified that way

A2 — Future Trigger (Future Triggers)

When there is too much output to understand: "There is a lot of code in the repository but I can't understand it"
When the quality of Loop output is uncertain: "It says it's done, but I'm not sure whether it's correct"
When warning the team about the risks of AI use: Convey to the team that "automation ≠ understanding"
When designing a Loop supervision mechanism: At which steps should human review be added?

Language signals: "I can't understand AI-generated code," "too much output to understand," "risks of AI use," "a loop with no one watching"

Differences from adjacent skills:

loop-worthiness-test: Deciding whether to do a loop (this skill is risk management after running)
maker-checker: Using AI to review AI quality (this skill is risk at the level of human understanding)
three-stage-evolution: Stage positioning (this skill is a specific risk of Stage 3)

E — Execution (Executable Steps)

Step 1: Assess the cognitive gap

Regularly ask yourself:

Can I explain what this loop produces to a newcomer?
If the loop goes wrong, can I quickly locate the problem?
How much code/content in the repository have I not personally reviewed?

Step 2: Set up human review checkpoints

Regular review: Review samples of loop output weekly/monthly
Key checkpoint review: Trigger human review on major loop changes, new task types, or abnormal metrics
Comprehension check: Randomly sample loop output and try to explain its logic in your own words

Step 3: Mitigation strategies

Documentation: Require the loop to include a "design explanation" with its output
Progressive automation: Start from loop-build-path Step 1, and only escalate after ensuring each step is understood
Team review: Have team members regularly review each other's loop output

B — Boundary

Scenarios where this skill should not be used:

Output is fully objectively verifiable: Tests pass 100% → low risk of comprehension gap
Pure technical debugging: "This loop throws an error" — not a comprehension risk
Non-AI scenarios: This model only applies to AI-generated content

The author's blind spots and limitations:

"The deeper the understanding, the better" is an implicit assumption, but some scenarios (such as CI/CD) do not require people to understand every line
The author does not provide a standard for "how much understanding is enough"
The risk is warned about but not quantified — "how big a gap counts as dangerous?" has no answer

Adjacent but easily confused methodologies:

Technical Debt: "code quality debt"; this skill is "comprehension debt"
Bus Factor: "only one person understands it"; this skill is "no one understands it"