Code: notes from building Taproot I/O
These are working notes from building Taproot I/O. Each post covers one practice we actually use, like protobuf contracts, documentation first, automated guards, a monorepo, and as few dependencies as I can get away with, along with what it cost us and where I'd start. A lot of it is about working with AI coding assistants, because that's how we build software now.
One AGENTS.md for Claude Code, Codex and Copilot: keeping AI instructions in one place
Why I build with two AI models, and how one AGENTS.md keeps Claude Code, Codex and Copilot working from the same rules, plus how we audit it.
Why I avoid third-party packages, and how AI helps
Why I write or vendor small pieces of code instead of adding third-party packages, how AI makes that practical, and when a package is worth it.
Contract-driven development: How we keep Taproot’s frontend and backend in sync
How Taproot uses protobuf contracts, generated clients, and drift checks to keep its frontend and backend in sync while building with AI.
Why documentation-first development helped us build with AI
How documentation-first development helped us build Taproot with AI, using working examples, shared language, and checks that keep docs connected to code.
How we enforce coding standards
How lint rules, architecture tests, and contract checks keep AI-written code consistent with our standards, and which decisions still need a person.
Why moving to a monorepo made AI-assisted development easier
How a monorepo made AI-assisted development easier on Taproot: fewer package releases, coordinated changes, migration costs, and the boundaries we kept.
From Y2K to AI: 26 years of figuring things out
From Y2K fixes and Visual Studio to mapping systems and Taproot: how 26 years of full-stack engineering shapes my approach to building software with AI.
Planning and workflow
1 post
Building Taproot I/O
I started building Taproot I/O because I wanted the coolest web platform on the planet, and WordPress's bloated ecosystem wasn't it.