Keep Agents Moving

Coding agents often fail in a familiar way: they start well, then stall. The first pass looks promising, but the task drifts into repeated edits, shallow fixes, or a loop of “almost there.” The useful move is not to restart from scratch every time. It is to give the agent a tighter operating frame and a clearer recovery path.

A source signal behind this article points to a simple idea: when a coding agent is not working, the prompt should not just ask for a better answer. It should ask the agent to keep going for hours, while making progress visible and failures legible. That is the part teams can reuse across tools.

What usually breaks

Long agent runs fail for a few predictable reasons. The task is too broad. The agent has no stable definition of done. Verification is weak or expensive. The environment changes under it. Or the prompt encourages one-shot completion when the work actually needs iteration.

In practice, the failure mode is rarely “the model is bad.” It is more often a mismatch between task shape and control shape. A coding agent can be competent at local edits and still be poor at sustained work if it cannot recover from uncertainty.

The prompt pattern that helps

The most useful prompt pattern is simple: tell the agent to continue until the task is genuinely resolved, but require it to surface blockers, test results, and next steps at each turn.

A workable version looks like this:

State the goal in one sentence.
Define what counts as success.
Require the agent to inspect the current state before editing.
Ask it to make the smallest useful change.
Require verification after each change.
Tell it to stop and explain when it cannot make progress.

That sounds basic, but it changes behavior. The agent stops optimizing for a single polished answer and starts optimizing for forward motion with checks.

For example, if a tool keeps failing on a flaky test, the prompt should not just say “fix the test.” It should say: identify the failure mode, make one change, rerun the relevant check, and report whether the failure moved. That keeps the loop grounded.

A practical recovery loop

When an agent gets stuck, use a recovery loop instead of a fresh prompt every time.

Ask it to summarize the current state in plain language.
Ask what it tried and what changed.
Ask for the smallest next experiment.
Require a concrete verification step.
If the experiment fails, ask for a new hypothesis.

This works because it forces the agent to maintain continuity. Without that continuity, long tasks degrade into repeated guesses.

The loop also helps humans review the work. You can see whether the agent is learning from the environment or just rephrasing the same plan.

Where this pattern fits best

This approach is strongest when the task has a real feedback signal: tests, builds, linting, type checks, or a reproducible manual check. It is weaker when the task is mostly open-ended design judgment or when verification is slow and ambiguous.

It also works better in repositories with stable structure. If the codebase is highly dynamic, or if the agent has limited visibility into the relevant files, the loop can still stall. In that case, the fix is often not a better prompt but a narrower task boundary.

Tradeoffs and limits

The main tradeoff is speed versus control. A tighter loop adds overhead. The agent spends more time reporting state and checking work. That is worth it when the task is expensive to get wrong, but not for trivial edits.

Another limit: long-running agents can become overconfident in local evidence. If the verification step is weak, they may keep iterating on the wrong hypothesis. So the loop only helps if the checks are meaningful.

There is also a human cost. Teams can overuse “keep going” prompts and turn the agent into a substitute for planning. That usually produces more churn, not more throughput. The prompt should support a task that is already well framed, not rescue a vague one.

What teams should standardize

If your team uses agentic coding tools regularly, standardize the parts that make long runs recoverable:

a short task brief
a required success condition
a preferred verification command or check
a rule for reporting blockers
a convention for summarizing what changed

These are small process choices, but they matter more than model choice in many day-to-day tasks.

This is also where our methodology matters: in the Build step, the goal is not just to produce code, but to produce code that can be checked, explained, and resumed.

Bottom line

If a coding agent keeps failing, do not only ask for a better answer. Ask for a better loop. Make the task smaller, the checks clearer, and the recovery path explicit. That is usually enough to turn a short burst of useful work into a longer run that still holds up.