I was restoring old files. Not for a client — for myself. Thirty years of digital sediment, backed up across a graveyard of dead machines: old mail, source trees, CVs, project documents, customer work, half-remembered websites, and databases in formats I hadn’t thought about since the last century. I wanted to turn the whole pile into a personal memorabilia wiki, and I’d pointed a coding agent at it and told it, in effect, to go digging.

It came across some Lotus Notes data. Old Notes data. And I said, sure, open that up — and of course, we don’t have Lotus Notes. The vendor sold the product off years ago. The client software isn’t installed on anything I own. The passwords are long forgotten. By every rule I grew up with, this was a sealed tomb.

“No Notes client? Fine. The AI wrote enough Notes software to get my data back.”

Claude Code¹ shrugged. “No worries, I’ll just invent a driver in C++.” And it did. It opened the Notes NSF file. The whole thing took under three minutes. Fucking crazy.

The easy reaction is the wrong one

There is a tidy, dismissive read of that anecdote sitting right there, waiting for you: yeah, yeah — AI wrote a parser. Big deal. They do that now. File it away, upgrade your subscription, move on.

That read is comfortable, and it is wrong, and it is the most expensive mistake you can make about what just happened. Because the parser is not the story. The story is where the parser came from — that a missing capability, a piece of software that did not exist anywhere in the world for this specific job, got manufactured as a step inside the work, and the work simply continued. This short book is about the thing you’d miss.

What you’ll be able to do by the end

By the last page, three things should feel obvious that probably don’t yet:

• ①Name the pattern. Encounter → synthesise capability → hit a boundary → re-engineer → continue. Once you can see it, you’ll spot it everywhere.
• ②Understand why a six-hour agent is a more capable organism than a one-minute agent — and why interrupting it is worse than interrupting a person.
• ③Re-price your own backlog. The “impossible” list you keep in your head was costed under the old economics. It’s stale.

And to see all of that, you first have to unlearn a belief so deep you probably don’t know you hold it: that the capabilities you have are a fixed input. That you build a workflow out of the tools that already exist, and when a tool doesn’t exist, you’re blocked — engage a specialist, scope a project, buy a product. We’ll take that belief apart in the next chapter.

Let me be honest about it up front

I’m not going to tell you the agent derived the entire Lotus Notes format from first principles in five minutes, out of thin air. It didn’t. An NSF file is a real database with a documented history, and there is existing knowledge about its structure in the world. My honest inference is that the agent found enough of that knowledge — format notes, headers, structural clues — to synthesise the particular reader it needed for my files.

And that is almost more interesting, not less — because it means the boundary that used to seal these tombs shut is now cheap to cross for a specific mission. How far that reach extends across every dead format on earth is a genuinely important question, and it’s the one I take up in a companion piece, The Backup Is the API. This book is deliberately narrower and, I think, sharper. It’s about the engineering economics of what you just watched: what it means that the software arrived as a step, what that does to the size of the thing we call “an engineering job,” and what it does to the price of everything you’ve been putting off.

Start with the tomb, and how expensive it used to be to open one.

To feel what changed, you have to remember what opening an extinct format used to require. It wasn’t hard so much as it was a procession — a fixed sequence of expensive steps, every one of which could stall for days, and any one of which could kill the whole effort.

Every extinct format was a little sealed tomb, and the cost of opening it was absurd. So most of them stayed sealed. The rational move, nearly always, was to leave the data where it lay and pretend you didn’t need it. Today, the agent manufactures the archaeological tool at the tomb door. The procession collapses to four steps: what is this? I need a reader. Writes one. Opens it.

Why did we ever build it the hard way?

Because software was expensive. That is the whole answer, and it’s worth sitting with. When writing a reader cost human-weeks of skilled effort, you only did it once, and you did it properly — a general solution that handled every variant, supported and maintained, so the cost could be amortised across everyone who’d ever need it. Capability was something you procured at product scale, and then you designed your workflows out of the capabilities you happened to have. Miss one, and the answer was reflexive:

Engage a Lotus Notes migration specialist. Find the supported software. Scope a discovery project. Three weeks.

