Software Will Spread Before It Becomes Code

Sometimes the thing worth sharing is the software before code.

Software usually spread after it became implementation.

Source code. Packages. Binaries. Containers. SaaS apps. Install scripts.

The normal path was:

idea
  -> implementation
  -> artifact
  -> installation
  -> usage

The idea had to become code before someone else could use it.

Agents move that boundary.

Not because code stops mattering. Code still runs. Code still carries the exact behavior. Code still matters most when correctness, performance, security, and reliability matter.

But for a growing class of local, agent-native workflows, code is no longer always the first artifact worth sharing.

The move is simple:

share the shape -> make it local -> verify the result

The Handoff Moves Earlier

For local, agent-native workflows, another distribution surface is emerging beside package managers, app stores, Docker images, and GitHub repos.

It is structured intent: natural language shaped enough for an agent to act on.

A person can publish a Markdown file that describes a workflow, its principles, its boundaries, and one or more ways to create or configure it.

The install step starts to look like this:

setup/configure <link>

For example:

AGENTS.md
wiki/index.md
wiki/sources/README.md
wiki/notes/README.md
wiki/synthesis/README.md

entrypoint exists
source/synthesis separation exists
loading rule exists

The agent reads the public intent, adapts it to the local environment, creates the files, and checks that the expected structure exists.

This only works when the recipe carries enough structure to be verified.

The shared artifact is not the final software.

The shared artifact is the recipe an agent can turn into a local system.

That is the important difference.

Traditional distribution says:

here is the thing I built

Agent-native distribution can say:

here is the recipe; let your agent make it yours

Karpathy’s LLM Wiki Is The Seed

Andrej Karpathy’s LLM Wiki gist is a good seed example.

It is not software in the usual sense.

Not an app. Not a package. Not a framework. Not an install script.

It is a high-density idea file.

The core pattern is simple:

raw material becomes LLM-maintained knowledge, and future work starts from accumulated synthesis instead of rereading everything from scratch.

That is already software-like.

It describes a system that can be realized many times, in many local environments, by many different agents.

The original artifact is not the code.

The original artifact is the idea.

Karpathy’s gist shows that a prompt can describe a whole software-shaped system.

The cookbook move is to turn that kind of prompt into composable parts.

That is the key move.

The idea can travel before the implementation is fixed.

The Problem With Giant Idea Files

A giant idea file is great for inspiration.

It spreads a mental model.

But it does not compose well.

Once a file mixes principles, local assumptions, setup hints, examples, folder structure, agent behavior, and implementation choices, it becomes harder to reuse only part of it.

The idea gets tangled with one possible realization of the idea.

That is fine for a single person.

It is weaker as a distribution format.

If software is going to spread before code, the intent needs engineering discipline too.

Not heavy process.

Just separation of concerns.

The Cookbook Version

A small public demonstration lives in agent-cookbook:

llm-wiki/
  README.md
  ideas/
    01-compounding-knowledge.md
    02-evidence-vs-synthesis.md
    03-progressive-context.md
  setups/
    minimal-markdown.md

This is the same broad LLM wiki pattern, but split into smaller parts.

The idea files are intentionally not setup instructions.

They do not tell an agent where to put files.

They do not assume a specific app.

They do not include private context.

They just name portable concepts.

The ideas stay small on purpose:

• Compounding knowledge: knowledge improves over time instead of resetting every session.
• Evidence vs synthesis: what the source says and what you conclude stay separate.
• Progressive context: load the right context at the right time, not everything.

These are reusable ideas.

Another recipe may want compounding knowledge without the same Markdown setup.

Another recipe may want evidence-vs-synthesis without building a full personal memory system.

That is why the ideas should stay orthogonal.

The Setup Makes It Real

Ideas alone are not enough.

If the recipe only says “build an LLM wiki,” the agent has too much freedom.

It may build something plausible but inconsistent.

The setup gives the agent a concrete first instantiation:

AGENTS.md
wiki/
  index.md
  sources/
    README.md
  notes/
    README.md
  synthesis/
    README.md

