I Vibe Code With My Eyes Closed (Sort of)
The eyes-closed part is a lie. You cannot literally code with your eyes closed. What I did for a week is more like — dim the monitor, lean back, and see how much of the agent's workflow I could run on audio alone. The laptop screen stayed on, because nobody is writing TypeScript blindfolded, but I made myself route every long agent output through TTS and catch the code with peripheral vision. Some of it worked. Some of it really did not. I want to tell you which is which.
Day one was Claude Code, the CLI version, in Ghostty. I had a backlog of three bugs that had been waiting for me to care. First bug: the eval runner would silently drop URLs with UTF-8 in the path. I gave Claude the file, said "find it," walked to the kitchen, came back to a long explanation about Node's URL parsing and a suggested diff. I selected the explanation, hit play, sat back down, and watched the diff scroll past while the reasoning played. Nine minutes from "find it" to "merged." I was not reading the explanation word by word. I was listening to it while my eyes scanned the three changed files. The bug was real, the fix was real, the audio made the review feel like I was being briefed by a junior engineer who had already done the work.
Day two was Cursor Composer. Different rhythm. Composer tends to chunk its output more aggressively — short paragraphs, then diff, then short paragraph, then diff. The audio workflow I developed on Claude Code didn't map cleanly. I would select the first paragraph, start playback, and by the time the paragraph finished Composer was already on the third diff block. So I tried selecting everything. That worked better but felt wrong — I was listening to content that referred to code I hadn't looked at yet. It's like watching the director's commentary for a movie you've never seen. You need the frame of reference.
What I settled on for Cursor was a compromise. Listen to the overview paragraph, look at the diff summary while it plays, then when audio ends, scroll through the diffs at my own pace without audio. That felt fine. Not as smooth as the pure Claude Code flow but fine.
Day three was Gemini CLI and it broke me for a minute. Gemini's output style is shorter. Tighter. Less of the meandering explanation Claude writes. Which meant — there wasn't really enough text to need audio. Selecting a four-sentence summary and pressing play felt like using a forklift to carry a single envelope. So Gemini became my read-normally tool that week. That's fine. Not every tool needs the audio layer. Audio earns its keep when the text is long enough that your eyes would drift away.
Day four I had to pair with a colleague on a schema migration. This was the point I thought would fall apart. You can't "listen" to a pair session. Except — you can. The pattern that emerged was, she'd explain what she wanted, I'd ask Claude to do it, Claude would spit out a plan and a diff, I'd click the orange bubble on the plan and put it on speaker so we both heard it. She nodded along. I scrolled the diff. We approved it together. The funniest part of that day was when the audio said something she disagreed with and she just said "no, rewrite that." The loop was tighter than if we'd both been reading silently at different speeds.
Day five was when I pushed the limit too far. I tried to do a full code review of a 40-file PR with just audio. Claude summarized the PR, I listened, I approved. Which, you know, is how you accept subtle bugs into your codebase. Halfway through I realized I hadn't actually looked at a single line of code, I'd just been listening to Claude's reassurance that everything was fine. I closed the PR. Went back the next morning. Reviewed it properly, with my eyes on the diffs, Claude's summary playing for each file. Found four things worth questioning. Two were real issues. One was a false alarm. One was a judgment call where I ended up agreeing with Claude but I wanted to see the change myself first.
That's the honest line. Audio works when your eyes are on the code. Audio does not replace your eyes on the code. If you try to use audio to skip looking at the code entirely, you are not vibe coding anymore, you are vibe approving, and you will ship bugs.
Day six was OpenAI Codex CLI, which I hadn't tried before. Mostly because I kept forgetting it existed. Similar to Gemini in terseness. Different in reasoning style. The audio flow worked but wasn't transformative. I kept coming back to the pattern from day one. Claude Code plus audio is where the experience shines brightest, because Claude is the most verbose agent. More words means more parallelism opportunity. Which is the unintended joke of the week — the tool that people complain is too wordy is actually the one where the wordiness is the feature, as long as you're consuming it through a different channel than your eyes.
Day seven I went back to my default setup. No experiment. Just work. And I realized I'd internalized the audio loop so completely that I was selecting text without thinking. It wasn't a gimmick I had to remember, it was just — how I consumed agent output now. Email came in while Claude was explaining something. I read the email while the explanation played. Slack DM. Handled it. Went back to the diff. The audio played through. I hit approve.
That, for me, was the real test. Not whether audio is faster, but whether it disappears into the workflow. Tools that make you think about the tool are friction. Tools that make you think about the problem are value. By day seven the audio was in the second category.
A couple of specific tips if you try this yourself. One, 1.5x is almost always the right speed for agent output. 2x works for lists and bullet points but not for dense reasoning. I tried 1x for one afternoon and felt like I was listening to a meditation app. Two, don't try to listen while typing code. The audio works when you're reading diffs, plans, summaries, error messages. It does not work when you're actively writing, because your brain can't produce prose and consume prose at the same time. Three, if the audio finishes before your eyes finish — which happens, with short outputs — just keep reading normally. Audio is a supplement, not a master clock.
I am curious what happens when the next generation of agents gets even more verbose, or even less verbose. My guess is verbose wins, because richer reasoning gives better output, and verbose is where audio pays off. But the tools will keep changing. What I think sticks is the pattern. Eyes on code. Ears on explanation. Keyboard ready for the next prompt. It's a triangle the tools are still figuring out, and it's a triangle that each developer will wire up differently.
For me, it turns out, it wires up through a little orange bubble on the edge of a text selection.
Not the ending I expected. But here we are.
Related Reading
More ways to use audio in your coding workflow.
