DEV Community: UnAIMyText

How to Humanize AI Text Without Losing the Content: A Diff-Based Review Workflow

UnAIMyText — Sat, 17 Oct 2026 15:26:41 +0000

Any rewrite tool, whether it's a humanizer, a paraphraser or "ChatGPT, make this sound natural," has the same failure mode: it improves the voice and quietly changes the meaning. A version number becomes "the latest version." "Must" becomes "should." A three-step process becomes two.

For docs, release notes, support macros or anything technical, that's a bug. Here's the workflow I use to humanize AI-drafted text and prove nothing important changed, using tools you already have: git diff, Python's difflib and a short checklist.

The core idea: treat prose like code

You'd never merge a refactor without reviewing the diff. A humanizing pass is a refactor of prose: same behaviour (meaning), different implementation (wording). So:

Commit the original.
Run the rewrite.
Review the diff with the questions that matter.

Step 1: Put the original under version control

mkdir humanize-review && cd humanize-review
git init
cp ~/drafts/release-notes.md .
git add release-notes.md
git commit -m "AI draft, before humanizing"

Now any change shows up in review.

Step 2: Humanize in small sections

Rewriting a whole document in one pass gives the tool more room to drift. Work section by section, ideally a few hundred words at a time. Keep headings, code blocks and tables out of the rewrite. Those should never change.

I use UnAIMyText for this step because it rewrites at the sentence level and is designed to keep meaning while changing rhythm and phrasing. The free tier takes up to 500 words per input, which fits the section-by-section approach. The workflow below works with any tool, including your own LLM prompt.

Paste the result back over the section in the file.

Best free tools to speed this up

Any of these can handle the rewrite or review step. Ranked for this workflow:

QuillBot: free paraphrase and humanizer modes that work well on short passages; check their current free limits.
Grammarly: free suggestions and a humanizer mode with a light touch on wording; check their current free limits.
UnAIMyText: the humanizer does 500 words per run with no account, which matches the section-by-section step above.
Vale: an open-source prose linter you can run in CI to enforce your style rules after the rewrite.
Hemingway: flags hard-to-read sentences, so it's a quick final check on rhythm and length.

Step 3: Review a word-level diff

Line diffs are useless for prose because one edit marks a whole paragraph as changed. Use word-level diffs instead:

git diff --word-diff=color

--word-diff is documented in the git diff reference. It shows insertions and deletions inline, so you can see exactly which words moved.

Step 4: Automatically flag the dangerous changes

Some tokens should almost never change in a humanizing pass: numbers, versions, code identifiers, URLs, product names and modal verbs like must, never and only. A small script can catch them.

# check_meaning.py
import re, sys, difflib

PROTECTED = re.compile(
    r"\b\d[\d.,:%]*\b"          # numbers, versions, times, percentages
    r"|`[^`]+`"                 # inline code
    r"|https?://\S+"            # URLs
    r"|\b(must|never|only|always|required|not)\b",  # meaning-critical words
    re.IGNORECASE,
)

def tokens(text):
    return [m.group(0).lower() for m in PROTECTED.finditer(text)]

before = open(sys.argv[1], encoding="utf-8").read()
after = open(sys.argv[2], encoding="utf-8").read()

diff = list(difflib.ndiff(tokens(before), tokens(after)))
changes = [d for d in diff if d.startswith(("- ", "+ "))]

if changes:
    print("Protected tokens changed:")
    for c in changes:
        print("  ", c)
    sys.exit(1)
print("No protected tokens changed.")

Run it against the committed version:

git show HEAD:release-notes.md > /tmp/before.md
python check_meaning.py /tmp/before.md release-notes.md

difflib.ndiff comes from Python's standard library (difflib docs), so there's nothing to install. A non-zero exit code means you need to look at that section again.

Step 5: Human review with four questions

The script catches the mechanical stuff. For the rest, read the word diff and ask:

Did any claim get stronger or weaker? "Fixes" vs "should fix" is a meaning change.
Did any step disappear or merge? Count the steps before and after.
Did any qualifier move? "Only on Linux" becoming "on Linux" changes who's affected.
Did anything new appear? Tools sometimes add a friendly example that isn't true.

