Dibur: Review a Voice Request Before a Coding Agent Starts

“Add a test for login and leave the API unchanged.” Imagine saying that in Hebrew while keeping login and API in English. The words are easy to say. Before a coding agent receives them, there are several things to get right: the transcript, the project folder, the selected agent and the point at which the user agrees to start.

I’m Daniel Goldman, the developer of Dibur, a Hebrew dictation application. It connects speech to text and can hand a reviewed request to an installed coding agent such as Claude Code or Codex. This case looks at the handoff described in the public Mac agent guide. The example request is illustrative; it is not a customer result or a report of a completed coding task.

The speech model is one part of the product

Dibur builds on Handy and a Hebrew speech model from ivrit.ai. That distinction matters: developing an application around speech recognition is different from training the underlying model. The product work includes Hebrew defaults, handling developer vocabulary and giving the user a way to review what will go to the next tool.

A developer can mix a Hebrew sentence with an English file name or command. A plausible transcript still needs checking. If “do not change the API” loses its negation, fluent text is the wrong instruction. The useful check is whether the request preserves the intended constraint, not whether it looks like a well-written sentence.

Separate dictation from the agent handoff

Local dictation and agent execution have different data paths. Dibur can transcribe on the computer. When you approve an agent task, its text is passed to the chosen agent, which may send information to its model provider. “Local transcription” therefore does not mean that every subsequent operation remains offline.

Before sending work from a sensitive project, check both stages. Decide what may enter the transcript and what the chosen agent may access. A folder name is not a complete description of permissions. The agent’s configuration and provider still matter after the handoff. This is a boundary to inspect, not a privacy guarantee created by a microphone button.

Make the request inspectable before starting it

Dibur’s Mac guide describes a launch card where you review the transcript, agent, model and working folder before choosing “Approve and run”. This gives the request a visible destination. A correct sentence in the wrong project is still the wrong task. A familiar agent name alone does not tell you which folder it will work in.

Use the example above to read the card in order. First check that the text still asks for a test and explicitly leaves the API unchanged. Then check the intended project. Finally check the agent and model. If the transcript is wrong, reject the request and record it again. Resolve other incorrect details before starting. This first approval starts the request; it does not promise another approval before every action inside the agent’s run.

A small example with an observable finish

For a practice task, use a project you control and a change you can inspect. “Improve login” leaves several decisions open. “Add a test covering a missing password, without changing the login API” provides a narrower target. You still need to know the expected behavior of that project. A more specific sentence does not make an unverified assumption true.

After the agent runs, compare the changed files with the request and run the relevant test. Check whether it tests the intended behavior and whether unrelated implementation files changed. An agent saying “done” is a status message, not evidence that the test passed. Keep that completion check separate from the earlier decision to approve the request.

What to test when building your own handoff

You can turn this workflow into a short acceptance checklist for your own product. Treat these as proposed tests, not a claim that every scenario has been executed against Dibur:

• Speak a sentence containing Hebrew and an English identifier. Check the identifier and the constraint in the displayed text.
• Choose a request with a clear negative instruction. Confirm it remains visible before approval.
• Inspect the selected working folder before a harmless practice task. Confirm the result belongs to that project.
• Stop before approval and verify what your product does. Define that behavior explicitly instead of assuming cancellation works.
• After an approved practice run, inspect changes and the actual test result. Do not use a successful launch as the completion criterion.

The product decision is where speech becomes an action someone has agreed to. A readable request, a visible destination and a separate completion check make that boundary easier to inspect. They do not remove the need to understand permissions or review generated changes. This is a practical part of building software around agents, even when an agent helps write the implementation.

Dibur: product and local dictation information

Dibur Mac guide: review and start an agent request

Apply this to your first product

If you have a product idea and need help defining what the user approves, what the system does and how the first version will be checked, read about my AI product development work.

Work with Daniel Goldman on AI product development