The Extended Frontier: Repairability

---

Changelog

• 2026-03-24 — Initial draft published.

*This is the third post in a series called "The Extended Frontier." [Part 1](/2026/03/24/extended-frontier) establishes the core claim: the jagged frontier of AI capability is predictable from the extensions that constitute actual work. [Part 2](/2026/03/24/extended-frontier-first-mile) argues that verification is the last mile—most people are stuck on the first.*

---

Verification is where the conversation usually stops. Did the AI get it right? Can you check? The previous posts in this series have been building that case: the frontier is smooth where work is extended with feedback loops, peer review, testing, and the whole ecology of practice that makes evaluation possible.

But there's a second question that matters just as much: when you find the error, can you fix it?

Verification catches the error. Repairability determines whether you can do anything about it. These are different properties of the work. A domain could have excellent verification and terrible repairability. Or the reverse.

Screws, not glue

IKEA furniture is not well-made furniture. But it is remarkably repairable furniture. The panels connect with screws and cam locks, not adhesive. The hardware comes in numbered bags keyed to labeled steps. A non-expert can take it apart and put it back together.

Someone decided screws, not glue. Someone decided modular panels, standard sizes, Allen keys in the box. None of this makes the bookshelf sturdier. All of it makes the bookshelf recoverable when you realize in step 12 that you installed a panel backwards in step 7.

Concrete is the opposite. You pour it, it sets, it's done. You can verify it while it's wet—is the form right, is the mix right, is the surface level. But once it cures, your options are demolition and replacement. Verification and repairability are independent axes.

Crochet is the one that gets me. You can unravel rows and redo them. But you lose the rows. Twenty rows past a mistake, and you're pulling out hours of work to get back to the error. Physically reversible, practically expensive.

Four dimensions

Repairability isn't one thing. I keep coming back to at least four dimensions.

Reversibility. Can you undo the action at all? Git lets you revert a commit. A sent email can't be unsent. A filed legal brief is on the record—you can file corrections, but the original filing happened. A medical recommendation, once acted on, has consequences that no retraction reaches. The question isn't whether you wish you could undo it. It's whether the medium allows it.

Modularity. Is the work in separable parts? IKEA is modular by design—replace one shelf without rebuilding the unit. A lesson plan has separable segments; you can reteach Tuesday without redoing the whole week. Code can be modular: functions, modules, services with defined interfaces. A novel doesn't decompose the same way. Rewriting chapter 4 might require rewriting chapters 5 through 12, because the narrative is load-bearing across the whole structure.

Cost of recovery. Even where reversal is possible, what does it cost? Reverting a git commit takes seconds. Unraveling 20 rows of crochet takes hours. Recalling a medical recommendation after the patient has already acted on it—that's not even the same category of "cost." "Possible" and "practical" are not the same thing.

Visibility of error state. Can you see that something went wrong while recovery is still cheap? With IKEA, you're on step 7, the holes don't line up, you're only a few steps back. A compiler error fires the moment you save. But crochet—you might be 20 rows past the dropped stitch before you notice the pattern is off. Strategic advice—you might never know it was wrong. The longer the gap between error and detection, the more the other three dimensions deteriorate. Reversibility gets harder, modularity gets less useful because the error has propagated, and cost compounds.

These interact in obvious ways. Early detection plus cheap reversal is where you want to be. Late detection plus irreversibility is where you don't.

Repairability is an extension

This is where it connects back to the series. Repairability isn't just a property that some work happens to have. It's an extension—designed into the work, built into the tools, embedded in the practices.

Git is the obvious example. Version control is repairability infrastructure. Every commit is a save point. Branches let you try things without risking the main line. Diffs show you what changed. Revert takes you back. Bisect helps you find where things went wrong. None of this is accidental—it's decades of design decisions aimed at making software work recoverable.

But it goes further. Test suites don't just verify—they localize. A failing test tells you not just that something is wrong but roughly where. That's a repairability function, not just a verification function. CI/CD pipelines catch the error before it reaches production, when the cost of recovery is still a revert rather than a rollback-with-data-migration. Code review catches architectural problems when the fix is "restructure this function" rather than "restructure the entire service."

Software engineering is organized around the assumption that you will make mistakes and need to fix them. That assumption is what makes coding one of the smoothest parts of the AI frontier.

Most domains don't have this

Repairability explains a lot about why coding works so well with AI—things that verification alone doesn't cover.

Take the lawn care example from the previous post. You can verify that your lawn looks bad—the brown patches are right there. But repairability? Grass grows on biological time. You can't revert a bad fertilizer application. You can't modularly replace one section of soil chemistry. The cost of recovery is "wait a season and try again." The brown patches show up weeks after the damage was done.

