When Work Starts to Compound

There's a tempting argument about AI projects. Models improve every few months and code is getting cheap. So why keep anything? Why maintain connectors, components and documentation when next year's model can produce better ones on demand? Keep nothing, regenerate everything.

It's half right, and the half that's wrong is where most of the value of an AI program lives.

Here's the idea in one sentence: work compounds only when each piece of work leaves something reusable behind, and the next piece of work actually uses it. Both halves are required. A team that captures everything and reuses nothing pays for the capture and gets nothing back. A team that reuses whatever happens to be lying around, without capturing on purpose, finds very little lying around.

Ask a team that has shipped five AI projects what the fifth reused from the first four. Often the answer is thin: a few prompts in someone's folder, a connector only one person understands, an evaluation spreadsheet nobody has updated since project one. That team repeated its work instead of building on it.

Ten percent a step

A small model shows what's at stake. The numbers are illustrative, chosen to be plain rather than realistic.

Say one AI project done from scratch costs 100 units of effort: weeks, euros, whatever you count. Some of that effort, say a fifth, produces something reusable: a connector to a core system, a set of test cases, a written decision, an approved pattern of data access. The next project can use those assets, but not perfectly. A connector built for orders covers much of what invoices need; an evaluation method transfers, while the specific cases mostly don't. Say they're about half as useful to the next project as something built for it.

Multiply the two and each project removes 10 percent of the from-scratch work the next one would otherwise do. Earlier assets stay in use, so the savings stack. Packaging an asset so someone else can use it isn't free, so charge 5 units per project for capture.

About half. The eighth project costs around 53 units against the first one's 105. Ten percent a step sounds small. Over eight projects it halves the cost.

Now the opposite. Many AI projects leave behind something that costs effort later: a chain of prompts that has to be retested whenever anything changes, a fix applied by hand in production and never written down. Software engineers call this technical debt, a metaphor Ward Cunningham introduced in 1992: every shortcut keeps charging interest until someone cleans it up. Model it as upkeep, 5 units added to every later project for each earlier one. By the eighth project, cost has climbed to 135.

Scroll sideways to see the whole figure

Over eight projects, a team that reuses nothing spends 800 units. The compounding team spends about 610. The team piling up debt spends 940. And a fourth team, which captures and reuses but never removes anything, spends about 750. It keeps only about a quarter of what the clean team saved, and after the eighth project its costs start rising again.

Three things in this toy model carry over to real work.

Only the product matters. How much you capture times how well it gets reused. Capture twice as much and reuse it half as well, and you get nothing extra. Capture without reuse is strictly worse than doing nothing, because you paid for packaging.

The payoff arrives late. The compounding team is behind after its first project, because it paid for capture, level after the second, ahead only from the third. A program judged on its first two projects will see capture as pure overhead, and cancel it.

Debt and compounding happen in the same teams at the same time. Savings shrink geometrically while debt grows in a straight line, so without removal the debt eventually wins.

Compounding needs capture and reuse at once. Capture without reuse costs more than doing nothing.

What counts as an asset

An asset, in this sense, is anything a piece of work leaves behind that makes later work cheaper or better, and that later work can find. Two tests. Would the next project be slower or worse without it? And will the people, or agents, doing the next project know it exists and be able to use it without asking its author? A connector only its author can operate fails the second test. So does a brilliant prompt in someone's personal notes.

Five kinds of asset pass both tests reliably in AI work.

Evaluation cases. An evaluation set is a fixed collection of real cases with agreed correct outcomes, run after every change. Each case makes every later decision cheaper, from switching models to deleting code you no longer need (Build an Evaluation From Your Own Work).

Recorded reasons. A short decision record for each significant choice: what was decided, which alternatives lost, why, and what would make it worth revisiting. Kept together, they work like a ship's log, written as the work happens. They save the next team from reopening settled questions, and let it reopen the right ones (Write for the Model That Doesn't Exist Yet).

