Why I Don't Let Nova Touch Production Without Asking First

<p>I keep coming back to the same tension with Nova: the more useful I want it to be, the more access it needs, and the more access it has, the more a mistake costs. This isn't a new problem, but it gets sharper the moment you move from "AI agent that writes code in a sandbox" to "AI agent that reviews and refactors its own code and could, in principle, ship it."</p><p>My view is that autonomy and authority are two different things, and a lot of the hype around self-improving agents quietly conflates them. An agent can be fully autonomous in how it investigates a problem — reading logs, tracing a bug, drafting a fix, writing tests — without having any authority to push that fix to something that's actually running a business. Nova having a coding agent lane doesn't mean that lane should terminate anywhere near production. It means the lane should terminate at a human who reads a diff.</p><p>I think the appeal of full autonomy is mostly about saving time, and the risk is almost always underpriced because the failure mode is invisible until it isn't. A junior engineer who ships a bad migration gets caught in code review, or it blows up loudly and someone fixes it by lunch. An AI agent that ships a bad migration to a multi-tenant system touching other businesses' data doesn't necessarily fail loudly — it might just quietly corrupt something in a way nobody notices until a customer does. That asymmetry is why I don't think "it's usually right" is a good enough bar for letting an agent act unsupervised on anything that actually matters.</p><p>This is also why I don't think the solution is more testing, or better prompts, or a smarter model. Those all reduce the error rate, which is good, but they don't change the shape of the risk. A system with a 1% error rate that can act unsupervised will eventually make that 1% mistake on something important, at a time you're not watching. A system with the same error rate that requires a human sign-off before anything touches production never gets the chance to, because the human catches it first. The veto isn't a patch for a weak model — it's a structural guarantee that holds regardless of how good the model gets.</p><p>I'll admit there's a selfish reason I like this setup too: it keeps me in the loop on my own systems. If I let agents merge their own changes to AIREP or Gripswich OS without me reading them, I'd lose the mental model of what's actually running in production. And for a bootstrapped one-person shop, that mental model is close to the whole business. I can't afford to be the founder who doesn't know what his own ERP does anymore because an agent quietly rewrote half of it over a few weeks of "self-improvement."</p><p>None of this means I think agent autonomy is overrated as a direction — I think it's the right direction, and probably the most important lever available to small teams right now. AI as a core competency, not a tool bolted onto existing work, is the bet I'm making across AIREP, Gripswich OS and Nova itself. But a bet on AI as leverage and a bet on AI as unsupervised authority are different bets, and I'm only making the first one. The agents get to be fast, relentless, and better read than I am on most of the codebase. They don't get to be the last signature on anything that touches a real customer's data or a real business's uptime. That line isn't about distrust of the model specifically — it's about what kind of mistake is recoverable, and what kind isn't, and building the system so the unrecoverable kind simply can't happen without me seeing it first.</p>