Code Comments Are Writing, and Nobody Optimizes for Them
There is a strange gap in how developers think about their tools. We will spend an afternoon configuring our editor to autocomplete a function name, and then spend the same afternoon typing comments, TODOs, and pull-request messages by hand, one slow sentence at a time, as if prose were beneath our tools.
Nobody optimizes for the writing developers actually do. The code gets all the autocomplete, and the words around the code get nothing. That is backwards, because developers write a lot of words, and they write the same kinds of words over and over.
The prose hiding inside your code
If you're a developer, you write prose all day without calling it that. The comment explaining why the code is the way it's. The TODO that says what still needs doing. The PR description that tells your team what changed and why. The code review comment that points out a problem without being a jerk about it. The message in the team chat explaining what you just shipped.
None of that's code. All of it's writing, and most of it follows shapes you've typed before.
The "why is this weird" comment. The "don't touch this" warning. The "this should be refactored but" confession. Developers type these sentences constantly, and they're near-repeats, the same shapes with different specifics, which is exactly the kind of writing a model that has learned your phrasing can finish for you.
Why it is a writing problem, not a code problem
Here is the thing I keep coming back to. The reason code autocomplete works is that code is repetitive, and the reason it doesn't help with comments is that comments are prose, and prose is a different kind of repetitive. A function name is predictable in a way a sentence isn't, but a comment that starts "this is intentionally" is predictable in its own way, because developers have a shared vocabulary of comments, the shapes everyone types to explain the same situations.
WriteAmp works in code editors, but it's not a code autocomplete. It reads the sentence you're typing and finishes it, whether that sentence is a function call or a comment explaining why you didn't use the cache. In an editor, it handles both, and the comment side is the one nobody else optimizes for. I wrote about how the whole pipeline works in another post, and the short version is that it watches the field you're in and adapts, code or prose.
The honest scope note
I want to be straight about the boundary, because the developer audience deserves precision. WriteAmp isn't a code completion tool. It won't autocomplete your variable names better than your editor's built-in tooling, and it's not trying to. It is for the words around the code, the comments, the TODOs, the PR text, the chat messages. Your editor owns the code autocomplete. WriteAmp owns the sentences.
There is a second honest note about where it works in an editor. Code editors can opt into mid-line completion, and the way WriteAmp behaves in a code file is tuned for the comment and prose context, not for trying to out-guess your editor at code. If you want the code-side completion too, you keep both running, and they don't fight, because they're doing different jobs.
If you are a developer who writes comments all day and has never had autocomplete for them, the first week is a small revelation. The "why is this weird" comment finishes itself, the PR description stops being a blank-page dread, and you start writing better comments, because the mechanical cost of writing them just dropped.
The developer setup
If this sounds useful, here's the honest setup. Let WriteAmp run in your editor alongside your existing code completion. Give it a few days to learn how you phrase things, because your comments have a voice, the way you explain "this is ugly but it works" is yours, and the history is what lets it match that voice. You can read what it has learned or wipe it, and it never sends anything anywhere, which matters when the code you're commenting on isn't yours to talk about. I wrote about the client-confidentiality angle for exactly that situation.
The trial is free for 30 days if you want to feel what autocomplete for the words around your code is like. Code comments are writing, and writing deserves the same tooling treatment that code has had for a decade. The gray words were always for the sentences. It just took a while for someone to point them at the sentences developers actually type.
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.