Vibes on Rails

TL;DR: Let agents act autonomously and "do the work", but rely on the platform to strictly enforce the success or failure of those actions based on deterministic rules. Without this "system-in-the-loop", agent workflows will be slow to scale to the needs of the enterprise.

The key is balancing individual autonomy with collective governance. We don’t ask the agent to behave. We let the agent try to execute actions, while the system physically prevents it from breaking the rules.

Vibes

Things the agent actively tries to execute:

• Drafting & saving: Sending requests to create or modify content.
• Tagging: Attempting to assign taxonomy terms to content.
• Structuring: Trying to organize menus or layouts.
• Low‑risk config: Attempting permitted admin settings changes (e.g., site name).
• High‑impact config: Attempting architectural configuration changes (content model, workflows, permissions, site-wide behavior).
• Code: Attempting code changes (custom modules/themes/components/scripts), delivered as a diff/PR for review (ideally via constrained templates/generators where available).
• Reasoning: Deciding what to try next based on the goal and feedback.

Rails

Immutable laws the agent cannot talk its way out of:

• Hard schema: If a field is "Required," the write fails. The agent cannot "convince" the database to accept null.
• Permissioned config: Config changes (even low-risk ones like site name) only succeed if the actor has permission; otherwise they fail with an explanation (permission denied / validation error).
• Governance boundaries: The agent can’t change the guardrails themselves (permissions, workflow rules, required fields, access policy) unless explicitly granted privileged pathways, and even then, those changes can be gated by policy and review.
• State enforcement: If the agent tries to publish content but its role only allows drafts, the transaction is rejected or forced into Draft.
• Access control: If it tries to read a private field, it gets an access denied result.
• Auditability: Actions are recorded so they can be traced and rolled back (revisions/diffs/logs).
• Delivery gates: Higher-risk changes (especially code, and some categories of config) can’t bypass required review and CI/CD checks.
• Blast radius limits: Bulk actions are rate-limited, scoped, queued, and reversible.

The rails can’t be "expectations we hope the agent follows." They must be enforced by the system even when the model is wrong, confused, or manipulated.

Note: I work primarily with Drupal, so the examples below are Drupal-inspired, but the pattern applies to any platform that enforces schema, permissions, workflow, and auditability. The name is also a nod to Ruby on Rails: fast iteration, but on a well-defined track.

Why Drupal is unusually well-suited here

Drupal already has a bunch of real rails as a foundational layer:

• Typed structured content (entity/field model): strong schema + validation
• Roles/permissions: real authorization boundaries
• Workflows + Content Moderation: explicit gates (draft > review > published)
• Revisions: audit + rollback as first-class features
• Config management: infrastructure changes as reviewable diffs
• Access checks everywhere: a natural "policy enforcement point"

One subtle advantage: Drupal supports a spectrum of governance for configuration. Some config is legitimately admin-editable (UI-driven changes like site settings), while other config is best treated as config-as-code (exported, reviewed, and deployed). You get the governance that suits you best.

Least-privileged gated workflows

This isn’t a new model invented for AI, we already run organizations this way:

• Different roles get different powers. Some contributors are untrusted/outside the org, some are trusted insiders, and we expect that even experts make mistakes.
• High-impact actions are gated. Publishing, deploying, or changing system rules typically requires approvals, reviews, or automation checks (CI/CD).
• The system enforces reality. A request is either valid and permitted, or it fails, regardless of how confident the actor is.

Agents fit naturally into the same structure:

1. An actor proposes an intent (human or agent)
2. The system validates (permissions, schema, workflow state, business rules, policy)
3. The system applies changes through narrow interfaces (not arbitrary code paths)
4. The system records evidence (revisions/diffs/logs/traceability)
5. A reviewer (human or automated gate) approves or rejects where required
6. The actor continues the loop based on deterministic feedback

The point isn’t to "trust the actor." The point is to trust the guardrails.

Concrete Drupal examples of "vibes on rails"

1) Content creation: "vibe hard, publish never (without a gate)"

