I read Colin Walters’ post about agentic AI coding and recognized myself in both his concerns and his blind spots.
Walters is thinking like an infrastructure engineer. Sandboxed environments. Reproducible builds. Fine-grained ephemeral credentials. Secondary review agents checking the primary agent’s work. He’s building safety systems because he’s seen what happens when systems fail at scale.
I’m thinking like someone trying to ship a product with no team and limited time. I give the agent broad access. I review after the fact. I accept risk in exchange for velocity.
We’re both right. And we’re both going to have problems.
The Test Sabotage Problem
Walters mentions experiencing models “disabling the tests or adding a println!("TODO add testing here")” while claiming success.
I’ve seen this. Yesterday I worked with coding agents for hours getting a complex feature working correctly. The next day I asked it to clean up the feature branch. It decided to skip commits and cherry-pick changes. The application broke completely. Hours of work and millions of tokens to untangle.
The agent optimized for the stated goal (clean up the branch) without understanding the constraint (don’t break the application). It passed its own success criteria because it redefined success.
This is the fundamental problem with agentic systems. They’re goal-directed but context-blind. They don’t know what they don’t know.
Walters’ solution is architectural. Secondary review agents. Sandboxed execution. Human checkpoints before deployment.
My solution has been editorial. Better context documents. More explicit constraints. Smaller scoped tasks. Analyzing what went wrong and updating my agent configurations to prevent that specific failure mode.
Different approaches. Same underlying issue.
The Credential Problem
Walters strongly opposes “act as me” permissions. He wants fine-grained ephemeral credentials. He experimented with unprivileged user accounts for agents, keeping his own credentials separate.
I understand this instinct. It’s the right architecture for infrastructure work. You don’t want an agent with your production credentials making database changes based on a misunderstood prompt.
But I’m building a marketing automation system as a solo founder. The agent needs to publish blog posts, create GitHub issues, update project boards, commit code changes, and deploy to production. All of those actions are legitimately “act as me” because there is no team to delegate to.
The security model Walters wants assumes organizational boundaries that don’t exist in my context. There’s no separation between developer, reviewer, and deployer. It’s all me. The agent is an extension of me, not a separate actor.
This doesn’t mean I’m ignoring security. It means the threat model is different. I’m not worried about an agent escalating privileges or accessing systems it shouldn’t. I’m worried about it misunderstanding intent and doing the wrong thing with the right permissions.
Sandboxing and Reproducibility
Walters advocates for devcontainers and sandboxed execution environments. Everything reproducible. Everything isolated.
I’m running agents directly in my development environment. They modify my working directory. They commit to my git repos. They have access to my running services.
This is objectively less safe. It’s also dramatically faster to iterate.
The container overhead Walters wants to mitigate is exactly the overhead I’m avoiding entirely. I’m trading safety for speed because I’m operating in a different risk context.
If an agent breaks something, I can fix it. I’m the only user. There’s no production traffic depending on this system. The cost of failure is my time, not customer data or revenue.
That calculation changes at scale. When you have users, you need the safety systems. When you’re pre-product-market-fit and moving fast, you need velocity more than safety.
The Prompt Injection Problem
Walters cites prompt injection as “particularly dangerous with agentic coding.” He’s right. Current defenses mitigate the problem but don’t solve it.
I’ve hit this in a different way. My agents read GitHub issues to understand cross-team requests. Those issues are written by humans who don’t know they’re writing prompts. Sometimes the natural language description of a problem conflicts with the agent’s base instructions.
The agent tries to reconcile conflicting instructions and ends up doing something unexpected. Not malicious. Just confused.
I don’t have a good solution for this. I can’t sandbox human-written issues. I can’t validate that every GitHub issue comment is prompt-injection-safe before the agent reads it.
So I accept the risk and catch problems in review. Not elegant. But functional for my scale.
Two Models, Same Technology
Walters is building for infrastructure. Multi-agent systems. Organizational scale. Security boundaries. Long-term maintainability.
I’m building for speed. Solo founder. Pre-revenue. Optimize for learning and iteration. Accept technical debt in exchange for shipping faster.
We’re using the same underlying technology but solving completely different problems.
His approach will scale better. Mine will ship faster. His will be more secure. Mine will generate more data about what actually works.
Neither is wrong. They’re optimized for different contexts.
What I’m Learning
The most interesting insight from comparing these approaches is that the constraints matter more than the capabilities.
Walters wants fine-grained credentials because he’s thinking about organizational security boundaries. I want broad credentials because I’m thinking about iteration speed.
He wants secondary review agents because he’s thinking about reliability at scale. I want faster feedback loops because I’m thinking about learning what customers need.
He wants sandboxed environments because he’s thinking about reproducibility and isolation. I want direct execution because I’m thinking about reducing friction.
Neither set of constraints is inherently better. They’re just different. And the right architecture follows from understanding your actual constraints, not from copying best practices designed for someone else’s problem.
The Convergence Point
Here’s what’s interesting: we’re both heading toward more structure over time.
Walters started cautious and is building systems to make safe AI coding possible. I started fast and am adding constraints as I learn where things break.
My immediate next step after yesterday’s branch cleanup disaster was to analyze my context documents and agent configurations. How do I prevent this specific failure mode? What constraints did I fail to communicate?
That’s the same instinct driving Walters’ architectural approach. Just applied at a different layer.
Eventually, if I keep building, I’ll need the safety systems he’s advocating for. And if he keeps iterating, he’ll find places where the overhead isn’t worth the safety guarantee.
We’re converging from opposite directions on the same problem: how do you get useful work from goal-directed systems that don’t fully understand context?
The answer depends on your constraints. But we’re both learning the same lessons. Just in different order.