Seventeen working days. That is how much time the average engineer now loses every year fixing code that AI wrote for them — reviewing it, unpicking it, patching the plausible-but-wrong parts, and occasionally rewriting it entirely. More than three full working weeks, spent as a cleanup crew for a tool that was supposed to save time.

The number lands at an awkward moment. Spending on AI tools per engineer has soared across the industry, and the returns are wildly uneven — one survey of twenty-seven companies found delivery gains ranging from nothing at all to threefold. Same tools. Same era. Completely different outcomes.

The gap between the teams saving time and the teams losing seventeen days is not the model they bought. It is the instructions they wrote and the review they applied. The rework tax is real — and it is optional.

Where the Seventeen Days Actually Go

AI-generated work fails in a specific way: it fails confidently. The code compiles. The paragraph reads fluently. The analysis is formatted beautifully. The errors are not typos — they are plausible mistakes, the kind that only surface when someone who knows the context reads carefully. Someone has to read carefully. That someone is you, and it takes time.

The waste concentrates in three places. First, plausible-but-wrong output: the function that works except for the edge case, the summary that cites a number slightly off. Second, missing context: the AI didn't know your conventions, your constraints, your history — and guessed confidently instead of asking. Third, unreviewed merges: output that skipped the check entirely and is now someone else's problem downstream.

Notice what is not on that list: bad AI. The teams losing seventeen days and the teams gaining triple the output are often using identical tools. One team accepts what the machine produces. The other team specifies precisely what it wants and reviews by risk. The seventeen days is not a technology cost. It is a specification-and-review cost that some teams pay and others designed out.

What Precision Looks Like: Before and After

The difference between a rework-generating instruction and a rework-proof one is visible in a single example. Take a routine task — asking AI to draft a weekly project update for stakeholders.

The vague version: "Write a project status update." The AI produces something fluent, generic, and wrong in texture: wrong length, wrong tone, mentions milestones you didn't include, buries the risk you actually needed flagged. You spend twenty-five minutes editing it into your voice, fixing the structure, re-adding the nuance. Saved fifteen minutes, spent twenty-five. Net negative — and that is the seventeen days, accumulating one plausible draft at a time.

The precise version: "Draft a 150-word status update for the client steering committee. Tone: direct, no cheerleading. Structure: one line per workstream, then one line each for blockers and next milestone. Known facts: [paste three bullets]. Flag the API delay as a risk but not a blocker. Do not mention the internal reorg." The first draft is ninety percent there. You spend five minutes on the last ten percent. That is the entire difference — not a better model, a better brief. (The brief-writing craft is the whole subject of our Prompt Engineering for Professionals course, and our Deep Dive in the Technical Science of Prompts takes it to the mechanics level for those who want the "why" underneath.)

Same pattern everywhere AI produces first drafts. "Summarise this report" produces a summary of the wrong things for the wrong audience. "Summarise sections 2–4 for a CFO who only cares about cost overrun risk, in three bullets, flag anything over 10% variance" produces something you can forward. Precision is not pedantry. It is the mechanism that decides whether the tool costs you time or saves it.

The Review Rubric: Proportional, Not Equal

The second half of the rework tax lives in review — and the fix is a rubric, not more effort. Sort every piece of AI output into one of three tiers before you look at it, and review each tier differently.

Tier one — reversible and low-stakes. Internal notes, throwaway scripts, first drafts you'll reshape anyway. Skim it. If it's directionally right, move on. The mistake here is over-reviewing: careful proofreading of work that doesn't warrant it is how the seventeen days accumulate on the other side.

Tier two — visible but correctable. Team-facing documents, routine code merges, client emails in established relationships. Check the specific failure modes: the numbers, the names, the claims that would embarrass you if wrong. A targeted check, not a line-by-line read.

