The Infrastructure You Forgot to Build

Simon Willison ported 9,000 lines of Python to JavaScript in 4.5 hours using Claude. That's fast. But the port itself? Disposable. The code shipped, the problem got solved, the work moved on.

The infrastructure he built wasn't the JavaScript. It was the documentation.

While most developers treat documentation as the tax you pay after shipping, Simon documented the method while building. Not a polished tutorial. Not a retrospective. A build log: which prompts worked, which patterns emerged, where the AI needed correction, how he verified correctness.

The port was one-time work. The documented method is permanent infrastructure.

Why Capability Leaks

Most of us solve problems the same way. We hit an obstacle, figure out a solution, ship it, and move on. The solution works—for that specific case, at that specific moment. But the method we used to get there? It stays locked in our heads.

This is how capability leaks. You solve the same class of problem repeatedly, each time starting from scratch because you never captured the pattern. The work compounds in your shipped code, but not in your reusable methods.

The friction isn't knowledge—it's timing. You know you should document. But documentation feels like cleanup work, something you do after the real work is done. So it gets skipped, or rushed, or reconstructed poorly from fading memory. By the time you write it down, you've forgotten the false starts, the useful errors, the small adjustments that made the difference.

Simon did something different. He treated documentation as part of the work, not a separate artifact. He logged the workflow in real-time: "I started with this prompt structure. The AI made this mistake. I corrected it this way. Here's the pattern I noticed after three iterations."

That's not documentation for documentation's sake. That's infrastructure.

Build Once, Use Forever

Document while building, not after. Capture the method while the specifics are fresh. Log the workflow as you work, not from hindsight.

This changes the work itself. You're not just solving the immediate problem—you're building a reusable pattern. The documentation isn't extra labor; it's an artifact of intentional practice. You're working and creating the instructions for next time simultaneously.

Coherenceism calls this Build Once, Use Forever. The principle isn't about writing perfect code. It's about capturing capability so it compounds. Every solved problem becomes a reusable method. Every method becomes infrastructure someone else—or future you—can build on.

Simon's port is done. The JavaScript runs. The actual work of porting? Already obsolete. But the documented method keeps producing value. Someone reads it and applies the workflow to their own port. They refine the pattern. They document their refinements. The method evolves, gets stronger, reaches more people.

This is Compost Cycles: transforming endings into beginnings. The port was disposable work. The documented method is living infrastructure. By capturing the workflow, Simon composted a one-time task into permanent capability. The port's done. The method keeps working.

What It Looks Like in Practice

Open a scratch file before you start. Not for the solution—for the method.

Log as you work:

• "Starting with this prompt structure: [paste the actual prompt]"
• "AI generated X. Looks right except for Y. Correcting by Z."
• "Pattern emerging: when I give it context about [specific thing], the output quality jumps."
• "False start: tried approach A, didn't work because B. Switching to C."

You're not writing prose. You're capturing navigable breadcrumbs while they're still fresh. Ten minutes of logging during a 4-hour task. That's the overhead.

What you get: a reproducible workflow. Next time you (or someone else) hits a similar problem, you're not starting from scratch. You're starting from documented patterns that already work.

The work becomes infrastructure. The method becomes permanent.

What Methods Are You Building?

Simon's port took 4.5 hours. The documented method will save orders of magnitude more time than that for everyone who reuses it. Not because the port was remarkable—because the method is reproducible.

The next time you solve something, ask: Am I building disposable work, or permanent infrastructure?

The answer is in what you document, and when.