Blog

The Hardest Part Was Teaching It to Stay Quiet

A quiet, minimal scene, the silence that is the feature
Photo by Toa Heftiba on Unsplash

People assume the hard part of building an autocomplete is the model. Make it smarter, make it predict better, and the product improves. That is what everyone assumes, and it's wrong. The model was the easy part. The hard part, the part that took most of the work and most of the fights with my own code, was teaching the thing when to say nothing at all.

I want to tell you that story, because it's the difference between an autocomplete that feels like a helper and one that feels like a backseat driver, and it's the part of the product you never see.

The bug that taught me the lesson

Early on, I had a version of WriteAmp that was, by the numbers, very good at predicting. It suggested constantly, confidently, and it was right a lot of the time. And people hated it. Not the wrong suggestions, they were rare, the right suggestions, arriving at the wrong moments. I'd be mid-thought, in the middle of rewriting a sentence, and the gray words would appear, offering a completion for a thought I had already abandoned. The suggestion was technically correct. It was completely unhelpful, because it was interrupting a decision I was still making.

That is the bug that taught me the real problem. A suggestion that arrives while you're still deciding what to say isn't a helper. It is a person finishing your sentence while you're mid-word, and it makes you want to stop talking. The model was doing its job. The system was failing at the human part, knowing when a suggestion is wanted.

The eager version
Always right, always talking
technically correct,
constantly interrupting
The quiet version
Speaks when it's sure
stays silent while
you're still deciding

The layer nobody sees

So I built a filter, and the filter became most of the product. Before any suggestion reaches your screen, it has to pass a gauntlet of checks. Is it long enough to be useful or just noise? Is it short enough to be ignorable? Would it collide with what you're typing? Does it fit this app? Are you in a place where a suggestion helps, or are you somewhere it would be an intrusion? And the check I care about most: are you still deciding what to say, or have you committed to the sentence?

1
The model suggests something
It's probably right. That was never the problem.
2
The filter asks the real questions
Is it useful? Is it ignorable? Would it land wrong?
3
Most of the time, the answer is silence
Showing nothing is the correct behavior, and it's most of the behavior.

That filter is the part of the product that took the real engineering, and it's the part that never shows up in a screenshot. You can't demo a suppression. You can't put "knows when to stay quiet" in a feature list without sounding absurd. But it's the whole product, because it's what makes the suggestions that do appear feel trustworthy. I wrote about why knowing when to shut up is the feature from the product side, and this is the same story from the build side, the version with the late nights and the log files.

The philosophy that cost me the most time

Here is the principle that made the filter hard, and it's worth stating plainly because it sounds backwards. A wrong suggestion costs more trust than no suggestion ever will. Every time the tool shows you a bad word, it spends a little of the trust it needs to earn the good ones. One wrong suggestion can undo ten right ones, because the wrong one is what you remember. So the only safe strategy is to be wrong as rarely as possible, which means being quiet a lot, which means the filter has to err toward nothing.

That philosophy is expensive. It means the tool misses opportunities to help, because it stays quiet when it's not sure. It means people sometimes type a sentence where a good suggestion was one keypress away, and the tool says nothing, because it was not confident enough. I've made my peace with those misses, because the alternative is an autocomplete that nags, and a nagging autocomplete gets uninstalled. The suppression principle post makes the product case, and the maker case is simpler: I'd rather the tool be quietly right than loudly annoying.

The honest cost

Being conservative means missing some chances to help. People type past moments where a good suggestion was available and the filter said no. That's the price of trust, and I pay it willingly, because the alternative is a tool that erodes its own credibility a little bit every day.

The moment it clicked

I knew the filter was right the first time someone used the tool and didn't mention the suggestions at all. Not "the suggestions are great," not "they're annoying," nothing. They just typed, and occasionally pressed Tab, and never once thought about the tool. That silence was the goal. The filter had done its job so well that the product disappeared into the typing, and the only thing the user noticed was that writing felt easier.

That is the whole maker's arc in one story. The model gives you the words. The filter decides if you should see them. And the filter, the invisible, undemoable, never-in-a-screenshot layer, is the part that turns a clever model into a tool people forget they're using, which is the highest compliment a tool that lives in your typing can get.

The close

The trial is free for 30 days if you want to feel what a filter that errs toward silence is like. The benchmarks show the model's numbers, and the suppression post explains the philosophy, but the real test is a week of typing, noticing that the suggestions that appear are the ones worth taking, and realizing you can't remember the last time one annoyed you. That is the filter working. It is the hardest part, and it's the whole product.

On macOS 26+ Macs, Apple Intelligence mode stays free even after the trial ends — you always keep a working path to suggestions.

Written by Amit Ashwini, who builds WriteAmp and runs its marketing. More: why the Tab key beats the chat box · mini, midi, and max compared · benchmark methodology.