When you tell developers that my solution to AI context drift was keeping four live markdown files updated alongside every code change, the reaction is entirely predictable:
“You’ve just traded code debt for documentation debt. This kills velocity.”
Or, from the IDE-purists:
“Why are you manually passing files around when native agents can scrape your whole repo?”
These are fair critiques.
If you treat documentation as a post-work chore or rely blindly on an autonomous agent to manage its own sandbox, the system collapses under its own weight.
But the TB / CC / FR loop — Task Brief / Codex Contract / Final Review — is not a bureaucratic process. It is a defensive pattern.
Coming from a background in cybersecurity, my default mode of operating is isolation, strict boundary enforcement, and assuming the agent will misbehave if given loose permissions.
This was the solution that fit my project, my tools, and my risk tolerance. The useful part is not that every developer should copy my exact setup. The useful part is that the pattern can change shape depending on the team, tooling, and codebase.
Here is how the project memory loop holds up against the four harshest criticisms of AI-assisted engineering.
1. The "Documentation Tax" Can Be Shifted, Not Removed
The Critique: Maintaining four separate documentation files — DEV_ARCHITECTURE.md, DEV_DATA_SHAPES.md, DEV_API_CONTRACTS.md, and TECHNICAL_DEBT.md — for every meaningful code change creates a bottleneck.
The Reality: The human developer does not need to write most of the documentation manually.
In this workflow, documentation is a required transactional output of the implementation contract. Because the context memory is defined during the Task Brief and refined into a bounded Codex Contract, the coding agent is the one tasked with updating the relevant markdown files.
The human’s job is to act as editor and gatekeeper during Final Review, verifying the AI’s reported documentation updates against the actual code changes.
That still costs attention. It is not free.
But the cost moves from “remember everything later and write documentation someday” to “review the documentation while the task context is still fresh.”
You are not eliminating the documentation tax. You are turning it into a reviewable part of the implementation transaction.
2. The Case for Separated Context
The Critique: Manually passing project files into an assistant or switching between an assistant and a coding agent feels primitive when IDE-integrated tools can auto-index a codebase.
The Reality: Full-repository context is convenient, but convenience is not the same thing as control.
The important separation in this workflow is not physical air-gapping. It is memory separation.
The assistant can operate from broader project memory: architecture, tradeoffs, future direction, unresolved concerns, and the reasoning behind the current shape of the system.
The coding agent should not automatically receive all of that.
The coding agent should receive the bounded implementation slice: what to build, what to preserve, what not to touch, which files are likely involved, what documentation must be updated, and how to report back.
That is the purpose of the Codex Contract.
The CC acts as a translation layer between broad architectural thinking and narrow implementation work. It lets the assistant help preserve strategy and future direction without creating a route for the coding client to start building future ideas too early.
A planning conversation can contain useful context that is dangerous implementation context.
“This might become a system later” is useful for architectural memory.
It is not useful as permission for the coding agent to start building that system now.
By keeping assistant memory and coding-agent context separate, the workflow forces intentionality. The coding agent only receives the implementation details and documentation updates that belong in the current task.
That keeps it in executor mode rather than co-architect-with-selective-memory mode.
3. Grading the Homework: Mitigating AI Hallucinations
The Critique: You cannot trust an AI to verify its own work or accurately report that it updated the documentation correctly. LLMs are notoriously prone to sycophancy.
The Reality: Correct.
LLMs will absolutely grade their own homework poorly if left unsupervised.
That is exactly why the Final Review stage relies on strict human acceptance and manual testing.
The assistant can assist in reviewing the coding agent’s return, but it does not replace human verification. The human remains the ultimate source of truth for scope and risk.
Furthermore, every software engineering methodology has a single point of failure: the human developer.
If a human engineer experiences a lapse in judgment, a critical oversight, or a medical emergency, the system breaks.
The loop does not assume the AI is perfect.
It assumes the AI is volatile, and creates a rhythm to catch mistakes before they are born.
4. The Scale Bottleneck: Moving Beyond the Prototype
The Critique: This works for a solo developer handling local JSON persistence. On an enterprise team with dozens of developers working on different branches, simultaneously modifying core markdown files will cause catastrophic Git merge conflicts.
The Reality: This is a completely accurate limitation of the manual prototype.
For a solo project, dragging files into a browser provides a simple, zero-cost map.
For a sprawling, multi-developer enterprise repository, the method would need to evolve from manual file handling to an automated tooling layer.
The architectural blueprint to solve this likely requires two next-generation components:
The Memory Controller: a system utility that programmatically parses, slices, and modularizes the core documentation files based on directory domains, feeding the LLM a compressed context packet rather than the entire repo documentation history.
The Semantic Diff Validator: a verification gate that compares the old documentation state against the new state, isolating the structural variance and presenting the human reviewer with a focused slice to approve or reject during pull requests.
Until better tooling exists around this kind of workflow, teams will have to adapt to these branching realities.
But the underlying principle remains useful:
AI-assisted development becomes safer when project memory is explicit, implementation context is bounded, and human review remains the final gate.
Conclusion
Defensive AI engineering means accepting a simple truth:
AI coding agents are incredibly fast, but they are strong enough to cause damage before lunch if left unconstrained.
The TB / CC / FR loop is not about slowing down development for the sake of process.
It is about establishing reviewable guardrails so that velocity does not turn into chaotic drift into the fog.
By treating documentation as a live transaction, keeping assistant memory separate from coding-agent context, and forcing human sign-off, you keep the human firmly in control of the codebase.
Top comments (0)