Ski Runs Voice Coding Locally
Ski is a Show HN project from heyski.io that adds on-device voice control to coding agents. Talking through a change is often faster than typing the perfect prompt, but sending raw speech into an agent can feel risky. Voice is a good way to capture intent, but the review boundary still belongs at the transcript and the diff. Use the microphone to move faster, then implement code review habits for ai-generated code where the code actually changes.
Ski is an on-device voice layer for agents such as Claude Code and Codex. The creator's July 30, 2026 Show HN description says Ski transcribes your voice locally, lets you optionally review and edit the transcript, sends it to the connected agent, and can have the agent speak project updates back through a skill. That shape matters for Claude Code users because it turns voice into a local prompt interface, not a new authority model.
A shorter companion note on Ski Makes Voice Coding On-Device covers the project at a glance. This piece slows down on the operating detail: where voice helps, where it gets weird, and how to try it without handing your repo to a half-heard sentence.
Watch the transcript before the agent acts
The best part of Ski's design is the pause between speech and action. According to the project description, the transcript can be reviewed and edited before it is sent to the agent. That is the safety valve.
A spoken request like this is normal:
Refactor the account settings page so the billing panel uses the same loader as the profile panel, and add a regression test.
Watch for that speech often smears intent. Did you say billing panel or billing page? Same loader or same loading state? In a typed prompt, you catch that while writing. In a voice prompt, the transcript review step is where you catch it.
For Claude Code, this pairs nicely with a small repo convention. Keep durable rules in a concise CLAUDE.md, then make the voice transcript task-specific. The repo memory says things like do not change generated files or use pnpm, while the spoken prompt says what to change today.
Compare voice prompts, typed prompts, and unattended runs
Ski is interesting because it does not try to replace the coding agent. It sits beside the agent and changes the input and feedback loop. That makes the comparison less about model quality and more about control.
| Criteria | Ski voice prompt | Typed agent prompt | Unattended agent run |
|---|---|---|---|
| Input speed | Fast for messy intent, especially when describing UI or multi-step bugs | Slower, but precise by default | Fastest once queued, but weak for ambiguous work |
| Review point | Transcript before send, then diff after agent work | Prompt before send, then diff after agent work | Mostly diff after completion unless you add checkpoints |
| Privacy shape | Project says transcription runs completely on-device | Depends on the agent and terminal workflow | Depends on agent permissions, tools, and connected services |
| Best fit | Explaining a change you already understand | Precise edits, migrations, risky data work | Mechanical refactors with tight tests |
| Main failure mode | Misheard or underspecified speech becomes a confident task | Overlong prompts hide the important constraint | Agent runs too far before a human notices |
Verdict: Ski wins when you can describe the change faster than you can type it and you are willing to inspect the transcript. Typed prompts win when exact names, file paths, or API contracts matter. Unattended runs win only when the task is boxed in by tests, permissions, and a narrow command path.
Let the agent speak, but make the diff the record
Ski also flips the output side. The creator describes an agent using a skill to talk about project updates, summaries, or queries by voice. That is a nice fit for local agent work, because a spoken status update can pull you back into the loop without making you read a whole chat transcript.
The gotcha is obvious: spoken summaries are not evidence. They are orientation. The evidence is still the patch, the test output, and the command log.
A good Claude Code rhythm looks like this:
Voice: Fix the settings loader mismatch and add the missing regression test.
Agent: Works through the repo.
Voice summary: I changed SettingsBillingPanel and added a test for the loading state.
Human check: git diff, test command, changed files, risky assumptions.
If your agent has Model Context Protocol access to external systems, keep that separate in your head. MCP is the integration layer for tools like issue trackers, docs, databases, and design systems. Voice should not blur whether the agent is allowed to read a ticket, write a comment, or modify code.
Try Ski in a throwaway branch first
Start with a boring repo task. Not auth. Not billing. Not migrations. Voice coding is easiest to judge when the change is small enough that you can review the whole diff in one sitting.
This is also the practical place to connect the story to agentic coding governance without making the tool feel heavier than it is. If you are doing AI coding training for teams, the useful lesson is not use voice everywhere. It is this: separate intent capture from code acceptance.
Copy this review checklist into the pull request or your local notes:
## Ski local voice trial receipt
Task spoken:
- What I asked Ski to send to the agent:
Transcript checked:
- I reviewed the transcript before sending: yes/no
- Words or identifiers I corrected:
Agent boundary:
- Branch name:
- Agent used: Claude Code / Codex / other
- External tools allowed: none / read-only / write-capable
- MCP servers allowed, if any:
Diff review:
- Files changed:
- Tests run:
- Generated files touched: yes/no
- Public API or database changes: yes/no
- Security, auth, billing, or permissions touched: yes/no
Human verdict:
- Accept as-is / edit manually / ask agent for a smaller patch / discard
- One reason:
The one gotcha to watch: do not let a clean spoken summary replace a dirty diff review. The whole point is to move faster to the review, not around it. If you want to implement code review habits for ai-generated code, make this receipt boring and mandatory for the first few local trials.
A tiny slash-command-style handoff can help too. Save a reusable prompt called review-agent-diff in whatever command workflow you already use:
Summarize the current diff in five bullets.
Call out changed behavior, tests run, files touched, and any risky assumption.
Do not claim success unless the relevant command output is present.
That command is not fancy. It just keeps the agent's last word tied to files and commands instead of vibes.
Further reading
Next step
Try Ski on one throwaway branch with a change you can fully review in ten minutes. If the transcript check saves time and the diff review still feels boring, the workflow is doing its job.