On choosing tools

Every few months, a new tool arrives that promises to change everything. A faster way to design. A smarter way to write. A more efficient way to think. The interface is always clean. The demo is always convincing. The promise is always the same: more output, less effort, less time.

Students notice immediately. So do teams. The question follows quickly.

Should I learn this?

What they are really asking is something else. Will this make me better? The answer is rarely found in the tool. Because tools do not remove the need for judgment. They amplify it, and make it more visible. When something is produced faster, the gap between what is generated and what is actually good becomes easier to see. Speed does not improve taste. It exposes it.

I have watched students produce ten variations in the time it once took to produce one. The work is more polished, more complete, more presentable. But the underlying question remains unchanged: is this the right thing to make?

The tool cannot answer that. There is a moment before every action where a decision is made. What direction to take? What to prioritise. What to leave out. That moment has not been automated. And it will not be.

The students who develop fastest are not the ones who chase every new release. They are the ones who build a way of thinking that travels across tools, who understand structure, intention, and consequence well enough to move from one interface to another without losing their bearings. The tool changes. The thinking stays. That is the only stable advantage I have seen.