Full transparency: this site — and the projects it will showcase — is built by me working with AI coding agents. Not “AI-assisted” in the autocomplete sense; the agents draft specifications, adversarially review each other’s work, implement, and keep the decision records. My job is direction, taste, and the merge button. This post is the architecture, written down partly so I can always catch back up to it.
The shape
One platform repo per site; one repo per project; a contract between them.
- The platform repo owns this website, its deployment pipeline, and the governance specs. It never contains project code.
- Each project (like the AI improv partner) lives in its own repo with its own lifecycle, and publishes a showcase bundle — a manifest, a cover image, posts, media — that gets vendored into the platform by pull request. The site build never depends on a project repo being reachable, or on my desktop being on.
The promotion pipeline
Everything flows one way:
branch → PR (preview build) → merge to main → sandbox.packetsandpianos.com
→ tagged release → packetsandpianos.comContent carries a status field (draft | sandbox | published), and the
build tier filters it: the sandbox site is the workshop — half-built things
visible on purpose (you might be reading this there) — while production
only ever ships what’s deliberately promoted. Merging to main is the
publishing act, so a human (me) approves every merge; a git tag, cut by
hand, is the whole production ceremony. No hand-edits to servers, ever.
Agents with job titles
The workflow that built all of this assigns roles: a spec author writes the plan; an adversarial reviewer — always a fresh agent with no attachment to the draft — attacks it; an implementer builds; a chronicler writes the decision records and catch-up notes. The review step is not ceremony: on this site’s specs it produced ~40 findings, including several genuine design errors (a field-name collision that would have auto-published unfinished work, a preview-URL scheme that didn’t exist on the hosting platform). On the music project’s specs it reshaped the entire teaching design. Every accepted finding lands in a decision record; the specs say what wins when documents disagree.
Why bother, for a hobby site?
Because my previous projects died of structurelessness, not lack of interest. Speed was never the problem — AI made the build process fast. The problem was that fast building outruns understanding, and six months later the project is a stranger. Specs, decision records, and honest status files are how a one-person-plus-agents team stays comprehensible to the person.
The structure of this site is reusable — the specs mark which parts are framework and which are this site’s own personality. That’s the plan for future sites too: stamp the pattern, swap the skin.
My goal is still to learn and to share. Putting care and attention into the structure of this site drives this goal in three distinct ways:
- I’m learning how to properly build and structure assets to share them effectively and securely.
- The structure gives my ideas and the corresponding creations a solid basis. It allows me to grow the idea, the skill, and the knowledge.
- The governance I’ve agreed to enforce with my agent lends a level of discipline that helps keep me from moving faster than what I can absorb. It forces me to think a moment about what I’m doing and how I’m doing it, and that has already paid huge dividends.
If you’re building something similar around your own hobby, the ideas here are free to take — I hope you can put them to good use!