Parallel Claude Code and Codex tabs multiply faster than your working memory can track. You start one fix, open a second while the model thinks, then chase clarifications across a dozen threads until focus shatters. Developer Sergey Kuhne calls that collapse AI brain fry in a November 8, 2026 essay that trended on Hacker News. His answer is not a new model. It is infrastructure: tickets as markdown in git, agents draining a priority queue, and a single owner inbox where human judgment happens once per item — then the ticket closes so context does not linger.
This guide explains the workflow in plain terms, compares it to tools explainx.ai already covers, and cites how developers on HN pushed back or extended the idea.
TL;DR — the queue pattern
| Piece | Role | Why it matters |
|---|---|---|
| Markdown tickets in repo | System of record | Survives crashed chat sessions |
| Agent cycles | Research, build, test, verify | Replaces ad hoc tab juggling |
| Owner inbox | Prioritized human decisions | One surface for judgment calls |
| Claude artifact viewer | Read-only board + per-ticket review | Digest context without terminal scrollback |
| Close-then-next discipline | Cognitive reset | Stops "open loops" in your head |
Kuhne says the approach did not remove exhaustion but stopped him feeling distracted or lost. That is a realistic bar for anyone running parallel agents with worktrees.
Parallel git worktrees give each AI coding agent an isolated branch folder, which pairs with a markdown ticket queue to reduce AI brain fry from tab switching
What Kuhne says causes brain fry
In his post, Kuhne describes a familiar loop. A task starts in the terminal. The model runs long enough that you open another tab. The first reply needs a clarification, a follow-up and a side quest — each spawning more tabs. Soon you hop across many threads, holding partial state in mental RAM.
Common advice — take breaks, think before typing, shrink scope — helps but does not fix sequencing and context. Two failures stack:
- Sequencing: there is no single ordered backlog; urgent chat replaces planned work.
- Context: decisions and partial results live in ephemeral UI, not durable files.
That matches what we see in agent autoloop hubs and 0rwx scrutiny levels: the hard part is not invoking the agent; it is knowing what state the work is in when you return.
The git-backed ticket board
Kuhne's fix starts by moving state off chat chrome and into the repo.
Tickets live next to code. Every item is a markdown file in the project tree. The board's snapshot is whatever git last committed. If a session dies, the queue remains.
Agents run in cycles. Each cycle researches new tickets, implements items tagged safe for autonomous build, runs tests and browser checks, and verifies deployed work. Sensitive paths still get branches and explicit permission. Agents never deploy to production — that stays human.
Humans only decide. Anything needing judgment lands in the owner inbox. A script reads the board and returns a prioritized list: review this diff, answer this question, rule on this tradeoff.
Reading surface: a Claude artifact rebuilds the full board plus a review page per ticket from git on every cycle. Kuhne opens one link, reads what was built and why, and records the verdict on the card. The artifact is a viewer; git remains authoritative.
The closing step is deliberate. He takes one inbox item, loads context, decides, writes the outcome to the ticket, and closes it. Closed tickets should not keep burning attention while the next item loads.
How this compares to other agent workflows
GitHub Issues as broker. HN user kvark asked why invent a git-ticket scheme instead of Issues with labels like needs more info. Functionally similar: an external queue with UI, kanban and ecosystem tools. Kuhne's version optimizes for repo-local markdown and artifact viewing without leaving the Claude surface.
Fewer parallel tabs. wallstop argued the answer might be less parallelism, not richer tooling. docheinestages made the same point: one task, one focus. Fair — if your model is fast enough to wait, parallelism is optional. See speculative decoding for why latency still varies by stack.
Waiting for speed. mdemare suggested ultrafast Codex modes may make waiting preferable to filling idle time with new tabs. That is a bet on hardware and inference, not a process you can ship today.
Worktree CLIs. If parallelism stays, isolate filesystem state with git worktrees, which check out several branches at once in separate directories. Worktrunk gives each agent a branch folder; Kuhne's queue decides what runs, worktrees decide where.
Branching chat UIs. Thinkstream attacks the same multitasking pain in the conversation graph, not the issue tracker. Teams may need both: graph for exploration, git tickets for delivery.
Meta / culture. godelski noted that slowing down requires work culture change — speed and FOMO dominate tech. Process tools cannot fix incentives alone.
Step-by-step: adapting Kuhne's pattern
You do not need his exact scripts to trial the idea.
- Create a
tickets/directory (name it what you like) beside application code. One markdown file per unit of work; front matter or headings for status, owner, and risk class. - Define agent permissions in prose in
AGENTS.mdor ticket templates: auto-build allowed paths, branch-only zones, forbidden production commands. - Commit after every state change so
git logis an audit trail agents and humans share. - Build an owner inbox script that greps for
status: needs-human(or your equivalent) and sorts by priority field. - Use one review URL per ticket — artifact, static site, or a simple local HTML generator — so you never reconstruct intent from terminal scrollback.
- Enforce "one open human decision." Finish verdict, commit, then pull the next inbox row.
If you already run Agent Autoloop, map approval cards to inbox rows so notifications stay unified.
Alternative patterns from the HN thread
Not everyone buys a custom git board.
Named tab groups instead of a queue. User yuppiepuppie described cmux tab groups ranked in a sidebar — typically three or four groups, not more. That is pure attention management: you still parallelize, but you cap breadth.
Markdown in-repo without artifacts. stillpointlab said tracking work as MD files in the repo helped, yet they still reopen terminals asking where we are after long runs. Kuhne's artifact layer targets exactly that gap.
EtherPK graph notes. gb2d_hn pointed to a wikilink + kanban notes graph with an MCP server — closer to personal knowledge management than flat tickets.
Agent-as-manager framing. tra3 wrote that agentic development turns every developer into a team lead; stand-ups and design docs return. GitHub Issues as the queue is sufficient if you ritualize updates.
Visual cards. jpadkins described a rough visual board with discussion threads — same abstraction as Kuhne, different renderer.
Pick one external queue (Issues, tickets folder, or notes graph), one inbox contract, and one hard cap on parallel agents. Mixing all three without discipline recreates brain fry.
Structured coding workflows route agent tasks through gears of automation instead of chaotic terminal hopping, a metaphor for taming AI brain fry when running Claude Code and Codex
Why git beats chat as system of record
Chat UIs optimize for fluency, not audit. They compress history, fork threads silently, and bury decisions in scrollback. Git commits do the opposite:
- Blame and bisect still work when an agent introduces a regression.
- Branches align with merge policies and loop engineering for coding agents you already enforce.
- Offline review is possible on planes and in CI mirrors.
Kuhne's pattern also mirrors how OpenAI's Pando Git backend narrative treats version control as the spine of agent scale — even megacorp infra assumes reproducible trees, not ad hoc transcripts.
Limits Kuhne admits
On his blog and in HN replies, the system is not finished:
- Context serving still hurts: loading a ticket should take minutes, not twenty minutes of reconstruction.
- Blocked tickets can loop when they wait only on you — risk of inbox pile-up.
- Tooling churn: digest viewers, scripts and artifact rebuilds are custom glue.
- Exhaustion remains: structure reduces lost feeling, not total cognitive load.
hexapus joked that posting an essay Claude helped write might itself signal unresolved brain fry. Treat that as a reminder to label 0rwx WRITE vs EXECUTE on published process docs.
Security and hygiene
Centralizing agent work in git helps reviews but does not remove risk:
- Tickets may contain secrets if agents paste keys; scan commits and use pre-commit hooks.
- Autonomous build tags should exclude credentials paths and customer data.
- When agents run browser checks, isolate network like agent sandboxes recommend.
For policy-heavy repos, pair the queue with Claude Code token efficiency so cycles do not burn quota replaying full boards.
What to try this week
| If you… | Start with… |
|---|---|
| Juggle 5+ agent tabs daily | One markdown ticket file per active task; ban second tab until first is committed or parked |
| Use GitHub already | Issues + labels mirroring inbox; agent updates PR description from issue ID |
| Hit merge conflicts across agents | Worktrunk or plain worktrees plus queue priorities |
| Run overnight cron agents | Agent Autoloop feeding the same ticket schema |
Archive snapshot when the live blog throttles: HN user firefoxd linked a web.archive.org capture of Kuhne's post during the traffic spike.
Measuring whether your queue works
Track boring metrics for two weeks:
- Open human decisions — inbox count at day end; trend down if closes work.
- Time-to-verdict — minutes from inbox ping to committed verdict on the ticket.
- Mystery sessions — how often you ask an agent where we are after 30+ minutes idle (stillpointlab's pain point).
- Parallelism ceiling — max concurrent agent runs before error rate spikes.
If mystery sessions stay high, your viewer layer is too weak. If inbox grows unbounded, agents are enqueueing decisions you never make — tighten safe-to-build tags or add automation guardrails.