~non-deterministic/engineering
2026-07-24

Master the coding agents

#tooling#workflow

Agent buttons are popping up everywhere. In your email app, your note-taking app, your document-sharing app, your chat app, and soon probably your fridge. Everyone is pushing their own agent tool, beautifully integrated into their legacy application from the pre-AI age. The issue? None of them are any good. They are half-baked, half-integrated, half-working solutions, and most likely, nobody actually uses them.

They will probably improve. Large enterprises will learn, slowly, to build useful agentic applications, and with the advantage of first-party integration, they should eventually be able to provide something that is not totally useless.

On the other end of the spectrum, you have the generic coding agents. The Claude Code, Codex, OpenCode, and pi of the world. They are very simple CLI-based tools. They fundamentally only know how to speak bash, and they somehow massively outperform any integrated agent. Connecting Claude to Notion through its MCP server or a CLI, and using it from your computer with your other relevant context, completely dwarfs anything that the Notion built-in agent can do.

How come? Part of the reason is that coding agents are one of the oldest forms of agentic tools, and they have received a very large amount of engineering effort to make them good and learn what works and what doesn’t. We learnt over 2025 that bash is all you need, and that as long as you give a computer and bash to a coding agent, it can do wonders. As they have been optimized around these primitives, we have figured out how to expose external connections through CLIs (and sometimes MCPs), and once we steer them with the right set of skills, they become incredibly powerful tools.

As coding agents are so flexible and so powerful, people have naturally started to use them as generic agent frameworks and explore what can be built on top of these foundations. OpenClaw was an early example of how far such coding agents can be pushed for non-coding tasks. And today, with harnesses like pi, we have something that is very close to a generic agent framework that can be used to build very custom agentic experiences that don’t necessarily relate to coding anymore. At the same time, they are designed for highly interactive experiences in the terminal with their users.

That combination actually makes terminal coding agents incredibly powerful tools to master. You get a highly effective agent harness with high flexibility and tons of extension points. You can quickly connect any data source that you need, both fully local and in the cloud. You can vibe code your own custom tools for weird, ad hoc requirements that only you have, with your unique set of data. Once you master a generic coding agent tool, and once you know how to customize it, you can apply it to your entire life and work.

My argument is that you must master the coding agent. You should not wait for your apps to eventually catch up and bring a useful agent embedded into their UI and nicely connected to everything that matters for your use case. Instead, you should learn one powerful generic harness, and you should connect it to what you care about, through MCPs or CLIs.

I think it will take a very long time for established products to bring an agent that is on par with the state of the art in coding agents. And even when they manage to, it is very likely that the state of the art will have moved far ahead again. You should be at the frontier, not 12 months behind.

The model itself will keep changing. The durable advantage is the harness you know how to operate, the tools and skills you have built around it, and the connections to your own data. Those survive the next model release and the next product cycle. Master the coding agent now, and you own the workflow. Wait for the packaged version, and you will always be using somebody else’s outdated and suboptimal workflow.