That reflex — procurement, specialist, project — was not stupidity. Under the old economics it was correct. The point of this book is that the economics moved, and the reflex didn’t.

An NSF is not a ZIP file

It matters that the thing the agent walked into is genuinely hard. An NSF — a Notes Storage Facility file — is not a glorified archive you can unzip. It’s a real document database with typed items, access-control lists, object stores, compression behaviours, and a long lineage of on-disk formats. HCL still documents an entire native C API for opening these databases and reading their contents — functions like NSFDbOpen, NSFSearch, NSFNoteOpen and NSFItemInfo, a whole storage model sitting underneath.²

Which brings us to the single line that names what fell:

“Format extinction is ceasing to imply information extinction.”

I’ll say that once and then hand it off, because the sweeping version of that claim — any dead format, anywhere, now openable — is a separate argument with its own edges, and I make it in The Backup Is the API. This book stays in a tighter lane. Because the truly startling thing about my afternoon wasn’t that the tomb opened. It was how it opened — and what that does to the size of the job we call “engineering.”

Once the first NSF was open, my actual intent became clearer — I didn’t want to read Notes, I wanted the records out of Notes and into Postgres, where I could do anything I liked with them. “Yep,” the agent said, “done.” It had copied the records across. Then it found another NSF and reused its reader automatically, no decision required. Then it found one bigger than four gigabytes.

“Oops — our driver doesn’t handle blobs past 4 GB. Don’t worry, I’ll just re-engineer it.” Five or six minutes later, it did, and kept going.

Read that again, slowly, because everything turns on it. The boundary the agent hit was not in Lotus Notes. It was in its own freshly written software. Its abstraction had been too narrow — it hadn’t planned for four-gigabyte blobs — so it changed the abstraction and continued the archaeology. That is not “AI helped me write a converter.” That is an adaptive toolchain being synthesised in the path of the work.

The loop

Strip it to its shape and you get a loop that repeats whenever reality pushes back:

Traditional software design runs the other way around. It says: we have capabilities A, B and C — now design a workflow from them. The agent inverts it. It says: I need D. I don’t have D. I’ll make D. Right, back to work.

It’s worth drawing the two worlds side by side, because the difference is the entire book:

Mission-shaped software

I did not procure an NSF Reader Pro™. I had a mission — recover my old world — and the software’s shape was determined entirely by whatever obstruction the mission ran into. Call it mission-shaped software. The reader existed because an NSF was in the way; the moment it wasn’t the objective anymore, it became a temporary component in a migration pipeline; and when it broke at 4 GB, it got redesigned on the spot. The striking property is that the lifetime of that software might be twenty minutes. It doesn’t need:

• ×a product name
• ×a UI, or installation documentation
• ×a roadmap, or generic configuration
• ×support for every NSF ever made
• ×a vendor, or a purchase decision

It needs to open my files today. The asset was never the software; the asset is the recovered history, and the software is exhaust emitted while pursuing it — which is the whole of the “code is not the asset” argument, compressed into an afternoon. When the reader broke, the agent didn’t nurse it. It regenerated it from the same intent. The intent is the kernel; the tool is disposable.

Why the pipeline couldn’t have been designed in advance

We usually picture an architect drawing the topology up front: an LLM step, then a query, then another LLM step, arrows all planned. But nobody drew “mount the VMDK, reverse the struct, boot QEMU” before the work began. Those boxes appeared because reality kept fighting back and the agent kept forging the next thing it needed.

The workflow is not designed first and executed second. It precipitates out of contact with reality. The pipeline is the trace left behind by thinking.

When code generation is nearly free and the agent sits on a general-purpose machine, the shell becomes a meta-tool: need something → write a program → run it → the capability now exists. The distinction between tools the agent has and tools the agent can create has almost disappeared. And this isn’t a lone party trick, either — it’s already being productised. Anthropic documents agents persisting their own code as reusable functions, building “a toolbox of higher-level capabilities” over time, evolving the scaffolding they need to work.⁴

An ETL that writes its own decryption software

