Why AI-Built Work Comes Back for Rework, and How to Cut It

If your AI coding agent keeps coming back with fixes, or redoes things it already called finished, that is common and usually explainable. Rework with AI agents mostly comes from missing information, no way for the agent to check its own work, and requests that change halfway through. You can reduce all three without writing any code.

This guide explains where rework comes from, which kinds are cheap and which are costly, and what you can do about each.

What does "rework" mean with an AI coding agent?

Rework is any work done a second time. The agent builds a feature, someone finds a problem, and the agent goes back to fix it. Or a test fails after the work was called finished. Or you look at the result and say, "That is not what I meant."

Human teams have rework too. The difference is that an AI agent redoes work quickly, so it can feel free. It is not. Every second pass takes time, and it also uses part of your plan's usage allowance or, on a pay-as-you-go setup, your money.

Some rework is healthy. A reviewer catching a real flaw before release is the system working. The goal is not zero rework. The goal is to stop paying twice for problems you could have prevented.

Why does the agent get it wrong in the first place?

Claude Code's best-practices documentation says that when a session does not go the way you expected, it is almost always because Claude built something different from what you had in mind, or because it is missing information it cannot get from reading the project. Think of a very capable new contractor on day one. They can read everything in the building, but they cannot read your mind.

Cause 1: facts that live only in your head

The agent can read your project files. It cannot see a deal you made with a customer last week, a rule your legal team insists on, or the fact that "active user" means something specific at your company. The same documentation lists examples of things no default setting can know: a deploy process that lives in someone's head, a file that must never be read, a check that has to pass before anything counts as done, a budget you need to stay under.

If you do not say it, the agent guesses. A guess that turns out wrong becomes rework.

Cause 2: vague wishes

"Make the signup page better" can mean twenty different things. The agent picks one. You wanted another. Both of you did your job, and the work is still wasted.

A good brief names the result you want, who it is for, and what must not change. If you can describe how you would test it ("a new visitor can sign up in under a minute, and the welcome email arrives"), the agent can aim at it.

Cause 3: the agent has no way to check itself

Anthropic describes Claude Code as working in a loop of three phases: it gathers context, takes action, and verifies the result. Verification is the step that catches mistakes early. It might run the project's tests, read the output, or compare the result with what you asked for.

The best-practices page says the same thing from the other side: give the agent a check to run. It lists a test file, a build that must succeed, a script that compares output with an expected result, or a screenshot compared against a design mockup. If there are no tests and no clear definition of "correct", the agent can only say, "It looks right to me." Then you or a reviewer find the problem later, when fixing it costs more.

Cause 4: long sessions and forgotten instructions

An agent holds the conversation in a limited working space, called the context window. As it fills up, Claude Code shrinks the conversation into a summary. The documentation says that summary keeps your requests and key code, but detailed instructions from early in the conversation may be lost. So a rule you gave at the start of a long session can quietly vanish.

The fix the documentation gives is to put rules that must always apply in a file called CLAUDE.md, which Claude Code reads at the start of every session, instead of relying on the chat.

Cause 5: you changed your mind

This is the costly one, and it is not the agent's fault. If a screen is designed, built and tested, and you then say "actually, we need approvals before it is submitted", parts of finished work must be redone, along with their tests. Nobody did anything wrong. The decision simply arrived late.

Which rework is cheap, and which is expensive?

A rough guide:

• Cheap: a typo, a wording choice or a colour, caught while the work is still open.
• Moderate: a bug found by a test or a reviewer before release. The agent still has the context and the fix is local.
• Expensive: a misunderstanding found after several pieces were built on top of it, or a changed requirement after design, building and testing are done.
• Very expensive: a problem found by customers after release. Some actions cannot be undone by the agent at all. Claude Code can rewind its file edits, but its documentation says that actions affecting remote systems such as databases, APIs and deployments cannot be undone that way.

The pattern is simple: the later a problem is found, the more it costs. Most of the habits below move discovery earlier.

How do I reduce rework?

Settle the open questions before building

Spend ten minutes listing what is undecided: who can see this, what happens when it fails, what happens with an empty list, what it must not break. Answer what you can. For what you cannot, say so, and ask the agent to list its assumptions before it starts. Wrong assumptions are far cheaper to fix on paper than in finished work.

Describe "done" in your own words

Write two or three sentences about what you would check to accept the work. For example: "I can add a customer, edit their address, and the old address shows in the history." You do not need technical language. This gives the agent the check it needs to tell whether it has succeeded.

Ask for tests first on anything that matters

For billing, sign-in, or anything where mistakes are expensive, ask that the tests be written before the feature. A test is a small program that checks the feature works. Then "done" is not an opinion; it is a set of checks that pass.

Review in small pieces

One review of a huge batch finds many problems at once, and every fix touches work built on top. Smaller pieces mean smaller fixes. If you see the agent heading the wrong way, you can stop it. Claude Code lets you interrupt at any point and steer it without starting over, so a correction after five minutes beats a correction after five hours.

Keep the standing rules in writing

Put the rules that never change (naming, security rules, what the product must never do) into the project's instruction file so they do not depend on a long chat. A fresh session then starts with the same rules as the last one.

Notice repeats

If the same kind of problem comes back again and again, such as missing permission checks or unchecked input, add that rule to the standing instructions instead of fixing it each time.

How can I tell whether rework is a problem on my project?

Measure it. Ask your team or your tool a few plain questions each week:

1. What share of tasks were redoing earlier work?
2. What did that cost in time and usage?
3. What were the main reasons: unclear request, failed tests, review findings, changed requirements?

A share that is steady and small is fine. A share that climbs usually points to the brief, not the tool. If most rework is "changed requirements", the fix is on your side: decide earlier. If it is "failed tests", the fix is better checks or smaller pieces.

How Atlas handles rework

Atlas is a team of AI engineers built on Claude Code. You talk to one of them, PA, your project assistant, and PA shares the work out to specialists. Several parts of that are aimed at catching problems early:

• Order of work. Building waits for an approved architecture, a signed-off design and failing tests, and a screen waits for the API it calls. Questions get settled before code is written.
• "Done" is enforced. Completion is refused until the work is on the main branch or queued to land, a screen has its test cases and screenshots, and the product's rules pass.
• Review. Every build is reviewed as it finishes. It comes back releasable, or fix tasks are filed to the engineer who built it, by name. Before a production release, everything going out is reviewed together.
• Lessons carry forward. Lessons from finished work are passed to future engineers. One is held back as a control, and lessons that track worse results or higher cost are retired automatically.
• Decisions stay with you. Atlas never drops scope, spends money or releases to production without you.

Atlas does not yet report the share of work that was redone, with its cost and causes. It also does not yet tell you, at the moment you change a request, how much finished work that change will reopen. Both are coming to Atlas, built in, so they will need no setup on your side. Until then, ask PA what a change would touch before you confirm it, and keep your own weekly tally using the three questions above. Learn more at Atlas.

Conclusion

Rework with AI agents is not a sign that the tool is broken. It shows where information was missing, where checks were weak, or where decisions came late. Tell the agent what only you know, define "done" in plain words, settle open questions before building, review in small pieces, and watch the share of redone work each week. Those habits remove most of the avoidable rework.