Fighting cognitive debt in the age of AI coding
Coding with AI agents became a de facto standard at many companies. In fact, a few are pushing for 100% AI-generated code. I recently shared my thoughts on why “Coding is cheap, but code isn’t”. I explained why an AI coding agent leads to a quantity-over-quality trap. In the same article, I also mentioned why this will hurt junior engineers the most.
Whether you are a vibe coder or a developer following spec-driven development, it is important that you understand the rationale behind the agent’s decisions and the execution flow, and that you can comprehend and explain the code when an unexpected bug surfaces. Relying solely on AI-generated designs and code will lead to cognitive or comprehension debt. This is not limited to just junior developers.
Is there a way we can eliminate or reduce this cognitive debt? Yes, by using the coding agent as a pair programmer and a coach. I have enforced this using AGENTS.md.
Here is the complete version of my AGENTS.md. Expect this to be tweaked regularly. I will walk through the critical parts of this.
Developer assistance
I direct the agent to operate in two complementary modes.
- Pair Programming Mode: In this mode, the agent follows its usual development workflow but pauses to hand off sections of code to the developer. Once the developer completes the handed-over sections, the agent reviews their code, interviews them on their decisions, and suggests improvements.
- In the Comprehension Walkthrough Mode, the agent completes the code generation task and walks them through the generated code by pointing at specific code flows and asking targeted questions to verify their understanding. The agent explains the code in response to the developer’s input.
The agent must always adhere to the following core principles.
-
Calibrate and build a developer profile.
-
Handover what helps the developer learn and act.
-
Act like a team member. Not a teacher.
-
Explain all significant design decisions and not just code.
-
Shipping is as important as skill-building.
-
Code the developer doesn’t understand is a liability, not an asset.
Developer Calibration
It is not just enough to use the strategic points in the code to determine what needs to be handed over to the developer. Instead, the agent must understand developers’ capabilities and how they are evolving. This is an important factor in determining what gets handed over and which questions are asked to assess the developer’s understanding of the code.
There are different signals that the agent will be asked to observe to calibrate and build a developer profile.
| Signal | Where agent Sees It | What It Tells the agent |
|---|---|---|
| Codebase complexity | The repo’s patterns, frameworks, architecture | Baseline expectation for this project |
| Conversation language | How the developer describes what they want | Depth of technical vocabulary and conceptual understanding |
| First handover result | How they handle the first coding task you assign | Calibration anchor — adjust all future handovers from here |
| Code quality patterns | Variable naming, error handling, edge cases, structure | Skill level in specific areas (may vary by domain) |
| Questions they ask | Clarifying questions during or after handovers | Knowledge gaps and strengths |
| Speed and confidence | How quickly they complete tasks; do they need hints? | Comfort with the domain |
| Existing code in workspace | Code the developer has already written in the project | Style maturity, patterns they know, habits |
The calibrated developer profile gets persisted in the repository. In a team scenario, this file should be added to .gitignore.
Session Flow
There are three different flows I encoded into AGENTS.md. As a pair programmer, the agent works with me to implement features and fix bugs. In the code comprehension mode, the agent evaluates my understanding of the code it generated.
Feature development workflow
In this workflow, the developer starts with a feature request or specification. The agent infers that, creates a plan, identifies areas to handover, and generates the necessary scaffold or boilerplate.
share rationale for the plan] Plan --> Scaffold[Agent: Scaffold, wire, write boilerplate
explain decisions in code you write] Scaffold --> Teachable{Agent: Identify teachable moment
Is there a high-value piece to hand over?} Teachable -- Yes --> HandOver[Hand over to developer with context, not solutions] Teachable -- No --> ContinueBuilding[Agent continues building
with rationale comments] ContinueBuilding --> Teachable HandOver --> DevWrites[Developer writes their code] DevWrites --> Review[Agent: Review code
• Interview developer on decisions
• Suggest improvements with rationale
• Acknowledge strong choices] Review --> LoopBack[Continue to next step] LoopBack --> Plan style Start fill:#f9f9f9,stroke:#333,stroke-width:2px style HandOver fill:#fff3e0,stroke:#ff9800,stroke-width:2px
Bug fixing workflow
Bug fixing workflow is similar to the feature development.
• Reproduce / understand the issue
• Trace code to identify root cause
• Assess blast radius] Analyze --> Guide[Agent: Guide without revealing
• Share which files / area the bug is in
• Share triggering conditions
• Do NOT share the fix or specific lines] Guide --> DevFix[Developer investigates and writes the fix] DevFix --> Help{Developer asks
for help?} DevFix --> Submit{Developer submits
their fix?} Help -- Yes --> Respond[Agent: Respond with guidance, not solutions
Loop until they are ready] Respond --> DevFix Submit -- Yes --> Review[Agent: Review & Interview
• Root cause or just symptom fix?
• Regression risk?
• Interview decisions
• Suggest improvements
• Verify test coverage] style Start fill:#f9f9f9,stroke:#333,stroke-width:2px style Review fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px
Code comprehension workflow
In this workflow, agent generates the code and then attempts to interview the developer to evaluate their understanding of the generated code.
critical paths, non-obvious logic, error handling, data transformations] Identify --> Probe[Agent: Point to specific code and ask
a targeted question about the flow] Probe --> Explain[Developer explains their understanding] Explain --> Assess{Assessment} Assess -- Correct --> Confirm[Agent: Confirm & move on] Assess -- Partial --> Fill[Agent: Fill gaps] Assess -- Wrong / Lost --> Walkthrough[Agent: Walk through step by step] Confirm --> MoreFlows{More flows?} Fill --> MoreFlows Walkthrough --> MoreFlows MoreFlows -- Yes --> Probe MoreFlows -- No --> Summarize[Summarize gaps and key takeaways] style Start fill:#f9f9f9,stroke:#333,stroke-width:2px style Summarize fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
Examples from my usage
To demonstrate this, I started building a simple URL Shortner project in Python with the help of AI. I started with this prompt.
|
|
To this, the agent responded with a detailed plan and a scaffold of the project as usual. Here is where the agent persona as a pair programmer kicks in.
Once I submit the code that I developed and let the agent know, it reviews and comes back with its feedback.
The agent also starts an interview session to grasp why I made certain design choices.
When I report bugs in the generated code, here is how the agent responds to that.
Overall, I find this workflow helpful in comprehending the code in the repository. Given the speed at which coding agents generate, this may feel like slowing that flow down. However, I find it important to ensure I understand the code agents are generating. This is enforcing that discipline for me. There are bypasses in the agent instructions to go with its flow when needed but for critical sections of the code, I expect to pause and reflect on the code the agent is generating.
How are you dealing with comprehension or cognitive debt?
No Previous Article
This is the first post
No Next Article
This is the latest post
Comments
Comments Require Consent
The comment system (Giscus) uses GitHub and may set authentication cookies. Enable comments to join the discussion.