Vibe coding tools need a production boundary

Vibe coding tools are easy to compare in a demo and surprisingly hard to compare once a customer, a database, and an on-call rotation enter the picture. The useful question is not which tool writes the most code from the shortest prompt. It is how much work the tool can take on, what evidence it leaves, and where a competent human can stop a bad change before that change reaches production.

I have watched teams buy autonomy and assume they also bought engineering discipline. They did not. A builder can turn a paragraph into a working app while hiding decisions that an experienced engineer would want to inspect. An agent can edit fifty files and pass the tests while misunderstanding the business rule. An IDE can keep every change visible and still let a tired developer approve nonsense. Choose the interaction model for the work, then build a production boundary around it.

Map autonomy before comparing products

Autonomy describes the distance between an instruction and a completed change. It does not describe the quality of that change. That distinction clears up most confused comparisons among builders, IDEs, and agents.

At the first level, an assistant proposes a line, function, or explanation while a person drives. At the second, an editor agent changes several files, searches the repository, and runs commands inside an active session. At the third, a task agent receives an outcome, works through a plan, runs tests, and returns a diff or pull request. At the fourth, a builder owns much of the environment as well as the code: it can create the interface, connect data, preview the result, and publish it.

Those levels are not a maturity ranking. A lower-autonomy tool can be the better production choice because it fits an existing repository, test suite, review policy, and deployment path. A high-autonomy builder can be the right choice for an internal intake form because the cost of a week of conventional setup would exceed the risk. The same builder may be wrong for a billing service whose retry and reconciliation behavior already took years to learn.

I use five questions to place any tool on the map:

• Does it work in a generated project, an existing repository, or both?
• Can it run commands and observe their output without being prompted for every action?
• Can it change infrastructure, data, secrets, or deployment state?
• Does it return editable source, a reviewable diff, or only a published result?
• Can the team constrain its tools and require human approval at risky boundaries?

A vendor can add a new model or mode next week without changing these questions. That makes the map more durable than a leaderboard. It also exposes the cost hidden behind convenience. The farther an agent can travel, the more context, permissions, and acceptance tests it needs.

Builders win the blank page and lose context first

AI app builders are strongest when the product can begin inside the builder's assumptions. They compress setup, interface work, backend wiring, preview, and hosting into one conversation. Lovable, Bolt, Replit Agent, and v0 sit in this broad family, although each draws the boundary around code, hosting, and integrations differently.

This category is a good fit for a disposable prototype, a founder's first interactive specification, a campaign tool, a simple internal workflow, or a new web product with conventional data patterns. It is much less convincing when the task starts with a mature monorepo, a private package graph, unusual infrastructure, or behavior encoded across years of incidents and workarounds. The blank page has no legacy context to miss. An established system does.

The production question is not whether a builder has a Publish button. Publishing proves that the platform can place an artifact at a URL. It does not prove that your team can reproduce the build, inspect dependency changes, migrate data safely, restore production state, or operate the service during a provider outage. Lovable's documentation makes one boundary unusually clear: publishing deploys a snapshot, and later edits do not go live until someone publishes again. Its GitHub integration provides another important escape hatch by syncing editable source and allowing work in a conventional IDE. Those are useful controls, but a team must still decide which system owns the truth and deployment process.

Replit's checkpoint documentation is equally instructive. Agent checkpoints can capture project files, conversation context, configuration, and connected database state. The same manual warns through its behavior that restoring a development checkpoint is not the same as restoring a production database. That distinction matters. Source rollback, schema rollback, and data recovery are three separate operations, even when one interface makes them look adjacent.

A builder is ready for production only within a bounded product shape. Export the source before the application matters. Put it under the company's repository controls. Add independent monitoring, backups, access review, and a tested recovery path. If the builder cannot support those moves, call the result a prototype and budget for replacement rather than quietly declaring it production.

IDE agents trade some speed for control

Agentic IDEs are the default choice for teams that already own a codebase and need the engineer to remain inside the feedback loop. Cursor, Windsurf, GitHub Copilot in an editor, and similar tools can search across files, propose a plan, edit the working tree, run terminal commands, and react to compiler or test failures. The engineer sees the repository, diff, terminal, and diagnostics in one place.

This arrangement gives the agent far more reach than autocomplete without handing it the whole delivery process. Cursor's documentation, for example, describes Agent as able to edit code and run terminal commands, while project rules carry coding standards and recurring context. Command approval in its CLI is an explicit control. GitHub Copilot's editor modes now extend from questions and edits to agent sessions and delegation, but the repository remains the unit of work.

