AI coding has a decision fatigue problem. Here’s how we’re fixing it.

M.M. CAN — Thu, 15 Oct 2026 19:35:36 +0000

After a few hours of coding with an AI agent, I'm usually more worn out than after a day of writing code myself. For a while I blamed the waiting. Then I started paying attention to what I was actually doing during those hours, and most of it was making small decisions the tool kept handing back to me.

A normal turn with a coding agent goes something like this. I figure out how to phrase the request. I decide whether to sit and watch it work or go do something else (just.... scrolling reels) and lose my place. When it finishes, I decide whether to read the whole report or skim it. It says the tests pass, and I decide whether I believe that. I decide whether to open the diff. I decide whether the result is what I meant or just close enough. Then I decide whether to accept it, retry, or rewrite the prompt.

That's around seven calls per turn, many times an hour. Very few of them are about the thing I'm building. They're about babysitting the tool. I've started calling it AI decision fatigue, and I think it's the main reason agent-assisted work feels so draining.

So I built a tool around one rule: only ask me the things only I can answer, and handle the rest.

What that looks like

The tool is called Fade. It runs in the terminal and has a single conversation. Behind it are two agents working at the same time: one that talks and plans with you, and a Builder that writes the code in a sidebar. You never pick which agent to talk to or switch modes. You type what you want and it just f'ing does that.

The Builder works while the conversation stays open, so there's no turn to wait for. While it builds one thing, you can plan the next feature, ask how some part of the code works, or change your mind. Whatever you agree on goes into an "up next" list, and the Builder picks it up when it's free.

The part I cared about most is the question of whether to trust the result. Agents say "all tests pass" a lot, and sometimes it isn't true, so you end up checking everything yourself. In Fade, the Builder writes a proof for each thing it claims, usually a focused test or a command. Fade commits the change and then runs those proofs itself, on that commit. If one fails, the work goes back to the Builder with the real error output before you ever see it. When something comes back marked as checked, it means Fade ran the check, not that the model said so:

✓ Search notes — typing "gro" finds Groceries · checked

Some things can't be tested: whether a screen feels calmer, whether the wording sounds friendly, whether the layout is what you had in mind. Those are real decisions and they should be yours, so Fade asks them as a single question and waits for your answer:

◆ Settings is built. Your call: Does it feel calmer?

Everything a test can settle lands on its own without asking you anything.

Clear requests start right away, with a one-line read-back so you can see how it was understood. If a request is vague, you get one question with concrete options instead of a back-and-forth:

you   make the help text friendlier
fade  Short and direct, or warm and conversational?
you   the second one
fade  On it: Friendlier help.

Every change is a git commit, and "undo that" reverts it cleanly, even if later work touched the same files. Knowing anything can be reversed makes each decision feel less heavy.

A short session

you   add search to my notes
fade  On it: Search notes. The Builder is on it now; keep talking to me while it builds.
you   while that runs, what would tags look like?
fade  A tag field on each note; clicking one filters the list. Want it next?
you   yes
fade  On it: Note tags.
fade  ✓ Search notes — typing "gro" finds Groceries · checked

In that exchange I decided what to
build and said yes to tags. I didn't wait, read a report, or wonder whether search really worked.

Limits

A proof only covers what it checks. If the Builder can't come up with a check it can run, Fade marks the result as not checked instead of passing it quietly.

Model quality matters. The Builder needs a model that's reliable at tool calling. In my testing, a stronger model for the conversation and a cheaper one for the Builder worked well.

It's early, version 0.5. I'd like to hear whether it actually reduces the fatigue for other people or just moves it somewhere else.

Trying it

The demo runs without an API key, using fake agents in a temporary folder:

npx @muzaffermahi/fade --demo

To use it on a real project, connect a model and run it in the project folder:

npx @muzaffermahi/fade login
npx @muzaffermahi/fade

It works with any model Pi supports, including local models through Ollama. It's MIT licensed.

GitHub: https://github.com/muzaffermahi/Fade

Lastly, I'm curious if this project actually helps you focus more or it feels like another project/agent to babysit to. And any suggestions, comments, how much you hate your e-girlfriend like idk just share it here :D

DEV Community: M.M. CAN

AI coding has a decision fatigue problem. Here’s how we’re fixing it.

What that looks like

A short session

Limits

Trying it