<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Daksh Verma</title>
    <description>The latest articles on DEV Community by Daksh Verma (@daksh_verma).</description>
    <link>https://dev.to/daksh_verma</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3925607%2F7ae85cc2-e28c-401f-bdfc-9e19dfac420f.jpg</url>
      <title>DEV Community: Daksh Verma</title>
      <link>https://dev.to/daksh_verma</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/daksh_verma"/>
    <language>en</language>
    <item>
      <title>Why waiting longer makes voice AI worse</title>
      <dc:creator>Daksh Verma</dc:creator>
      <pubDate>Sun, 02 Aug 2026 09:53:38 +0000</pubDate>
      <link>https://dev.to/daksh_verma/why-waiting-longer-makes-voice-ai-worse-1g2a</link>
      <guid>https://dev.to/daksh_verma/why-waiting-longer-makes-voice-ai-worse-1g2a</guid>
      <description>&lt;p&gt;Most voice agents decide you are done talking by measuring silence. Voice activity detection flags the audio as speech or not speech, a timer runs during the not-speech, and when the timer crosses a threshold the turn ends and generation begins.&lt;/p&gt;

&lt;p&gt;It is a reasonable first architecture. It is also wrong in a way that gets worse the more natural the conversation gets.&lt;/p&gt;

&lt;p&gt;The failure looks like this. Someone is thinking while they speak. They pause mid-sentence, because that is what people do when they are constructing a thought rather than reading one out. The pause crosses the threshold. The system ends the turn and starts responding, and the user gets cut off by a machine, mid-thought.&lt;/p&gt;

&lt;p&gt;The fix that presents itself immediately is to raise the threshold. Wait longer before deciding the turn is over.&lt;/p&gt;

&lt;p&gt;This is the part worth writing down: raising the threshold trades one failure for a worse one. Latency in conversation is not a smooth cost curve. Below a certain point people do not perceive a delay at all. Above it, they perceive a system that is slow, and slowness in a voice interface reads as broken in a way that visual latency does not, because there is no spinner, no loading state, nothing to indicate the machine is alive. Silence from a voice agent is indistinguishable from failure. So you push the threshold up to stop the interruptions, and you lose the thing that made the product feel real.&lt;/p&gt;

&lt;p&gt;Both ends of the tuning range are bad. That is the actual shape of the problem, and it is why threshold tuning is not the answer at any value.&lt;/p&gt;

&lt;p&gt;The reframe that helped: silence is the weakest available signal for a decision this important, and it is the only one a pure VAD approach is using. Humans do not detect turn ends by timing gaps. We use syntax, whether the clause has resolved. Prosody, whether the pitch fell into a terminal contour or stayed suspended. Semantics, whether the thing said is complete enough to answer. We are running a continuous prediction of whether the other person is finished, and we start preparing our response before they actually stop.&lt;/p&gt;

&lt;p&gt;Which points at a different architecture. Instead of a timer that fires on silence, run a lightweight endpointing model over the partial transcript that outputs a probability the turn is complete, and let silence be one input to that rather than the whole decision. A trailing-off pause after a resolved clause and a pause mid-clause are the same event to a VAD and completely different events to anything that reads the text.&lt;/p&gt;

&lt;p&gt;The second piece is decoupling detection from commitment. A turn-end prediction does not have to be a single irreversible decision. You can begin generating on a probable endpoint and cancel cheaply if the user resumes. That converts a hard classification problem into a soft one, and soft problems tolerate being wrong.&lt;/p&gt;

&lt;p&gt;None of this is solved. Barge-in handling, cancellation cost, and what happens when the user talks over the response are all still open on my end, and I would rather write about them while they are open than after I have tidied them into a conclusion.&lt;/p&gt;

&lt;p&gt;If you have shipped real-time voice, I want to hear what your endpointing actually looks like in production, particularly what you do when the prediction fires early and generation has already started.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>voice</category>
      <category>architecture</category>
      <category>llm</category>
    </item>
  </channel>
</rss>
