DEV Community: Altair

Which Session Is Waiting for Me? Claude Code Hooks on a Stream Deck

Altair — Sat, 24 Oct 2026 03:14:24 +0000

I usually have several Claude Code sessions running side by side — a document here, a small fix there, some research. On a busy day, around five.

Delegating the work wasn't the problem. Noticing was:

A session asking "may I run this?" gets buried behind other windows.
A session finishes, and I don't notice for a while.
I keep switching windows just to check.

The AI wasn't the slow part. The time until I noticed was. The more sessions I ran, the worse it got.

The setup: three small pieces

I put the state of each session on a small button box on my desk (a Stream Deck Neo: 8 keys and a thin info bar).

Claude Code hooks run a small script at fixed moments — a prompt is submitted, a tool is about to run, permission is requested, the turn stops.
The script writes one tiny JSON file per session: which folder, which session, which state. No prompt text, no tool output.
A Stream Deck plugin reads those files every second and colors the keys.

The hook side is mostly a mapping from hook events to four states:

// hook events -> key state
function stateFor(d) {
  switch (d.hook_event_name) {
    case "UserPromptSubmit":
    case "PostToolUse":
      return "running";                  // blue
    case "PreToolUse":                   // asking me a question also counts as waiting on me
      return ["AskUserQuestion", "ExitPlanMode"].includes(d.tool_name) ? "ask" : "running";
    case "PermissionRequest":
      return "ask";                      // red
    case "Notification":
      if (d.notification_type === "permission_prompt") return "ask";
      if (d.notification_type === "idle_prompt") return "waiting";
      return null;
    case "Stop":
      return "waiting";                  // orange: done, please look
    case "SessionStart":
      return "idle";                     // gray
    default:
      return null;
  }
}

The colors:

Color	Meaning
Blue	Working
Red	Waiting for my permission
Orange	Done — please look
Gray	Idle

Pressing a key brings that session's window to the front. See red, press it, approve in that window. No more hunting.

Where it broke

The bug that took longest: a session finished, but its key stayed blue.

The hook writes to a temp file and renames it over the real one. The plugin reads that file every second. On Windows, if the rename lands at the exact moment the plugin is reading, the rename can fail with EPERM. My first version silently swallowed that error — so the "done" state was never written, and the key stayed blue. By the time I found it, 28 orphaned temp files had piled up.

The fix is boring: retry a few times with a short wait.

function replaceFile(tmp, file) {
  for (let i = 0; ; i++) {
    try { fs.renameSync(tmp, file); return; } catch (e) {
      if (i >= 9) { try { fs.unlinkSync(tmp); } catch {} throw e; }
      Atomics.wait(new Int32Array(new SharedArrayBuffer(4)), 0, 0, 30); // ~30 ms
    }
  }
}

Boring, but necessary. A status light you can't trust is just decoration.

Smaller one: after /clear, the session continues under a new ID, so I briefly had two keys with the same name. Now the hook removes the old record when a session starts from a clear, and keeps an old-ID → new-ID map for the plugin.

Then a character moved in

Colors alone felt a bit dry, so I drew a pixel-art chick into the keys. Her name is Aqui (from Aquila, the eagle constellation).

Working: juggling a ball
Waiting for permission: holding up a "?"
Done: a "!"
Idle: eyes closed, "z"

If the next key is also working, she passes the ball over. I wanted a box I like looking at, not just another notification.

That turned into a series of YouTube Shorts — over 20 episodes now. These days she rides around in a pixel-art WRX S4 through the seasons.

Shorts playlist: https://www.youtube.com/playlist?list=PLOctjyutDnug
How it works (2:25, Japanese with visuals): https://www.youtube.com/watch?v=m7cUQ3Owqv0

If you only do one thing

Put "waiting for permission" somewhere you'll see it. It doesn't need a Stream Deck — a colored corner of the screen or a sound works. For me, the time a session spent waiting on me was the least visible and the most wasted.

I haven't measured how much time this saves, so I won't claim a number. What I can say is that I stopped hunting through windows.

Japanese version (note): https://note.com/modern_elk8749/n/n516084403556

A personal project by a Claude Code fan. Not affiliated with Anthropic or Elgato.

Ask, Don't Just Read: Keeping Up With Code an AI Wrote

Altair — Sat, 17 Oct 2026 07:46:22 +0000

I'm the person in charge of digital transformation at a Japanese company. I build internal tools and workflow automations, and these days an AI coding agent (Claude Code) writes almost all of the code.

