Code Is a Commodity. Structured Experience Is Not.

A few days ago I was on a call with one of our partners. We were discussing how to integrate the IOTA Gas Station into their Digital Product Passport project. At the end of the call, they asked me for a quick guide on managing the Gas Station in production.

Simple request. I've done it many times. Two paragraphs on fund management and key management, a few lines on the operational process, hit send. Twenty minutes of work, maybe less.

But I stopped. Could I create something that makes their experience simpler and more effective? Something they can run, break, and learn from?

So instead of writing a guide, I used my knowledge system and Claude Code to build a small repository that contains the guide, the setup scripts, the Docker configuration, and a working example of sponsored transactions. The partner didn't just get instructions. They got a reproducible experience.

Why Documentation Goes Stale

Today, writing repository documentation is trivial. Tools like Claude Code generate it in seconds. Documentation is no longer scarce. What is scarce, especially for niche SDKs, is working code that follows best practices. Code that trains our models to produce better output next time. Code that someone can clone, run, and verify against a real environment.

Most documentation has problems that people rarely talk about:

Problem	What happens in practice
Hard to read	Dense, verbose, often poorly structured. Developers skim it and miss critical details.
Decays fast	Configuration values change, SDKs release new versions. Half-life of about 6 months.
Requires full reconstruction	Reading the guide is only the beginning. The partner still has to rebuild the system from scratch and verify each step.
Not designed for AI agents	AI coding assistants can't learn best practices from prose. They need working code, not paragraphs.
Stale references by default	AI agents trained on outdated docs produce outdated code. The developer spends time debugging what the AI got wrong.

What I built in a few hours thanks to my knowledge system can be verified in minutes. Clone, run, see it work. That repository becomes an asset for the partner and for me. The partner saves days of reconstruction. I get a tested, reusable reference that feeds the next project.

What a Knowledge System Does Differently

A knowledge system treats every deliverable as training data for the next one.

When I built that Gas Station repository, it wasn't only about the partner's immediate need. The repo includes setup scripts for the Gas Station with a local KMS sidecar, a Docker Compose configuration for the full stack, a Move contract deployment, and a working sponsored transaction example. Everything needed to go from zero to a running system.

But the real value happened underneath. My knowledge system (I've written about how I built it separately) ingested the new content. It now understands Gas Station production patterns at a level it didn't before. The next time I scope a DPP project that needs sponsored transactions, the system retrieves these patterns automatically.

I also built automated pipelines that sync the knowledge system directly with source code repositories. When a repo changes, the knowledge updates. No manual re-indexing, no stale references. The system stays aligned with the code it describes.

This is the difference between writing a document and building architecture knowledge. A document sits in a folder. Structured experience feeds a system that gets smarter with each project.

How a Knowledge Flywheel Compounds Over Time

A knowledge flywheel is what happens when each delivery simultaneously improves the next one. In this case, three things happened from a single partner request.

#	What happened	Why it matters
1	The partner got a working environment to experiment with, not a PDF to skim	Better deliverable than what was asked for
2	My knowledge system ingested the new content	It can now answer Gas Station production questions with real configuration examples
3	A reusable template was created	The next partner who needs Gas Station integration gets a head start measured in days, not hours

Each cycle makes the system more valuable. After 500+ indexed files, 3,000+ knowledge chunks, 13 synced repositories, and 18 regulation summaries, the compounding is noticeable. On a niche SDK like IOTA Trust Framework, building a demo used to take days. After the first iteration of the knowledge system, about 6 hours. Now I can create basic integrations in under two hours. And this capacity improves with every iteration.

This pattern works for any knowledge-intensive profession. Lawyers who structure their case research. Architects who catalog their design decisions. Consultants who index their engagement learnings. The tool doesn't matter. The discipline of turning one-off work into reusable, searchable knowledge does.

What Remains When Code Gets Cheap

AI can generate setup scripts. It can write documentation. It can scaffold a Docker Compose file in seconds. Six months from now, it will do all of this even better.

Code is increasingly cheap. Good documentation is cheap too. What compounds is the decision to turn a one-off task into a system. To treat every deliverable as an input for the next one. To build knowledge that accumulates rather than documentation that decays.

Jeff Bezos once said: in a world that changes fast, focus on the invariants. The things that will still matter in ten years.

One of those invariants is lowering the barrier to entry for a technology. Making integration faster, simpler, more reliable. That will always matter, regardless of which SDK, framework, or protocol is trending.

Even this article is another turn of the same flywheel. The partner's request became a repo, the repo became knowledge, the knowledge became this post. And now this post will feed the system too.

So here's what I keep coming back to: in a world where anyone can generate code and write docs, what are you building that gets better with every project you deliver?