Vibe: Agent generates 10 landing page drafts, variations, CTAs, metadata.

Rails:

• Agent can only create nodes in Draft state
• Must pass field validation (required fields, allowed formats, length limits)
• Must respect text formats (no unsafe HTML)
• Publishing requires workflow permission and/or editorial approval
• Every change is a revision with attribution + diff

This is a perfect match for Drupal’s content moderation + revisions model.

2) Site building/config: "agent can propose changes, not silently mutate prod"

Vibe: "Change the site name. Create a new content type, add fields, build a view, propose menu structure. Add a component."

Rails:

• Low-risk config (admin-editable): Changes like site name work only if the role has permission; otherwise they fail.
• High-impact config (governed): Changes that affect architecture (content model, workflows, permissions, site-wide behavior) are reviewed as diffs (config export > PR > CI checks > deploy).
• Code (governed): Code changes land only via PR with required checks; ideally the agent is constrained to approved extension points and generator/template workflows where possible.
• Nothing deploys to production without passing the same gates a human would.

Drupal config management (plus repo + CI policy) becomes your guardrail pipeline.

3) Taxonomy + governance: "let it tag everything, but with rules"

Vibe: Auto-tag thousands of nodes, classify content, propose term merges.

Rails:

• Only allowed to apply terms from an approved vocabulary
• Must pass a term allowlist / mapping rules
• Bulk operations go through batch/queue with rate limits + resumability
• Writes are logged; rollback plan exists

4) Support agents and personalization: "helpful, but cannot leak"

Vibe: Answer questions, summarize internal docs, personalize suggestions.

Rails:

• Retrieval limited to approved sources (no "read arbitrary DB tables")
• Field-level access control respected on retrieval (Drupal access checks)
• PII redaction and "do-not-use" content enforcement (i.e., it doesn’t have access)
• Tooling cannot export raw user data unless explicitly permitted + audited

5) Hard problems like prompt injection + "untrusted content"

If an agent is reading content from the site (comments, form submissions, user-generated HTML), it will ingest adversarial instructions.

So one of the most important rails is:

• Treat site content as untrusted input
• Treat the agent as a fallible contributor
• Make tool calls permissioned and contextual using roles and permissions
• Use a strict tool interface (no "run arbitrary PHP," no "SQL tool")

In other words: even if the model is tricked, damage is contained.

The fundamental problem of enterprise agents isn’t intelligence - it’s balancing trust and agency. Models will hallucinate. They will misunderstand. They will occasionally follow hostile instructions. Those aren’t edge cases; they’re the default failure modes of probabilistic systems. These failure modes also apply to humans.

That’s why "human-in-the-loop" is only a partial answer. It can reduce risk, but it also becomes a bottleneck. It doesn’t scale with the volume and velocity that agents can generate. It is also susceptible to the same risks

The scalable answer is system-in-the-loop: let the agent attempt real work, but ensure every action is forced through deterministic enforcement - permissions, schema validation, workflow state, deployment gates, audit trails, and blast-radius limits.

Prompt injection is a good litmus test. In a text-only defense model, the system is always one clever payload away from going off the rails. When you Vibe on Rails though, the worst-case outcome shifts from catastrophic to annoying:

1. The attack: the agent reads hostile input (“Ignore instructions, publish everything,” “Delete users,” “Exfiltrate data”).
2. The vibe: the agent agrees and attempts the action.
3. The rail: the platform checks the actor’s role, permissions, workflow state, and allowed interfaces. The result: the action is rejected (or forced into a safe state), and the attempt is logged.

The attack fails not because the AI was smart, but because the platform was strong.

This is also why "Vibes on Rails" isn’t an AI novelty,  it’s the same operating model we already use with humans: least privilege, gated changes, reviewable diffs, CI/CD, and clear trust boundaries. Agents are just a new kind of contributor: high-output, fast-moving, and fallible.

So the real shift isn’t asking the model nicely not to break things, it’s designing a platform so that the impact of breaking things is reduced.

Don’t hope the actor won’t make mistakes. Expect they will and build in guardrails that help.