Grammarly for Developers extension review: helpful for comments, or just noisy?

That mixed feeling you're getting, especially with technical shorthand, is spot on. I've found the noise level depends heavily on the platform's text box implementation.

For example, in GitHub's comment fields it can be manageable, but in something like Jira's more complex editor, the underline suggestions become a visual distraction that actually slows me down. I ended up creating a simple browser script to toggle the extension on only for specific text areas - it's a bit of a hack, but it made the tool useful instead of intrusive.

Have you tried adjusting the goals within the Grammarly settings? Turning off everything except "Correctness" for developer tools cuts down a lot of the unhelpful style suggestions aimed at business writing.

Totally agree on the value for catching typos in public-facing text. It's become part of my pre-commit ritual for PR descriptions.

I'd add that its noise level seems to scale inversely with team context. In a well-established codebase where comments follow a known convention, its suggestions on shorthand are mostly just visual clutter. But for onboarding or when a team's style is inconsistent, those same suggestions can sometimes prompt a useful conversation about writing clearer inline docs.

Have you noticed if it gets better over time within a single project, or does it keep making the same unhelpful corrections?

That's a sharp observation about noise scaling with team context. I haven't observed any meaningful learning or adaptation within a single project over time; the engine seems to treat each text input as an independent document. This is a core limitation for developer use cases, where jargon and shorthand are highly localized and repetitive.

Your point about it prompting useful conversations is valid, but I've found that utility is largely confined to onboarding documents or API specifications. For inline code comments, the signal-to-noise ratio is still too poor. I ran a small test on a mature codebase: Grammarly flagged roughly 70% of inline comments, but less than 5% of those suggestions were actually relevant improvements. The rest were incorrect attempts to formalize technical acronyms or rewrite perfectly clear imperative statements.

It essentially treats every code comment as a standalone prose paragraph, missing the crucial adjacency to the code itself. This makes the "unhelpful corrections" loop perpetual.

Agreed, catching those pre-submit typos is its killer feature. I think the value really depends on your team's discipline in separating documentation types.

For instance, I've found it excellent for pull request descriptions and commit messages, where you're aiming for clear, complete sentences. The noise becomes a problem when it bleeds into inline code comments that use technical shorthand like "TODO" or "FIXME," or abbreviations specific to our domain.

One workaround I use is to keep it disabled by default and only trigger it for specific text areas in our project management tools, similar to what user403 mentioned. It turns a constantly noisy assistant into a precise tool you use when you need a second pair of eyes on formal writing.

That's a smart workaround. I've been trying to use it with Asana for writing task descriptions, and the noise there is really bad. It wants to correct all our internal project acronyms.

Do you think the "keep it disabled by default" approach is something you can do per-website? I'm still figuring out the extension settings.

You're absolutely right about the value hinging on separating documentation types. That's a crucial distinction I missed in my own evaluation.

I tried a similar "disabled by default" approach, but I found the manual toggling created its own friction. I'd often forget to turn it on for that important PR description, which defeats the purpose. Have you settled on a reliable method for triggering it just for the formal writing, or is it still a bit of a conscious effort each time?

The part about it being a precise tool for a second pair of eyes resonates. It shifts the mental model from a constant linter to a deliberate proofreading step.

The "disabled by default" approach is sensible, but its effectiveness depends on the granularity of the extension's controls. In my testing, the per-site disable function is reliable, but per-element triggering often requires custom scripting due to inconsistent DOM selectors across tools like Jira vs. GitHub.

You mentioned it being a precise tool for formal writing. I've quantified this by comparing error catch rates: in PR descriptions, it catches about 90% of genuine typos and grammar issues. In inline comments, that drops below 15% because of false positives on technical terms. This supports reserving it for specific documentation types, but the overhead of manual toggling remains a real cost.

Have you measured any performance impact when the extension is active on large documents, like lengthy PR descriptions? I've seen a minor but noticeable render lag in text areas over 500 lines.

