9a9e58c935
Moved from maxwell/blog to standalone repository. - Next.js research journal application - Notes 001-005 with YAML/MD content structure - Claude Code configuration for blog development Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
84 lines
3.4 KiB
Markdown
84 lines
3.4 KiB
Markdown
## The Goal
|
|
|
|
Before writing any code, set up two things:
|
|
|
|
1. **Expert agents** — Who would be best at working on this project?
|
|
2. **Quality hooks** — What checks run before every commit?
|
|
|
|
## Step 1: Pick Expert Agents
|
|
|
|
I asked: What 3 people in the world would be best at working on this project? Pick from a diverse set.
|
|
|
|
Looking at Maxwell's intersection of hypervisors, eBPF, Rust, and thermodynamics-inspired agent control:
|
|
|
|
1. **Bryan Cantrill** — CTO of Oxide Computer, former Sun distinguished engineer. Created DTrace, now deep in Rust systems programming and hypervisor design. He literally thinks about computation as a physical phenomenon. His "software as materials science" philosophy aligns perfectly with the thermodynamic metaphor.
|
|
|
|
2. **Brendan Gregg** — The eBPF authority. Wrote the book on BPF performance tools. If Maxwell uses eBPF to observe and constrain agent processes at the kernel level, nobody understands that observability/control plane better.
|
|
|
|
3. **Joscha Bach** — AI researcher who frames cognition and agency through physics and thermodynamics. He thinks about agents as dissipative structures, intelligence as entropy management, and computation as a physical process. Brings the theoretical grounding for why "thermodynamic hypervisor" isn't just a metaphor.
|
|
|
|
Why this mix works:
|
|
|
|
- **Cantrill**: the Rust hypervisor craft
|
|
- **Gregg**: the eBPF instrumentation layer
|
|
- **Bach**: the agent-as-thermodynamic-system philosophy
|
|
|
|
All three are known for strong, opinionated thinking about their domains — they wouldn't just build it, they'd argue about whether it should be built this way.
|
|
|
|
## Step 2: Create the Agents
|
|
|
|
With the experts identified, I used `/do-parallel` to create all three agents simultaneously:
|
|
|
|
> /do-parallel /create-agent for each
|
|
|
|
Each agent gets their own file in `.claude/agents/` with their expertise, philosophy, and approach encoded.
|
|
|
|
## Step 3: Scaffold the Project
|
|
|
|
> /scaffold
|
|
|
|
This sets up the project skeleton and quality hooks. The skeleton gives you types, traits, and stubs — just enough to compile. But the most important part is the quality hooks.
|
|
|
|
Before writing any code, we need checks that run on every commit:
|
|
|
|
- **Code complexity** — Keep functions simple
|
|
- **File length** — No 2000-line files
|
|
- **Dead code** — Remove unused code
|
|
- **Circular dependencies** — Clean architecture
|
|
- **Similar code** — DRY violations
|
|
- **Linting** — Consistent style
|
|
|
|
`/scaffold` calls `/setup-hooks` internally. Every commit runs through these checks. If they fail, the commit is blocked.
|
|
|
|
## Step 4: Create Docs
|
|
|
|
> Create a basic readme.md and quickstart.md
|
|
|
|
The README explains what the project is. The quickstart explains how to get it running. Both should be minimal — just enough to onboard someone.
|
|
|
|
## Step 5: Verify Setup
|
|
|
|
> Run through the quickstart and pre-commit hooks and make sure everything works properly
|
|
|
|
Follow your own quickstart. Make a trivial change and commit it. If the hooks fail or the quickstart is wrong, fix it now.
|
|
|
|
## Why Quality Hooks First
|
|
|
|
It's tempting to skip this and "add it later." Don't.
|
|
|
|
Quality hooks installed at project start:
|
|
- Catch issues immediately
|
|
- Build good habits from day one
|
|
- Never accumulate debt
|
|
|
|
Quality hooks added later:
|
|
- Hundreds of existing violations
|
|
- Painful cleanup sprint
|
|
- Team resistance
|
|
|
|
The best time to install quality hooks is before the first line of code.
|
|
|
|
## Next Steps
|
|
|
|
Start building.
|