One Ticket at a Time: A Cure for AI Brain Fry

If you run Claude Code or Codex from the terminal, you probably know this pattern. You start a task, and while the AI works, you open another one. Then the first reply comes back asking for a clarification, a follow-up and a side task, and each one gets its own tab. A developer writing on Hacker News calls the result “AI brain fry”: twenty threads open, every context crammed into your “brain RAM,” until your focus breaks and you lose track of where you started.

The usual advice is to take breaks, think before typing and limit scope. This developer tried something else. He traced the problem to two failures, sequencing and context, and rebuilt his workflow so it runs like a priority queue. His setup is worth copying because it treats your attention as the bottleneck, not the AI.

⚡ Quick Start

What you’ll learn: How to move AI-assisted work out of chat windows and your head and into a git-backed queue you clear one decision at a time.

What you need:

  • A git repo for your project
  • An AI coding agent (Claude Code, Codex or similar)
  • A small script that reads ticket files and builds a list
  • A way to render a review page (he uses a Claude artifact)

🛠️ The Five Steps

1. Put the queue in git

Each ticket is a markdown file stored in the repo, next to the code it covers. The state of the board is a committed snapshot. In his words, “Nothing important lives in a chat window and nothing lives in my head.”

Why it matters: Chat sessions die, and terminals fill up and scroll away. Git doesn’t forget. If a session crashes, the queue is still there, and the history shows how each decision was made.

2. Let an agent work the board in cycles

The agent cycles through the board. On each pass it:

  • Researches new tickets
  • Builds the ones a human has tagged as safe to build
  • Runs the tests and a browser check
  • Verifies what’s already deployed

Two rules keep it in check. For anything that touches sensitive code, it builds on a branch and asks before going further. And it never deploys to production. That job stays with the human.

Why it matters: The agent does the slow, parallel work, so you don’t need twenty tabs to keep things moving.

3. Send every decision to one owner inbox

The agent can build, but it can’t decide. So everything that needs a human goes to one place, which he calls the “owner inbox.” A script reads the whole board and returns a prioritized list of only the items waiting on your judgment: review this change, answer this question, rule on this tradeoff.

Why it matters: You stop checking twenty threads to see who needs you. One list tells you what’s waiting and what comes first.

4. Read on one page, record the verdict in git

He reads everything on a single Claude artifact page. It’s rebuilt from git on every cycle, mirrors the full board and has a review page for each ticket. Instead of scrolling back through terminal output, he opens one link, reads what was built and why, and gives his verdict. The verdict goes back into git, on the ticket’s card.

Tip: Keep the page as a viewer only. As he puts it, “git is the record.” If the page breaks or goes stale, you lose nothing.

5. Take one item, decide, close it

He calls this the part that matters most. Take one item. Load its context. Make a decision or request an action. Then close it by putting it back in the queue.

Why it matters: “That closing is the whole trick.” Once a ticket is closed, you don’t have to remember it, and its context leaves your head with it. That frees you to focus fully on the next item.

⚠️ What’s Still Hard

He’s upfront that the work is “still exhausting,” but he no longer feels distracted or lost. Two problems are still open:

  • Loading context quickly. The tooling has to present each ticket so it takes a minute to absorb, not twenty.
  • Blocked loops. Tickets can go around in circles while they wait for a ruling only the owner can give.

He describes the system as “a living organism” that he keeps improving.

🚀 Next Steps

  • Start small. Turn your next three AI tasks into markdown tickets in your repo before building any automation.
  • Write the inbox script first. A list of what needs your judgment helps right away, even if the agent still runs by hand.
  • Set the agent’s limits early. Decide which tickets it can build without asking, which need a branch, and which it should never touch.
  • Track loading time. If a ticket takes more than a few minutes to understand, improve how the agent summarizes its work.

Coding agents are getting faster and more independent, so the human reviewer becomes the bottleneck. Setups like this one, built around your attention instead of the agents’ throughput, will likely matter more as that happens. The full write-up is on Hacker News.

Scroll to Top