Here is the sharpest way I can put the whole shift. Classic ETL — extract, transform, load — is defined by a buried assumption: that a source connector already exists.⁵ The assumption is so load-bearing that an entire industry exists to pre-build connectors for you. And it means that, traditionally, an ETL dies the moment you don’t have the server or library to read the source. No connector, no pipeline.

Put a persistent goal, broad machine access, an accumulating pile of scripts, and the ability to build new instruments together, and a model stops being a very smart prisoner in a chat box. It becomes a self-equipping expedition — which is where this book gets its name, and what the rest of it is about. Next, the comparison that makes the size of the change impossible to wave away: the company that owned this format, and how long it took to move the very same boundary.

The agent’s five-minute fix only becomes astonishing when you put it next to the company that owned this format. So let’s do exactly that, because the comparison is the point of the whole book.

The four-gigabyte limit is not an arbitrary number. It was a real ceiling in real products, and the history of how it moved is documented. IBM’s Notes/Domino Release 4 topped out at 4 GB per database. Release 5 raised that to 64 GB — a sixteen-fold jump — and shipped around 1999.⁶ Then that 64 GB ceiling stood, unchanged, through the 8.5.x and 9.0.1 generations, for the better part of two decades — until Domino 10 finally lifted it to 256 GB. HCL’s own documentation says it in as many words: the maximum “has increased to 256 GB; previously it was 64 GB.”⁷

Each of those moves was a product generation. Behind every row sits storage architects, compatibility analysis, on-disk-structure evolution, a test matrix, release engineering, and customer migration. The jump to 256 GB still shipped with rules about which on-disk-structure version you needed and how replication behaved beyond 64 GB.⁷ That is product-scoped engineering, and it took years — cumulatively, plausibly person-decades of ecosystem effort.

IBM moved a boundary as part of a product generation. The agent moved a boundary as part of reading the next file. That’s not “coding faster.” The unit of engineering has changed.

That sentence is the load-bearing claim of the whole book, so it gets stated here, definitively, and every later chapter points back to it rather than re-arguing it. My own instinct, watching it happen, was the same one you probably had reading the table: the main point is how long it took IBM to move 4 GB to something larger — probably human years. The agent did it in five or six minutes.

Now let me be scrupulously fair

This distinction is load-bearing, so I want to get it exactly right and not oversell it. These are not equivalent engineering burdens.

The agent did not solve IBM’s problem, and I won’t pretend it did. I also can’t hand you a precise “IBM spent 17.3 engineer-years on the 4 GB barrier” figure, because no public internal project accounting exists to attach a number to any single ceiling move. The defensible frame is the dated ladder itself: 4 GB to 64 GB to 256 GB, across product generations and decades.

So why does the difference matter, if it isn’t apples to apples?

Precisely because of that asymmetry. Historically we engineered the general solution because software was expensive: spend the human-years, make the reader handle the whole supported world, do it once. The agent doesn’t reach for generality at all. It says: I have encountered file 8437; my present software can’t cross this boundary; I will change the software to cross the boundary I’ve actually met.

Generality used to be the rational bet. Now it’s over-engineering for a mission of one. The unit of engineering shrank from “a product generation” to “the next file” — and once you’ve seen that, you can’t un-see it. In the next part, we’ll walk the full expedition that produced this fix, end to end, so you can see how far “the next file” actually reaches.

The four-gigabyte fix from the last chapter is one beat in a much longer expedition, and the full trace is worth seeing in order — not because the individual tricks are the point, but because the shape is. Nobody planned this route. It was two overnights, driven by a single goal, and every box on the map appeared only when the agent hit the wall that demanded it.

1. 1
   The tomb. Working through the archive for a memorabilia project, the agent hits a Lotus Notes NSF. No Notes client installed anywhere.
2. 2
   Spelunking the backups. It goes digging through old VMDK disk images — mounting them, pulling out the files it wants — and finds a Notes DLL and some Notes ID files buried in a Windows backup.
3. 3
   The passwords are gone. So it drives that DLL under Wine⁸ — no full Notes install, just the runtime component — builds its own recovery harness around it, and, because it isn’t running the whole application, sidesteps Notes’ login timeouts entirely. It generates and downloads word-lists, mangles them with Python, and runs billions of attempts.
