DEV Community: Julie Elis

Talking your way into an unfamiliar codebase with voice coding

Julie Elis — Mon, 24 Aug 2026 05:01:04 +0000

Reading unfamiliar code is mostly a search problem you can't phrase yet. You don't know the vocabulary of the codebase, so you can't grep for the thing you need, because you don't know what it's called.

So you do the slow version: open the entry point, follow an import, lose the thread, go back, try a different file. An hour later you have a rough map and no idea whether it's accurate.

The fastest way through is the thing you'd do with a colleague who knows the repo, ask a vague question and let them narrow it. That's a conversation, and conversations are much cheaper spoken.

Vague questions are the point

A good first question about an unfamiliar codebase is embarrassingly imprecise: "where does a request actually enter this thing?", "what talks to the database?", "is there a reason there are two config loaders?"

Those are terrible things to type. They feel unserious, so you rephrase them into something more technical-sounding, and the rephrasing smuggles in assumptions you have no basis for, you ask about "the middleware chain" before you know whether there is one.

This is where voice coding earns its keep on a codebase you didn't write. Spoken, you just ask the vague thing. It doesn't have to look good. And the vague version is more honest about what you actually don't know, which makes the answer more useful.

The question you're willing to type has already been cleaned up. The cleaning is where your real confusion went missing.

Follow-ups are where it pays off

Orientation isn't one question, it's twenty in a row, each depending on the last. That chain is where typing gets expensive, not any single prompt, but the twentieth one, when you've been reformulating for half an hour.

Out loud, a follow-up is four words. "Which one runs first?" "Who calls that?" "Is that dead?" You keep asking because asking is free, and the map assembles faster than reading would have built it.

It also survives interruption better. When the answer comes back spoken, you can be looking at the file it's describing rather than at a chat panel, your eyes stay on the code while the explanation arrives.

Point instead of describing

Some questions are much faster shown. A hotkey attaches a screenshot to your next spoken request, so "what is this doing?" can mean this, on screen, rather than a paragraph describing which part of which file you mean.

Half of onboarding friction is locating the thing you're confused about well enough to ask about it. Pointing removes that step entirely.

The day-one version

If you've just been handed a repository, the sequence that works is roughly:

Ask where execution starts, in the vaguest terms you like.
Ask what the three or four main moving parts are, and don't worry about naming them correctly.
Pick the part you'll be changing and ask it to walk you through one real path end to end.
Ask what surprised it, what looks unusual, inconsistent or load-bearing in this repo.

That last one is the question people forget to ask, and it's often where the useful warning lives.

The point isn't to avoid reading the code. It's to know which code is worth reading before you've spent the afternoon finding out. Connect a project and try it on the next repo you inherit.

What actually leaves your machine when you use voice coding

Julie Elis — Fri, 21 Aug 2026 03:51:26 +0000

"Runs on-device" is the easiest claim in software to make and one of the hardest to check. So here's the boring version: a list of everything SKI sends over the network, and everything it doesn't.

The short version:

Your voice never leaves the machine. Recognition and playback both run locally.
Your code never passes through us. SKI is a skill your agent loads, not a proxy in the middle.
Four things touch the network, and none of them carry audio, code, or transcripts.

What never leaves

Speech-to-text runs entirely on your machine. Your spoken input becomes text before anything else happens to it, there's no upload step where audio is sent somewhere to be transcribed and sent back.

Text-to-speech runs locally too, using one of four on-device neural voices. The reply you hear is synthesized on your own hardware.

Both halves of the loop work with no network connection at all. That's the practical test, and it's the one worth running yourself: pull the wifi and keep talking to your agent.

Why we're not in the middle of your code

This is the part people assume wrong, and it's the more important half. SKI doesn't sit between you and Claude Code's or Codex's model, it installs a shared skill your agent already knows how to read, teaching it that voice I/O exists...

Read the full article here: heyski.io/blog/is-voice-coding-private

Why Walk When You Can SKI: Ditching the Type-Wait-Check Loop for Voice Coding

Julie Elis — Mon, 17 Aug 2026 05:25:20 +0000

Typing a prompt to an AI coding agent is a lot like walking: controlled, deliberate, one careful step at a time. You form the whole thought in your head, then convert it into keystrokes one clause at a time, checking yourself along the way. It works. It gets you there. It's also not how the thought showed up in your head in the first place, you already had the sentence, whole, before your fingers caught up to it.

There's a faster way to move through a thought, and it doesn't involve typing it out at all. You just say it.

That's the whole pitch behind SKI, a free tool that gives Claude Code, Codex, Cursor, and other agents a voice in both directions, you talk instead of typing, and the agent answers you out loud instead of just printing text. Here's what actually setting it up looks like.

1. Download it

Grab it from https://heyski.io - Mac (Apple Silicon, macOS 14.4+) or Windows (x64). No Linux build yet.

2. Run onboarding

First run has you pick a widget, a floating pill, or a notch bar under the camera housing on a MacBook, choose a speech model, and install SKI's skill into your coding agents in one click. That skill install is what actually lets an agent understand voice input and know it can speak a reply.

3. Connect a project

Open your normal session, Claude Code, Codex, Cursor, whatever you're running, inside your project folder, and type ski once. The agent connects on its own; you'll see the project name and a green dot appear on the widget.

4. Talk instead of typing

Hold fn/Globe (or click the widget), say what you want, let go. SKI transcribes it locally and hands it to the agent exactly like typed text would be. No conversion step, no "let me phrase this properly", just the thought, as-is.

5. Let it answer instead of checking back

This is the actual point of the whole thing: the agent speaks up on its own when it's done or needs a decision, "tests pass, want me to commit?", and you answer by voice without walking back to the terminal. If you're running more than one project, each one can use a different agent and a different voice, so you know who's talking without looking.

6. Mute whenever

fn/Globe, Space after clicking the widget, a hotkey, or the widget's own mute button. It actually releases the mic at the OS level, the orange indicator on macOS turns off, which a lot of voice apps don't bother doing.

What's actually running where

Speech-to-text and text-to-speech both run on your machine. Nothing about your voice or your code gets uploaded, and it works offline. What you say to the agent still goes to that agent's own LLM, same as if you'd typed it, SKI is the voice channel, not the model.

The honest limits

It's built specifically for the agent loop (Claude Code, Codex, Cursor, Windsurf, Gemini CLI, Cline, Kilo Code, Continue, and about 16 more via a shared skill folder), not general dictation for arbitrary apps. English only for now. Apple Silicon only on Mac, no Intel builds.

The voice loop is free for life, no card, no caps. There's an optional paid add-on (AgentCall) if you want your agent to join a live Zoom/Meet/ Teams call as a participant or notetaker, recording a meeting locally and getting a transcript/summary is free and unlimited on its own.

Walking gets you there. This is the other option. If you try it, I'd genuinely like to know what breaks or what you'd want it to do next.