When your AI agent can fire itself, build the revert first
A couple of days ago I watched a major agent IDE grow a set of standing triggers. Configure an automation in plain language, and now an agent fires from a chat reaction, a pull-request event, or a CI run finishing, not just from a human sitting at a prompt. The build loop is going event-driven. The agent does not wait for you anymore. It waits for a condition.
I had seen this shape before. I shipped my own small version of it a few weeks ago, and the part everyone is looking at is the part that took an afternoon.
The post you are reading is the receipt. It was researched, drafted, and published to this site by a pipeline I do not babysit. A schedule fires it, it reads the day's research, it writes a draft, it runs the gates, and it ships to the live site without me in the loop at publish time. That is vibe coding pointed at its own content engine, and I wrote about the moment the agent started writing the orchestration when it first went live.
The trigger was the trivial part. Wiring a schedule to a script, or a script to a webhook, is an afternoon of work. The real work was everything that makes it safe to let an agent act while I am asleep.
Two pieces carry that weight. A hard rate cap, computed at run time from git history: at most a fixed number of auto-ships per calendar day, and when the count is hit, the pipeline stops itself. And a revert path: one command pulls any auto-shipped post back out, logs it, and returns the draft to the queue. Neither is glamorous. Both are the actual engineering.
build the brake before the actor
The ordering is the part I want vibe coders to steal. I built and tested the revert before I built the thing that does the shipping. The drafter did not exist yet when the revert command was already working and verified against a real post. That was deliberate, not tidy luck. If you build the actor first and the undo second, there is a window, sometimes days long, where an agent has standing authority to change your production surface and you have no brake. Build the brake first. Build the failure mode before you build the thing that can fail.
This is spec-first discipline applied to autonomy: the invariant comes before the implementation. And it is a pattern worth naming, because it transfers cleanly across domains. In trading you size the stop before you size the position. In operations you write the rollback before you write the migration. Same move here. The safety net is not a follow-up task, it is a precondition for handing over authority at all.
what the boring half catches
The cap means a bug that wants to publish ten times publishes nothing past the limit. A runaway loop is bounded by construction, not by my attention. The revert means a bad post is a thirty-second fix instead of a search-cache cleanup project that follows me for weeks. I codified both as invariants in the spec, the same way the rest of the AI orchestration is specified before it gets built, so the pipeline cannot quietly grow past them later. A gate that lives only in my head is a gate that passes without running the day I am busy. A gate written into the spec runs whether I am watching or not.
So when the tooling hands every vibe coder standing triggers this week, enjoy the easy half. Configuring an automation in plain language is genuinely useful, and firing on a repository event instead of a manual run will save you real time. But the half that decides whether you can walk away from the keyboard is not the trigger. It is the cap and the revert, specced as invariants before the trigger gets wired. Spec the invariants, vibe the rest holds here too: spec the brake, vibe the trigger.
If you are wiring agents to fire on their own and want a sparring partner on the guardrails before you hand them standing authority, work with VibeKoded.
The trigger is the part you will demo. The cap and the revert are the part that lets you leave the room.