When in Doubt, Give Them Their Own Words

Say this out loud: “Let’s move the review to Tuesday. No wait, Thursday.”

Any human hears Thursday. Our model heard a scheduling conflict.

Speech is full of these little repairs. We make them constantly and handle them so easily we don’t notice. Models notice. Getting them right is harder than it looks.

The billboard the model drove past

This summer we fine tuned a small cleanup model for Pomvox, the open source dictation app I work on. Its whole job is to take the messy text that comes out of speech recognition and turn it into what you meant to write: punctuation, capitals, no “um” or “like”, and those spoken repairs resolved. It runs on your Mac, and your words never leave it.

We knew self corrections would be the hard part, so we planned for them. A quarter of the training data was sentences like the one above.

The model still missed them.

A quarter of the training data. That’s not a hint. That’s a billboard. The model drove right past it.

It wasn’t every time, and it wasn’t dramatic. But it happened often enough that we couldn’t pretend the data had solved it. We did the work, and the model surprised us anyway.

Plan the bad day first

At that point you can go two ways.

The first is more data, better data, one more training run. That’s worth doing, and we’re doing it. But more data is the “let me just add one more slide” of machine learning. Sometimes it helps. It never finishes.

It also rests on an assumption I’ve learned to distrust after twelve years of shipping software: that with enough effort, the failure goes away. It doesn’t. It gets rarer. And rare is a statistic. For the person it happens to, it’s one hundred percent.

The second way is to ask a different question. Not “how do we stop the model from being wrong?” but “what does the person see when it is?”

That question shaped the cleanup engine more than any training run did.

If cleanup fails, you get your own words back. Exactly what you said, untouched. It’s a bit messier, maybe with a stray “um”, but it’s yours and it’s accurate. The smart feature’s worst case becomes the plain feature’s normal case.

If cleanup is slow, it stops. Every request has a deadline. When it passes, the engine gives up cleanly, and a late answer is thrown away instead of pasted over whatever you’ve moved on to. A late correct answer is autocorrect fixing your text after you hit send.

Every result shows what changed. The engine returns more than the final text. It returns the edits it made, the outcome, which model and version made them, and how long each step took. If the only way to debug is squinting at the output, you don’t have a log. You have a mystery novel.

None of this makes the model smarter. All of it makes the model’s mistakes cheap.

Make mistakes cheap

For most of my career, reliability meant prevention: tests, reviews, regression suites, the long march to zero. I’d do all of it again. But with a model in the loop, prevention has a ceiling. You can’t write a test for every way someone says “no wait.”

So the job changes. You stop working only on how often a mistake happens and start working on what each one costs. A wrong answer that’s easy to spot, cheap to undo, and falls back to something true is one product. A wrong answer that looks confident and goes straight into an email to your boss is another. That one isn’t a bug. It’s a career event.

I’ve written about the Verification Tax, the human effort it takes to check what AI produces. This is its quieter sibling. Good design doesn’t only make checking faster. It makes some checks unnecessary, because the worst outcome is already fine.

Same question, bigger building

I’ve seen this pattern outside Pomvox. When we put our first LLM agent into production for financial aid, where a wrong answer lands on a real student, the conversations that mattered most weren’t about accuracy on a good day. They were about the bad one. Who sees it? What does the system do instead? How fast can a person step in?

A weekend dictation app and an enterprise agent look nothing alike. The question that makes them safe to ship is the same.

Before you celebrate the eval score

Ask three questions:

1. When this is wrong, what does the user see? If the answer is “something that looks right,” start there.

2. What is the honest fallback? There’s almost always a simpler, duller, true answer. Make it the default for failure.

3. Can anyone tell what the model did? If not, every mistake becomes an investigation.

In the garden, you don’t plant as if frost won’t come. You plant so the frost doesn’t take everything. The good seasons take care of themselves. The design work is for the cold nights.

Fall back to their words. Stop when you’re late. Show your edits.

And remember: Tuesday was never the plan.

---

Pomvox is free and open source. The cleanup engine and the fine tuning notes behind this piece are on GitHub and the Pomvox blog.