Cleaned and connected data access. A documented path from an AI system to the data it needs, with the quirks handled. The first project that reads the ERP, the core system holding orders and accounts, pays for discovering that customer codes changed format in 2019 and that half the addresses live in a free-text field. The second project gets that for free, if someone wrote it down.

Reusable skills and components. Packaged instructions, scripts and tools that an agent or a person loads when a task calls for them. The Agent Skills format is now an open specification read by tools from several competing companies, so a skill written once can travel between them.

Earned permissions and trust. A security approval for a pattern of access. A process owner's willingness to let drafts go out after a spot check. A track record that justifies more autonomy next time. They accumulate slowly and are the asset most often forgotten, because they live in other people's decisions rather than in a repository.

The debts mirror them. Prompt sprawl: the same instructions copied into five notebooks and three tools, each slightly edited, none authoritative. One-off scaffolding: code that compensates for one model's weakness and has to be maintained, retested and eventually found and removed. Undocumented fixes: corrections made by hand that work until the person who made them leaves. Systems built around language models add a twist to old-fashioned technical debt: much of their debt is text that nobody treats as code and nobody tests.

The capture step

Left alone, every asset stays implicit. The evaluation cases sit on one laptop. The reason for a threshold is in a chat thread. The approval is in an email to someone who has since changed teams. Implicit assets are worth close to nothing to anyone who wasn't there.

So compounding needs a deliberate step. The simplest form is a short session within days of a project reaching its result, while people still remember, built around one question: what do we keep? In practice:

• Which cases did the system get wrong, and are they now in the evaluation set with the right answer?
• Which decisions would a newcomer question, and is each written down with its reason?
• Which access did we get, from whom, on what conditions, and where is that recorded so the next team reuses the pattern instead of repeating the review?
• What did we build that another project could use, and is it where that project will look?
• What did we build only to compensate for the current model, and is it labeled so someone can remove it later?

The last question is the one teams skip, and it's what makes later cleanup possible. Scaffolding labeled with the weakness it covers can be tested and deleted when a new model arrives. Unlabeled scaffolding stays forever, because nobody dares remove what they don't understand.

Capture needs an owner and a destination: wherever the next piece of work will start. An asset stored where the next project doesn't look is worth the same as one never stored.

The ratchet

The most valuable capture happens at the moment something goes wrong. A ratchet turns only one way: every real failure becomes a test, a constraint or a sensor, so the same failure can't come back silently.

The practice is old. In Toyota's production system, when something abnormal happens a machine stops or an operator pulls a cord to stop the line, and the point is to detect the problem clearly and keep it from recurring. Google's reliability engineers write a blameless postmortem after an incident and track its follow-up actions as bugs until they're closed, because a postmortem with no follow-up changes nothing for users.

In AI work the three outlets do different jobs.

• A test catches the failure before the next release. A misread field on a supplier invoice becomes a new evaluation case, added before anyone touches the prompt. The set grows toward the failures your system actually has.
• A constraint makes the failure impossible. An agent that once sent a draft to a customer by mistake loses the permission to send without approval, enforced by the tool itself rather than requested in a prompt.
• A sensor notices failures no test could predict. A scheduled run of the evaluation set on an unchanged configuration catches the day a provider quietly points a model name at a different model.

Scroll sideways to see the whole figure

Applied without judgment, the ratchet turns every incident into a new prohibition until the system stops being useful. Each failure deserves the narrowest fix, and the pile of tests and rules needs regular cleanup, or it becomes debt of its own.

The tidy

Assets decay. The fastest to go is anything tuned to one model, because models have short lives: Anthropic retired Claude 3 Opus, released in early 2024, in January 2026. Settings expire too. On Claude models from 4.7 onward, setting temperature to a non-default value returns an error, so a team that had tuned it task by task lost that work outright. Even genuine assets fade: an evaluation case labeled correct under last year's payment terms is wrong under this year's. The counter is a periodic tidy with three verbs.

