{"slug": "agent-fatigue-where-ai-coding-agents-genuinely-save-time-and-where-they-quietly", "title": "Agent fatigue: where AI coding agents genuinely save time and where they quietly cost you", "summary": "A developer's analysis of AI coding agents argues that the perceived speed of agent-assisted work diverges from actual speed, citing METR's mid-2025 randomized study in which experienced open-source developers finished tasks about 19% slower with AI tools despite expecting to be 24% faster and believing afterward they had been 20% faster. The piece pairs that finding with DORA's 2024 report, which linked higher AI adoption to feelings of greater productivity alongside a small drop in delivery throughput and a larger drop in delivery stability, and lays out which task types—pattern-matching endpoints, test generation, codebase explanation, tooling-verified refactors, disposable scripts and docs—make the review cost worth paying.", "body_md": "It is 4 PM and you have been \"almost done\" since lunch. The agent wrote the first version of the feature in eight minutes. Since then you have read its diff three times, asked it to fix a test it broke, watched it fix that test by changing the assertion, reverted that, explained the actual bug, reviewed a new diff that touched files you never asked about, and started wondering if you should have just written the thing yourself.\n\nThat feeling has a name now in a lot of teams: agent fatigue. Not the fatigue of hard work, but the fatigue of supervising something that is fast, confident and wrong just often enough that you can never stop watching it.\n\nAI coding agents are genuinely useful. I use them every day. But the speed you feel and the speed you get are two different numbers, and the gap between them is where the fatigue lives. This article is about telling them apart.\n\nIn mid 2025, METR ran a randomized study with experienced open source developers working on their own mature repositories. With AI tools, they finished tasks about 19% slower on average. Before starting, they expected to be about 24% faster. After finishing, they still believed they had been about 20% faster.\n\nOne study on one kind of work does not settle the question, and tools have improved since. But the shape of the result matches what many engineers notice once they start measuring: the agent makes the start of a task feel instant, and the cost moves to the end, into review, correction and cleanup, where it is easy to not count it.\n\nThe DORA research program saw something similar at the team level. Its 2024 report found that higher AI adoption was associated with people feeling more productive, alongside a small drop in delivery throughput and a larger drop in delivery stability. More code was moving, but not necessarily more working software.\n\nSo the useful question is not \"are agents good or bad\". It is \"for which tasks does the time I save at the start outweigh the time I spend at the end\".\n\nThese are the tasks where, in my experience and in most teams I talk to, the math clearly works out.\n\nA new API endpoint that looks like the ten existing ones. A new database migration. A CLI command with the same structure as its neighbors. The agent has a template right there in the codebase, the shape of a correct answer is obvious, and review is fast because you are checking for deviation from a known pattern.\n\nGive the agent a function and ask for tests covering the edge cases. It is good at enumerating cases you would skip out of boredom: empty input, unicode, off by one boundaries, null in the middle of a list. You still review them, but reviewing a test is quick, and a wrong test fails loudly.\n\n\"Explain how a request flows from the router to the database in this service\" is one of the highest value uses there is. Nothing gets written, nothing can break, and it turns an hour of jumping between files into ten minutes of reading a summary and verifying the parts that matter.\n\nRenaming across a codebase, migrating from one library API to another, converting callbacks to async. When a type checker or a solid test suite will catch mistakes, the agent's errors are cheap. The tooling does most of the review for you.\n\nA script to reformat a CSV, a quick dashboard for a debugging session, a data migration you will run once. If it works, it is done. Nobody maintains it, so code quality matters far less than whether the output is right, and the output is easy to check.\n\nDocumentation, a README, an architecture decision record, a design doc outline. The agent gets you past the blank page, and you were always going to edit it heavily.\n\nThe common thread: **the cost of checking the work is low compared to the cost of doing it.** Either the answer is easy to verify, or a machine verifies it for you, or the work is disposable.\n\nNow the other side. These are tasks where the agent often feels productive while the session is running, and the bill arrives later.\n\n\"Add caching to this service\" sounds like a coding task. It is actually a set of decisions: what to cache, for how long, how to invalidate, what happens when the cache is stale, what happens when it is down. The agent will make all of those decisions for you, silently, in plausible looking code. You then have to reverse engineer which decisions it made before you can judge whether they are right. That review is often slower than making the decisions yourself.\n\nFor an obvious bug with a clear error, agents are fine. For the intermittent failure, the race condition, the bug that only shows up under production load, they tend to pattern match to a common cause, apply a fix, and report success. If the test passes for the wrong reason, you now have a confident explanation and a change that hid the symptom. Finding that out costs more than the original bug.\n\nReview effort does not grow linearly with diff size. A 40 line change gets real attention. A 900 line change across 25 files gets skimmed, by humans and agents alike. Agents produce large diffs easily, and every unreviewed line is a small loan against your future debugging time.\n\nIf the agent writes something in a part of the system nobody knows well, you lose the one thing that made that code maintainable: a person who can explain why it is the way it is. Six months later, the incident review asks \"why does this retry three times with no backoff\" and the honest answer is \"the agent did it and it looked fine\".\n\nThis is the one that creates most of the fatigue. You ask for a change. It is 80% right. You correct the 20%. The correction breaks something else. You correct that. Each step is quick, so it never feels like a decision to stop, but after the sixth round you have spent longer than writing it by hand, and you are more tired, because reviewing someone else's near misses is draining in a way that writing your own code is not.\n\nThe common thread here is the reverse: **the cost of checking the work is high, or the mistakes are silent.**\n\nYou don't need a research study. You need a few honest habits.\n\nMeasure from \"I started this\" to \"this is merged and I trust it\", not from prompt to first diff. If you track work in tickets, compare cycle time and review rounds for agent heavy changes against similar changes done by hand. A week or two of rough numbers beats any amount of gut feeling.\n\nLook at reverts, hotfixes and bugs traced back to recent changes. If agent assisted pull requests show up more often in that list, the time you saved upfront is being paid back with interest. The DORA finding about stability is exactly this effect at scale.\n\nDecide in advance: if the agent hasn't got it right after two or three rounds of correction, stop, and either write it yourself or rethink the request. Most wasted sessions are the ones where each next correction felt like the last one.\n\nAsk for one focused change at a time. Tell the agent which files it may touch. A sequence of five small reviewed diffs is almost always faster in total than one large one you only skim.\n\nFor anything with judgment involved, ask it to list the decisions and tradeoffs before writing code: \"Propose how you would add caching here: what keys, what TTL, how invalidation works. Don't write code yet.\" Reviewing a plan takes two minutes. Reviewing the same decisions buried in code takes twenty.\n\nStrong types, a fast test suite, linters and a CI pipeline that runs on every change turn agent mistakes from silent into loud. The better your automated checks, the larger the set of tasks where agents are a clear win. This is the least glamorous and most effective investment you can make if your team uses agents heavily.\n\nBefore handing a task to an agent, ask one question: **how will I know this is correct, and how long will that take?**\n\nIf the answer is \"the tests will tell me\" or \"I'll see it immediately\", hand it over. If the answer is \"I'll have to read it carefully and think about edge cases in a system I know well\", that reading and thinking is the real work, and the agent has not removed it. It has only moved it to the end, where it is harder to do and easier to skip.\n\nAgents are fastest where checking is cheap, and slowest where checking is the job. Use them aggressively for the first kind of work, deliberately for the second, and measure the whole task, from first prompt to trusted merge. The fatigue goes away when you stop supervising work that was never a good fit in the first place.\n\nI'm Amit Shukla, a software engineer working across DevOps, cloud and applied AI. Behind the Stack is where I write up the things I learn the hard way, with working code and honest tradeoffs.\n\nIf this saved you some time, a reaction or a comment helps more people find it.", "url": "https://wpnews.pro/news/agent-fatigue-where-ai-coding-agents-genuinely-save-time-and-where-they-quietly", "canonical_source": "https://dev.to/amitshuklabag/agent-fatigue-where-ai-coding-agents-genuinely-save-time-and-where-they-quietly-cost-you-4in6", "published_at": "2026-10-29 13:15:30+00:00", "updated_at": "2026-10-29 13:17:51.643670+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["METR", "DORA"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/agent-fatigue-where-ai-coding-agents-genuinely-save-time-and-where-they-quietly", "markdown": "https://wpnews.pro/news/agent-fatigue-where-ai-coding-agents-genuinely-save-time-and-where-they-quietly.md", "text": "https://wpnews.pro/news/agent-fatigue-where-ai-coding-agents-genuinely-save-time-and-where-they-quietly.txt", "jsonld": "https://wpnews.pro/news/agent-fatigue-where-ai-coding-agents-genuinely-save-time-and-where-they-quietly.jsonld"}}