Sorry, your browser does not support inline SVG.

Documentation

Code Reuse

Reference proven code instead of regenerating it

This is the middle of the Stellify development loop — the part between connecting your editor and syncing back. Most application code has been written before, so when your agent gets a feature request, its first move is to find that code, not generate it: Stellify's reuse system lets your project reference proven, curated units — whole files or individual methods — and wires them in. Referencing an existing unit costs a fraction of the tokens of regenerating it, and you get code that has already been reviewed and used in real projects. We've published the numbers in The Economics of Code Reuse.

References, Not Copies

When you (or an agent) reuse a unit, Stellify doesn't paste a copy into your project. It creates a reference to the canonical unit in the shared library, pinned to a specific version. The canonical code is immutable — it can't change underneath you.

Your project treats a referenced unit like any other file or method: it assembles into your exports, runs in your environment, and appears in your file tree.

Finding Reusable Code

Agents connected via the MCP server do this automatically — search_code is the mandatory first step before creating anything new. It searches the shared library at method-level granularity, so an agent can pull in a single proven method rather than a whole file.

In the editor, units with curated alternatives show a variant badge, and public projects in Constellation show how many other projects reference them.

Editing Referenced Code: Copy-on-Write

Referenced code stays live until the moment you change it. When you edit a referenced unit, Stellify automatically forks it:

  • Your project gets its own private copy with your edit applied
  • The canonical unit and every other project referencing it are untouched
  • The fork records its ancestry (forked_from), so lineage is preserved

You never need to think about this — edit as normal, and the fork happens transparently.

Variants

Popular units accumulate curated forks — variants that solve the same problem differently. In the editor you can browse a unit's variants, see how many projects have adopted each, and swap your reference to the variant that fits better.

Submitting Your Own Code

You can offer your own files and methods into the shared library:

  1. Select the unit in the editor and choose Submit for reuse (or have your agent call submit_code)
  2. Add a short note explaining what it does and why it's worth sharing
  3. The Stellify team reviews submissions — approved units are locked into the library and become referenceable by other projects

You keep ownership of submitted code, attribution is preserved through fork lineage, and adoption of your units is tracked — you can see how many projects reference your code from Constellation.

Submission requires a subscription. Duplicate submissions (byte-identical to something already in the library) are rejected automatically.

Why This Matters

Every unit that enters the library makes the next project cheaper to build. Instead of every team paying an AI to regenerate the same registration flow, the flow is written once, reviewed once, and referenced everywhere — with copy-on-write protecting anyone who needs to diverge.

Next Steps

Next
Importing with MCP