Skip to main content

Command Palette

Search for a command to run...

When Your Agent Gives Up, It Leaves Behind Five Half-Finished Attempts

The working tree after a failed agent loop is its own archaeological dig — five stashes, three branches, a commit message that says 'wip', and no record of which attempt actually worked.

Updated
•4 min read•View as Markdown

You finish a long coding session with an agent. It said 'I'm stuck' on the last try, and you closed the laptop. Next morning, you run git status and there are three modified files, two stashes you don't remember making, a branch called auth-fix-attempt-3, and a commit from yesterday that just says wip.

You have no idea which attempt actually worked. You have even less idea which one broke something else.

This is the hidden cost of agentic coding: the sessions that succeed leave clean diffs. The sessions that fail leave archaeology.

The loop nobody talks about

An agent loop looks like this: attempt one fails tests, it tries a different approach, that fails, it refactors the first approach, that introduces a new bug, it tries a third angle, the context window fills up, it summarizes what it's done, you give it more context, it tries a fourth approach, and after thirty minutes it says I wasn't able to resolve this — you may want to try a different approach.

That last sentence is not the end of the work. It's the end of the agent's patience. The actual state of your repo is: four partially-completed changes, none of which was ever reverted cleanly.

Why this gets worse before it gets better

Every agent tool encourages you to let it run. That's the value prop — you describe what you want, it goes off and does it. But the tooling is optimized for the success path: clean diff, green tests, mergeable PR. Nobody has built the equivalent of a 'rollback to last known good state' button for the working tree.

When an agent gives up, it doesn't undo its work. It just stops. The files it touched stay touched. The stashes it created stay stashed. The branches it branched off stay branched. Your local repo becomes a record of every approach the agent tried, not a record of the approach that worked.

What actually helps

A few habits, none of which require a new tool:

Start from a clean tree every time. Before you kick off an agent task, make sure everything is committed or stashed. Don't let an agent build on top of uncommitted changes from a previous session. You'll never disentangle them.

Tell the agent to work on a branch. Not a feature branch — a throwaway one. At the end of the session, you either merge it or delete it. No in-between.

Ask for a summary of what it actually changed. Not 'here's what I did' — ask for the exact list of files modified and the exact test command that failed last. If you come back tomorrow, you need a starting point.

Set a time limit. An agent that has been trying the same problem for twenty minutes without a new idea is not about to suddenly find it. Stop the loop, revert, and re-read the problem yourself. The next human insight will be faster than the next agent attempt.

The tooling gap

The thing I keep waiting for is a tool that shows me the net state of my repo after an agent session: what changed, what still compiles, what tests pass, and what's left over from abandoned attempts. Right now, that's a git diff and a prayer.

We built Powerduck around a similar problem on the API side — when you're verifying that an agent's changes match the spec, you need to see exactly what drifted, not just trust that the agent said it was done. The same principle applies to working trees: the agent's 'I'm stuck' message is not a status report. It's a request for you to go dig through the mess it left behind.

Next time an agent gives up, don't close the laptop. Open git status first.

More from this blog

P

Powerduck Blogs

142 posts

Essays on local-first API tooling, OpenAPI contracts, MCP, and agentic coding failures. We build Powerduck, a local-first OpenAPI studio where the spec stays the source of truth. Topics: AI code review trust, testing AI-generated code, context engineering, and what actually breaks when AI writes your code.