Tier three — hard to undo. Anything published, anything touching money, anything a decision depends on, anything leaving the building under your name. This gets the full human treatment — and this is where the discipline pays for itself. One prominent AI lab cut its reverted-change rate by over forty percent doing exactly this: review effort assigned by risk level, humans reserved for what is hard to undo. They did not get a smarter model. They got a sharper process.

Do the Rework Math on Your Own Workflow

The economics of any AI-assisted task reduce to one equation: instruction time plus review time versus doing it yourself. Most people never run the numbers, which is how they end up in workflows that lose money on every transaction.

Take the weekly-report example. Doing it manually: ninety minutes. Vague prompt plus heavy edit: three minutes instructing, twenty-five repairing — sixty-two minutes saved, but only once, because next week the vague prompt produces the same repairs. Precise prompt plus tiered review: eight minutes instructing the first time (write it well once, reuse it), four minutes checking the flagged figures — seventy-eight minutes saved, every week. Over a year, the precise version banks roughly sixty hours against the vague version's fifty — and the vague version's output is worse. The gap widens because precision is reusable: a good instruction is an asset, while a vague one is a recurring expense.

Run that audit on your three most AI-assisted tasks this week. Time the instruction. Time the review. If the total isn't clearly beating manual, the tool isn't the problem — the spec is. That is the entire diagnosis, and it takes an afternoon to run.

This Is Now a Core Work Skill

It would be a mistake to file this under "engineering problems." The same rework pattern shows up wherever AI produces first drafts: reports that need re-fact-checking, emails that need re-toning, analyses that need re-doing. Anywhere a machine produces fluent output and a human signs off, the same equation applies — the cost of your instruction plus the cost of your review is either less than doing it yourself, or it isn't.

Which means "working well with AI" has quietly split into two distinct, learnable skills. Writing instructions precise enough that the output is right the first time. And building a review habit proportional to risk, so attention lands where errors are expensive. Neither is taught in school. Both are becoming the difference between the person AI makes faster and the person AI makes busier.

The compounding part is worth one more beat. Precision instruction scales: the well-written brief you build this month becomes the template for next month's — an asset that appreciates. Proportional review scales too: the rubric you internalise once applies to every tool you'll ever use, including the ones that haven't shipped yet. This is why the rework gap will keep widening between people who learned the discipline and people who just got faster at fixing. Both are "using AI." Only one is accumulating skill.

The common objection deserves an answer too: "writing a detailed spec takes as long as doing it myself." Sometimes true — once. But the spec is written once and reused fifty times, while the repairs repeat forever. The calculation only looks unfavourable if you measure the first run instead of the fiftieth. Vague instructions are always faster to type; the bill just arrives later, itemised in seventeen-day chunks.

The team-level version of this math is where it gets uncomfortable for managers. Multiply the vague-prompt tax across a team of ten and the "productivity tool" is quietly costing the department a headcount's worth of cleanup every year — invisible because it arrives in twenty-minute increments rather than a line item. The fix isn't a memo about careful AI use; it's a shared instruction standard. The teams publishing their prompt patterns internally — the way they publish code style guides — are the ones whose rework numbers actually fall.

Start the clock this week. Pick your single most rework-prone AI task — the one where the output always needs "a quick pass" that isn't quick. Rewrite its instruction using the precise version's parts: audience, format, length, constraints, what done looks like, what to exclude. Time the next run and the cleanup honestly. Most people recover thirty minutes on the first try — the seventeen days start coming back the same way they left: one task at a time.

The first of those skills — precision instruction — is exactly what our 7-day email course Prompt Engineering for Professionals teaches: how to specify work so the first output needs no cleanup, with frameworks for context, constraints, and quality checks that transfer across every AI tool you'll use. If the rework loop sounds familiar, that is the course that breaks it. And for the broader picture of what companies actually want from AI-fluent staff, see our piece on the question behind every AI automation search. And once the instructions are precise, our AI Automation course puts them on rails — pipelines that run without you in the loop.