Whether you’re ready to admit it or not, we’ve reached a point where most of us don’t write most of the code we ship. AI agents do.
You can be as enthusiastic as DHH, who recently shocked a Rails World audience by essentially betting it all on agentic development and efficient languages like Rust. Or you can be more skeptical. But in 3 years’ time, not many companies will opt for code crafted by hand without AI assistance.
Coding is dead. Long live software engineering.
Many of us didn’t get into tech to make big bucks. We appreciate the side effect, don’t get me wrong, but we were geeks fascinated by what this magical box we call a computer could do for us.
Do you have any idea how freaking cool this box just got? It just got “holy shit” magical. Now that English has won out as the most powerful, if a bit ambiguous, programming language, many limits no longer apply. What a time to be alive when a single person with enough Claude Opus tokens can utter into existence a clone of Photoshop.
The rules of engagement have also changed, and in many ways we are still figuring out best practices. (Some will argue we were still figuring them out after decades of old-school software development, too.)
And the number one rule is that you need to think of AI agents as brilliant but dangerously unpredictable employees. Give them the keys to the office, not the keys to the kingdom.
In less lyrical words, keep them away from production. Even the smartest models will make errors such as wiping your drive due to a quoting mistake or dropping your database. Search X and you’ll find plenty of examples of both.
The key is not to trust that the agent won’t make mistakes. The key is to limit access so that it can’t make serious or irreversible mistakes even if it wanted to. And of course backups you have restored before and can trust.
Microsoft Execution Containers (MXC) or Claude Code’s and Codex’s own sandboxes built on top of bubblewrap (Linux) or Seatbelt (macOS) are good. Not granting your agents access to production is best.
In practice:
- Keep production credentials out of reach. Not in the agent’s environment, your dotfiles, or your shell history.
- Ship through CI or a human. Agents can open pull requests, but they don’t deploy or run migrations against production.
- Require approval for anything destructive, like rm -rf, drop table, or similar.
- Give each agent its own scoped credentials, so you can see what it did and revoke it in one step.
The counterargument is that access to production and the shape of real data allow agents to iterate much faster with a tighter feedback loop.
It’s valid, but easily achieved with scoped, read-only access. Read-only credentials accessing a replica or snapshot of the primary database with short-lived tokens and, ideally, PII filtered out.
I’m very bullish about all this. So much so that it got me out of technical blogging retirement. But in a less deterministic world where we’re not fully in control, we need to be the adults in the room. Agents will be agents.
Leave a Reply