What I use AI for
I build software, in two settings. At work it is a large content-management product: a big codebase that runs as one Docker stack. Outside work I build my own tools, mainly orchestrator, plus a handful of smaller projects.
Agents write most of the code. I decide what is worth changing, and I own the plan. At work I also do the verifying myself — there is one Docker stack, so running the product is not something three agents can each do. On my own projects I hand that back to the agent.
My setup
- Claude Code on Opus 5: my only coding agent.
- orchestrator (disclaimer: it's my own tool) used at work and at home. A Rust daemon plus a small web app that runs several Claude Code sessions over one repository in one window. A worktree and a terminal per session, the daemon owning every process, and a board showing which sessions are working, which wait on me, and which PRs have review threads unanswered. It also ships some skills that I find useful. At work it is mostly how I manage agents and PRs.
- mise: my default for everything. Toolchain and task runner in every project, including the `claude` binary itself. Its tasks are how I tell an agent what "verified" means.
~/.claude— rules, hooks and skills, tailored per project rather than shared. This is the part I spend real time on.- Happy — Claude Code on my phone, for non-critical work away from the desk.
How I work
A large feature at work. Research, then plan, then implement. adapted from the approach HumanLayer describe. The research phase produces an understanding of the existing code and nothing else; the plan phase turns that into steps I read and correct; only then does an agent write code. Several agents run in parallel in their own worktrees, and I steer them and clear the PRs. I verify the result against the running stack myself.
A change to orchestrator, from the phone. Same agent through Happy, one session, no monitor. Here the agent verifies: it compiles, runs the tests, drives the end-to-end flow and reports what actually happened. Anything I need to see comes back as a published artifact, because a file path on disk is useless from a phone.
Always be thinking how do improve your setup. when a new model arrives or just reflecting on old mistakes / sessions.
Claude writes great code, but you are in charge of the architecture and business logic.
Lessons and limitations
- Plan quality decides everything. A weak plan produces confident, wrong code faster than a human can read it. Almost all of my own effort sits before the first line is written.
- One Docker stack is a hard ceiling. Agents get parallel worktrees; they cannot get parallel running systems. That single fact is why verification stays mine at work and not a matter of taste.
- Parallel agents need a state machine. Three sessions at once are unmanageable if you must open each one to see whether it is waiting on you. That is the core reason orchestrator exists, rather than a nicer terminal layout.
Drafted with AI assistance, from my own configuration and repositories, edited manually a bit.