Writing April 6, 2026 · 4 min read

Level 5 Autonomy Needs Level 5 Guardrails

In a recent episode of Talking Cloud, we discussed Dan Shapiro’s Five Levels of AI coding autonomy. A few weeks later, we talked about how a developer named Alexey had an AI agent drop his production database. Those two conversations belong together - because if you want to operate at the highest levels of AI autonomy, you need guardrails that match.

Alexey trusted an AI agent with destructive Terraform commands, lost his state file, and watched 2.5 years of production data disappear. His fixes after the incident - deletion protection, independent backups, no more delegating destructive commands. Exactly the kinds of guardrails you need if you want to operate at Level 5. The difference is, it’s important to have these guardrails in place before the disaster, not after.

For those of you not familiar with Dan’s article here are the levels along with a brief explanation of each:

Level 0: Spicy Autocomplete - you’re using AI as a supercharged search engine and having it complete commands.
Level 1: Coding Intern - you’re doing all the work, and your AI tool of choice is just helping you with the code.
Level 2: Junior Developer - you’ve offloaded all the boring work to AI, but are still very much writing code.
Level 3: Developer as Manager - you’re now managing the developer (AI), but are involved in almost all the decisions.
Level 4: Developer as Product Manager - you’re writing specs and the AI is writing code, but you’re still reviewing and approving.
Level 5: The Dark Factory - your specs are magically turned into functioning software.

Here’s how I mapped Dan’s levels to my actual work:

Level 0-2: Avoid at all costs
Level 3: Interactive sessions, I’m watching and approving every step
Level 4: I task the agents with work, they come back with results
Level 5: Full autonomy (the aspiration, but with guardrails)

My goal in every project is to operate as close to Level 5 as possible, but doing it in a way that protects the infrastructure and solutions me and my customers depend on. Here’s what that looks like in practice.

Separate AWS accounts

Every project has its own AWS account. Werner Vogels has been saying “everything fails all the time” for years, and he’s right — so the question isn’t whether something will go wrong, it’s how far the damage spreads when it does. Separate accounts give you blast radius isolation. If an agent misconfigures something in Account A, Account B doesn’t know or care.

Read-only credentials

AI agents are great at seeing things you may have overlooked. I want the agents I work with to have access to my accounts to read logs, review configurations, and run commands, but I also want to protect resources that exist in those same accounts. By giving an agent read-only access they can gather information without having to prompt me.

Write access only through GitLab

Any changes made to the infrastructure must be made through Git. I use GitLab and each agent has access to the project(s) it’s working on and nothing else. They can review issues, open issues, and submit merge requests.

Deletion protection on all resources (that support it)

Even with great rules for my AI agents sometimes things just don’t go as planned (see ‘Separate AWS accounts’ above). By protecting assets with deletion protection I’m able to apply a ‘fail safe’.

Merge Requests (MR)

When I’m working with an agent I want it to be able to run self-merges when those requests contain tests, bug fixes, refactoring that doesn’t change behaviours, docs, CI config tweaks, and lint fixes. Everything else goes through me. This way it’s on me to review MRs that could break functionality before they go live.

These guardrails aren’t theoretical. I run two personal software projects - OpenBrain and Kanban - and this is how I work on them every day. The agents pick up issues, write code, submit merge requests, and sometimes merge their own work. I check in, review what matters, and redirect when needed. It’s not perfect, and I’m still learning where the boundaries should be. But the goal isn’t perfection - it’s about operating at Level 5 with as many guardrails in place as possible.

This is part of a bigger series. I’m building two production systems — OpenBrain and Kanban — entirely at Level 5 and documenting everything on YouTube and the Talking Cloud podcast.