Guillaume Barrois' Post

Guillaume Barrois · article · 2026-10-08 source ↗ Reader 🖥️

Agent Planning Artifacts Cognitive Debt Disposable vs. Durable Code Mental Models & Understanding

Building features at the speed coding agents enable creates 'cognitive debt' — an accumulating gap between what has been built and what the engineer still understands — which, like technical debt, must be deliberately repaid (through upfront planning, disposable prototyping, and PR-based review) or it will erode confidence and slow you down.

practical · mixed — A short, reflective LinkedIn post: narrative (a personal 'lost the plot' experience), borrowed theory (cognitive debt), and a practical list of personal coping practices — ending with an open question to readers rather than a firm conclusion.

Structure

Part	Role
Personal anecdote: 'losing the plot' when building fast with Claude Code	narrative hook / motivating problem
Borrowing Margaret-Anne Storey's 'cognitive debt' framing and its technical-debt analogy	theoretical grounding
Two speculative long-term resolutions (practice evolution vs. abstraction-level shift) plus a probable blend	forward-looking hypothesis
Three current personal practices (disposable code, upfront planning, PR-based repayment) and an open question to readers	practical recommendation / call for input

Key terms

cognitive debt Cognitive Debt
Borrowed from Margaret-Anne Storey: the accumulating gap between how a system was built (by a fast-moving coding agent) and how well the engineer actually understands it — repaid by rebuilding a mental model (reading code/docs, writing tests, running experiments), not by a mechanical fix.

Propositions

explicitBuilding a feature quickly with Claude Code can leave the author feeling like he's 'lost the plot' — less confident and afraid of breaking something he no longer fully understands.conf: high
explicitThis feeling matches 'cognitive debt': like technical debt, it accumulates and must eventually be repaid (rebuilding a mental model via reading code/documentation, writing tests, running experiments) or it will slow the developer down.conf: high
supportsAI coding creates two kinds of debt. You're only measuring one · p1 — The author's first-person account of 'losing the plot' is a concrete illustration of exactly the cognitive-debt dynamic the other document formalizes as an accumulated loss of system understanding.
explicitTwo possible long-term resolutions exist: engineering practice evolves to prevent cognitive debt from accumulating (more testing, continuously updated documentation, better review workflows), or code becomes an abstraction layer agents manipulate while engineers work one level up on specifications, constraints, and outcomes — with reality likely landing somewhere between the two.conf: high
explicitCurrent personal practices for managing cognitive debt: normalize throwing away code (especially proof-of-concepts), spend more time planning upfront to build a solid mental model before the agent starts writing code, and use pull requests as the specific checkpoint to 'repay' cognitive debt when feeling overwhelmed.conf: high
supportsThe Orchestration Tax is You · p14 — Both treat a deliberate review checkpoint (pull requests here, closing the orchestration loop there) as the mechanism that prevents agent-driven speed from compounding into unpaid cognitive debt.
implicitcontestedThe post treats repaying cognitive debt as primarily a matter of individual developer discipline (personal planning habits, personal PR-review timing), even though one of the author's own two forecasted resolutions — evolving testing, documentation, and review workflows — is itself a team- or organization-level practice change, not an individual one.conf: medium
contradictsAI coding creates two kinds of debt. You're only measuring one · p9 — This post implicitly treats cognitive debt as repayable through individual habits (planning, personal PR review timing), while the other document argues cognitive debt is a property of the team/system that no individual-level practice or dashboard can surface or repay.

Arguments

Developers should deliberately schedule points to repay cognitive debt — planning before an agent writes code, and reviewing via pull request afterward — rather than let agent-driven speed compound an ungrounded understanding of their own system. strength: medium

Explicit premises:

Cognitive debt accumulates the same way technical debt does: unaddressed, it compounds and eventually slows you down.
Rebuilding a mental model (via planning beforehand, or review afterward) is the repayment mechanism.

Implicit premises:

A developer can accurately self-assess the moment they're 'a little bit overwhelmed' and intervene before shipping something they don't actually understand.
Reviewing a pull request is itself sufficient to rebuild genuine understanding, rather than a comfortable but superficial check.

Inferences:

If the author's second forecasted future (code as an abstraction manipulated by agents, with engineers operating on specs/constraints/outcomes) materializes, the unit of 'repayment' shifts from understanding code to understanding specifications — which would make a PR-review practice focused on code obsolete as a repayment mechanism, not just insufficient.

Narratives

The author's own experience of building a feature fast with Claude Code and feeling he had 'lost the plot' — less confident, afraid of breaking something no longer fully understood.
→ Grounds the abstract 'cognitive debt' concept in a concrete first-person feeling, making the borrowed theory immediately legible to other practitioners.

Questions addressed

⭕ How will the tension between coding-agent speed and cognitive debt play out over time?
The author sketches two possible resolutions and guesses reality will land between them, but offers no criteria for which is winning or how to tell.
⭕ Does reviewing a pull request actually restore the engineer's genuine understanding of agent-written code, or just the feeling of having checked it?

Gaps

incompleteThe post's remedies (planning, disposable code, PR review) are framed entirely as individual habits, but other corpus material on cognitive debt argues it is fundamentally a property of the team/system — no individual dashboard or personal practice can surface or repay the team's shared loss of a 'mental map of who knows what.' The post never addresses whether his personal repayment actually restores anything beyond his own understanding.
Read next: Pair with team-level cognitive-debt accounts to see whether individual repayment habits like his actually transfer to team-level understanding, or only patch the individual's own gap.
incompleteThe 'spend more time planning' practice presupposes the planning skill and domain expertise to build a solid mental model upfront — the post doesn't address whether a less senior engineer, who may lack that expertise, can use the same practice to the same effect.
Read next: Look for evidence on whether upfront-planning-as-cognitive-debt-mitigation holds across seniority levels, not just for experienced practitioners like the author.