I recently shipped an open-source Terraform provider, mostly written by Claude Code, an AI coding assistant, running on a low-effort setting where I mostly stayed out of its way. It went smoothly. Not the chaotic, half-broken “vibe coding” story people expect when an AI writes most of the code.
No provider existed for Beszel before this, a lightweight, self-hosted monitoring tool built around a hub-and-agent model. Anyone already managing infrastructure as code has one manual step left with Beszel: clicking through its UI to register each system. That gap, not the AI angle, was the actual reason to build this.
Deciding What It Should Actually Do
The provider models the resources that make sense to manage declaratively: systems, users, alerts, and user settings. It deliberately does not model the collections the monitoring agent itself writes to, since Terraform has no business fighting an agent for ownership of data it didn’t create. A few other pieces are left for later, since they go through custom, stateful routes rather than plain CRUD, not because they were forgotten.
It also requires superuser authentication, since regular accounts can’t create or list systems arbitrarily. That’s a real limitation, stated plainly rather than glossed over.
None of these were decisions Claude made for me. Knowing what a tool like this should own, and what it shouldn’t, is the same judgment I’ve written about before in How I Decide What Not to Build, and it doesn’t change just because an AI is doing the typing.
Where the Typing Speed Stopped Mattering
The actual risk with an assistant that’s usually right isn’t broken code. Broken code announces itself. The quieter risk is a confident-sounding explanation for a decision, written down early, that nobody questions again because it sounds like it was already checked.
That happened once, concretely. Claude wrote a comment describing a quirk in how Beszel handles one of its resources:
// Creating a user_settings record resets settings to
// server-side defaults, regardless of what was posted.
// We work around this with upsert-then-patch.It shaped how the logic was written, made it into the project’s own documentation, and shipped across two releases without anyone checking it against Beszel’s actual source.
I asked a reasonable-sounding question first, whether the resource being effectively un-deletable made some of the logic dead code. Claude checked its own implementation and confirmed it wasn’t. Fair, but not the real issue.
The question that actually mattered was different: not does this sound right, but is this actually true. That forced a real check against the source instead of a restated assumption, and the real behavior turned out narrower and more deliberate than documented, one specific field forced to a fixed value on create, everything else passed through as posted. Not a bug. A mischaracterized default. The fix was two lines. The finding was upstream of the code entirely.
A Second Checkpoint, Not Just One
This wasn’t the only place something got caught. A second AI reviewer went over every change on its own and consistently flagged real issues, bugs, edge cases, small logic mistakes, a different kind of catch entirely from the one above. Neither tool replaced the other. Between them, more got caught than either would have surfaced alone.
What Actually Held Up
The provider shipped clean, scoped the way it’s described above, published on the Terraform Registry under an MIT license.
But a clean result isn’t really what two releases of an unquestioned assumption proves. What held up was something smaller: deciding what the tool should model in the first place, and refusing to accept an explanation because it sounded thorough instead of checking whether it was actually true.
