Tools

Choosing tools

How I pick between what I have, and the integrations that did not survive a real task.

What I use

Claude Code and Codex, side by side, and I move between them quite freely. Usually it is because I have run out of usage allowance in one of them. Sometimes it is because I want a second reading of the same problem, or because the first approach has stalled and a fresh start is cheaper than another round of nudging.

These products change often enough that a ranking would be out of date by the time you read this.

Claude and ChatGPT are primarily places to have a conversation. Most of the context comes from what you put into the chat. Claude Code and Codex put models from the same families inside tools that can inspect a repository, run commands and change files. That access makes them different tools, even when the model underneath is the same.

Judge the whole loop

A fast answer can still produce slow work.

What counts is setup, running it, checking the result, correcting it and keeping it working. I have used tools that won the middle step and lost the other four. Before standardising on anything I try it on one small real task rather than a demo, because a successful connection test says nothing about whether the daily work gets better.

Some integrations don't work out

I have tried connecting to external services through MCP with mixed results. I asked Sketch for a blank macOS window. That took two and a half minutes. Then a title bar with the three window buttons: another two and a half minutes, and it put the title string on top of the buttons.

I went looking for other people doing this properly and found setup instructions, and even conference talks explaining the concept, but practically nobody demonstrating it on real work.

I asked Sketch about it publicly, and they replied to say it is not meant to behave like that. That was decent of them. Until then, the hype had me convinced I was "holding it wrong".

Keep the workspace boring

One folder, one instructions file, one place for product notes. Split it when different parts have different owners or release cycles. A line on an architecture diagram is a weaker reason than it looks.

A fresh copy should be usable by somebody else. No links to files that only exist on my machine.

Keep a way back

Decisions and instructions live in plain files that any tool or person can read. Services get shut down and tools get abandoned. The setup should never be the thing holding the project's memory.

Further reading