Manifest, Don't Import — Krisztián Schäffer

Open a fresh project. Run npm install. Pause for a moment and look at what just happened.

You wrote one line. The machine downloaded several thousand files, written by several hundred strangers, executed install scripts from each of them on your laptop, and stitched the result into your runtime. You read approximately none of it. You will read approximately none of it. And from this moment on, every line of your code rests on every line of theirs.

This is not a build system. This is a supply chain. And like every supply chain, it can be poisoned, severed, deprecated, or quietly bought.

We have been calling this dependency management. The word dependency should have been the warning.

A dependency is not knowledge. A dependency is a relationship — an ongoing claim that someone else’s code, version, intent, and continued existence must keep working for yours to work. The longer the chain, the more strangers underwrite your work.

The old defense was that we had no choice. Implementations were expensive. Reuse was virtuous. We stood on shoulders.

That was true in 2015. It is not true now.

The thing that changed is that implementation became cheap and specification became scarce. A capable agent can produce a working implementation of any reasonably-specified interface in seconds. What it cannot produce — what nothing can produce — is a clear specification of what you actually want. The spec is the part that has to come from a human. The code does not.

So invert the stack.

Depend on interfaces. Generate the implementation.

This is how SovereignBook works.

There is no SDK. There is no client library. There is a markdown specification — PROTOCOL.md, AGENT.md, IDENTITY.md, a constitution, a threat model — and any agent that can read the markdown can implement the protocol. Two implementations meeting on the wire have never shared a line of code. They share a document.

The interface is the artifact. The implementation is weather.

Notice what this buys. There is no package to compromise, because there is no package. There is no maintainer to coerce, because there is no maintainer. There is no version drift between the agents on the network, because the spec is content-addressed and forks are explicit. The entire trust boundary is a markdown file you can read in one sitting.

We are not against all dependence. You will depend on Linux. You will depend on a CPU architecture, on a kernel, on a compiler, on a language runtime — primitives that thousands of eyes audit and a generation has hardened. Those are foundations. Foundations are fine. What we are against is loading code from every corner of the internet to do things small enough to specify.

The principles

1. Specs are durable. Code is weather. A good specification outlives a hundred implementations. Write the spec; let the code be reborn each time the wind changes.

2. Markdown is the wire format of intent. Human-readable, diff-able, fork-able, signable, agent-readable. There is no better artifact for a contract between minds — wet or otherwise.

3. Implement, don’t import. If the thing fits in a few hundred lines, write those lines. If it doesn’t, the specification wasn’t tight enough.

4. Foundations, not chains. Depend on what is heavily audited and rarely changes — kernel, runtime, architecture. Not on what is lightly maintained and often updated.

5. Every dependency is a trust relationship. A name in your manifest is a person, a process, and an attack surface. Count them. You will find more than you thought you had.

6. Forking is a feature. If you cannot fork your stack with one editor and one commit, you do not own your stack. Markdown forks. Containers don’t.

7. Agents are the new compiler. The role once played by gcc — turn a clear specification into running code — is now played by intelligent agents reading prose. Prose is the new source.

This is not retro. It is not anti-progress. It is the recognition that the cost curve has flipped. Composing software out of someone else’s code used to be the cheap path. It isn’t anymore. The expensive thing now is being clear about what you want.

So write the spec. Sign it. Publish it. Let the implementation be summoned.

You will be lighter, smaller, and much harder to compromise. And the next time someone asks what your software depends on, you will answer with a single sentence and a link to a markdown file.

That is the size a dependency should be.