1. AI Is Supposed to Save Time — So Why Am I Doing the Same Work Twice?
The central promise of artificial intelligence in engineering workflows has always been leverage. We are told that large language models will automate boilerplate, eliminate tedious operational chores, and liberate senior engineers to focus on architectural strategy and complex systems design.
Over the past several months, I have integrated AI deeply across my day-to-day engineering routines—from scaffolding distributed Kubernetes manifests to automating content delivery pipelines across my personal engineering ecosystem. When an AI model delivers an accurate, verified result on the first attempt, the speedup is undeniably impressive.
But there is an unaddressed friction point that rarely makes it into keynote demos: the compounding cost of incomplete execution.
All too often, the initial response looks polished and authoritative on the surface. Yet when you inspect the output against concrete engineering specifications, essential pieces are conspicuously missing. A required component wasn't rendered. A DOM node was placed outside the layout shell. A schema block was dropped. You point out the omission, the model apologizes profusely, and it kicks off another round of generation. Then another.
Before long, you find yourself trapped in a tedious human-in-the-loop QA loop. Instead of delegating a task to an autonomous assistant, you are actively micro-managing a junior intern who repeatedly forgets the instructions you gave them ten minutes ago.
If an automated tool requires two or three manual correction cycles before it satisfies documented criteria, you have not automated the work. You have merely replaced manual coding with manual code review and prompt remediation.
The 970+ Incident Handbook & K8s Runbooks are exclusive to subscribers — unlock for FREE
Get battle-tested production runbooks, AWS architecture blueprints, and zero-downtime CI/CD post-mortems sent directly to your inbox. 100% free, no spam.
2. I Created a Publishing Skill So I Wouldn't Need to Repeat Myself
Like any platform architect who despises repeating operational steps, I decided to codify my requirements. In my publishing repository, I created a comprehensive, reusable skill definition for technical articles.
I did not want to re-type the same operational parameters every time I published a new deep dive. I wanted a single source of truth that an agent could inspect, ingest, and follow deterministically. The skill laid out the complete production contract:
- Structural Layout: An immutable 3-column layout shell wrapping a left-hand sticky Table of Contents (with active scrollspy), a center article column, and an upward-scrolling live recent ticker sidebar.
- Component Hierarchy: Strict DOM placement where the author bio card must be closed before related guides, and headings must include
scroll-margin-topto prevent fixed header overlap. - Metadata & SEO: Comprehensive OpenGraph tags, canonical URLs, and an integrated Schema.org
@graphcombiningBlogPosting,TechArticle,BreadcrumbList, andFAQPage. - Internal Topic Clustering: Contextual interlinking into high-authority hubs across my ecosystem, including the SRE & DevOps Interview Hub and the Kubernetes Mastery Path.
- Multi-Platform Syndication: Short, humorous teaser packages in
cross-publishing/tailored for LinkedIn, X/Twitter, Dev.to, Hashnode, Medium, and Daily.dev.
The requirements were clear, unambiguous, and supported by concrete reference templates. In traditional software development, providing an API contract like this guarantees consistent client implementations.
With AI, however, documenting requirements is only half the battle.
3. The Frustrating Cycle: Generate, Inspect, Correct, Repeat
The theoretical workflow looked like a clean, single-pass pipeline: pass the topic and brief to the AI, let it read the skill, and receive a production-ready artifact.
In practice, the operational reality felt like an exhausting loop of digital ping-pong:
The most frustrating aspect of this cycle is not that the requirements were complicated. The frustrating part is that I had already done the work of specifying them.
When you spend hours documenting conventions so you never have to think about them again, having to prompt the model with "Please re-read Step 4 of the skill you were already given" feels like an architectural regression. You aren't collaborating with an intelligent agent; you are doing manual error-checking for a system that dropped its instructions.
4. The AI Rework Tax: The Hidden Costs We Don't Notice
To describe this phenomenon, I started using a term in my internal architecture notes: "The AI Rework Tax."
I define the AI Rework Tax as:
The AI Rework Tax manifests across four distinct dimensions:
Compounding Token Overhead
Every conversational turn resends cumulative message history. Correcting a small omission forces complete regeneration, burning high-priced output tokens needlessly.
Context Switching Debt
Instead of delegating and moving to deep creative work, the engineer remains tethered to the terminal, reading diffs and hunting for subtle syntax regressions.
Premature Throttle Caps
Whether on pay-per-token API tiers or subscription seats with hourly message allowances, multi-turn rework depletes quotas 3x faster than expected.
Cognitive Model Drift
As a chat thread grows with multiple corrections, earlier instructions fade from attention weight, increasing the probability of new hallucinatory regressions.
5. Why Switching AI Models Didn't Consistently Solve the Problem
My first instinct was simple: switch to a larger, more capable frontier model.
Over several weeks of experimentation, I tested different model families and parameter classes across my publishing workflow. Surely, moving to top-tier reasoning engines or switching providers would eradicate basic instruction-following omissions?
The results were illuminating: switching models altered the flavor of the mistake, but it did not eliminate the rework.
- One model wrote exceptionally fluid, nuanced prose but consistently omitted structured schema blocks or altered CSS class names.
- Another model followed JSON schema formatting rigorously but hallucinated non-existent URLs or arbitrarily truncated DOM containers.
- A third model produced syntactically perfect HTML structure on pass one, but dropped half of the social syndication bundle files during the final output step.
This was a vital realization. The failure to satisfy an exhaustive skill document on the first pass is not merely a model capability benchmark issue. It is a fundamental property of how conversational large language models handle complex, multi-constraint tasks in open-ended contexts.
Believing that the "next model release" will magically eliminate the need for systematic verification is wishful thinking. Until our workflows enforce deterministic contracts, we will continue paying the rework tax regardless of which frontier model powers the API.
6. The Mathematics of Repeated AI Requests: Context Drift & Token Inflation
To understand why the rework tax becomes expensive so quickly, one must examine the underlying mechanics of modern LLM APIs.
Tokens and the Illusion of Memory
LLMs are stateless engines. They have no continuous memory between API calls. When you use a chat interface or an interactive terminal assistant, the application creates the illusion of conversation by resending the entire conversation history with every single prompt.
Furthermore, API pricing distinguishes sharply between two types of tokens:
- Input Tokens: The prompt, system instructions, and previous chat turns sent to the model. In late 2026, standard input pricing on frontier models averages $2.00 to $4.00 per million tokens.
- Output Tokens: The text or code the model generates. Output generation requires intensive autoregressive compute and is priced 3x to 5x higher than input—typically $10.00 to $20.00 per million tokens.
- Prompt Caching: Providers (including OpenAI, Anthropic, and Google Cloud) now offer cached input reads at significant discounts (often 80% to 90% cheaper for static prefixes). However, cached reads are not free, and every corrective turn still requires a full-priced output generation.
Worked Example: Single Pass vs. 3-Turn Correction Cycle
Let us examine an explicitly hypothetical, illustrative example grounded in realistic token metrics and verified market rates.
Assume an engineering publishing task where:
- The system prompt + publishing skill documentation + reference code = 15,000 input tokens.
- The generated complete blog post + components = 3,500 output tokens.
- Benchmark API rates: $3.00 / 1M input tokens, $0.30 / 1M cached input tokens (90% discount), and $15.00 / 1M output tokens.
Arithmetic Breakdown:
- Token Expansion: Total token consumption surged from 18,500 to 66,750—a +260% increase.
- API Cost Inflation: Even with prompt caching granting a 90% discount on previous input tokens, the API expenditure increased from $0.0975 to $0.2182—a +123% increase, driven by redundant high-cost output generations.
- The True Cost (Human Time): The $0.12 API difference is trivial. The catastrophe is the additional 22 minutes of senior engineering time spent context-switching, reading code diffs, verifying tags, and formulating corrective prompts.
When scaled across an engineering organization with hundreds of developers running daily agent workflows, this rework tax rapidly aggregates into thousands of wasted dollars, millions of burned tokens, and weeks of squandered human productivity.
7. Why Detailed Instructions Alone Don't Guarantee Complete Output
Why do LLMs drop requirements that are explicitly written down in clear English?
The answer lies in the fundamental architecture of the Transformer attention mechanism and how language models prioritize context.
The "Lost in the Middle" Effect
In their landmark Stanford / UC Berkeley research paper, "Lost in the Middle: How Language Models Use Long Contexts" (Liu et al., 2024), researchers demonstrated that language models exhibit a severe U-shaped performance curve when processing long inputs.
Models are exceptionally good at adhering to constraints positioned at the very beginning of the prompt (primacy bias) or the very end of the prompt (recency bias). However, performance degrades substantially when critical instructions or rules are buried in the middle of long reference documents or comprehensive skills.
When you give an AI a 150-line skill covering everything from header synchronization to author cards and footer styles, the rules situated in the midsection suffer from lower attention weight.
The Illusion of Plausibility
LLMs are trained to generate tokens that sound statistically plausible based on their pre-training distribution. They do not naturally maintain a strict boolean audit checklist of constraints.
When asked to write an article, the model's objective function prioritizes generating natural, convincing technical prose. If it produces an article that looks complete and reads well, the generation finishes successfully according to the model's internal heuristics—even if it omitted Step 4b or Step 5 from your specification.
In short: language models are optimized for semantic coherence, not contract compliance.
8. How Developers and AI Users Can Reduce Unnecessary Rework
Knowing why AI drops instructions allows us to design architectures that prevent rework instead of passively enduring it. While no method guarantees 100% compliance on every task, adopting the following engineering patterns will dramatically reduce your rework tax:
Five Operational Rules for Rework-Free AI Systems
- Convert Prose Rules into Explicit Checklists: Never assume an LLM will remember a rule embedded in a narrative paragraph. Convert requirements into a numbered, scannable checklist at the very end of your prompt (exploiting recency bias).
- Enforce File Inspection Before Code Generation: Instruct the agent to inspect the existing template, reference scripts, and neighboring implementations before generating files. Grounding the model in concrete local code reduces hallucinated DOM structures.
-
Use Deterministic Scripts for Deterministic Rules:
Do not ask an LLM to remember 35 lines of exact social media footer HTML. Use a deterministic script (like
sync-headers.pyorsync-social-footer.py) to inject exact boilerplate programmatically. Let AI write what requires creativity; let scripts enforce what requires precision. -
Automate Pre-Flight DOM & Syntax Verification:
Incorporate a programmatic validator (such as a Python DOM parser like
BeautifulSoup) that automatically scans generated artifacts for required containers, closed tags, and schema objects. If a requirement is missing, fail the build locally before presenting it to the human. - Decouple Drafting from Auditing: Separate the generation step from the verification step. Have the primary agent draft the artifact, then instruct it (or a lightweight subagent) to conduct an explicit compliance audit against the initial checklist before reporting completion.
By moving verification out of your human eyes and into automated tooling, you stop being an unpaid QA tester and restore leverage to your workflow.
9. What I Expect from a Genuinely Useful AI Assistant
As engineers, we hold our compilers, linters, and CI/CD pipelines to uncompromising standards. If a compiler silently drops a function parameter because it felt like it, we do not praise it for being fast; we file a critical bug.
We must cultivate the same professional expectations for AI agents:
- Read Before Writing: A capable agent should thoroughly examine available documentation, templates, and directory structures before producing code.
- Self-Verification as Part of the Task: Generating a draft is only 50% of the job. Checking that the draft meets every instruction in the prompt is the other 50%. A task is not done until it has been verified against the original contract.
- Deterministic Validation Over Guesswork: When automated linters, test suites, or syntax checkers exist in the repository, the agent should run them automatically rather than waiting for the human to report a syntax error.
- Respect for Context and Token Efficiency: Agents should be mindful of token consumption, avoiding unnecessary bloated chat turns and executing targeted edits rather than continuously re-emitting thousands of unchanged lines.
Treating verification as part of the agent's core delivery contract—rather than outsourcing it to the user—is the single biggest dividing line between a novelty chatbot and a genuine engineering partner.
10. Final Thoughts: AI Should Complete More Work, Not Create More Corrections
Artificial intelligence represents the most profound shift in developer tooling since the invention of the compiler. The ability to express intent in natural language and receive working software in seconds is genuinely transformative.
Yet as the initial hype gives way to real-world operational maturity, we must confront the hidden friction that slows down experienced builders. Prompting an AI model should not feel like an endless trial-and-error game of whack-a-mole.
When you take the time to build detailed skills, runbooks, and architectural guidelines, you are investing in leverage. Your AI tools must respect that investment by executing thoroughly on the first pass.
The goal of AI in platform engineering and software development is not to make us write more prompts. The goal is to finish real work, preserve our cognitive focus, and build resilient systems that stand the test of production.
Frequently Asked Questions
What is the "AI Rework Tax"?
The AI Rework Tax is the author's descriptive term for the cumulative operational drag—measured in wasted input/output tokens, API bills, human review time, and context-switching fatigue—incurred when an AI model fails to satisfy documented requirements on its initial pass, requiring repetitive cycles of prompting, inspecting, correcting, and regenerating.
Why do AI models fail to follow instructions even when provided with a detailed skill or prompt?
Large Language Models suffer from attention degradation phenomena such as "Lost in the Middle" (documented by Liu et al.), where constraints placed in the middle of long prompts experience lower retrieval and compliance rates due to primacy and recency biases. Furthermore, statistical next-token prediction prioritizes fluent, plausible-sounding syntax over exhaustive constraint auditing unless reinforced with deterministic verification gates.
How does multi-turn prompting inflate AI token consumption?
Stateless LLM API architectures require the full conversation history—including initial instructions, previous incomplete generations, and human correction prompts—to be resent with every subsequent turn. Because output tokens cost 3x to 5x more than input tokens, regenerating complete artifacts repeatedly multiplies token consumption and financial cost by 250% to 400% compared to a single-pass successful delivery.
Does prompt caching solve the problem of repeated AI corrections?
Prompt caching reduces the cost of reading static prefix tokens by 80% to 90%, but it does not make corrections free. Cached reads still carry a fee, newly appended conversational turns and corrections are charged at standard rates, and expensive full-length output generations are billed at full price on every retry. More importantly, prompt caching does not recover the human engineer's lost time.
How can engineering teams eliminate repeated prompt loops in AI agent workflows?
Teams can eliminate rework by: (1) converting prose guidelines into deterministic validation checklists, (2) requiring agents to inspect source files and schemas before generating code, (3) implementing automated pre-flight DOM and syntax linters, (4) decoupling drafting from verification using separate audit steps, and (5) treating self-verification as an essential acceptance criterion before the agent reports completion.
Mastering Systems Architecture & Production Engineering?
Explore real-world SRE failure modes, Kubernetes incident runbooks, and distributed cloud patterns across my production ecosystem:
