Earned Autonomy: What AI Development Gets Wrong About Speed
On This Page
The Moltbot situation should concern anyone building with AI.
Security researchers have spent the past week tearing it apart. The vulnerabilities are substantial. The architecture is questionable. And perhaps most telling: the developer apparently doesn’t read his own code.
Thousands of people deployed it anyway. The vibes were right.
I want to be careful here. I’m not interested in piling onto one developer. What I’m interested in is what Moltbot represents - and why it matters for anyone thinking seriously about AI systems.
The Name Says Everything
Let’s start with something that might seem superficial but isn’t: the name.
Moltbot was originally called something that closely mirrored another company’s branding. When you model your product after another company’s name, you’re making a statement. You’re either trying to compete with that brand or leverage it. Either way, you’re borrowing credibility you haven’t earned.
From a branding perspective, this is lazy. From a trust perspective, it’s a signal. If the surface-level decisions are shortcuts, what does that suggest about the decisions you can’t see?
Building what Moltbot does isn’t hard. If you use the same tools, you could probably build it just as fast and probably faster, depending on your experience. The barrier to entry for AI tooling has collapsed. Anyone can ship something that looks impressive.
The problem isn’t capability. It’s trust.
The Speed Trap
The vibe coding movement has a thesis: AI can write code faster than humans, so let the AI write the code. Ship fast. Iterate faster. Speed is the goal.
I understand the appeal. I’ve spent the past couple years building AI systems myself. I have over fifty agents that handle different aspects of my work like research, analysis, drafting, code review, security assessment, etc. I’ve felt the pull of velocity.
But here’s what I’ve learned: as my architectures have grown more complex, I’ve slowed down, not sped up.
This is the opposite of what vibe coding promises. And as a security professional it’s intentional.
Building for Trust
I’ve never given an AI agent unsupervised access to my critical systems. Not email. Not finances. Not security infrastructure. Not passwords.
It’s not that I don’t have the compute. I have nearly a dozen machines in my home running various workloads and more in the cloud. Spinning up another environment is trivial.
The constraint isn’t resources. It’s trust.
Today’s tooling and designs don’t support the level of trust required to hand an AI system the keys to what matters most. The models are capable. The interfaces are smooth. The results are often impressive. But the architecture for trust doesn’t exist yet - not in the tools being shipped, and not in most of the systems being built with them.
So I’ve been building it myself.
The Graduation Model
My approach to AI autonomy is graduated. Nothing starts autonomous. Everything starts watched.
When I build a new agent or capability, it runs asynchronously. I see every change. I review every output. I understand every decision it makes before that decision affects anything real.
Only when a process proves itself, when its utility becomes repeatable and dependable across dozens of runs. Only then does it graduate to a background service, even then, the scope is narrow. The blast radius is contained.
This is slow. That’s the point.
Speed without trust is just debt you haven’t discovered yet. Every shortcut you take in understanding what your system actually does is a vulnerability waiting to surface. Maybe it surfaces in a security review. Maybe it surfaces when something breaks. Maybe it surfaces when a researcher decides to look under the hood.
The Moltbot developer doesn’t read his own code. That’s not a personal failing, it’s an architectural one. The system was built for speed, not comprehension. And now the debt is coming due.
Multi-Agent Governance
When I think about my fifty-plus agents, I don’t think about them as tools. I think about them as something closer to employees.
This isn’t a cute metaphor. It’s a governance model.
In any system where you need trust, you need validation. Validation takes many forms: authentication, authorization, integrity checks, confidentiality controls. But at its core, validation often means getting another perspective. A second opinion. A different set of eyes.
Multi-agent architecture provides this naturally. When I route a task through multiple agents for research, then analysis, then synthesis, then review. I’m building in validation. Each agent brings a different perspective. Each handoff is an opportunity to catch what the previous step missed. Consensus protocols, waterfall checks, and re-loop practices add further opportunities for catching what the average skim will miss.
This isn’t autonomous yet. It’s asynchronous and directive. I control the flow. I make the decisions. But it’s a better model for establishing trust than a single monolithic system that does everything and explains nothing.
The key insight: this is a principled system, not a hardcoded workflow. I can adapt it as I see fit. I can direct these agents toward new goals as my needs change, much like a chief executive can redirect a company toward a new vision. The architecture is flexible because it’s built on roles and relationships, not rigid pipelines.
As models improve and my confidence in specific patterns grows, some of this will become more autonomous. But that autonomy will be earned, not assumed.
The UX Trap
When we think about AI, we usually think about the experience. The interface. The results.
We’re humans. We experience the tactile, the immediate: the UI, the voice, the words on screen. We experience results that we either couldn’t create ourselves or that appear faster and more organized than what we’d produce manually.
This is seductive. And it’s exactly where most AI development focuses: making the experience smoother, the results more impressive, the speed more dramatic.
But here’s what I keep coming back to: if we started from a different question not “what experience do we want?” but “what architecture do we trust?” we would build very different systems.
Our intentionality would shift. Instead of optimizing for the surface, we’d optimize for the foundation. Instead of measuring success by how fast something ships, we’d measure it by how well we understand what shipped.
The UX question asks: does this feel good?
The architecture question asks: do I know what this does?
Both matter. But when AI capabilities outpace our ability to validate them, the second question matters more.
What Would We Build?
The developer of Moltbot built for speed and shipped something moderately impressive. Security researchers barely poked at it and found it hollow.
I don’t know where this goes. The tools are improving faster than most people can track. The capabilities are expanding into domains that were science fiction two years ago. The pressure to ship fast and capture markets is immense.
But I know this: when I think about the systems I want to trust with my most important work not demos, not experiments, but the infrastructure of my actual life I don’t want something built on vibes.
I want something I understand. Something with graduated trust. Something where every layer of autonomy was earned through demonstrated reliability. Something where the architecture itself encodes the question: “should this be allowed to do what it’s about to do?”
Building that is slower. It requires more thought upfront. It means saying no to shortcuts that would feel good in the moment.
But speed isn’t the goal.
Trust is the goal.
Speed is what happens after trust is established, not before.