My Development Workflow

AI changed the shape of my work, not the responsibility attached to it. I still own the architecture, the trade-offs and whatever ships. What changed is how much of the day goes into typing versus thinking — and the tooling below exists to shift that ratio as far toward thinking as it will go.

Planning comes before prompting

The single biggest determinant of output quality isn't the model. It's how well the problem was specified before the model saw it.

Ahead of any implementation I write the problem statement, the user stories with their acceptance criteria, the UI flow including the empty and error states, and an explicit out-of-scope list. Then the tests, against those acceptance criteria, before the implementation exists.

That last one matters more than it sounds. A failing test is an unambiguous specification — it either passes or it doesn't. Given one, a model writes toward a target rather than toward something that merely looks plausible. Given a vague paragraph instead, it will confidently build the wrong thing and the code will compile perfectly while doing so. Most of what gets called "AI slop" is really a planning failure that arrived at speed.

The tools

• Claude — the primary driver. Planning, implementation, refactors and test suites. It does the typing; the architecture decisions and the review stay with me.
• Cursor — when the work is editor-native — inline edits, tab completion, and quick multi-file changes where staying in the buffer beats describing the change.
• VS Code — my editor when I'm running Claude. Noticeably lighter than Cursor, and if the AI already lives in the terminal there's no reason to pay for a heavier shell around it.
• Herdr — an agent-aware terminal multiplexer. tmux-style persistent panes and sessions, but it also surfaces each agent's state — idle, working, blocked, done — in a sidebar, so I can see which one needs me without cycling through panes.
• FluidVoice — dictation, free and fully on-device. Prompts are prose, and I speak prose faster than I type it. Nothing leaves the machine.
• Tailscale — a private mesh network across my devices. My development machine is reachable from anywhere, so a laptop, a tablet or someone else's desk is just another terminal into the same session.

How a feature actually moves

1. Specify. Problem statement, stories, acceptance criteria, scope boundary.
2. Design the flow. Screens and states, so there's something concrete to build against rather than a description to imagine.
3. Write the tests. Red first, straight from the acceptance criteria.
4. Delegate the implementation. Claude in a Herdr pane, dictated where dictating is faster. Cursor when the change is easier to point at than to describe.
5. Review properly. Every diff read as though a contractor wrote it, because in effect one did. Speed of generation is not a reason to lower the bar for what gets merged.
6. Ship, then watch it. Monitoring and error tracking, because the failure modes that matter only ever surface in production.

What this is actually for

None of this is about writing less code. It's about spending a larger share of the day on the decisions that are genuinely hard — the data model, the boundary between systems, what happens when the third-party API times out — and a smaller share on the mechanical work that surrounds them.

The engineering judgement is still mine. The typing no longer has to be.