09

Article 9 of 12 · ARTHA Craft

The Three Registers That Replaced "I'll Remember That." My AI Agent Logs to Them Too.

Said it hundreds of times across 25 years. The fix was not discipline.

Jitander Singh Chauhan

Lead AI & Data Technologist · Haystream

"I'll remember that."

The most expensive lie in software development

I have said those words hundreds of times across 25 years of building software. About a bug I spotted while working on something else. About an enhancement idea that arrived mid-session. About a shortcut I took because the deadline was real and the proper solution was not.

And I remembered. Sometimes. For a while. Until the next session opened and the next problem arrived and the thing I was definitely going to remember quietly disappeared.

In the vibe coding era this got worse. More agents. More context switches. More things that never got picked up.

The fix was not discipline. Discipline fails. [1]

The fix was a system. Three registers. Every discovery logged. Nothing fixed without an entry first.

What a Register Actually Is.

Not a ticket system. Not a Jira board with seventeen custom fields. A register is a structured markdown file, a flat list with a consistent format. Lightweight enough that logging an entry takes thirty seconds. Structured enough that every entry has an ID, a severity, a status, and enough context to act on it later.

The format matters because the agent reads these files. They are not human-only documents. They are part of the system.

Three registers. Three jobs. Nothing duplicated.

The Three Registers.

🐛

Register 1: Bugs

BUGS.MD

Every bug found in testing goes into BUGS.MD before it gets fixed. No exceptions. Not because bureaucracy is valuable, because fixing a bug before it is registered means fixing it without triage. Without knowing if there are three other bugs in the same module that should be fixed together. Without a traceable record that this problem existed, was fixed, and was verified.

The register entry takes thirty seconds. The triage it enables saves hours. Even VERIFIED bugs stay in the file. Knowing a bug existed, was fixed, and stayed fixed is information worth keeping.

BUG-NNN | CRITICAL/HIGH/MEDIUM/LOW | OPEN/IN-FIX/FIXED/VERIFIED | Surface | Description | Fix task reference
💡

Register 2: Enhancements

ENHANCEMENTS.MD

Every improvement idea, UX observation, and "we should do this properly one day" goes into ENHANCEMENTS.MD before it gets built. Good ideas arrive at the wrong moment: mid-session, while building something else, when the scope boundary says stay in your lane.

Without a register the idea gets acted on immediately, breaking scope. Or it gets ignored and the moment of clarity is lost. The register is the third option: capture it now, schedule it properly later. At the start of every sprint, the list is reviewed and items that are ready get promoted to step files.

ENH-NNN | HIGH/MEDIUM/LOW | IDEA/SCHEDULED/IN-PROGRESS/DONE | Description
⚠️

Register 3: Tech Debt

08-Tech-Debt.MD

Every shortcut taken deliberately. Every stub left intentionally. Every test skipped because the deadline was real. The tech debt register exists because debt that isn't recorded becomes invisible, and invisible debt compounds. You refactor a module without knowing it had a known gap. You build on top of a stub that was never meant to be permanent.

A truth table for every module: WORKING, PARTIAL, or STUBBED. Reviewed at every major planning session. Every stub has a comment in code pointing back to the register entry. Nothing is silently promoted. A step file is required to resolve any debt item.

DEBT-NNN | ACTIVE/RESOLVED | Module | Description | Rationale | Resolution step

The Guardrail That Makes the System Airtight.

The Rule That Closes Every Gap

Every coding agent has one obligation beyond its scope boundary: if it finds something, it logs it.

Most teams treat registers as something humans go to after they notice a problem. That is half the system. The other half, the half that makes it airtight, is built into every task file as a standing instruction.

The agent's job does not end at "build this." [2] It ends at "build this and report everything you found along the way."

Bug Found

Agent logs to BUGS.MD: ID, severity, description, what it was doing when it found it. Then continues with its assigned scope. Does not fix it. Does not ignore it. Logs it and stays in its lane.

Enhancement Spotted

Agent logs to ENHANCEMENTS.MD. The moment of clarity is preserved. Sprint planning decides whether and when to act on it. The agent does not implement it. That would break scope boundary.

Shortcut Taken

Agent logs to Tech-Debt.MD before the session closes. Comment in code points back to the entry ID. Nothing is silently incomplete. Everything deliberate is recorded and traceable.

This means the registers are not updated when humans remember to update them. They are updated as a contractual part of every execution session.

What This Gives You That Memory Never Could.

Complete Health Picture

Not just what was built: what was found, what was deferred, what was deliberately left incomplete. Every agent, every session, every sprint planning conversation starts from this picture.

Triage Before Fix

Nothing fixed in isolation. Everything reviewed in context. Related bugs grouped. Debt items sequenced. Enhancements prioritised. No more random firefighting.

Agent as Reporter

The agent doesn't just build. It discovers and logs. Every session ends with not just code but a record of what was found along the way. The system gets smarter with every execution.

Permanent History

IDs never reused. Entries never deleted. A bug that was fixed three months ago is still in the file, because knowing it existed and was resolved is information worth keeping forever.


Nothing falls through the cracks because the cracks have been sealed by a system, not by memory. The registers don't rely on you remembering to log. They rely on the agent being instructed to log as part of every execution.

Research & Further Reading

  • [1] Forsgren, Humble & Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution Press, 2018: Proved that high-performing teams use structured information flow, not individual discipline, as the foundation of delivery performance. "You can't achieve high performance through heroics or hoping people try harder. You need a system." Book
  • [2] Rigby et al., "Quantifying and Mitigating Turnover-Induced Knowledge Loss", ICSE 2016: Found that issues discovered during development but not formally recorded are disproportionately lost in knowledge-loss events. The register system creates the formal record that prevents this. Separately, Avelino et al. (2016) found 65% of popular GitHub projects have a bus factor of 2 or less. Academic Paper
  • [3] Perrow, C., Normal Accidents, Princeton University Press, 1984: In tightly coupled systems, small unreported anomalies cascade into major failures. The register system is the "loose coupling" that makes anomalies visible before they cascade, exactly the mechanism Perrow identified as the key to preventing normal accidents. Book

← Previous

Article 8

Next →

Article 10: You Haven't Given It Rules