Vibe Engineering Without Losing Control

Vibe engineering is a useful name for working at the speed of an agent: describe an outcome, let the tool explore and edit, then steer it with feedback. Simon Willison’s writing on agentic engineering makes the important accountability point: the person who deploys the result still owns the consequences. More generated code increases the value of tests, review, and an inspectable trail; it does not remove them.

For payments-api, the contract is more precise than “make payments safer”: accept Idempotency-Key, persist the first successful result by key, return the same result for a retry, and reject a reused key with a different request body. That contract gives the agent room to choose an implementation while giving the reviewer something falsifiable to check. The goal is a short feedback loop with a hard definition of done.

A CLAUDE.md file is an always-on project instruction surface: it can tell an agent how to run tests, which directories are generated, what the API conventions are, and when it must stop for approval. Keep it operational and versioned. A rule such as “run npm test before reporting success” is stronger than a style wish because it names a checkable action.

Permission flags change who approves tool calls; they do not make an agent correct. --dangerously-skip-permissions (often called YOLO mode) removes interactive friction, so it belongs only inside a disposable, least-privileged environment with no production credentials. A repository rule can still require a diff review and a clean test run, but it cannot undo a destructive command after the fact. Separate the speed of execution from the blast radius of execution.

Agent interfaces often offer checkpoints or rewind: a convenient way to return the workspace to an earlier state during exploration. Use them like a local scratchpad. They are useful when the agent edits the wrong files, changes direction, or needs a clean retry, but they are tied to the tool’s session and may not capture the team’s review context.

Git records the durable engineering story: named commits, branch ancestry, authorship, review comments, CI status, and the exact change that was merged. Before asking the agent to implement payments-api, create a branch and capture a clean baseline. Commit coherent milestones—contract, implementation, tests—so a reviewer can bisect or revert without reconstructing an ephemeral session.

A Ralph loop is an autonomous iterate-until-done pattern associated with Geoffrey Huntley and popularized by the Wiggum-style workflow: give the agent a task, run checks, feed the result back, and stop when the acceptance condition passes. The loop is only as good as its stop condition. “Keep improving” can run forever; “the idempotency test passes, TypeScript is clean, and the diff touches only the payments module” is finite and inspectable.

MCP—the Model Context Protocol—connects an agent to external tools and resources such as issue trackers, GitHub, documentation, or a read-only database. It extends the agent’s reach, so it also extends the trust boundary. Give a Jira tool permission to read the ticket before giving it mutation rights; give a database tool a read-only identity; log which external facts informed the patch. MCP is a contract for tool access, not a guarantee that the tool’s data is current or safe.

A skill is an on-demand instruction pack for a focused task: for example, a database-migration review that explains the checks, files, and failure modes to inspect. A plugin is a shareable bundle that can distribute several skills, commands, hooks, agents, or MCP connections. Start with a small plugin when multiple repositories need the same workflow; keep project-specific policy in the repository so it remains visible beside the code.

The official feature-dev plugin illustrates the pattern with a seven-phase workflow: discovery, codebase exploration, clarification, architecture, implementation, review, and summary. That sequence is useful because it puts uncertainty before editing and review after editing. It is not a substitute for a team’s approval policy: a plugin can suggest a process, while the repository and CI enforce the acceptance boundary.

A ticket-to-PR workflow is where the pieces meet. Jira provides the request and acceptance criteria; the agent reads the repository rules, explores the code, and proposes a plan; MCP can fetch the ticket or post status; skills can run the project’s review routine; Git records the implementation; CI and a human reviewer decide whether the change is acceptable. The important boundary is that “agent finished” and “PR approved” are different states.

For the payments-api example, the intentional failure is a retry with the same idempotency key but a different amount. The service should reject it, the test should demonstrate that rejection, and the PR should show the test. If the loop reports success without that case, the failure is not an agent personality problem—it is an incomplete acceptance contract. Fix the contract or the evaluator, then rerun from a clean checkpoint.

Create a disposable branch in a small repository and ask your agent to implement the payments-api contract. Give it a short CLAUDE.md with the test command and forbidden paths. Start without YOLO permissions. If you use MCP, connect only a read-only issue or documentation tool. The starter prompt should name the exact endpoint, expected retry behavior, intentional mismatched-body failure, and the command that proves success.

After the agent proposes a plan, create a checkpoint and a Git commit before implementation. Let the loop run for at most three iterations. Then inspect the diff yourself. Deliberately break the idempotency test or remove the acceptance criterion from the prompt. The expected symptom is either a failing check or an incomplete PR description; recovery means restoring the contract, rerunning the checks, and recording the evidence.