"Just make it work for now," is how the directive often gets distilled for engineers no matter how smart, bold, and customer focused leadership may be. Over time, the result is a declining customer experience and costs that later emerge as an iceberg threatening the year's budget.

A key part of the answer is often documentation, creating institutional memory. But that's work that doesn't clearly impact the immediate value chain. Why allocate an engineer or product manager to that when it slows down delivery of the next new thing?

It's a classic short vs. long-term tradeoff. We can address it by encouraging teams to plan for success and other platitudes. But how about actually providing a tool to make it happen?

This is what I do:

1. Every project has a planning file in simple markdown formatting named CURRENT_WORK.md.
   1. The file is for planning and remembering, not tracking current output.
   2. The file is checked into git, but somewhere "to the side" of the actual codebase.
2. When beginning a new work package, I use CURRENT_WORK to describe my goals, major concerns, potential architectural choices, and relevant aspects of the current implementation.
3. During normal iteration with my coding agent, the developing plan is always captured into CURRENT_WORK, not just the agent's chat stream. I make especially sure to capture any conscious tradeoffs, delayed decisions, roadmapped intentions.
4. When the work is done, check in the CURRENT_WORK file along with it. If it's an important release, tag it-- we'll use those later.

Bam! There's now a record of all those tradeoffs and delayed choices.

As your process gains momentum, you will likely find this document gets most of the group attention from human colleagues. This is fantastic: You've taken planning for the future and "shifted left"! Do a little dance!

Time to actually address that debt:

1. Prompt: "Review all CURRENT_WORK.md iterations between git TAG A and TAG B and list any delayed choices, technical debt, or other missed opportunities for improvement."
2. Plan your next iteration, address some of the pended work as you do.

Congratulations! You have gone from an organization that suffers technical debt to one that manages it proactively. If something doesn't get addressed, it's because the team decided, not because circumstances demanded.

As a next step once this workflow is under control, ask the agent to review the codebase and identify missed opportunities and technical debt for you. Bear in mind that some debt may be emergent, for example a refactor opportunity that only appears after multiple developers contributed in separate areas.