Filler words are not the hard part. Knowing what to keep is.

The ten-second demo

A voice demo can look very impressive in ten seconds. Someone talks. There are a few “umms”. Maybe a repeated phrase. The final text appears without them. Clean. Magic.

But filler-word removal is probably one of the least interesting parts of the problem. The difficult question begins immediately after: what else are you allowed to change?

That question has occupied a surprising amount of our thinking while building Lungoor.

Speech is not badly written text

It is tempting to treat spoken language as a noisy version of writing. Transcribe it, remove noise, add punctuation, done. But speech has its own structure.

Take this: “I think we should maybe hold the release till Monday because the API thing is still not completely sorted.”

There are several possible transformations. You could write: “We should delay the release until Monday because the API issue is unresolved.” Looks reasonable.

Except something changed. “I think” disappeared. “Maybe” disappeared. “Not completely sorted” became “unresolved.” The final sentence is more decisive than the speaker was.

Depending on the context, that may be helpful. It may also be wrong.

A more aggressive model can produce output that looks objectively better while being less faithful.

Cleanup has a risk budget

Internally, I think about voice cleanup as having a kind of risk budget.

Some changes are low-risk: remove duplicated filler, fix obvious punctuation, join a sentence that broke because of a pause, correct an accidental repeated word.

Other changes have much higher semantic risk: change uncertainty into certainty, infer an owner for a task, replace a vague reference with a specific one, change criticism into agreement, add a conclusion the speaker never actually made.

The more useful AI becomes, the easier it is to overstep. This is an unusual engineering problem because a more aggressive model can sometimes produce output that looks objectively better while being less faithful.

Confidence is not intent

Speech models are getting very good. Language models are getting very good. That does not mean the system always knows what the person meant. A model can be extremely confident about the wrong interpretation.

That matters when a casual thought becomes an email, task, product decision or client message.

So a lot of the work behind a product like Lungoor is not asking: can the model rewrite this? It almost certainly can. The harder question is: should it?

Context helps, but context also creates responsibility

If Lungoor knows that you are writing an email, it can make useful formatting decisions. If it knows you selected an existing paragraph, it can treat your next instruction as an edit rather than fresh dictation. If you say “make this shorter”, the selected text provides clear context.

These are good constraints. Constraints make AI more predictable. But every additional piece of context also gives the system more opportunity to infer.

That means architecture matters. We want enough context to make the experience intelligent, but not so much hidden inference that the user stops knowing why the output changed.

The ideal output is not always the prettiest one

This is something engineers have to remind ourselves of. Optimising for the nicest-looking generated sentence is easy to measure visually. Optimising for fidelity is subtler.

Sometimes the correct result contains uncertainty. Sometimes it contains personality. Sometimes the person genuinely talks in short fragments. Sometimes a slightly imperfect sentence sounds much more like them than the polished one.

So “better writing” cannot simply mean “more formal”. For Lungoor, the more useful definition is: less accidental mess, same underlying thought.

Voice commands make this interesting

One reason I like explicit voice instructions is that they make transformation intentional. There is a meaningful difference between Lungoor automatically deciding to make your paragraph shorter and you saying: “Make this shorter.”

Likewise: “Turn this into bullets.” “Translate this into Hindi.” “Make it more professional.”

Those instructions give us permission to transform. The user has moved the boundary. Now the system can be more opinionated because the person explicitly asked it to be. That makes the architecture cleaner and the behaviour easier to trust.

The invisible engineering goal

Users should never have to think about semantic risk budgets. That is our problem. They should be able to speak, select, rewrite and continue working.

But underneath that simple flow, we need to keep asking a fairly difficult question: did we make this clearer, or did we accidentally make it different? The difference between those two is where a lot of the real work lives.