The IDE is the right place for ambiguous changes that need frequent steering: replacing an internal API, tracing a UI regression, updating a data model across call sites, or adding tests around poorly documented behavior. A developer can interrupt when the agent chooses the wrong abstraction rather than reviewing a large finished branch after the mistake has spread. That interruption is productive work, not a defect in autonomy.

The weakness is approval fatigue. After ten harmless command prompts, people approve the eleventh without reading it. A permission dialog cannot carry the whole safety model. Keep secrets outside the working tree, run the agent with the least operating-system access it needs, and place irreversible actions behind a separate credential or workflow. If the editor session can read production tokens and invoke the production control plane, the team has already made the dangerous decision before any prompt appears.

IDE agents also tempt teams to confuse visibility with review. Watching files change feels like understanding them, but fast scrolling is not code review. Require a clean diff, passing checks, and a second set of eyes for the same classes of change that required them before AI entered the editor.

Task agents earn autonomy through a reviewable handoff

Task agents are most useful when they can accept a bounded outcome and return a branch, patch, or pull request with evidence. Claude Code and Codex can work locally across a repository and terminal. Cloud agents such as GitHub Copilot's coding agent can take an issue, work asynchronously, and prepare a pull request for review. The interaction shifts from pairing continuously to delegating a work package.

That shift pays off on migrations, dependency updates, test repair, repetitive refactors, documentation changes tied to code, and well-specified features. It performs badly when the task hides a product decision, depends on tacit knowledge, or has no executable way to distinguish correct from plausible. A detailed issue cannot replace a missing policy decision.

Permissions determine whether the extra autonomy is useful or reckless. Anthropic's Claude Code documentation separates read access, shell commands, and file modification, and lets teams distribute permission rules. Its hooks can inspect tool calls before execution. The important qualification is that a hook runs inside the agent's operating environment; teams should not treat a prompt-level rule as an operating-system security boundary. Sandboxing and restricted credentials still do the hard containment work.

GitHub's documentation gives a clean example of a review boundary. Its coding agent works on a task and opens a pull request, while repository rules and human review control the merge. The agent can research, plan, and iterate before creating that pull request. This is a better production pattern than granting an agent direct deployment rights because the handoff uses artifacts the team already knows how to inspect.

A task agent becomes more trustworthy when the repository can explain success mechanically. Give it commands for formatting, types, unit tests, integration tests, and a focused end-to-end check. Tell it which files are forbidden, which interfaces must remain compatible, and what evidence belongs in the handoff. Autonomy without an acceptance contract only produces mistakes faster and farther from the person who requested the work.

Context quality sets the real ceiling

An agent can act only on the product knowledge that reaches its context, so repository preparation often matters more than switching models. Code shows what the system does now. It rarely explains why an odd behavior must remain, which customer depends on it, or which apparently unused field supports a monthly reconciliation job.

Separate durable context from task context. Durable context belongs in versioned repository files: build commands, architecture boundaries, naming conventions, generated code rules, forbidden dependencies, and the location of authoritative tests. Task context belongs in the issue or acceptance contract: the desired behavior, non-goals, examples, risk, and evidence required for this change. Chat history is a poor home for either because reviewers cannot reliably see it and the next session may not receive it.

Most teams make one of two errors. Some write a giant instruction file full of general engineering advice, which consumes attention without resolving local choices. Others provide no instructions and expect the agent to infer architecture by reading thousands of files. Keep durable guidance short, specific, and testable. "Use the existing Money value object and never pass floating-point amounts across the billing boundary" helps. "Write clean, maintainable code" adds nothing.

Consider a subscription service with a cancellation endpoint. The visible request says to stop future renewals immediately. The repository contains an apparently redundant pending_cancel state, and an agent simplifies the flow by deleting it. Unit tests pass because they cover the final state. In production, the payment provider sends a delayed success callback for a renewal already in flight. Without the intermediate state, the handler reactivates a cancelled subscription and sends an incorrect receipt.

The failure did not begin with bad syntax or a weak model. The business invariant existed only in the head of the engineer who handled the original incident. A useful fix records that invariant beside the state machine, adds a test for the delayed callback, and states in the task that cancellation must win over later renewal events. After that, builders, IDE agents, and task agents all have a better chance of preserving the rule.

Context also has an access cost. Giving an agent every document, ticket, database, and message may improve recall while exposing secrets and irrelevant personal data. Scope retrieval to the task and prefer curated technical records over an unrestricted company search. An agent implementing invitation expiry may need the API contract and authorization rules. It does not need payroll files or the production customer table.

