In the last post, we talked about how debt is an instrument, not a smell. We carry forward the intentionality and the financial metaphor into the thinking for this post.
In particular, we want you to remember
- Mark’s metaphor of “AI companies that sell coding agents are the equivalent of predatory credit card companies offering introductory cards on college campuses to freshmen.”
- Comprehension debt as a new and higher interest-rate loan. “Every agent is the new hire on day one, forever.”
- “The Last Responsible Moment” needs to account “for ‘holding costs’ [to] curtail sidequests and keep your project running tightly and in its desired direction.”
Building from these cornerstones, this post asks “if that’s comprehension debt, can we just not take on any? Can we pay for all of our understanding now, in cash?” The answer is “no,” for three reasons we’ll get into.
How much to pay, when
Decision capacity is the budget constraint regardless of when the decisions happen.
- Sure, we’re developing faster now, but the work still needs to be verified before customers see it if you hope to retain trust.
- That validation is taking more time now, not less.
- Future You might know more about the situation you’re developing for, but less and less about how your product works under the hood.
Where and when are you going to make which decisions over the product lifecycle? When and how will you pay down your comprehension debt by learning how the system works now? AI spins up an unending amount of decision points, especially if you’re using it as we recommend (experiments in early stages as a way of alleviating traditional technical debt).
Decisions take executive function, and are exhausting in aggregate1;. Every “LGTM” is a micro-loan; but replacing them all with real review would mean slowing down and making lots of decisions. So don’t just shift your Last Responsible Moment to later at the cost of making a bunch of new decisions now, design so you’re making fewer decisions, better, at necessary points.
Example: Tom’s agents spend a lot of their tokens doing technical art: abstract images derived from free play with mathematically defined fields and symmetries which react in realtime to sensors and music (which is also reacting to sensors). The agent handles the coding decisions, and Tom declares whether the aesthetics work or not. Tom has to set up his pipeline in a way that his decisions are easy to make, surfaced at the right points in time, and easy to adjust for (reduced implementation time based on tech debt being lightweight). 2
What to do instead
A lot of agent outputs are experiments. Full comprehension of this throwaway code is buying insurance on a rental. Instead, query the experiments based on what you were trying to figure out when you designed them, and what you anticipate caring about moving forward. Which architectural approach has the fewest security issues? Which is the most modular? You can even ask the agents to remove decisions for you based on parameters you’ve put in place, and surface only the most promising two or three routes forward, with “reasoning.” This reduces the delta between what’s being decided on and the comprehension we have of it.
Example: Tom did not actually know what mathematical algorithm would give “dystopian.” So he followed this playbook:
- Generation — Agents run free-play generation, constrained only by the markdown notes on what Tom’s aesthetic is, and produce dozens of images
- Judgement – Every piece auto-renders to a thumbnail, laid out as a grid of small-multiples. Tom doesn’t look at the code at all.
- Promotion – He picks the 2-3 that kind of work, and snapshots the code that produced them into a database.
- Development – The image that code generates gets opened in a live environment. He requests new code changes or tunes the parameters with a MIDI instrument until the art is satisfying.
There are two things we think come into carrying forward relevant choices into future loops so you don’t have to keep making those choices (unless you want to):
Context
What is relevant for the AI to know based on what you’re currently asking it to do? Context windows aren’t indefinite, and so picking and choosing what context to surface is important. In our session together, we talked about a “Document of Documents” or an Index with reasoning about when each item is relevant, so your agent can pick the right things at the right times. In human orgs, we call this Organizational Folklore, and it sometimes remembers things the humans have rightfully forgotten – “we can’t do it that way because it never works” is actually out of date but no one checked against new realities. Your agent will need to be told to forget such things as well.
Constraints
We talked about three different forms of constraints, each of which should be approached with intentionality:
- Iron Ring constraints (load-bearing ethics and the laws of physics, sometimes at the same time),
- “we’ve always done it this way” fossils, and
- constraints nobody meant mentioned in passing, taken by the agent as binding, and nobody knew it was there to consider removing it.3
Constraints should be aligned with your problem space so far as what can’t go wrong while leaving space for path exhaustion/creativity.
The Rate is Negotiable
This is the title’s claim: the interest rate on comprehension debt is set by how well the relevant information survives. Carrying forward relevant knowledge at the right scale of loop is what gets your code towards “less wrong” and more towards something you can understand and/or build upon for longer because it behaves in a predictable way by following constraints you’ve agreed to or put in place. The debt will still exist, but you get to determine how extreme it becomes over time (and therefore what future options you have) by being intentional about this.
What this means
Last time we talked about comprehension debt as more like a payday loan. That metaphor still applies to vibecoding, LGTM hypnosis, and amnesiac deferral. We hope this post helped you see past the context horizon and to start looking to “when I expand this off of my machine” and pitching to the next person. If decisions are limited rather than proliferated, comprehension debt becomes a line of credit instead of a payday loan, and the question becomes about if it is secured or unsecured. Your collateral are your recorded decisions integrated into your system: Architecture Decision Records (ADRs), folklore that survives, the harness.
And that means, we need to talk about Looping on Loops. Next post!
Footnotes
- The nap is real — see Yegge’s “Nap Attacks.”
- For a performance at Georgetown Steam Plant, Tom and his team were told a theme (“Dystopia All The Way Down”) and a time, but they had no further information about what the space would look like. What are the responsible moments to make decisions in this situation? The dystopic theme and watery sound world (from one of his collaborators) was known weeks in advance, so he developed the static images around the idea of a surveilling eye wreathed in toxic smoke, but near a peaceful oceanside. The ambient lighting wouldn’t be known until the moment of arrival, so in those weeks he chose on-theme but high-chroma colors, readable when projected in a high-ambient light situation. The data pipeline was complete a week in advance, so he took a recording of sensor events in a rehearsal space to get a reasonable simulacrum of the kinds of levels his animation would be reacting to. But the exact variety the sensors would generate in the performance space was unknown, so he implemented a set of UI sliders to allow for fine-tuning the animations to match the reality of the room. During that last week he also implemented a safety harness to ensure coding agents could catch broken shader code immediately, rather than after deploying to the projector, and while operating those agents, made frequent commits to have safe rollback points – at no point did we not have something cool to show to the audience.
- The problem of inferred constraints isn’t new with agents. For instance, in ShapeUp, Ryan Singer describes a design moment where customers asked the team to “add a calendar” to Basecamp. While the team could have inferred a large amount of work (create events, edit events, add people to events, notify people they were added to events, etc.), they did additional discovery to find out a much smaller deliverable.