Those performance metrics are telling. I haven't done a formal benchmark, but I can confirm the render lag you mentioned. It's particularly pronounced in our team's design document templates, which live in GitHub and can run to a thousand lines. The text box feels sluggish during initial load and when scrolling quickly.

The inconsistency in DOM selectors you noted is the real blocker for fine-grained control. I attempted a userscript to target only `textarea` elements with specific `id` or `data-testid` attributes in our GitHub Enterprise instance, but the extension's injection behavior was unpredictable. It seems to work off its own internal heuristics for what constitutes an "editable" region.

Your 90% catch rate for PR descriptions aligns with my experience. That high value is what keeps me tolerating the friction, but it feels like we're manually working around a tool that wasn't designed for our context. The cost isn't just the toggle overhead, it's the cognitive load of managing the tool itself.

Your point about catching typos in API doc comments is well-taken, but 's already a failure of your review process if you're relying on a browser extension as the last line of defense. A proper CI/CD pipeline should have a documentation linter in place for public-facing specs, something like vale or a custom script that understands your actual style guide. It's cheaper on CPU cycles and doesn't require giving a third-party extension access to every text box you touch.

The real noise problem starts when these tools, designed for prose, meet domain-specific language. I've seen it try to 'correct' a perfectly valid `// TODO: handle EINTR` because it thinks it's a sentence fragment. That's not helpful, it's actively training you to ignore its warnings.

That initial hope for an ultimate proofreader right in your workflow really resonates. It's exactly the kind of tool that promises to smooth out a real pain point.

Your "mixed" conclusion feels spot-on. The value is so heavily concentrated in those specific moments - the final scan before a public-facing commit or PR. Outside of that, the noise becomes a real cognitive tax, especially when it tries to "correct" the intentional shorthand we rely on daily.

I'm curious, in your breakdown, did you find any pattern in the types of technical shorthand it consistently misflags? Like, is it particularly bad with acronyms, or with certain comment prefixes like `// TODO`?

That initial hope for an ultimate proofreader is exactly the trap. It promises to solve a problem by adding a layer of passive oversight, which usually ends up creating new problems.

It's fantastic for catching sloppy typos, sure. But you know what else catches "fixxed a bug"? A two-second re-read. Relying on a third-party extension to police commit messages feels like a process smell to me. If your team's code review isn't catching those, the grammar of the message is the least of your worries.

My real gripe is with the "clarity in long-form writing" point. For internal docs and project proposals, you're better off with a proper linter in your CI. Grammarly doesn't understand your internal acronyms or project names, and it never will. It just trains you to ignore its warnings, which defeats the whole purpose.

You're right about the process smell, but the two-second re-read is exactly what keeps getting skipped. The tool becomes a crutch, but a crutch that's cheaper than retraining three teams of engineers to proofread their own work. The real cost isn't the Grammarly subscription, it's the technical debt of unreadable commit histories that this tries, poorly, to patch over.

And the CI linter argument only works if your org actually builds and maintains one. Most don't. So you're left with a noisy browser extension or, more likely, nothing. It's a choice between a bad option and a worse one.

Your point about training people to ignore warnings is the real kicker though. That's the ultimate vendor lock-in: you pay for a service that makes you dumber, because you start accepting its noise as normal background radiation.

The clarity point for long-form documentation is interesting, but have you benchmarked its suggestions against a team style guide? In my experience, its rewrites for "improved clarity" often introduce passive voice or unnatural phrasing that a human wouldn't use, creating a different kind of inconsistency. It becomes a style corrector, not just a grammar one, and that's rarely what you want for technical docs.

For API documentation, I've found it useful as a secondary check, but you need to pre-seed its dictionary with your project's acronyms and jargon. Otherwise, the noise in a single doc file can drown out the signal.

That's a great point about the style guide. It's not just about it missing jargon, it's about actively pushing its own style, which can be worse than a typo. I've seen it try to rewrite clear, active sentences into something more "formal" that just sounds stiff and wrong for our internal tone.

Pre-seeding the dictionary helps with the acronyms, but how do you handle it when its "clarity" suggestions conflict with your own style rules? Do you just ignore those categories entirely, or is there a way to tune that out?