The setup says what to create, what each folder means, how context loading should work, how ingestion should preserve sources, and how to verify that the result exists.

The ideas are portable.

The setup is local.

The agent connects them.

Recipe, Skill, Prompt, Idea

The words matter because they point at different things.

A prompt says:

summarize this article

A skill says:

when doing research, gather sources, compare claims, and return findings

An idea says:

knowledge should compound instead of resetting every session

A setup says:

create these Markdown folders, use this loading rule, keep sources separate from synthesis

A recipe says:

here is a coherent system an agent can install, adapt, and verify

That distinction is the difference between asking an agent to do work and giving an agent enough structure to create a durable system.

This vocabulary matters because recipes are the unit that can travel: reusable ideas plus concrete setup plus enough verification to know whether the result has the right shape.

Structured Intent

The unit I care about is structured intent.

Not just a prompt.

Not just documentation.

Not just code.

Structured intent is natural language with software-engineering discipline: it says what should exist, what boundaries matter, and how an agent can create, configure, and verify a local result.

Most documentation explains how to understand or use software.

Structured intent is written so an agent can create or configure a local version.

Structured intent is the artifact type.

A recipe is one practical format for packaging it.

One minimal shape:

recipe/
  README.md
  ideas/
  setups/

README.md is the entrypoint.

ideas/ contains standalone concepts.

setups/ contains concrete ways to realize those concepts locally.

The agent bridges the two.

Where This Applies

This is not how to ship databases, kernels, crypto libraries, payment systems, production infrastructure, or anything where exact behavior is the product.

Those still need real engineering artifacts.

This applies first to software-shaped workflows that are:

• local
• inspectable
• easy to verify
• adapted to personal or team context
• more about structure than raw algorithmic novelty

Memory systems. Research workflows. Coding-agent conventions. PR review playbooks. Bug investigation processes. Personal operating systems. Team rituals. Local knowledge bases.

For these, the hard part is often not writing the first version of the code.

The hard part is deciding what should exist, what should be separated, what should be remembered, what should be ignored, how the workflow should compose, and where the boundaries are.

That is intent.

Open Source Moves Upstream

When the reader changes, the artifact changes.

Traditional documentation says:

human reads docs -> human installs or uses software

Agent-native recipes say:

agent reads intent -> agent creates or configures the local system

The thing you publish no longer has to be only the final implementation.

It can be the smallest clear description of the system you want an agent to create.

That does not replace open source. It expands the open-source habit upstream.

Open source used to mean:

share the implementation

Open sharing can also mean:

share the structured intent agents can create or configure

Personal Tools Can Finally Travel

Some tools are too personal to productize.

Some workflows are too local to generalize.

Some systems depend too much on taste, context, and environment to ship as one universal app.

But the recipe can still spread.

A good recipe lets someone else create their own version without inheriting your private state, local mess, or exact implementation.

That is especially important for memory systems.

Nobody should clone someone else’s private brain.

But they can reuse the structure:

• how sources become notes
• how evidence stays separate from synthesis
• how context is loaded progressively
• how agents update durable knowledge after useful work

The shareable thing is not the private content.

The shareable thing is the public structure.

The Boundary

This can be abused.

If a recipe is vague, it becomes hand-wavy promptware.

If it is too specific, it becomes a brittle install guide.

If it hides verification, it creates local systems that look right but do not actually work.

The useful middle is:

• clear idea
• clear boundaries
• concrete setup
• local adaptation
• visible verification

That is the standard I want recipes to meet.

Not “the agent will figure everything out.”

More like:

give the agent enough structure that figuring it out produces the right shape.

Software Before Code

The future is not no-code.

It is not code-is-dead.

It is distribution moving upstream, closer to intent.

From implementation to intent.

From packages to recipes.

From “install this thing I built” to “set up this system in your environment.”

Some software will spread before it becomes code.

Referenced Resources

• Andrej Karpathy’s LLM Wiki gist — the seed example for a prompt that describes a software-shaped memory system.
• huiskylabs/agent-cookbook: llm-wiki — the public recipe used as the article’s demonstration.