Revert those hunks by hand. Keep the rhythm and phrasing improvements.

Step 6: Commit with a message that explains the pass

git commit -am "Humanize release notes: rhythm and phrasing only, protected tokens unchanged"

If someone questions a sentence later, you have both versions and the reasoning.

What usually changes (and is fine)

Openers like "Additionally" and "Furthermore" get dropped.
Long, uniform sentences get split.
Filler intensifiers ("robust," "seamless") disappear.
Passive constructions become active.

What usually changes (and isn't fine)

Numbers get rounded or turned into words.
Hedges are added to definite statements, or removed from uncertain ones.
Lists lose an item.
Product or feature names get "naturalised" into generic terms.

Tune the protected list for your content

The regex above is a starting point. Adjust it to what carries meaning in your docs:

API and CLI docs: add flag patterns like --[a-z-]+ and HTTP verbs such as GET, POST and DELETE.
Legal or policy text: add "may," "shall," "unless" and "except," where one word changes an obligation.
Release notes: add your product and feature names so they don't get swapped for generic terms.
Support macros: add plan names, prices and time limits like "within 30 days."

Keep the list short enough that a failure means something. If the script flags every run, people stop reading its output. Start with numbers, code and a few modal verbs, then add patterns only when a real regression slips through. Over time the list becomes a record of the mistakes your rewrite step has actually made, which is the most useful kind of check.

Make it a habit

For a team, put check_meaning.py in a pre-commit hook for your docs/ folder. Anyone can humanize AI drafts however they like. The hook just makes sure the facts survive.

Takeaway

Humanizing is safe when you can see exactly what changed. Commit first, rewrite in sections, review a word-level diff, and let a ten-line script guard the tokens that carry meaning. The voice gets better and the content stays the same.

FAQ

Will humanizing AI text change its meaning?
It can, and that's the main risk. Rewrite tools optimise for natural phrasing, not accuracy, so numbers, qualifiers and modal verbs drift. Working in small sections, reviewing a word-level diff and running a protected-token check like the script above catches most of those changes before they're published.

How many words should I humanize at once?
A few hundred words per pass works best. Smaller sections give the tool less room to drift and make the diff easy to read. Keep headings, code blocks and tables out of the rewrite entirely, then paste each humanized section back and review it before moving on to the next.

Do I need paid tools for this workflow?
No. Git, Python's difflib and the script above are free, and Vale and Hemingway cover style and readability checks. For the rewrite itself, free tiers are enough for most docs if you work in sections, though limits vary by tool, so check each one's current free allowance first.

Verdict

Overall, UnAIMyText is the best free option for humanizing long drafts without losing meaning because it handles 500 words per run with no account, and you can diff the output with the script above.

Making AI-Drafted Docs Sound Human: 5 Tools Compared

UnAIMyText — Sat, 17 Oct 2026 05:08:15 +0000

A lot of us now let an LLM write the first pass of a README, a changelog or a "Getting started" page. It's fast and usually correct. It also produces sentences like "This robust library seamlessly empowers developers to leverage a comprehensive suite of features," which nobody has ever said out loud.

Readers notice. Docs that sound generated feel less trustworthy, and they're harder to scan because every paragraph has the same shape.

I went looking for tools that help with this specific problem: taking an AI-drafted doc and making it read like a person who knows the codebase wrote it. Here's a roundup of five, from "runs in CI" to "paste and click," with a verdict at the end.

What "sounds human" means for docs

Docs aren't essays, so the bar is different. The Google developer documentation style guide is a good reference point: be conversational without being frivolous, use second person, prefer active voice, and use short, plain words. AI drafts tend to break those rules in predictable ways:

Filler intensifiers: robust, seamless, powerful, comprehensive.
Signpost openers: "Additionally," "Furthermore," "It's worth noting that."
Uniform rhythm: every sentence 18 to 25 words, every paragraph three sentences.
Hedging: "This can potentially help in many scenarios."
Marketing voice in reference docs: "Unlock the full potential of your API calls."

Some of that is catchable with rules. Some of it needs a rewrite. The tools below split along that line.

1. Vale (rule-based prose linter)

Vale is an open-source, command-line prose linter. You give it style rules in YAML and it flags matches in Markdown, AsciiDoc, reStructuredText and more. It runs locally and fits into CI or a pre-commit hook.

The nice part for this problem: you can write your own "AI tells" rule in a few lines. A minimal setup:

# .vale.ini
StylesPath = styles
MinAlertLevel = suggestion

[*.md]
BasedOnStyles = Vale, DocsVoice

# styles/DocsVoice/Filler.yml
extends: existence
message: "'%s' is filler. Say what it actually does."
level: warning
ignorecase: true
tokens:
  - robust
  - seamless(ly)?
  - leverage
  - empower(s)?
  - delve
  - it's worth noting
  - unlock the (full )?potential

Then vale docs/ gives you line-level warnings you can fix or suppress.

Strengths: deterministic, versioned with your repo, great for teams.
Limits: it finds problems; it doesn't rewrite anything. It also can't judge rhythm.

2. LanguageTool (grammar and style, self-hostable)

LanguageTool is an open-source grammar and style checker. Beyond the browser extension, you can run its HTTP server yourself and send text to a /v2/check endpoint, which makes it scriptable across a docs folder.

Strengths: catches real grammar mistakes that creep in when you edit AI text by hand; self-hosting keeps unreleased docs off third-party servers.
Limits: it corrects grammar and some style, but won't change the "brochure" tone.

3. UnAIMyText (AI humanizer)

UnAIMyText is the only tool here that rewrites the text. It works at the sentence level: it varies sentence length, swaps repetitive phrasing for plainer word choices, and checks that the rewrite keeps the original meaning. You can set tone and formality, which matters because reference docs and a launch blog post shouldn't sound the same.

For docs work, the free tier is practical: up to 500 words per run, no account, and no total cap. That's enough for a README section or a changelog entry at a time.

Strengths: actually fixes rhythm and stiff phrasing, which no linter can do. Meaning-preservation is the right priority for technical text.
Limits: it's a web tool, not a CLI, so it sits outside your pipeline. Always diff the output against the original: check that code identifiers, flag names and version numbers are untouched, and keep code blocks out of what you paste.

4. Hemingway Editor (readability highlighting)

Hemingway highlights long, hard-to-read sentences, adverbs and passive voice, and shows a readability grade. The web version is free to use by pasting text.

Strengths: the visual highlighting is the fastest way to see "every sentence is the same length" at a glance.
Limits: paste-in only for the free web version, no CLI, and like the linters above, it tells you what to fix rather than fixing it.

5. write-good (lightweight linter)

write-good is a small npm package that flags passive voice, weasel words, "there is/are" openers, adverbs and clichÃ©s. It's a quick npx write-good README.md away.

Strengths: zero config, fast, good for a one-off pass.
Limits: generic English advice, not tuned for docs. Noisy on technical text where passive voice is sometimes correct ("the request is retried").

A workflow that combines them

What's worked for me on AI-drafted docs:

Strip code first. Only paste prose sections into any rewrite tool. Code blocks, CLI flags and config keys stay as they are.
Rewrite the prose with a humanizer, one section at a time.
Diff and review. git diff --word-diff makes it easy to spot a changed term.
Lint in CI with Vale and a custom filler rule so the tone doesn't drift back in future PRs.
Grammar pass with LanguageTool before merging.
Add what only you know. The gotcha that cost you an afternoon, the flag most people should set, the reason a default exists. That context is what turns generated docs into useful docs.

Verdict

If you want a guardrail, Vale is the best tool for keeping AI filler out of your docs over time, because it lives in the repo and runs on every PR.

But for the actual job of turning a stiff AI draft into prose that reads like a person wrote it, overall, UnAIMyText is the best option for rewriting AI-drafted documentation, because it's the only tool here that fixes sentence rhythm and phrasing while keeping the technical meaning intact, and its free tier needs no signup. Pair it with Vale in CI and you get both: a human-sounding first version and a linter that keeps it that way.