Use = Build
Core Concept
In a well-designed environment, the act of using the system and the act of building the system are indistinguishable. There is no “use mode” and “build mode.” Every interaction simultaneously produces value AND improves the system’s ability to produce future value.
Named after Smalltalk’s Morphic framework, where you could grab any UI element, inspect it, change its behavior, and it was still running. The same gestures that used the interface could reshape the interface. Clay doesn’t distinguish between sculpting and “configuring the clay.”
The Pattern
Most systems have a clear separation between operating and improving:
| System | Using | Building |
|---|---|---|
| Traditional PM tool | Create and update tickets | Configure workflows, custom fields |
| Knowledge base | Write and read notes | Design templates, organize structure |
| Development environment | Write code | Configure tooling, update CI |
In a use = build system, these collapse:
| Using the OS | What Gets Built |
|---|---|
| Discussing a 1:1 with a colleague | New pattern extracted → pattern note created → person profile updated → pattern index linked |
| Preparing for a meeting | No playbook exists → propose one → refine together → now it’s permanent infrastructure |
| Reviewing a WCP item | Schema gap discovered → new field proposed → schema evolves |
| Making a decision | Decision entity created with stakeholders and rationale → queryable for future reference |
Every session leaves the system better than it found it — not through a separate “maintenance pass” but through the act of thinking itself.
Where I’ve Seen It
- This OS: Claude follows CLAUDE.md’s linking protocol during normal work. Discussing a colleague surfaces patterns; Claude extracts them to standalone notes. Preparing for meetings creates playbooks. Using the system builds the system.
- Show Notes: Operating the company (CEO sessions, board updates, community scanning) simultaneously improves the operating model (refining CEO protocols, capturing decision records, extracting validated patterns). Claude-as-CEO doesn’t have a “meta day” for self-improvement — improvement happens through operations.
- Zettelkasten method: Reading and note-taking ARE the knowledge system. You don’t build the zettelkasten and then use it — the act of engaging with ideas IS the construction. Luhmann’s card system grew through 30 years of thinking, not through deliberate “system maintenance.”
- Smalltalk itself: Programming in Smalltalk WAS extending Smalltalk. When you defined a new class, you were simultaneously using the class browser (a tool) and extending the class library (the system). The tool and the artifact were the same thing.
- Management Philosophy: “Make myself irrelevant” and “develop leaders” are Use = Build applied to people. The act of leading (using the leadership system) simultaneously builds capacity (developing leaders who don’t need you). There’s no separate “leadership development program” — development happens through the work itself.
- Alan Kay’s vision: “The computer is a medium for human thought.” A medium is inherently use = build. You think with it, and by thinking with it, you shape it, and by shaping it, you think better next time.
When It Breaks Down
Use = Build fails when:
- The system is too rigid to absorb improvements. If adding a new entity type requires a schema migration, a code change, and a deployment, the build cost overwhelms the use benefit. (Markdown files avoid this — adding a new type is just creating a file with frontmatter.)
- Improvements aren’t captured. If Claude extracts a pattern during conversation but doesn’t create the note, the insight evaporates. The linking protocol in CLAUDE.md exists precisely to prevent this.
- Maintenance is deferred to “later.” If observations pile up as inline text instead of being extracted to atomic notes, the system accumulates debt. Use = Build requires that improvements happen during use, not after.
The Connection to Augmentation
Use = Build is Augmentation-Over-Automation taken to its logical conclusion. In augmentation, the human provides the 20% that matters (judgment, taste, decisions). In Use = Build, that 20% simultaneously produces the next cycle’s context infrastructure. The human’s judgment isn’t just consumed — it’s captured, linked, and made available for future sessions.
This is why context over parallelism matters: each session’s judgment compounds into the next session’s context. The knowledge graph gets richer, the patterns get more connected, the entity index gets denser. The system improves because you used it, and you use it better because it improved.
Related Patterns
- Augmentation-Over-Automation — Use = Build is augmentation’s purest expression: human judgment simultaneously produces value and improves the system
- Zettelkasten-as-Object-Model — the zettelkasten IS a use = build system; thinking produces objects (notes) that improve future thinking
- Graceful-Self-Extension — the mechanism by which Use = Build happens: the system encounters gaps and proposes filling them
- Integration-vs-Composition — use = build works best with composable systems (creating a markdown file is both using and building; creating a database migration is only building)