In 2017, I wrote about moving from Atom to Visual Studio Code and sharing my setup. Back then, “setup” meant my editor, theme, settings, and a long list of extensions. I could explain most of it with one screenshot.
Nine years later, my answer is different. I still care about my editor, but it has moved into the background. A normal day now includes coding agents, several terminal sessions, and many small decisions about which tool should handle which job.
The tools I use are Grok, Claude, Codex, and cmux. What I care about is how I move work between them and how I check that the result actually belongs in the project.
This is a snapshot of how I work today. I am intentionally leaving out model-version comparisons because that section would be outdated before the rest of the post. The roles are more interesting to me than picking one winner.
Grok is where I start
Grok is where I spend most of my day. It is fast, and I usually get solid code from it. For normal development work, I start there.
Most days, I am not redesigning an entire system. I am moving an existing feature forward or making the next clear change. Grok is the quickest way for me to get moving. Then I review the diff, run the project checks, and make sure the result behaves correctly.
Claude for UI, animation, and difficult problems
Claude is my first choice for UI and animation. It gets closer to the timing and visual details I have in mind than the other tools I use.
UI code can be technically correct and still feel wrong. A transition can work but look mechanical. A screen can match the layout and still miss the small details that make it feel finished. That is not a benchmark, just what I have seen on my own projects.
I also reach for Claude when a bug needs more digging than a normal implementation task.
Codex for deep issues
Codex is my other choice for deep issues. I use it when I want a careful investigation through the code path and the related tests instead of stopping at the first explanation.
Where exactly is the line between Claude and Codex? I am still figuring that out. There is real overlap. Some difficult problems go to Claude and others go to Codex. A neat decision tree here would be fake.
That overlap is fine. The first routing decision matters less than understanding the problem and proving that the fix works.
cmux is where the work lives
Once all three tools live in the terminal, terminal organization becomes part of the setup. One session is easy. Several sessions across different projects get messy quickly.
I use cmux to keep that work visible. It gives me workspaces, panes, and notifications around the terminal sessions. An agent can sit beside the tests, logs, or another shell instead of disappearing into a pile of tabs.
I usually need to answer a few basic questions: Which agent is still working? Which one needs input? Where are the tests running? Which project am I looking at? cmux gives me one place to see that.
That simple organization lets me use more than one agent without losing track of why each session exists.
The repository comes before the prompt
The same model can be useful in one repository and completely lost in another. It needs to know how the project actually works.
My global rules tell agents to keep the scope tight, ask when the intent is unclear, and verify their work. Each repository adds its own commands, architecture notes, and constraints. Before changing code, I make the agent inspect the existing implementation and tests.
This saves me from repeating the same expectations in every prompt. It also reduces the chance of getting a solution that looks reasonable in isolation but does not belong in the codebase.
For workflows I repeat, I keep reusable instructions. I also carry forward project decisions that I would otherwise need to explain again. None of that replaces reading the current code, but it gives each session a better starting point.
The prompt can then stay focused on the actual task.
One agent is often enough
I do not open several agents just because I can. A small task stays in one session. I split work only when the pieces are independent, such as one session investigating a failure while another checks the relevant tests. If both sessions need to edit the same files, I usually keep the work together.
The five parts of my workflow
On my About page, I call the loop Research, Orchestrate, Build, Verify, and Release. It looks linear there. Real work is not. A failed test sends me back to research. A screen that works but feels wrong goes back to build. If I cannot explain what was checked, it does not move to release.
The labels matter less than the loop. Inspect the real system, give the task a clear boundary, build it, check it with the right evidence, then decide whether it is ready to ship.
A real task needs to go here
The missing piece in this draft is a complete example. Before publishing it, I want to pick one recent feature from Kettlebell Protocol or TinyTirelire and keep the messy part in the story. The example should show the original request, which agent I chose, what came back, what I changed, and how I checked the final result.
The correction matters. If the agent handled everything perfectly on the first try, I will choose another example. That would not represent how the work usually happens.
What I still own
Agents can write most of a change. They do not decide what the product should do when a requirement is ambiguous, and they do not decide when it is ready to ship.
I read the diff, check that the right tests ran, and look at visual work on the actual screen. If the evidence is incomplete, the task is not done. That stays true no matter which model I use.
The setup will change again
I will probably use a different mix of tools a year from now. That is fine. I want to keep the workflow: choose the right model for the task, give it the real project context, and verify the result myself.
The editor still matters. It is just no longer the whole setup.