Watch for context decay during long sessions. Agents summarize earlier material to keep working, and important exceptions can disappear behind newer instructions. Break large outcomes into reviewable changes and repeat the acceptance criteria in the artifact that governs each change. If the agent starts editing unrelated areas or explaining around a failed test, stop the session and narrow the task. Continuing usually produces a larger diff with the same misunderstanding.

The highest autonomy level a team can use depends on how much of its intent is explicit. A well-prepared repository lets a task agent finish meaningful work without constant correction. A repository built on oral history forces an experienced engineer to supervise every step, regardless of the product capabilities advertised in a demo. Before blaming the tool, check whether a new human engineer could discover the same rule from the material you supplied.

Repository context should survive a tool change. Put commands in ordinary scripts, constraints in plain text, and decisions beside the code they govern rather than encoding all knowledge in one vendor format. Product-specific rules can point to those sources, but they should not become the only copy. This keeps a builder export usable in an IDE and lets a local agent and a cloud agent work from the same contract.

Treat generated explanations as leads, not records. When an agent discovers a real dependency or an unexpected deployment constraint, verify it and update the repository documentation or test. Do not expect a later session to recover the discovery from conversation history. The compounding benefit of AI-assisted work comes from making the codebase easier for the next worker to understand, whether that worker is a person or another agent.

Production readiness is a separate axis

Production readiness measures whether the team can understand, control, and recover the resulting system. It belongs on a separate axis from autonomy because a highly autonomous tool can produce an operable change, while a careful assistant can still help create an untestable mess.

I score readiness across six gates. Ownership asks whether the company has the source, build definition, dependency lockfiles, and legal right to operate the result. Reproducibility asks whether a clean environment can build and test it. Reviewability asks whether humans can inspect a bounded diff and trace it to a requirement. Operability covers logs, metrics, alerts, cost limits, and support responsibility. Security covers identity, secret handling, dependency checks, data access, and permission scope. Recovery covers application rollback, schema compatibility, backup restoration, and a person authorized to act.

A tool does not need to supply every gate itself. In fact, mature teams usually assemble them from repository controls, continuous integration, cloud policy, observability, and incident practice. The coding tool needs to fit those controls without bypassing them. A builder with source export and a normal deployment pipeline may score well. An IDE agent with unrestricted credentials and no tests may score badly.

Use four readiness states instead of a fake numeric score. "Prototype" means failure is cheap and data is disposable. "Supervised internal" means known users, limited data, and a named owner can tolerate manual recovery. "Customer-facing" requires repeatable delivery, monitoring, security review, and tested recovery. "Regulated or high impact" adds evidence retention, separation of duties, access governance, and domain-specific validation.

The awkward question, "Is vibe coding safe for production?", has a precise answer: the interaction style is neither safe nor unsafe by itself. It is safe only when the consequence of failure fits the controls around the generated change. A marketing calculator and a medication dosing service should never share an approval policy, even if the same agent can build both.

Match the tool to the failure cost

The best tool is the least complicated one that can complete the work inside the required controls. Teams often pick the most autonomous product because the demo looks cheaper. Then they spend the saved time reconstructing context, reviewing oversized diffs, and repairing deployment assumptions.

For a throwaway proof of concept, choose a builder and optimize for learning speed. Keep the data synthetic, avoid production credentials, and decide in advance whether the code will be discarded or exported. For an internal app with a small user group, a builder can still work if the company owns the source and someone owns access, backups, and incidents.

For an established product, begin with an IDE or repository agent. The existing code, tests, review history, and pipeline are assets. Do not move the work into a closed project just to get a nicer prompt box. Use a task agent when the acceptance criteria are executable and the diff can return through the normal pull request path. Use an IDE agent when the engineer must make product or architecture calls during implementation.

For infrastructure, authentication, billing, privacy, and destructive data changes, reduce autonomous reach. The agent can investigate, draft, test in an isolated environment, and prepare a plan. A person should approve the exact change and a separate deployment system should apply it. This is not a judgment about model intelligence. These areas have large failure costs and often require information that does not live in the repository.

Tool choice also changes across one project. A founder may use a builder to prove the flow, export the code, move into an IDE for product development, and delegate contained maintenance tasks to a cloud agent. Treat categories as operating modes, not tribes. Switching when the risk changes is a sign that the team understands the work.

The production boundary belongs in CI

