Blueprints: open-sourcing the architecture, not the code

When I find an interesting open-source project now, I almost never fork it. I point Claude at the repo and say “look at this for inspiration, then build me something like it.” The AI reads the architecture, understands the decisions, and builds something that fits my stack and my opinions. The source code is a reference, not a starting point.

I think most developers are doing some version of this, and it changes what’s worth sharing.

I’ve built a handful of tools over the past year that I want to share. A session management CLI. A memory system that gives AI agents persistent context across sessions. A markdown-based planning system. Claude Code plugins and skills. The obvious move is to open-source them. But if the code is just something an AI scans for patterns before rebuilding from scratch, then maybe the most useful thing I can share isn’t the code at all.

The repo nobody reads

Most open-source projects under a few hundred stars follow the same pattern. Someone finds it, reads the README, maybe skims the directory structure, and stars it. They don’t fork it. They don’t read the code. They definitely don’t contribute. The ones who do dig in are usually trying to understand the decisions. Why is the config YAML instead of JSON? Why is there no database migration runner? Why does the pipeline score everything instead of filtering by keyword first? The architecture is what they actually want, and the code is just one possible expression of it.

In 2026, it’s not even the most useful expression. If you understand the architecture, the constraints, and the key design decisions, you can hand that to an AI agent and have working software in an afternoon. Software that fits your stack, your conventions, your opinions about file structure and error handling. And if I did publish the repo, most people would just point Claude at it, have it extract the architecture, and rebuild it in their own stack anyway. The source code is an extra step that the AI has to reverse-engineer before it can do anything useful.

What I’m actually sharing

So instead of publishing repos, I’m writing about the architecture. A series of posts, each covering one of the tools I’ve built, going deeper than the typical “how I built X.”

Each post covers the problem the tool solves, the architecture and key design decisions, the domain docs that make an AI agent build the right thing instead of a generic approximation, and starter prompts you can paste directly into Claude Code or Codex to get a working version. The domain docs are honestly the most valuable part, and also the part nobody shares.

The difference between this and traditional open source is that you’re not inheriting my codebase. You’re getting the reasoning behind it, and then building your own. You can disagree with half my decisions and still get value from the other half, because the decisions are explained, not just embedded in code.

What’s coming

I’m starting with sesh, my session management tool. It’s the simplest architecture of the bunch, but it has some design decisions I think are interesting, especially around file-based state and why I avoided a database for something that could obviously use one. After that, a markdown-based planning system that runs my week, and whatever else feels worth sharing.