Teaching is similar. A lesson plan has decent modularity—you can reteach a concept. But the student's confusion from a bad explanation compounds in ways you can't cleanly reverse. You can try to correct it, but correction and reversal aren't the same thing. The student now has two competing models in their head.

Legal work has strong verification (Shepardizing, case law databases, opposing counsel who will find your mistakes) but weak repairability. A filed brief is filed. A missed deadline is missed. A bad argument in oral proceedings is on the transcript. The practice is structured around getting it right the first time, not around recovery—because the medium doesn't support cheap recovery. That shapes how cautiously lawyers approach AI in ways that the verification-only framing misses.

Medicine is the starkest case. Verification infrastructure is extensive: labs, imaging, second opinions, clinical teams. But a misdiagnosis that leads to treatment has consequences that no correction fully reverses. The patient's body has been changed. Time has passed. Other conditions may have developed while the wrong one was being treated. High verification, low repairability. "Human in the loop" means something fundamentally different in medicine than in software—the loop has to catch the error before the action, because afterward the cost of recovery isn't just high, it's a different kind of cost.

What happens when AI speeds things up

AI accelerates production. That's the pitch. And repairability determines whether acceleration is safe.

In high-repairability domains, speed is mostly fine. Generate code faster, find bugs through testing, revert what doesn't work, iterate. The repairability infrastructure absorbs the increased throughput. You make more mistakes per hour but you also fix more mistakes per hour.

In low-repairability domains, speed is dangerous. Generate more medical recommendations faster, and each wrong one has consequences that accumulate and can't be cheaply reversed. Generate more legal filings faster, and each error is on the record. Generate more strategic advice faster, and the decisions compound before anyone checks whether the advice was sound.

The acceleration doesn't change the repairability of the domain. It changes how much damage accumulates before the slow repair mechanisms can respond.

This asymmetry matters for policy. The domains where AI produces the most impressive acceleration are often the ones with the best repairability—coding, data analysis, structured content generation. The domains where acceleration is most dangerous are the ones where repairability is weakest. But the impressive demonstrations in high-repairability domains generate enthusiasm that gets applied to low-repairability domains without adjusting for the difference. That's not a subtlety. It's the mechanism by which AI enthusiasm outruns AI safety—not through malice, but through misapplied pattern matching.

Repairability can be designed

The IKEA insight is that repairability is a design choice. Screws, not glue. Someone anticipated that the person assembling the furniture would make mistakes and need to recover from them.

The same applies to AI-assisted work.

CrochetPARADE—a formal verification system for crochet patterns—is a good example of how verification and repairability blur. By catching structural errors before you start crocheting, it moves error detection upstream of the point where recovery becomes expensive. It looks like verification. It functions as repairability.

Staged deployment in software (dev, staging, production) is repairability infrastructure. Each stage is a checkpoint where the cost of reversal is lower than at the next stage. Rolling back from staging costs nothing. Rolling back from production costs incident response, data migration, user trust. The stages don't catch different errors—they provide different recovery costs for the same errors.

I think about this with the tools we're building at Hypandra. Every design decision about how work is structured is implicitly a decision about repairability. Can the user undo this action? Can they see what changed? Can they go back to a previous state? Is the work modular enough that a mistake in one part doesn't corrupt the whole? These aren't features. They're what determines whether the user's frontier is smooth or jagged.

The connection back

Temporal distance—how long between the error and its detection—is about when you find out. Repairability is about what you can do once you know.

These are independent. Concrete has fast detection but low repairability—you can see the problem immediately but you can't undo it once cured. An IKEA shelf installed crooked might not be noticed for a week, but when you do notice, you just unscrew it.

The ideal is coding: compiler catches errors instantly, git lets you revert. The nightmare is strategic advice that turns out to be wrong six months later when the consequences are baked in.

This connects back to the first-mile argument from the previous post. Part of why the first mile is so hard in many domains is that you can't easily try and see. In coding, "just try it" is reasonable advice. Run it, see if it breaks, fix it. For the lawn, the temperament, the sleep schedule, the legal filing—"just try it" is somewhere between impractical and reckless. Repairability determines whether experimentation is a viable learning strategy or an unacceptable risk.

That matters for how people learn to use AI. If you can't cheaply experiment and recover from mistakes, you can't develop the intuitions that Mollick says come from "using AI a lot." The try-and-learn cycle requires that trying be cheap. Repairability is what makes it cheap.

What I'm working toward

The next post asks what else changes beyond productivity and output quality when AI enters a practice—skill formation, craft, pace, accountability. The handoff analytic is what makes those dimensions visible.

Repairability is one of those extensions. It can be designed in, like IKEA's screws. It can be inherited from existing practice, like version control. It can be engineered after the fact, like CrochetPARADE. Or it can be absent—and when it's absent, every other extension has to work harder, because errors that get past verification have nowhere to go but downstream.