Short answers to what readers ask most about this topic.
Why an open-ended daily brief produces zero commits, and the numbered procedure — first commit by turn six, land by turn thirty — that produced merged PRs.
Matthews Wong
Software Engineer
Key Takeaway
An unattended agent given an open-ended task explores until it runs out of turns and commits nothing. Replacing the brief with a numbered procedure — one small item, first commit within six turns, push early, stop committing by turn thirty, never end with zero commits — turned floundering runs into merged pull requests.
My daily coding agent spent two consecutive nights doing this: create a branch, read files for thirty-five turns, and stop. No commits, no pull request, no error. The model was working exactly as instructed, and the instruction was the problem.
What follows is the difference between a brief that sounds reasonable to a human and a procedure that a weaker model can actually execute unattended. It is the single highest-leverage thing I changed in the whole project.
Pick the top item from the backlog and implement it is a perfectly good instruction for a person. For an unattended agent on a limited budget it has three fatal properties.
The most expensive version of this I saw was a run that spent eighty turns and several million tokens grinding on one genuinely hard task — a database integration test — and produced a single unpushed commit. Nothing crashed. It simply chose a task it could not finish and worked on it until the budget was gone.
The rewrite turned a goal into a numbered sequence with explicit budgets and an escape hatch. Every clause exists because its absence caused a specific failure.
# The prompt that produced zero commits, twice:
"Pick the top item from BACKLOG.md and implement it."
# The prompt that produced a merged pull request:
"1. Check main is green before starting.
2. Create a branch named chore/refine-<date>.
3. Choose ONE small, self-contained improvement: a single test, one
type tightened, one doc fix. NO new dependencies. NO refactors.
4. Land your FIRST commit within 6 turns. Stop reading and start editing.
5. Push after the first commit and every ~3 commits after that.
6. By turn 30 STOP committing and open the pull request.
ESCAPE HATCH: a run that ends with zero commits is a failure. If you
are stuck, commit whatever compiles, push, and open the PR anyway."Two clauses do most of the work. Land your first commit within six turns kills the exploration spiral, because it converts reading from the default activity into something the agent must budget. And the escape hatch — a run ending with zero commits is a failure — removes the option that the model kept choosing when it felt uncertain.
Write the budget in turns, not in words like quickly or briefly. A turn is something the agent can count; quickly is something it can rationalise. Every soft instruction in my prompts eventually got replaced with a number.
Prompt content is only half the question. The other half is which surface carries it, and they do not have equal authority in practice.
| Surface | What it is good for | What I learned the hard way |
|---|---|---|
| The one-shot run prompt | Today's specific task and its constraints | It does not reliably override a persistent instruction file; the agent will follow the file and its own judgement instead |
| The persistent instruction file | Standards, discipline, the definition of done | This is the real control surface. Quality habits belong here, not in a daily prompt |
| A curated backlog file | Choosing what gets worked on next | Curating the top item is how you steer, because the instruction file points at it |
| A skill or runbook | The repeatable procedure itself | Keeps the same sequence across every run without repeating it in each prompt |
I found this out by briefing a specific feature and getting something else entirely: the agent noticed the pipeline was red and fixed that instead. It was the right call, and it happened because the persistent file told it to check the pipeline first. The lesson is that steering happens through the durable surfaces, not through today's message.
Contradictions between surfaces are worse than either instruction alone. A daily prompt saying do one tiny thing and stop, against an instruction file saying work through the backlog, produced the lowest output of any configuration I ran — the agent split the difference and did almost nothing.
The failure that replaced floundering was subtler and more annoying: a run that produced eleven good commits, used every available turn doing so, and never opened the pull request. The work existed and was unreachable.
Two rules fixed it. Push after the first commit and every few commits after that, so work reaches the remote even if the run dies mid-way. And set an explicit landing deadline several turns before the hard limit, at which point the agent stops adding commits regardless of how much is left on its list. A guaranteed merge of six commits beats eleven stranded ones, and that trade is worth stating in the prompt in exactly those words.
Prompt structure only helps if the task is the right size. Four categories reliably fit inside one unattended run.
What does not fit: new features, anything needing a new dependency, and anything touching more than a handful of files. Those are for a supervised session where a human can course-correct in the moment.
Before leaving a schedule unattended, verify these — I have been burned on each one.
That first one is worth repeating: monitoring you wrote yourself, in a hurry, to watch an agent is exactly the code least likely to be tested, and a false success report is more damaging than no report at all.
The gap between an agent that flounders and one that ships is not model quality, it is procedure. Give it one small item, a turn number by which the first commit must exist, a push habit, a landing deadline, and an explicit rule that zero commits is a failure — and a modest model becomes a reliable daily contributor.
