Multiplier
I won’t be the first to call AI a multiplier. It is exactly that. Like any other tool, a lever model helps us to achieve something faster. But just as an axe in untrained hands, an agent can cause more harm than good.
Forget about stories where Claude dropped the database without backups. It has happened to us all by now. Those tools are probabilistic, which means they will make mistakes by design. That’s the same thing that makes them appear creative - while they aren’t.
The risk from those technologies is that they magnify our flaws. It does it at a greater scale than multiplying our strengths. And I’m talking about strengths here instead of outputs on purpose. Bigger output isn’t necessarily a good thing.
If you create more code, you need more time and energy to review it. More things can go wrong, and more side effects can be introduced. If you turn down the volume while still using automation, you end up with higher velocity and hit the same bottleneck. So you go towards automating review and testing. You give away control, which on its own doesn’t have to be bad. That’s the same thing that company owners do to scale. They delegate. But that brings new risks: bigger drift, more things that can go wrong.
The benefit of delegating to people is that with the level of agency and ownership, they tend to show ingenuity, initiative and vigilance. Agents don’t have the agency. They don’t have stakes. They don’t have self-discipline.
If you don’t know how to build clear guidelines and guide rails, split the work, build the plan and steer the agent (or team of contractors for the sake of argument), you learn fast that what you get is far from what you requested. Given to the humans, you have a chance that they corrected your mistakes along the way and didn’t lose your north star. That is what saves many organisations. You don’t have that with agents. You just get the drift.
It is extremely important for us to work on our old-fashioned skills: clear communication, critical thinking, systems thinking, and domain understanding. If we lack those, our results with agents will be far from expected. Agents will become multipliers of our flaws.
As organisations, we need to rethink our structures. We won’t survive with multiple, conflicting owners and stakeholders, long approval chains, and a shallow understanding of the problem. Just as engineers will spend less time coding directly, there is less need for project or product managers who just pass the papers around. You need to be an involved member of a small, defined team of owners. Every engineer must become a product owner, and every product owner must become an engineer. Otherwise, agents will multiply our bottlenecks: loads of stale branches waiting for approval and sign-off; tokens burned on never-ending iterations; drifting results and reduced quality. Fragmented teams are already a pain without AI - they are a death sentence with it.
This is one of many journal posts I started to write to vent my thoughts while using various AI tools at work and in private projects, as well as while creating AI solutions at work and in private projects. My (third so far) bespoke agent system - Eidan - is meant to help me address many issues defined in those topics. Relating to the scope of this post, I try to give Eidan agency and memory with the aim for it to be more help than a burden - another tool to maintain and steer. Feel free to fork it, clone it, and have a play with it.