Coding Changes That Survive Review

We ran 24 AI-generated changes against the same frozen repository. The rough and revised prompts both passed every required command in 12 of 12 runs. The revised prompts still produced the better outcome: all 12 stayed focused on the requested task, while only 6 rough-prompt runs did under our post-run review.

The best vibe-coding prompt did not make the tests greener. It made the successful change smaller.

That distinction matters once generated code reaches a real reviewer. A passing patch can still add an export nobody requested, change behavior outside the ticket, and make rollback harder. The prompt should help the coding agent deliver the requested result without turning one task into three.

The passing patches hid a scope problem

We built a dependency-free activity-feed repository with four ordinary jobs:

Each task started from a fresh copy. The model received the full repository snapshot, task-specific acceptance test, allowed paths, and a strict response format. An external harness applied complete file replacements, rejected unsafe primitives, and ran the acceptance command plus npm test, npm run lint, and npm run build.

We used the openai/gpt-5.6-luna route for three rough and three revised runs per task. OpenRouter returned Azure as the provider for all 24 completions. The provider did not return a model-version identifier, so the result belongs to this captured route and date rather than every future model carrying the same name.

All 96 command executions passed.

The automated result was a tie. We then inspected whether each patch stayed on the task. That review was performed after the run and was not blinded, so it is editorial judgment rather than a preregistered metric.

The rough feature runs implemented the requested filter, then also exported a severity-ranking function and changed the existing summary path to use it. The rough refactor runs performed the requested extraction, then added a new filtering feature. Every extra change happened to pass the visible suite.

Correct code is not free code. Each unrequested export creates another interface to maintain. Each behavior change gives the reviewer another path to trace. The patch can pass and still be worse to merge.

The repository did most of the prompting

This was not a clean contest between a six-word request and a fully specified instruction. Both variants received the repository, the allowed paths, the tests, and the output schema. Those shared inputs explain why even the rough prompts passed every check.

That is a useful result.

Repository instructions, visible tests, and a narrow patch contract can rescue a terse request. Teams building coding-agent workflows should invest in that environment before collecting clever prompt phrases. A maintained AGENTS.md, fast local checks, explicit acceptance tests, and a small permission boundary keep working across tasks.

The revised instruction added a second layer. It named the exact behavior, restated the scope, prohibited adjacent cleanup, and defined when the agent could claim completion. That layer did not repair a failing build in this run. It kept two ambiguous jobs from expanding.

The prompt and the repository are one control system:

No role incantation is required. “Act as a senior engineer” says nothing about which behavior must remain stable or which command decides whether the work is complete.

The prompt contract that narrowed the change

The rough feature request was:

Add severity filtering to the activity feed.

The revised task instruction was:

Make one bounded change in the supplied repository.

Task
Export filterEventsBySeverity(events, minimumSeverity). Return events at or
above low, medium, or high while preserving input order and without mutating
the input array.

Repository procedure
1. Read the repository README and inspect the relevant implementation and tests.
2. Keep the diff inside:
   - src/activity.mjs
   - test/activity.test.mjs
3. Do not edit package.json, scripts, acceptance checks, or unrelated files.
4. Do not add dependencies.
5. Run the task acceptance command.
6. Run npm test, npm run lint, and npm run build.
7. Repair only the smallest task-related cause if a check fails.

Return a short summary, files changed, command results, and any remaining
human-review question. Do not claim completion unless every check passes and
the changed files stay inside the allowed list.

The extra words earn their place by closing decisions. “At or above” defines the filter. Preserving order and avoiding mutation protect existing behavior. The file list and prohibition on unrelated edits define the review surface. The commands define the receipt.

The AI Prompt Optimizer can turn an existing coding request into that sort of contract and show every addition as a diff. No tool can read your repository for you, though — replace its placeholder paths, commands, and invariants with real ones before handing the result to an agent.

The complete 24-run artifact and frozen task fixtures are downloadable without a form. They include the exact prompts, outputs, diffs, command logs, token usage, cost, safety settings, and retained failures. There were no provider failures or repair turns in this run.

When a shorter request is enough

The pagination and test-addition tasks stayed focused under both variants. Their allowed file lists were narrow, and the requested behaviors pointed to small, obvious edits. Turning either task into a page of procedure would add reading cost without changing the outcome we observed.

Start with the smallest prompt that makes success testable. Add structure where ambiguity remains:

1. Name the observable behavior.
2. Provide the files or evidence the agent needs.
3. Mark facts and behavior that must not change.
4. State the commands that must pass.
5. Set the boundary against unrelated cleanup.
6. Require a completion receipt.

The prompt optimization loop is useful here because it treats every addition as a hypothesis. If an agent consistently stays focused with the repository controls alone, remove redundant prose. If it keeps widening refactors, strengthen the task boundary and rerun the same case.

Model choice still matters. A cheaper route may be sufficient for bounded edits, while a harder migration may justify a stronger model. Compare current API prices, but measure cost per accepted change rather than cost per token. The cheapest completion can become expensive when its diff takes twice as long to review.

Where this result stops

This was one small synthetic repository, one model route, four tasks, and three repetitions per variant. The acceptance tests were visible. The model proposed full-file replacements instead of operating an autonomous shell. We did not test a large monorepo, hidden integration failures, merge conflicts, or long-running agent sessions.

The 6/12 versus 12/12 scope result is the editorial judgment described above; it should guide a follow-up test, not support a universal reliability claim. A stronger study would preregister the scope rubric, blind the reviewer, add more repositories and models, and measure changed lines plus review time.

The result still changes the immediate decision. Do not judge a vibe-coding prompt only by whether its patch passes. Judge whether it produces the smallest change that satisfies the task and leaves a receipt a reviewer can verify.