4. 4
   Brute force fails — so broaden the goal. One ID won’t crack. I nudge it: try the other Notes IDs (same filename, years apart, likely different passwords), and search the Postgres data we’ve already recovered — unencrypted — for plaintext passwords. It works. It recovers the IDs and passwords across the whole archive.
5. 5
   The C++ driver. With no Python NSF connector in existence, it writes one from close to scratch: iterating struct offsets, discovering a 16-byte offset for the Notes ID, working out the field layout — building it, as I watched, largely out of its own head with a little web reference.³
6. 6
   Replication. It copies NSF into Postgres in under three minutes, preserving the Notes universal ID across replicas so partial, differently-dated copies can be reconciled later.
7. 7
   The wall. It hits the >4 GB NSF, re-engineers its own driver in five or six minutes, and continues — the beat from Chapter 3, in the wild.
8. 8
   Booting the original. I want to log into the real system. The old Intel VMware image won’t run cleanly on my Apple-silicon Mac — so, unprompted, the agent spins the VM up in QEMU on a Linux box instead, translates the old VMware config into QEMU drivers, screenshots the boot sequence to work out how to bypass the “inaccessible boot device” screen, moves the VM onto a scratch SSD for speed, and hands me a VNC command to log in.

The point of the trace

Read that list of steps again and ask: what human being, at the outset, would ever design an “ETL pipeline” whose starting boxes were mount a VMDK, reverse a struct, brute-force an ID, boot a VM in QEMU, screenshot the boot, hand over VNC? Nobody. You couldn’t have specified it, because you didn’t know which walls existed until you hit them.

“It’s engineering the software on the fly as we’re reading the data.”

The boxes emerged because reality fought back and the agent kept forging the next capability required to move forward. That’s the loop from Chapter 3, run across a whole night: the pipeline is the trace left behind by thinking.

There is one thread running under all of this that I’m deliberately not going to pull here — the way the agent has to turn every piece of the world (a database, a disk image, a boot screen) into text it can actually perceive before it can reason about it. I have a word for the instruction that snaps it out of measuring and into looking — I tell it to “eyeball it” — but how an agent sees is its own subject for another day. What matters right now is simpler and stranger: this was a job that ran for hours, and running for hours changed what the agent was.

Here is a fact that most discussions of AI agents skate straight past. The agent you have at the end of a long run is not the agent you had at the start. Not because the model changed — it’s the same model — but because the mission accumulated machinery around it.

The mission accumulates machinery.

A long-running goal agent is building itself a mission-local capability stack. It gets more capable with respect to that goal as it works. It knows the weird offsets. It remembers why id3 was more promising than id7. It has scratch files, scripts, running processes, and an evolving representation of the problem that took hours to form. It has, in a real sense, built itself a burrow and filled it with tools.

Is this just a nice metaphor, or is it measurable?

It’s measurable, and the measurement is why this book exists now rather than three years ago. Anthropic reports its models maintaining focus for more than thirty hours on complex, multi-step tasks.⁹ And the trend is the real headline: the independent evaluation group METR finds that the length of task a frontier agent can complete autonomously has been doubling roughly every seven months, and accelerating since.¹⁰

The architecture that keeps those long runs from falling apart — stateless workers doing the work while a stateful kernel holds the accumulated state and understanding — is a subject in its own right, and I’ve written it up as breaking the one-hour barrier. The relevant point here is that the burrow lives in that kernel, and a six-hour run is compounding, not linear.

So don’t poke the burrow

This has a sharp, practical consequence that I learned the hard way, and it’s the oldest management lesson there is. When you interrupt a long-running agent to bolt on the next task, you are not just distracting it. You may be yanking an intelligence out of a locally accumulated cognitive environment that took six hours to build.

