How one-shot engineering works

One-shot engineering moves a bounded software task from a clear request through implementation and configured checks with one deliberate human handoff. Your team decides what should be done and where judgment is required. The software factory coordinates the repeatable work in between.

It does not mean giving a model one prompt and trusting whatever comes back. The “one shot” belongs to the engineering process, not to a single agent response.

The factory owns the process. Agents perform the work inside it.

What changes with one-shot engineering

Coding agents are already good at inspecting repositories, editing files and running commands. The harder problem is everything around the code: deciding which work is safe to delegate, enforcing the same rules on every run, responding to failed checks and knowing when a person should step in.

One-shot engineering moves that coordination into a defined workflow.

One clear inputA scoped issue with enough context to act on.

One governed pathKnown stages, tools, checks and approval points.

One visible resultA pull request with its execution history and evidence.

Human judgment when neededThe workflow pauses instead of guessing.

The important shift is the unit of automation. A coding assistant automates an action. A software factory automates the path from intent to a result your team can review.

People review decisions and results. The factory carries work between those points.

Start with work that can be checked

Not every backlog item should be sent to an agent. One-shot engineering begins by separating work with a bounded scope and observable success condition from unresolved judgment.

A strong candidate usually has:

• A focused outcome
• Enough repository and issue context
• A small or clearly bounded surface area
• Tests, checks or review criteria that can confirm the result
• A safe point where a person can inspect the change before merge

Strong starting point	Keep with the team for now
A reproducible bug with an expected result	A problem that still needs investigation or product direction
A narrow maintenance task	A broad architecture change
A failing test with a known contract	A behavior change with unclear acceptance criteria
A small interface or accessibility fix	A subjective redesign

Confidence is not a promise that an agent will succeed. It is a decision about whether the task has enough structure for the factory to attempt it safely. If the scope is unclear SuperPlane can keep the task in Backlog and ask for more context.

The one-shot path

1. Discover and understand the work

Work begins in the tools your team already uses. A GitHub issue or another connected source enters the factory Backlog. SuperPlane examines the issue, repository context and available checks before deciding whether the task is ready for an agent.

This first step matters because an unsuitable task does not become safer simply because the model is capable. The factory should know what success looks like before implementation begins.

2. Put the rules in the workflow

The workflow defines the allowed path before an agent starts. It can specify the repository, branch behavior, available tools, required checks, review policy, approval points and escalation rules.

The workflow owns the rules.The agent works inside them.

This keeps the process consistent when the model changes, when another person starts the task or when the same pattern is used in a different repository.

An automation makes the execution path explicit instead of hiding it inside one long prompt.

3. Let the agent implement the change

In Implement the configured agent receives the task, inspects the relevant code and makes the change. A typical run can clone the repository, edit the required files, run local checks, commit the result and prepare a pull request.

The agent is responsible for the engineering work. SuperPlane is responsible for carrying inputs and outputs between stages, recording what happened and deciding what runs next.

4. Verify and recover

A pull request is an output, not proof that the task is complete. The Verify stage checks the result against the rules defined by the factory. Verification can include tests, continuous integration status, deterministic validation, pull request feedback and human approval.

Verification keeps the result and the remaining decision visible before the task reaches Done.

Failure is part of the workflow. If a test fails SuperPlane preserves the error and the execution context, then returns actionable feedback to the next attempt. The agent does not need a person to copy logs from one tool into another. If the workflow cannot resolve the problem safely it stops and asks for attention.

A failed check can return to implementation. An ambiguous decision returns to a person.

5. Hand back a reviewable result

The end of a one-shot run is not “the agent finished.” It is a result that a reviewer can understand and evaluate.

The completed task should make it clear:

• Which issue started the work
• What changed
• Which checks ran
• Whether any failure required another attempt
• What pull request contains the result
• Which decision still belongs to a person

That evidence is what turns generated code into engineering work that can move through a team’s normal review process.

Humans stay responsible for judgment

One-shot engineering reduces manual coordination between defined workflow steps. It does not remove ownership.

People still choose priorities, clarify ambiguous work, approve sensitive changes and decide whether a pull request should merge. A well designed factory makes those moments explicit. It does not ask a person to watch every command and it does not let an agent quietly make decisions outside its boundary.

Human involvement is most valuable at decisions, not at every mechanical handoff.

What to measure

The goal is not to maximize the number of tasks sent to agents. It is to increase the number of bounded tasks that pass the team’s configured checks without creating more cleanup for engineers.

Useful signals include:

• The share of backlog tasks that have enough confidence to start
• The share of factory pull requests that are ready for approval
• How often a person must intervene before the configured checks finish
• How often verification catches and repairs a failure
• The time from issue selection to a reviewed pull request

These measures reveal where the factory needs better task context, stronger checks or a clearer approval boundary. They also discourage a common failure mode: counting generated pull requests without asking whether those pull requests were useful.

The practical definition

A task has been one-shot when it moves from a clear request to a verified and reviewable result without a person coordinating every intermediate step.

That outcome depends on three things working together:

1. A suitable task: The scope and expected result are clear.
2. A governed workflow: Tools, checks and decision points are defined before execution.
3. A recoverable process: Failures keep their context and either retry safely or reach a person.

The model matters, but it is only one worker in the system. The factory is what makes the result repeatable.

Next steps

Choose suitable workLearn how tasks enter the factory and how confidence guides execution.Understand the factory pipelineSee how stages and automations move work toward a verified result.Build your first FactoryConnect a repository and apply the model to a real task.Explore use casesSee one-shot engineering applied to focused issues and small improvements.