IN THIS BREAKDOWN · 10 SECTIONS
You can read 16% of this breakdown.
The paper in one minute
Ten engineers at Google wrote down what they had learned from running ML systems for years, and the headline was uncomfortable: building and deploying an ML system is "relatively fast and cheap", but maintaining it over time is "difficult and expensive".
They borrowed Ward Cunningham's metaphor of technical debt. Moving fast borrows against the future, and the interest compounds. Their claim is that ML systems have every maintenance problem of ordinary code plus a set of their own, and that the new debt lives at the system level, where a code review cannot see it. Data, not code, decides how the system behaves, so the usual tools for paying debt down (refactoring, unit tests, tighter APIs) do not reach it.
The paper offers no algorithm and no benchmark. It is a catalog. Models entangle their inputs, so changing anything changes everything. Outputs get reused by systems nobody declared. Input signals owned by other teams shift under you. Models pick their own future training data. Glue code and pipeline jungles grow around generic packages until the model is a small box inside a large machine. Configuration outgrows code. And the world changes underneath all of it.
That is why it opens this list. Every later paper here describes a model or a method; this one describes the system you will be responsible for once the demo is over.
Research notes: the problem, approach and results
the most a mature system might be ML code, against at least 95% glue code, in the authors' estimate
lost by Knight Capital in 45 minutes, the paper's cautionary tale about dead experimental codepaths
risk factors the abstract names, from boundary erosion to changes in the external world
ML systems ship quickly and then get slower and riskier to change every month, for reasons no code review catches.
Name the debt. Catalog the system-level ways ML couples things that should be separate, so teams can see the cost before they take it on.
A vocabulary the industry still uses: CACE, glue code, pipeline jungles, undeclared consumers, hidden feedback loops, configuration debt.
Why it matters to an FDE
A forward deployed engineer builds fast, inside someone else's company, and then leaves. That is the exact setup this paper warns about. The demo is the cheap part; the customer inherits the interest.
An LLM application has every debt in the paper under new names.
Undeclared consumers. Someone in finance starts copying your assistant's summaries into a weekly report. Nobody tells you. You improve the prompt, the summaries change shape, and their report breaks. The paper's fix still applies: access controls and explicit contracts for anything downstream.
Unstable data dependencies. Your retrieval index is built from a wiki another team owns, and your model is a hosted API whose version can change. Both are signals you consume but do not control. The paper's advice, to pin a versioned copy until a new one is vetted, is how mature teams handle model upgrades today.
Configuration debt. Prompts, retrieval settings, model names and refusal thresholds are configuration, and in a busy deployment they outnumber the code. The paper says configuration should be reviewed, diffed and checked into a repository like code. Most prompt changes on real projects are not.
The practical consequence is a handover question you should be able to answer before you leave: what did we borrow, and who is paying it back?
Understand the mechanism. Try it on a real problem.
Unlock this breakdown and 49 more papers.
Premium opens every paper in full, plus every answer, concept, course and guide on the site. One payment for six months of access.
6 months · One payment · No auto-renewal
- ◇1 architecture diagram
- </>1 runnable code experiment
- ▦3 results tables
- ?5 interview questions with answers
- 03Key takeaways
The ideas to keep, the full debt catalog, an LLM-era translation and the common misreadings
Free account - 04How it works
How debt enters a system and compounds, mechanism by mechanism, with a diagram
Premium - 05The numbers that matter
Every figure the paper gives, where it gives it, and how to read each one
Premium - 06Try it yourself
A twenty-line experiment that shows three of the paper's debts and the monitor that catches one
Premium - 07Where it breaks
What the paper cannot tell you, and what it could not foresee
Premium - 08Using it on a deployment
A debt register, acceptance criteria and the handover questions to settle before you leave
Premium - 09Interview angles
Five questions this paper prepares you for, with answer hints
Premium - 10Read next
Where to go from here on this site
Premium