The honest truth is that the interfaces haven’t caught up with this yet. When I have the next day’s task in my head while an agent is still grinding on yesterday’s, my options are genuinely bad: dictate it into a notes app, or type it into the agent window and pointedly not hit enter — the worst queuing system you’ve ever seen. That gap between a human’s next intention and the tooling’s ability to hold it is a real problem, and its own piece of writing. For now, the discipline is simple: one goal per organism, and don’t interrupt the dig.

Which raises the obvious question — if you’re not feeding it steps, what are you giving it? That’s the next chapter.

Go back to the expedition for a second and notice what I didn’t do. I never told the agent to mount the VMDK. I never told it to reverse a struct, or to try Wine, or to boot the VM in QEMU and screenshot the boot screen. I couldn’t have — I didn’t know those steps were needed, and half of them I wouldn’t have thought of. What I gave it was an intent: understand my old Notes data. It self-organised the entire expedition from there.

You give it your intent — not the list of steps, your intent. If it understands the intent, it can go and do the work for you.

This is not a soft point about being nice to your tools. It’s the mechanism that lets capability acquisition become a step at all. If I specify steps, the agent can only assemble a workflow from capabilities I already knew existed — I’ve pre-baked the boundary into my instructions. If I specify the outcome, the agent is free to manufacture whatever capability the outcome turns out to need. Intent-expression is precisely what lets the unit of engineering shrink, because you’re no longer pricing a sequence of steps — you’re pricing a result.

How to actually hand an agent a night

The North-Star discipline is short and it’s learnable. Give it a compact statement of what you’re trying to achieve. Tell it how to check its own doneness and completeness. Add a few quality gates to check along the way. Then say go — and leave it (see the one-task rule from the last chapter).

The uncomfortable, liberating part is that once you delegate an outcome rather than a method, you have to let go of how. Sometimes the agent shortcuts brilliantly — finds a path that would’ve taken me hours and does it in minutes. Sometimes it takes the long way round: on one job it extracted an entire thirteen-gigabyte database into a single intermediate JSONL file before importing it, which is not how I’d have coded it. But it worked, it cleaned up after itself, and the outcome was correct — so who cares? I priced the result, not the method.

What are you actually handing it access to?

Here’s the enabling condition, and it’s more extreme than “a good set of tools.” I give the agent a whole general-purpose machine — passwordless sudo, so it can do whatever it likes — and I lean hard on Git, an offsite Backblaze backup and ZFS snapshots so it’s genuinely difficult for it to break anything for good. The “tool surface” isn’t a curated palette of database tools and VM tools. It’s a computer. And because code is generatable, that computer is a meta-tool: need a capability, write a program, run it, now the capability exists.

Exactly which machine, with what guardrails, and how much rope to give it, is a whole discipline of its own — a subject I’ll take up separately. What matters for the argument here is only this: it’s the combination of a persistent goal, a general-purpose machine, and the freedom to build that turns a model into a self-equipping expedition. As I found watching the Notes job self-organise: the North-Star discipline is what made it so cheap to launch — intent plus a sandbox, no spec, and the machine organised the whole dig itself.

And here is the part that starts to compound. The more time I spend expressing intents, the more intents I find I have. This wiki project began as “index my published writing” and kept growing — index my dev folders, index the conversations that built them, index my mail, index a twenty-year-old mail file I’d done nothing with… there seemed to be no limit to the ideas, or to the agents I could set going on them. That’s not a coincidence. It’s the subject of the next chapter.

Reality doesn’t merely answer the question. It reprices the future.

This is the part that outlasts the anecdote. When the Notes job finished, I didn’t just have recovered records. I had a different sense of what was worth attempting — because a whole category of tasks had quietly moved from one column to another in my head.

My capability frontier moved — so the next day, I generated intents that the day before I would have discarded as unrealistic. And crucially, the discarding used to happen before the idea ever reached a conscious backlog. The old reflex ran silently: idea → “too hard” → gone. Now it runs: idea → “hang on, it recovered Lotus Notes out of VMDKs” → maybe possible → capture.

Why is this a flywheel and not just a one-off surprise?

Because the repricing feeds itself. Each unexpected result expands what you believe is possible, which lets previously-impossible ideas survive your internal filter, which means more intents get dispatched as goals, which produces more unexpected results.

