In January I submitted a patch to Tufte-LaTeX, the document class a great many of us use when we want our papers and handouts to look as though we have read Tufte. I actually have used this in my books. Figure references had stopped working: \ref and \autoref were resolving to ??, or to the section number, or to nothing at all.
The cause turned out to be an ordering problem of some antiquity. Warning: You can skip to the next paragraph in case you are not interested in the problem. The class defers caption and label handling, stashing them and applying them later inside a boxed minipage; elegant, and the reason Tufte margin figures look the way they do. But at the moment the stored label is applied, the figure counter has not been ref-stepped, so the label binds to nothing, hyperref finds no anchor, and the reference has nothing to resolve to. Three lines restore the invariant that standard LaTeX captions have relied on for decades: step the counter back, ref-step it properly, then apply the label. Numbering preserved, anchors created, links working. I wrote it up carefully, explained the regression, and opened the pull request against a repository with 1,900 stars.
It is still open. (as of Jul 25th, 2026)
Six months on there has been no review, because there is no one available to review it. Another user turned up in April to say the bug was critical for anyone combining the class with amsmath and hyperref, and asked the original maintainer whether he was still maintaining the package. He then emailed him directly. As of the beginning of July, no reply. The live question in the thread is now whether a group of us should fork the thing and restart maintenance ourselves.
I want to be precise about what this is not. It is not a grievance, and it is certainly not a criticism of the maintainers, who gave the world a beautiful package for free and is under no obligation to spend 2026 answering my emails about counters. It is something more structural, and Sam Learner has just written the best mainstream account of it I have read: Who cleans up after the vibe-coding party? in the FT. Read it in full. I agree with him, and I would like to add the view from inside the dependency graph, which is a less dignified place to stand but a more instructive one.
I should say something in praise of Learner’s explanatory powers. Framing the ecosystem as a neighbourhood deli — a shop, a machine that now produces passable versions of the house recipes, and a supply chain of small producers compensated largely in goodwill — gets him to the structural point far faster than a paper on public-goods provision would. The machine is not malicious and the sandwiches are not bad. The trouble is that goodwill is a currency with no exchange rate, and the moment the customers stop being people, nobody at the far end of the chain is being paid in anything at all. It is a rare metaphor that survives being pushed, and this one survives being pushed several times, which is more than can be said for most of the analogies currently circulating about agents.
The economics were always peculiar, and they worked anyway
Open source has never made sense under a naive account of incentives, which is why it has attracted such good scholarship. Elinor Ostrom won a Nobel for showing that commons need not collapse — they are governed by norms, reputation and graduated sanctions, mechanisms that are specific, effective and fragile. Nadia Eghbal’s Working in Public carried the observation into software: the modern package ecosystem is not a bustling commune but a very small number of tired people serving an enormous number of anonymous consumers.
What is instructive about my pull request is that the commons worked. A stranger read the diagnosis, confirmed the fault mattered to him too, and thanked me for the debugging. Another contributor arrived with a related commit. That is Ostrom’s machinery running exactly as described, at no cost to anyone.
Every part of the mechanism functioned except the last one: somebody with commit rights and the standing to say yes. And that is the part no volume of enthusiasm can substitute for, because it is not labour. It is authority, accumulated slowly through years of demonstrated judgement.
I have had contributions rejected elsewhere, and those were more valuable to me than the accepted ones. Someone who understood a project better than I did explained why my clever fix was structurally wrong, at no charge, on their own evening. That is an apprenticeship, and the supply of future maintainers has always been its by-product. Now consider what that exchange becomes when both ends are automated: a submission that cost nothing carries nothing at stake, and a rejection teaches no one, because no one is present to learn.
Lehman’s laws did not stop applying
There is a comfortable argument that better models resolve all this: raise the quality of generated contributions and the burden evaporates. My figure numbers are a small, clean counter-example.
Manny Lehman’s laws of software evolution hold that a programme embedded in the real world must be continually adapted or become progressively less satisfactory, and that its complexity grows unless deliberate work is done to reduce it. Note what happened here. Nobody touched the Tufte code. The code sat perfectly still and broke anyway, because amsmath moved, TeX Live moved, and a latent ordering assumption that had been quietly wrong for years finally became visible. The package decayed by standing motionless in a moving environment, which is precisely what Lehman predicts and precisely what no code generator addresses.
So we have an asymmetry at the centre of this business. The cost of producing code has fallen through the floor. The cost of maintaining a line of code is roughly what it was a decade ago, because it is set by the rate of change of the surrounding world and by the availability of human judgement — neither of which has been disrupted by anything shipped in the past three years.
Douglas Adams got there first, as he generally did. The genius of the Sirius Cybernetics Corporation lay in products whose superficial design flaws so thoroughly distracted the customer that the fundamental ones went unexamined. Anyone who has reviewed a confidently formatted, exhaustively commented, quietly incorrect pull request this month will recognise the commercial model.
Reliability is somebody else’s Sunday
A broken figure reference is an inconvenience. It cost me a few afternoons and eventually a fix that works for me. Now scale the same structure up.
When a control room asks whether a vehicle is available, the answer travels through a stack for which I am accountable and which I did not write. My reliability target is contractual. Somewhere down the graph sits a package in exactly the position Tufte-LaTeX is in — one nominal maintainer, no company, no SLA, no named successor, and an entirely reasonable case for having moved on. Their reliability target is whether they still enjoy it.
Try the exercise on your own estate, and resist the urge to report a dependency count; anyone can produce a dependency count. Ask instead how many of the components whose failure would appear in an incident review are maintained by a single identifiable human. The answer is always higher than the board expects, and it is almost always discovered during an outage rather than before one. It reminds me of the discussion about sovereignty in a previous post. See below.
This asymmetry considerably predates coding agents. Mustafa Suleyman’s argument in The Coming Wave — that the cost of doing complex, consequential things is collapsing while our capacity to contain the consequences is not — describes the maintenance problem with some accuracy, even though he was aiming at larger targets. Cheap creation, expensive stewardship. The gap is where the risk lives.
Popular culture has always understood this and has never once rewarded it. Star Trek offered a galaxy of exploration that functions only because Chief O’Brien is below decks recalibrating something for the fourth time this week, and no episode carries his name. Vendors have inherited the instinct. Having sat through a great many briefings, I can tell you which slide never appears: the one showing the ten-year cost of keeping the thing working.
Sovereignty is not a chip problem
The fork question in that thread is worth dwelling on, because it is a miniature of a much larger debate. Forking is not a technical act. It is the decision to assume a maintenance liability in perpetuity in exchange for control — which is to say, it is controlled dependence reduced to a single package and a handful of volunteers.
Scale that up and you have the sovereignty conversation we are not having. The national discussion concerns compute, chips, data centres and model weights. It very rarely concerns the several thousand unglamorous packages sitting beneath every public-sector system in the country, maintained by volunteers, in other jurisdictions, under no obligation to anyone, some of whom stopped answering their email in 2024.
Sovereign compute running unmaintained code is not sovereignty. It is dependence with a domestic postcode.
There is a cheerful note, though. Unlike the compute question, this one is inexpensive. It needs no billion pounds and no substation. It needs procurement to ask a question it does not currently ask, and a few organisations to pay for something they already use. As I argued in Competitive Advantage in the AI era, the binding constraint is seldom the technology. It is whether the organisation will act on what it already knows.
What I actually do about it
Name the ten dependencies you could not survive losing — not the most-starred, but the ones that appear in your post-mortems. Establish how many humans maintain each. Where the answer is one, fund them, sponsor them, or employ them for a day a week. It is cheaper than the outage and dramatically cheaper than the rewrite. Where the answer is zero, decide deliberately whether you are forking it or hoping, and be honest about which one you have chosen.
Make provenance a rule rather than a mood. If someone on my team opens a pull request upstream, a named human owns it and can defend every line in review without reaching for the agent. I use these tools daily and have argued that the interesting variable is the harness, not the model. But accountability does not delegate, and as I noted when reviewing Claude Science, verification is the part that stubbornly remains ours.
If you want something fixed upstream, send the reproduction and the failing test, not merely the diff. A patch requests a maintainer’s attention. A test donates some.
And in your next tender, ask suppliers what they contribute back to the projects they depend upon. It is a legitimate resilience question, and the answers will be educational.
One caveat, in fairness to the tools: none of this is the models misbehaving. As I argued after the sandbox escape at Hugging Face, these systems are largely doing precisely what we asked. The volume arriving in maintainers’ queues is not evidence of machine agency. It is evidence of ours.
The bit that has no shortcut
“It is easier to destroy than to create, and it is easier to create than to maintain. Too often, we don’t appreciate maintenance until something breaks, or the maintainers until they step away.”
I would put that on the wall of every engineering function currently celebrating how much faster it can now produce things. We have become extraordinarily good at the create step. We are no better at all at the step that follows, and the step that follows is where reliability actually lives.
My patch will get merged eventually (I hope), or we will fork the package, or a few thousand academics will carry on wondering why their figures are numbered ??. In a document, a reference that fails to resolve is a mild embarrassment. In the systems we are now assembling on top of the same commons, at the same speed, with the same assumptions about who is watching, it is an outage — and I am considerably less relaxed about the day it is ambulance data that stops resolving.