Everyone got faster at writing code. Nobody got faster at understanding it.
You prompt an agent, it works for four minutes, and it hands you something that runs. You merge it. A week later someone asks why the project talks to Redis, and the honest answer is that you do not know — an agent decided, and you were not really there. This is the first Problem of the Week, and the thing we built to close the gap.
By Ashutosh Tiwari ·
The agent's context is growing. Yours is shrinking.
A coding agent reads your whole repository, holds every file it touched in working memory, and makes a hundred small decisions on the way to a result. You read the final message. That asymmetry is the entire problem, and it gets worse every month as the agents get better, because the better they get the less reason you have to look.
It costs you twice. The first cost is immediate and obvious: the agent works for minutes at a time and there is nothing for you to do, so you go to Slack, and you come back cold to a diff you will skim rather than read. The second cost is slower and much more expensive. You accumulate a codebase full of decisions you own and did not make — a cache here, an auth library there — and each one is a thing you cannot explain to a teammate, a customer, or a security reviewer.
The usual framing is that this is a code review problem, or a documentation problem. It is neither. Review and docs both happen after the fact, when your attention has already moved on, and both assume the reader can read code. The people building with agents increasingly cannot.
You are not behind because the agent is fast. You are behind because nothing is teaching you while it works.
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.
Three obvious answers, and why each one fails.
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.
Then the obvious thing: the wait is not the problem. The wait is the opening.
It is the only moment in the whole loop when your attention is already on this project and there is genuinely nothing for you to do. You do not have to be interrupted, persuaded, or sent anywhere. Something just has to be there when you look up.
Vibers: a menu bar app that teaches you your own project while the agent works.
It watches your AI coding sessions and, in the gap while the agent is grinding, explains what is happening in your project. 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.
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.
Why can't I understand what my AI coding agent built?
Because the agent reads your entire repository and makes dozens of decisions, and you read only its final message. The understanding gap is structural, not a matter of paying more attention: by the time the result arrives, the reasoning that produced it is gone. Closing it requires something that explains the work while it is happening, rather than summarising it afterwards.
How do you learn from an AI coding session?
The useful moment is 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 we ran into it, how we checked it was not just us, what we tried before the thing that worked, and what shipped.
Got a problem worth a week? ash@idxstudioz.com.