The perturbation isn’t noise in the loop. It’s fuel. Contact with reality brings perturbation — even when I think I know what AI can do, today shatters another barrier, and what was true yesterday isn’t true tomorrow. That’s a strange cognitive environment to live in, and it’s the honest reason my idea rate keeps climbing.

Go twenty years forward and we can get back into our own old locked-up data in a heartbeat. If you put it in a sci-fi film, it wouldn’t be a believable script.

The same repricing, at national scale

This isn’t just a hobbyist’s feeling. The reason legacy is expensive is precisely that reaching it requires scarce, disappearing specialist capability. The US federal government alone spends more than $100 billion a year on IT, and reports spending roughly 80% of that operating and maintaining existing systems — some of it running on COBOL and Assembly, supported by a dwindling pool of people who still know how.¹¹

Legacy maintenance cost compounds while the cost of reaching a dead system just fell off a cliff. That gap is the arbitrage. The broader economics of replacing those systems outright — where the specification becomes the durable asset and the code regenerates — is the argument of AI Legacy Takeover. And what you choose to keep or delete once a dead archive is suddenly reachable is its own decision, which I take up in Keep the Bronze. Here, the point is narrower and sharper: one contact with reality repriced my whole backlog. To prove that’s not a fluke of enthusiasm, I have a controlled experiment — and it runs across twenty-five years of my own working life.

Before the victory lap, the ledger. Because the fastest way to overclaim — and to get rightly dismissed — is to blur what the agent achieved with what IBM achieved. So let me be exact about what my overnight recovery did not do.

Obviously, those are not equivalent engineering burdens.

The agent carried none of that. It read my corpus and got the records into Postgres. That’s the distinction between mission-scoped and product-scoped engineering, and it is a feature of the argument, not a hedge. You didn’t need the product boundary moved. You needed it moved for this mission, right now — and refusing to pretend otherwise is exactly what makes the “unit of engineering has changed” claim survive scrutiny.

The 25-year controlled experiment

Now the proof, and it’s a clean one because the variable that changed is neither the person nor the source technology — it’s only the software economics. And I know it’s clean because both ends of the experiment are me.

In the early 2000s I built a Lotus Notes application for Freemans Australia — insurance loss adjusters, around fifty offices, working out of disaster zones on notebooks with whatever connectivity they could find, replicating back to the office when they got a line. It transformed how fast they could work out reserves. Then their clients, the insurers, wanted visibility into claims. Notes was the wrong thing to hand an insurer, so I invented a signed, claim-scoped URL — a link emailed per claim that opened exactly one claim, read-only, with a bit of signing smarts baked into it. Years before S3 made signed URLs an ordinary thing.

Same bloke, same source technology, nearly the same architectural instinct: get the data out of the awkward operational format and stage it somewhere tractable. What changed is why I moved it. In the 2000s I moved Notes data into DB2 because the serving environment — the web, external users — needed DB2-shaped data. In 2026 I move it into Postgres because the cognitive environment — the AI — thinks far more freely over Postgres and plain text.

The difference is that the second time, the software arrived as a side effect of expressing the intent.

That is “code is not the asset” with a twenty-five-year receipt attached. The first time, the transformation substrate didn’t exist, so I was the substrate — I personally built the multithreaded checkpointing behemoth because nothing else could. The second time, I kept the architectural decision and barely touched the machinery.

One case is a story. Is two a pattern?

Fair challenge — maybe I just got lucky with a corpus that happened to have recoverable clues lying around. But it wasn’t one case. In a separate session, against a different backup set entirely, the agent hit the same wall — no Python NSF connector in existence — and again synthesised its own C++ driver, ran ten parallel threads, and deduplicated across partial, differently-dated replicas by their universal IDs. Two independent instances pointing at the same move is enough to promote it from anecdote to principle.

So re-price it. Find the extinct system, the encrypted archive, the format nobody can open, the twenty-year-old data hoard you kept for no reason and could never justify touching. Give an agent a general-purpose machine, one clear intent, and a night. Then leave it alone and see what it builds itself to get in.