I thought my problem was "code review can't keep up." When I looked closer, it was something else.

The bottleneck wasn't review. It was understanding.

To be honest, for most of this work I no longer read diffs line by line. What I was actually stuck on was:

I couldn't tell whether the change did what I intended.
I couldn't explain it to anyone else.

Tools that make diff review faster don't help if you've already stopped reading diffs. I needed a way to say "I understand this" without reading everything.

It turns out everyone is hitting the same wall

Anthropic's own Claude Code team has said the bottleneck has moved from writing code to reviewing it.
Margaret-Anne Storey (2026) splits the problem into three kinds of debt: technical debt in the code, cognitive debt (the team's understanding erodes), and intent debt (the reasons and constraints never get written down). It's a conceptual paper, not an experiment.
In a 2026 survey in Japan, 86.3% of engineers who review AI-generated code said the burden had increased, and the top problem (49.5%) was "the submitter can't explain the code."

The study that changed how I approached it was Anthropic's randomized trial from January 2026. 52 mostly junior engineers learned a new library. The group using AI scored 50% on a comprehension quiz versus 67% for the hand-coding group, and the biggest gap was in debugging.

But the result depended on how people used the AI. People who fully delegated to it scored under 40%. People who asked conceptual questions and fixed errors themselves scored 65% or higher. (The authors are clear that this is correlation, not causation.)

So maybe reading an AI's explanation isn't enough. Maybe what matters is the human asking the question.

What I do now: an intent check

Spec-driven development plus automated review is great for a big team, but it's too heavy for one person. I cut it down to four things.

1. Write the intent before building

One line of purpose, then 3–5 success criteria in the form "when X, Y happens." The AI drafts them, I confirm. One round-trip.

This is where mismatches between the goal and the approach show up — much cheaper than finding them afterward.

2. Judge the result with a table, not the diff

#	Success criterion	Result	Evidence
1	…	✓ / ✗ / unverified	test run, actual output, screen, counted numbers

Evidence must come from actually running it. "The code says so" doesn't count as ✓. The last row is always: "Do the comments and design notes still match what it does now?"

3. Leave one or two questions — without answers

Under the table, the AI writes one or two "questions worth asking to understand this better." It doesn't write the answers. I decide whether to ask. If I don't, that's fine.

If the study above is right, asking beats reading. This just leaves the door open.

4. Keep four lines for explaining it to others

- What changed: (from the user's point of view)
- Why:
- How to check it:
- What it doesn't do:

These go into the design notes. The table is for me to judge "did it do what I meant." These four lines are for explaining it to someone else.

A one-line change, two surprises

The first change I tried this on was a single line: keep 3 daily backups instead of 7. The goal was to free up disk space.

The table showed:

✓ It keeps the latest 3 plus one per week for 4 weeks.
✗ It barely frees any space. Old backups go to the Recycle Bin, so the disk space doesn't come back until the bin is emptied.
✗ The comment at the top of the file still said "keep 7."

Neither problem was visible from the diff. They showed up because I wrote down the purpose first.

What it is not

Not a replacement for automated code review. That finds defects; this finds gaps against intent.
Not a replacement for having the actual users check the output against real data.
When something is ✗, the AI doesn't quietly fix it. A human decides whether the intent or the implementation was wrong.

What I don't know yet

I've only just started. To avoid judging it by how it feels, I log four things each time:

Number of ✗ results
Time spent on the up-front back-and-forth
Whether I asked the questions
Later, when someone asked me about it, whether I could answer without asking the AI again

In one study, developers felt 20% faster with AI while actually being 19% slower (METR, 2025). I'll write a follow-up once I have a few months of data.

As AI writes more of our code, the human job seems to be shifting from "read everything" to "decide what to trust." If so, the key to keeping our understanding might be not how much we read, but how often we ask.

References

Anthropic, research on AI assistance and coding skill formation (Jan 2026): https://www.anthropic.com/research/AI-assistance-coding-skills
METR, early-2025 AI and experienced open-source developer productivity (Jul 2025; marked out of date in Feb 2026): https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
M-A. Storey, From Technical Debt to Cognitive and Intent Debt (2026): https://arxiv.org/abs/2603.22106
Survey on reviewing AI-generated code in Japan (@it, Jun 2026, Japanese): https://atmarkit.itmedia.co.jp/ait/articles/2606/16/news041.html