Continuous integration should decide whether agent-written code may advance, because CI applies the same checks regardless of who or what authored the change. Prompt instructions guide behavior. Branch protection, isolated builds, required checks, and deployment permissions enforce it.

Put the acceptance contract in the repository where both humans and agents can read it. A small task file can prevent a long conversation from drifting:

change:
  goal: "Reject expired invitations without changing valid invite behavior"
  allowed_paths:
    - src/invitations/**
    - tests/invitations/**
  forbidden_paths:
    - migrations/**
    - deploy/**
acceptance:
  commands:
    - npm run typecheck
    - npm test -- invitations
  evidence:
    - failing test before fix
    - passing test after fix
  rollback: "Revert one pull request; no schema change"

This artifact makes four decisions visible: scope, forbidden surfaces, executable checks, and recovery. The agent may still implement the wrong business rule, but it cannot plausibly claim completion after editing deployment files or skipping the invitation tests. A reviewer can compare the diff with a compact contract instead of reconstructing intent from a chat transcript.

CI should run in a clean environment with credentials that cannot deploy. Tests generated by the same agent deserve review because an agent can make a weak assertion pass. Require an existing regression test when possible, then add a new test that demonstrates the failure before the fix. For database work, test both forward migration and compatibility with the previous application version. A rollback that depends on reversing a destructive schema statement is not a rollback plan.

Keep deployment outside the coding agent's default tool set. Let the agent prepare an artifact and let the release system promote it after approvals. If a team wants automatic deployment for low-risk services, encode that exception in repository policy. Do not grant broad production access merely because repeated approval clicks became annoying.

A paid work sample beats a feature checklist

Evaluate vibe coding tools with one representative work sample in your own repository. Feature matrices age quickly and reward capabilities that your team may never use. A two-day trial on real work exposes context quality, review cost, permission friction, and recovery behavior.

Choose a task that a competent engineer can finish but that touches more than one file. Include a small ambiguity that good tooling should surface, an existing test that must keep passing, and one forbidden area. Give every candidate the same repository state and acceptance contract. Do not use a toy task whose solution appears in public examples.

Record five outputs: elapsed human attention, elapsed clock time, number of correction turns, size of the final diff, and evidence produced with the handoff. Then inspect the failure path. Cancel the agent midway, reject a proposed command, introduce a failing test, and roll back an unwanted change. A tool that is impressive only on the happy path is not ready to join a delivery process.

The reviewer should grade the result without knowing which tool produced it. Check whether the code fits local conventions, narrows the change to the request, handles error cases, and leaves useful tests. Measure review time separately from generation time. Saving forty minutes of implementation and adding two hours of forensic review is a loss, even if the agent's task timer looks excellent.

Run the sample with the permissions you would allow in daily work. A demonstration using unrestricted shell access, every secret, and direct deployment proves little about a governed setup. Also calculate the operational cost around the license: environment setup, failed runs, review load, model usage, and the engineer time spent maintaining instructions. Price per seat is rarely the deciding number.

One operating model can use all three categories

A small AI-augmented engineering team can use builders, IDE agents, and task agents together, provided one delivery system governs all of them. Builders explore new product surfaces. IDE agents handle changes that require live judgment. Task agents take bounded maintenance and implementation work. Every durable change eventually enters an owned repository, passes the same checks, receives risk-based review, and moves through a controlled release.

This model changes engineering roles more than it changes job titles. Senior engineers spend less time typing routine code and more time writing acceptance contracts, improving test signals, reducing architectural ambiguity, and reviewing high-consequence changes. Founders must stop measuring output by commits or generated screens. The useful measures are lead time to a verified change, escaped defects, review load, recovery time, and operating cost.

Do not begin by buying one tool for every developer. Inventory the work first: greenfield experiments, product changes, maintenance queues, incident fixes, infrastructure, and regulated surfaces. Assign an autonomy ceiling to each class. Then test one tool in each mode against the same production boundary.

This is where an experienced fractional CTO can save expensive trial and error. A Team & AI Audit should identify which work can move to agents, which controls are missing, and whether the payroll claim survives contact with the actual repository and release process. The tool is the easy purchase. The operating model decides whether a ten-person queue becomes work for one or two well-equipped engineers, or merely becomes a faster queue of unreviewed changes.

Keep the categories flexible and the boundary firm. Let a builder run far on disposable work. Let an IDE agent move quickly inside a developer's branch. Let a task agent return a complete pull request. Production should still demand owned source, executable evidence, a review proportional to failure cost, and a recovery path that someone has actually tested.