Voice coding in a shared workspace: make room for speaking and quiet work
One developer wants to explain a change aloud to a coding tool. A colleague nearby is tracing a difficult bug and needs quiet. Another person wants to read a proposal before discussing it. How can the team support all three?
Voice coding means using spoken input as part of software development. That can involve dictating text, issuing commands or describing a task to an AI coding agent, a tool that can take actions on a coding request. The way someone enters a request does not tell you whether the resulting change is correct.
The practical question is how voice fits the work, the space and the people around it. A short team agreement can make the arrangement clearer without requiring everyone to work in the same way.
Why have this conversation now?
In LeadDev’s 26 October 2026 report on engineers coding out loud, developers describe using speech to work with coding tools. The article also discusses background noise, recognition mistakes and the discomfort of speaking around other people. Those are reported experiences, not proof that voice improves every developer’s productivity.
Before recommending a microphone or a new routine, agree how colleagues will work alongside it. Start with one task and one week. Keep the arrangements open to change as people discover what helps.
Agree four things before the trial
1. Start with the person and the task
Purpose: Understand what support is needed before choosing the arrangement.
Ask what the person needs to do, which parts benefit from speech and which parts require reading, listening or another input method. Avoid assuming that everyone can simply switch to typing. Speech may be someone’s preferred way of working or an important access need.
The W3C Web Accessibility Initiative’s accessibility principles explain that different input methods can help different people, and that not everyone can use every method to the same degree. Its guidance concerns web accessibility; the team arrangements here are practical suggestions, not an accessibility assessment.
Discuss the working conditions needed without asking people to explain private medical circumstances to the whole team. Make tool adoption optional for colleagues who do not need or want speech.
2. Plan the space and the audible content
Purpose: Make speaking possible while protecting concentration and appropriate boundaries.
Distinguish a desk in a shared room, a space suitable for conversation and a public place. A microphone that captures your words clearly does not make those words inaudible to nearby people. Headphones can contain the tool’s replies, but your own speech still needs consideration.
Agree a suitable location, timing or other practical arrangement with the people affected. If speech is needed throughout the day, a small occasional booking is unlikely to meet that need. Involve whoever can arrange an appropriate workspace rather than leaving the person to solve it alone.
Also agree what should not be spoken where others can hear it. Use a made-up account and sample data for the trial. Check the approved tool’s recording and data-handling settings separately; do not assume that ending a conversation deletes a recording.
3. Keep a shared record of the work
Purpose: Give reviewers the information they need without making them hear every request.
Choose a reviewable output: the proposed change, its reason and the checks completed. Keep the relevant work record available to colleagues using their usual accessible tools. A private conversation with an agent should not become the only place where a team decision exists.
For a coding change, record the files affected, the intended behaviour and the results you actually checked. If the spoken request was misunderstood, correct the request and inspect the result. Speaking “that is finished” is not evidence that the agreed behaviour works.
4. Review the arrangement, not someone’s confidence
Purpose: Judge whether the work and working conditions are improving.
At the end of the week, ask whether the task was completed, whether the output was reviewable and whether people could concentrate. Note extra correction or coordination work as well as any convenience. Do not treat how confidently someone speaks to a tool as a performance measure.
Agree what to keep, change or stop. A colleague should be able to raise a problem with the arrangement without making it a complaint about the person using speech.
A worked example: the shared desk is the constraint
Adam is changing the wording on a report export screen. Speaking helps him explain the sequence to an approved coding agent. Elliott, at the next desk, is investigating a database issue and needs uninterrupted concentration. Jo will review Adam’s change later.
Their first idea is a fifteen-minute voice slot at the shared desks. Elliott points out that the timing overlaps an investigation session. Adam explains that he may need several short conversations, not one long request. They ask the workspace coordinator for a conversation-friendly desk for the morning, while keeping Adam’s normal accessible equipment available.
The trial uses a sample project with invented details. Adam asks for the export confirmation to name the report and explain which filters apply. He inspects the proposed wording and records the cases she checked, including returning to the report without exporting it.
Jo receives the change and review note, rather than a recording of Adam’s entire session. The note identifies an unanswered question about whether the download should include hidden columns, so the team can resolve it explicitly. At Friday’s review, they will check whether the workspace arrangement was available when needed and whether it created extra effort for anyone.
Write a one-week working agreement
Choose a small real task, fill in the agreement with the people affected and check that the workspace is actually available. Review the result after a week. If the arrangement works for only one person, change the arrangement before expanding the trial.
You May Also Like
Creating an Agile Glossary: The Unsung Hero of Clear Communication
When everything is urgent: how to have a useful priorities conversation
