I'm not tired of AI. I stopped talking to it.
I'm not tired of AI. I stopped talking to it.
That distinction matters.
Where AI fatigue comes from (and why the diagnosis is wrong)
In May 2026, a thread called "I'm Tired of Talking to AI" hit nearly 2,000 upvotes on Hacker News in under 24 hours. The comments were recognizable: hours spent in chat with nothing shipped, answers that sound confident but don't work, burnout from endless back-and-forth.
I read the whole thread. The symptoms were accurate. The diagnosis wasn't.
People don't burn out on AI. They burn out on a specific way of using it: open-ended dialogue, vague request, waiting for the right answer from something that doesn't know your context.
It's like hiring a junior developer, sitting them next to you, and saying: "Something feels off here, help me figure it out." An hour later, you're both exhausted.
Conversational mode vs tool mode: what they look like in practice
Conversational mode means starting with an open question — "what do you think about X?" or "help me figure this out." Tool mode means starting with a bounded task spec: specific output, explicit context, defined constraints. The first generates a discussion. The second generates a file.
When I started with Claude Code, I talked to it. "What do you think about this module?" "How would you organize this?" "Give me some options."
The output was long, confident-sounding answers that took another 40 minutes to parse and apply. After three of those sessions in a row, I'd close the laptop feeling like I'd wasted the afternoon.
The shift happened when I started writing tasks the way I'd write them in a ticket system: specific output, edge cases, what's off-limits.
Here's the difference in practice.
Before: "Help me improve this PHP class."
After: "Write a PHPUnit test for CatalogSync::processChunk(). Input: array $items. Return: SyncResult. Edge cases: empty array, product without price, duplicate ID. Don't touch external dependencies — mock them. PSR-12 format."
The first request might get a lecture on clean code principles. The second gets a working test in 25 seconds.
That's the difference between conversational and tool mode.
Three rules I follow when tasking Claude Code
After six months of running Claude Code in a PHP studio, I've distilled three rules. Not principles. Rules. Breaking any of them predictably leads to iteration, and iteration leads to fatigue.
First — specific output, not a thought direction. A task is a file, a function, a test, a list. Not "advise me," not "help me understand." If I can't describe what should appear on the screen when the task is done, the task isn't ready.
Second — context is explicit, not assumed. If Claude needs to know we're on Bitrix D7 and PHP 8.2, I write that directly. If a module uses a custom event bus instead of the standard AddEventHandler — I describe it in the opening paragraph. "It'll figure it out" is the source of half of all bad outputs.
Third — scope is bounded, and overreach is a stop signal. In every task I specify what shouldn't change: specific files, dependencies, patterns. Claude Code given a bounded scope won't "improve" a neighboring module because "it also has issues."
These three rules removed most of the iteration from my workflow. Not because AI got smarter. Because I started giving it tasks that could actually be completed.
→ More on spec writing: I write a spec before asking AI to write code
Approval gates are workflow architecture, not distrust
An approval gate is an explicit checkpoint where a human reviews AI output before it's applied to a codebase or sent to an external system.
Some tasks I let Claude run without me. Others I review before applying. That's not caution — it's deliberate architecture.
The rule is simple: if the error is reversible and cheap to fix, it's automatic. If the error is visible to a client or touches a contract with an external system, it gets a human review.
Writing a test for an existing method: automatic. Changing the sync schema with a third-party ERP: approval gate.
This isn't about not trusting AI. It's the same decision you make designing any system: where does a human need to be in the loop, and where don't they. Removing all gates isn't about trust. It's about not wanting to think about workflow architecture.
→ On where I keep gates intentionally: Why I keep human approval gates even when I could remove them
What I measure: tasks closed without backtracking
The usual AI productivity metric is lines of code per day or time-to-completion. I stopped tracking both.
My metric: how many tasks were closed without coming back to them.
A well-specified task for Claude Code closes once. A vague request comes back three times with clarifications. The difference shows up immediately: if I spent 10 minutes writing the task, it usually closes on the first pass.
Three months ago I ran a simple count: tasks with a clear scope and explicit context closed without iteration 78% of the time. Loose requests: 31%.
That's what real productivity with AI looks like. Not speed. Quality of task definition.
Closing
If you're tired of AI, don't uninstall the app. Look at your last ten requests.
How many were questions? How many were tasks?
AI doesn't get tired. You get tired when you're looking for an answer from something that doesn't know what you need. That's not a tool problem. That's a specification problem.
→ What not to give AI in the first place: I let Claude write tests. I don't let it choose architecture.