Expire what's no longer needed. When a new model arrives, the first experiment is removing scaffolding: delete the step, run the evaluation set, keep the deletion if results hold. Notice what makes that safe. A team with a good evaluation set can delete scaffolding in an afternoon. A team without one keeps everything, because it can't tell what's load-bearing. Compounding assets are what let you pay down debt.

Promote what keeps recurring. A check one person runs by habit becomes a test in the team's set. A prompt three people copied becomes a shared skill with an owner. A workaround applied at three customers becomes a product feature (What a Deployment Engineer Should Own, and Leave Behind).

Delete the rest. Anthropic's own guidance for the instruction files its coding agent reads offers a test that works for anything: for each line, would removing it cause mistakes? If not, cut it.

A monthly half hour per team and a pass after each model change cover most of the value. A tidy that waits for a crisis comes after the debt has already compounded.

What a better model can't regenerate

Back to the argument we started with.

A good part of it is right. Code, formats, boilerplate and document layouts are getting cheaper to regenerate than to maintain, and polishing what a model can reproduce is wasted care.

It fails on one specific class of asset: anything that records a fact about the world or the organization that can't be inferred from what survives in writing.

• Reasons. Why the threshold is €500, why weekend messages are held, why one customer is exempt. People decided these in rooms, often for reasons never typed anywhere. A model can guess a plausible reason, and when two plausible guesses conflict, nobody is left to settle it.
• Outcome data. Which cases went wrong, what the customer did next, which drafts the clerks corrected and how. That's history, observed once. A model can analyze it and can't produce it.
• Labels. The correct answer to a hard case is a judgment by someone who knows the business.
• Approvals. A security review that approved a pattern of access is a decision by an accountable person. A model can draft the request. It can't grant itself the approval.
• Trust. A process owner's willingness to let a system act rests on a track record, and a track record can only accumulate.

A future model can regenerate what you built. It can't regenerate what happened, why you decided, or who agreed.

So the objection ends up sharpening the advice. Keep cheaply, or don't keep at all, whatever a future model can regenerate. Keep carefully the reasons, outcomes, labels, approvals and record that it can't. Better models raise the value of the second kind: a team with a good evaluation set and approved access can put a new model to work on real cases within days, while a team that kept nothing has to rebuild both first.

What to do

Run a capture session after every project, within days, with the five questions above. Give it an owner and put what you keep where the next project starts.

Turn every real failure into a test, a constraint or a sensor, choosing the narrowest one that addresses the cause.

Label scaffolding with the weakness it covers, and try deleting it every time a model changes.

Tidy on a schedule: expire, promote, delete.

Measure whether it's working. Track time to first result across projects; if it falls, something is being reused, unless later projects are just easier. Track reuse: for each asset, how many later projects used it, and delete what nobody has reused in two quarters. Counting documents written or skills published measures effort, not compounding. Then run the decisive test: give the next project to a new person or a different team. If they also start fast, the assets are doing the work. If they start from zero, the compounding was in someone's head, and it walks out with them (Measuring AI Impact Without Fooling Yourself).

And judge a program on its third project, not its first. The early failures and missteps of an AI program can become the foundation of what comes later, but only for a team that wrote them down where the next project would look (Designing an AI Program That Ships).

Check yourself

Why does a team that captures a lot but reuses little gain nothing?

Compounding is the product of how much you capture and how well it gets reused. Capture also costs effort for packaging, so capture without reuse is worse than doing nothing.

What makes it safe to delete scaffolding when a new model arrives?

A good evaluation set. You delete the step, run the set, and keep the deletion if results hold. A team without one keeps everything because it can't tell what is load-bearing.

Why can a future model not regenerate reasons, outcome data or approvals?

They record facts about the organization that were decided or observed once and may never have been written down. A model can guess a plausible reason or analyze history, but it can't produce what happened or grant itself an approval.