Ski Makes Voice Coding On-Device

Ski is a free on-device voice coding app from the heyski.io project for Claude Code, Anthropic's coding agent, Codex, OpenAI's coding agent, Hermes, and other agents that can use skills. It deals with a real annoyance: long agent prompts are easier to say than type, but spoken prompts are easy to mis-send. The useful takeaway is simple: treat voice as a fast input layer, not an approval layer. The safe way to implement code review habits for ai-generated code around Ski is to review the transcript before send, then review the diff after the agent runs.

On-device voice coding is a local workflow where speech is transcribed on your machine before being sent to a coding agent. Ski's pitch, as described in the Show HN post and project page, is that transcription runs locally, you can optionally review and edit the transcript, and the connected agent can talk back with updates, summaries, or answers through a skill. For Cursor, Anysphere's AI code editor, users, that makes Ski interesting in a very practical way: it can sit beside an IDE workflow without asking you to turn every coding task into ai coding training for teams.

Let speech capture intent, not authority

Ski is most interesting because it separates saying the task from granting trust. You speak a request, Ski transcribes it locally, and you can inspect the text before it goes to the agent. That small pause matters.

A good voice prompt is usually high-level: fix the flaky test, trace the auth failure, summarize what changed since the last commit. A bad voice prompt tries to dictate exact syntax, file paths, and edge-case conditions from memory. Voice is fast, but it is not precise in the way a patch is precise.

The trap is assuming on-device transcription means the whole coding loop is local. Ski's transcription can run on your machine, but the connected agent may still call its own remote service depending on whether you use Claude Code, Codex, or another agent. Local input is a privacy improvement for speech capture; it is not automatically an air gap.

A concrete Cursor workflow looks like this: open the repo, check the current diff, say the task into Ski, edit the transcript, send it to the terminal agent, then inspect the patch in Cursor before accepting anything. That keeps the IDE as the review surface instead of turning the voice app into a rubber stamp.

Compare Ski with typed agent prompts

Voice coding is not better than typing for every task. It is better when the hard part is explaining the shape of the work, not spelling every token correctly.

Verdict: Ski wins when the prompt is mostly natural language intent and you want a local speech step before the agent sees it. Typed prompts win when exact identifiers matter. Unattended runs win only when the repo has tests, small scope, and reviewable checkpoints.

This is the same lesson showing up across agentic coding: the interface can change, but the review boundary still matters. Model routing work such as Tokenless Routes Agents to Cheaper Models asks a related question from another angle: where should the system make decisions automatically, and where should a person keep the wheel?

Try Ski on a repo that cannot hurt you

Start with a scratch branch and a boring task. Ask Ski to help update a README section, add a small test, or explain a failing local command. Do not begin with a migration, a secrets-related task, or anything that can push, deploy, delete, or rewrite history.

For Cursor users, keep the first experiment visible and reviewable. Cursor rules can make that explicit in the repo, so the agent sees the same boundary every time. This is where lightweight ai coding governance helps without turning the story into process theater; keep the rule small enough that you would actually maintain it.

Create a local rule like this:

---
description: Safe boundary for Ski voice-driven agent runs
globs: **/*
alwaysApply: true
---

For voice-started agent tasks:
- Work on the current branch only.
- Do not run destructive commands such as rm -rf, git reset --hard, or git push.
- Before editing, summarize the intended files.
- After editing, summarize the diff and tests run.
- If the transcript is ambiguous, ask before changing code.

The gotcha is scope. A global rule that says be careful is easy to ignore. A repo-local rule that names the dangerous commands and expected receipts is much harder to misread.

If you want the broader review-guardrail frame, keep it next to the related training topic, but do not let that abstraction swallow the experiment. Ski is a local operations story first: voice in, agent work, spoken or written summary out, human review before merge.

Copy this safe-run review checklist

Use this when you try Ski for the first time. It is deliberately small. The point is to make the voice path feel as reviewable as a typed prompt.

• Start from a clean working tree or a scratch branch.
• Pick one task that should touch one to three files.
• Speak the prompt, then read the transcript before sending it.
• Remove vague phrases like clean this up unless you add a boundary.
• Ask the agent to name intended files before editing.
• Keep Cursor open to the diff while the agent works.
• Run the smallest relevant test or typecheck before judging the result.
• Review generated code like human code: behavior, edge cases, naming, and deletions.
• Reject or revert any change you cannot explain in one sentence.
• Save the final prompt and summary if the patch becomes a pull request.

This is the practical place to implement code review habits for ai-generated code: not in a giant policy document, but in the moment between transcript, patch, and merge. The voice prompt can start the work. The diff still has to earn trust.

Common questions

• What are the best ways to implement code review habits for ai-generated code?

  Start by reviewing the prompt, the generated diff, and the test result as three separate artifacts. For Ski, that means checking the transcript before it reaches the agent, then checking the changed files in Cursor before accepting the work. A ten-line checklist beats a vague reminder to review carefully.

• Does Ski replace typing prompts into Claude Code or Codex?

  No, Ski replaces some typing with local speech transcription. You still need to review the transcribed instruction and the resulting code. It is best for conversational task framing, quick summaries, and hands-busy debugging notes, not for prompts where exact file names, API signatures, or shell commands matter.

• Is on-device voice coding private enough for work repos?

  It depends on the rest of the chain. Ski describes its transcription as completely on-device, which is useful for spoken input. But the connected coding agent may still send prompts, code context, or tool output to its own service, so check your agent settings and company rules before using it on sensitive repositories.

• Where does this fit with engineering team ai adoption?

  It fits as a small workflow experiment, not a grand program. Let one developer try Ski on a low-risk repo, save the transcript, diff, and test result, then discuss whether voice improved clarity or just added another step. The artifact to compare is the patch, not the novelty of speaking.

Best ways to use this research

• Best for: Developers who already use Claude Code, Codex, or another skill-aware coding agent and want a faster way to express intent without losing review control.
• Best first artifact: A repo-local Cursor rule plus the safe-run checklist above. Keep it close to the code so the boundary travels with the work.
• Best comparison angle: Compare voice prompts against typed prompts on the same small task. Measure whether the transcript captured intent cleanly and whether the final diff was easier to review.
• Best limitation to remember: On-device transcription does not mean the coding agent, model call, MCP server, or repo integration is local. Treat each hop separately.

Further reading

• Ski project page
• Claude Code — getting started
• OpenAI Developers — Codex quickstart
• Cursor Docs — rules
• Model Context Protocol — specification

Next step

Try Ski on one scratch-branch task where the expected diff is small. If the transcript, patch, and test result are all easy to review, the workflow is worth a second experiment.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.