Your agent works for four minutes.
You spend them on Slack.
That is the deal most of us have quietly accepted: the agent gets faster, and you get a few minutes of nothing, several times a day, while sitting in front of the project you care most about. The minutes are not the expensive part. Coming back cold to a diff you will skim rather than read — that is the expensive part. This is the first entry in Worth Solving: how I noticed the waste, how I checked it was not just me, and what it took to fill it.
By Ashutosh Tiwari ·
The wait is small. What it costs is not.
Prompt, wait, check back. Two to five minutes each time, a dozen times a day once you are really using an agent. Individually it is nothing, which is exactly why nobody budgets for it. Together it is the largest block of unclaimed attention in your working day — and unlike almost any other spare minute, it arrives while you are already sitting in front of the thing you care most about.
It is worse than idle time, because it is not idle. You fill it with Slack, or email, or somebody else's repository, and the switch costs more than the wait did. You come back with the thread dropped and a diff you will skim rather than read. Not laziness: rebuilding the context genuinely costs more than trusting the result, so trusting the result is the rational move every single time.
Then it compounds. Skim enough diffs and you are running a codebase full of decisions you own and did not make — a cache here, an auth library there — each one a thing you cannot explain to a teammate, a customer, or a security reviewer. The dead time is the cost you can see. Not being able to answer for your own project is the bill that arrives later.
It is the only stretch of the day when your attention is already on the project and there is genuinely nothing to do with it.
Four moments, in the order they landed.
None of these felt like a product idea at the time. They felt like mild embarrassment, which is usually the better signal.
The dead minutes
I would prompt an agent, watch two lines of output, and go read something unrelated. Four minutes later I would come back with no more understanding of my own project than when I left. I was paying for the time either way.
Shipping things I could not explain
The work was good. It passed. I merged it. And if you had stopped me in the hallway and asked what it actually did, I would have given you the commit message back, slightly reworded.
The question I could not answer
Someone asked why a dependency was in my project. It was a completely fair question with a real answer, and I did not have it, because an agent had made that call during a session I had half-watched.
Watching someone else do it
Then I watched a non-engineer build something real with an agent — genuinely useful, genuinely shipped — with no mental model of the system underneath it at all. Not a worse version of my problem. The same problem, further along.
That last one is what turned it from an annoyance into a thing worth building. My version was recoverable: I could always go read the code. Theirs was not, and there are going to be far more of them than of me.
I went and asked, before I wrote a line.
Informal conversations, not a study — and worth saying plainly rather than dressing up as research. I talked to three groups, because I suspected the same gap would show up wearing three different costumes. It did.
People building with agents who do not read code
Founders, operators and marketers shipping real things. They were not worried about code quality. They were worried about not being able to answer questions about their own product — and about the moment something breaks and they have no idea where to start.
Engineering managers and leads
Accountable for a growing share of code nobody on the team wrote by hand. The recurring theme was not fear of bad code; it was the review getting shallower as the volume went up, and knowing it.
Founders in my network
The bluntest version. Velocity was up and confidence was down, and they had stopped being able to tell whether their codebase was an asset or a liability.
Nobody described this as a problem they wanted a tool for. They described it as a thing they had quietly accepted, which in my experience is the strongest signal a problem is real — people stop complaining about weather.
Four tests, set before building anything.
Written down first, on purpose. A bar you set after you have already built the thing is not a bar, it is a justification — and three of these could have come back no.
- 01
Someone other than me has it.
Cleared. Three groups, the same complaint wearing three different costumes.
- 02
It costs something real, and it repeats.
Cleared. Two to five minutes a run, a dozen runs a day, plus a context switch each time that costs more than the wait.
- 03
The obvious answers do not already cover it.
Cleared, and this is the one I expected to fail. All three fall over below.
- 04
It can be filled without asking anything of the person.
The hard one. Not a yes or no so much as the constraint that shaped everything after it.
Three answers already existed. Each one fails the same test, which is how I knew the fourth criterion was the real one.
Ask the agent to explain what it did
Why notAfter the fact, so your attention has already left. It costs you another prompt and another wait, and it explains the diff rather than the decision. You also have to remember to ask, every single time, which nobody does.
Read the diff, or the PR summary
Why notA diff is a precise record of what changed and says nothing about why. It is also the one artefact that hard-requires you to read code — which rules out most of the people who need this most.
An editor extension, or a web dashboard
Why notAn extension lives in one editor and misses everyone driving an agent from a terminal. A dashboard is a tab you must remember to open, competing with every other tab. Both ask you to go somewhere. That is the wrong direction of travel.
Which leaves one hard constraint: it has to already be there when you look up.
Not a place to go, not a command to remember, not a habit to build. Filling the wait is only worth anything if it costs nothing — the moment it asks you to do something, you are choosing it over Slack, and Slack wins, because Slack is already open. That single constraint is what killed all three answers above, and it is most of what shaped the thing we ended up building.
Vibers: a menu bar app that teaches you your own project while the agent works.
It sits in the menu bar and does one thing: when your agent starts working, it puts something worth reading in front of you before you reach for Slack — about this project, not in general. When the session ends, it tells you what changed. It works with Claude Code, and carries Codex support built to that tool's documented transcript format.
- 01
You prompt the agent
Claude Code, in your own terminal, as usual.
- 02
Vibers notices
Zero setup. It follows the transcript the tool already writes.
- 03
It works out the task
From your prompt, the manifests and git — never your source.
- 04
While you wait
A 2 to 5 minute card about what is actually happening.
- 05
The agent finishes
You added Redis. Six files. Here is why it matters.
- 06
The map updates
Your project's technologies, with the new ones marked.
Zero setup, and nothing touched
Claude Code and Codex already write a local JSONL transcript for every session. Vibers follows it. That means no hooks installed, nothing written to your tool's configuration, and no screen scraping. Both tools normalise onto one internal event set, so nothing downstream knows or cares which one you used.
It teaches the session, not the stack
The first version ranked the technologies present in the project and confidently surfaced TypeScript, which is not news to anyone. Real transcripts showed why: a session is mostly running, testing and fixing. One carried 291 shell calls, 219 simulator calls, 58 failed tool results and 29 prompts — including "whats this error". So the unit of teaching became an observation about the session, carrying the evidence that proves it, and a question you actually typed outranks everything else.
It writes for whoever is reading
Onboarding asks what you are accountable for and how much code you read, and treats both as a starting guess rather than a verdict — what you do afterwards moves it. The same failure gets explained at a different altitude depending on who is looking at it.
Privacy enforced in code, not in a policy
Source files are never read. From a .env it reads variable names and never values. Redaction happens at the provider boundary across thirteen credential formats, before any other component sees the data. Paths are relative, so a card never carries your username or directory layout. The function that assembles anything leaving the machine is pure and small, which makes the list of fields that could ever leave fixed and auditable — and the Privacy tab shows you the literal payload used for the card you are reading.
The same error, two readers
This is the clearest thing the product does. One peer-dependency conflict, explained to two different people, from the same evidence.
npm's resolver hit a contradiction in your dependency graph… Does react-dom belong in this tree at all, given React Native renders through Fabric rather than the DOM renderer?
Your app is built from lots of pre-made building blocks, and each block says which versions of the other blocks it can work with.
Four screens, 380 pixels wide, living next to your clock.
Which project is this session even about?
It looks like a solved problem: read the working directory, done. Then you look at a real session. Over one of them the agent's working directory took fourteen different values — the repository root for most of it, but also an Xcode build output directory, a path inside node_modules, and a scratch folder it wandered into early.
Taking the first one seen attributed the entire session to a build directory. Build directories have no manifest, so nothing was detected, so there was nothing to teach, so the app said nothing at all. Not a crash. Just silence, which is worse, because it looks like the product has no opinion.
The fix is two rules. Resolve the path: drop everything from the first vendored or generated segment rightwards, then climb to the highest ancestor holding a real project marker. All fourteen collapse to one root. Then follow the weight of evidence: count how often each directory appears and re-attribute when the dominant one changes, so a session that opens in a scratch folder gets corrected once the real work starts.
This is the unglamorous majority of the work, and it is most of what separates a demo from something you would leave running. The adapters were validated against thirty-five real transcripts, which is where bugs like this come from — none of them were visible against clean test fixtures.
Honest answer: too early to say.
Too earlyThe problem cleared the bar. It is real, it belongs to other people as well as me, it costs something every day, and nothing that already exists fills it without asking you to go somewhere. That part I am confident about.
Whether the thing I built is the right answer is a different question, and I do not get to claim it yet. It has been shipped for days, to nobody. The binary is unsigned. Anyone announcing a verdict at this stage is selling you something.
So this entry stays open. I will come back to it when there is real usage to point at, and if the answer turns out to be no, that will be its own week.
- Problem worth solving
- Yes
- Solution proven
- Not yet
- Revisit
- After real usage
Run it on your own Mac.
Start a session in Claude Code and watch the menu bar. If the explanations are wrong, or dull, or aimed at the wrong person, that is the useful kind of feedback and I would like to hear it.
- Requires
- macOS on Apple Silicon
- First launch
- The build is not signed yet, so macOS will warn you. Right-click the app and choose Open.
- Where it appears
- The menu bar, near the clock — not the dock. Look for a small V.
- What it costs
- Free. Cards are written through your own Claude login, with a $1 a day ceiling and an offline fallback past it.
The four people ask first.
What should I do while my AI coding agent is running?
Most people switch to Slack or email, which costs more than the wait itself: you come back with the context gone and skim the diff instead of reading it. The better use of those two to five minutes is the project already in front of you — what the agent is touching, why a dependency appeared, what the error it just hit actually means. That only works if it takes no action on your part, because anything requiring a click loses to the tab that is already open.
How do you learn from an AI coding session?
Use the wait. While an agent works there is a two to five minute window where your attention is already on the project and there is nothing for you to do. Vibers uses that window to explain one thing about what is happening — chosen from what the session is actually doing, with a bias toward questions you typed yourself and errors you hit.
Does Vibers read my source code?
No. It reads the session transcript your coding tool already writes, your project's manifests, and git metadata. Source files are never read. From a .env file it reads variable names and never values, and everything is redacted at the point of entry across thirteen credential formats before any other part of the app sees it.
Which AI coding tools does it work with?
Claude Code today. Codex support is built to that tool's documented transcript format and covered by tests, though it has not yet been run against a live Codex install. Both normalise onto one internal event model, so adding another tool is an adapter rather than a rewrite.
One problem a week: how I stumbled on it, the bar I set to decide whether it was worth building, what I shipped, and the honest verdict. Sometimes the answer is no.
Got a problem worth a week? ash@idxstudioz.com.