Humanize AI — Devpost project page

Inspiration

I write a lot with LLMs, and the same thing kept happening: the draft was correct but it read like a machine wrote it. Sentences were all the same length, every paragraph opened with a transition word, and the whole thing had this flat rhythm that people notice even when they can't name it.

The obvious fix was to rewrite it myself, but that defeats the point of using a model. The other option was to make a prompt that says "write more naturally," which mostly produces the same text with a few contractions bolted on.

I wanted a tool that treats "does this sound human" as a measurable property rather than a vibe, and then optimises for it directly. That turned into Humanize AI.

What it does

You paste AI-generated text, and it returns a version that reads like a person wrote it — without changing what the text says.

• Handles essays, blog posts, emails, and marketing copy
• Free tier lets you try up to 200 words with no signup
• Targets the statistical patterns detectors actually look for, not surface-level word swaps

The output keeps the original meaning and structure. It changes the things that make a passage read as machine-written: sentence length variance, transition-word density, and repeated syntactic scaffolds.

How I built it

The pipeline is deliberately boring, because the interesting part is the rewriting signal, not the plumbing.

1. Segment the text. Split into paragraphs, then into sentences, keeping offsets so the reassembled document preserves the original paragraph breaks exactly.
2. Score each sentence. For every sentence I compute a small feature set: token length, dependency-tree depth, bigram repetition against the rest of the document, and whether it opens with one of the transitions LLMs overuse. This gives me a per-sentence "machine-like" score.
3. Rewrite only what needs it. Sentences below the threshold go through a constrained rewrite. Sentences that already read naturally are left alone. This is the single most important design decision — rewriting everything is what makes humanizers produce text that sounds off rather than human.
4. Reassemble and verify. The rewritten sentences are stitched back by offset. A final pass checks that entity names, numbers, and quoted text are unchanged. If the rewrite dropped or altered a fact, the original sentence is restored.

The frontend is React and the API is FastAPI. Rewrites run through a model call with a tight prompt that receives the sentence plus its surrounding context, so pronouns and references still resolve after the rewrite.

Challenges I ran into

Rewriting destroys facts. Early versions would happily change "reduced latency by 40%" into "made it much faster." For marketing copy and essays, that is unacceptable — the point is to change how it reads, not what it claims. The fix was a hard constraint layer: extract every number, proper noun, and quoted string before the rewrite, then verify each one survives. Any sentence that loses a fact falls back to the original.

Fixed rewriting makes text worse, not better. When I first rewrote every sentence, the output became less human — it had no rhythm, because every sentence got pushed toward the same "natural" target. Human writing is inconsistent. The threshold-based approach preserves the natural variance that was already there.

Length limits fight the model. The free tier caps at 200 words, but the model needs document context to rewrite a sentence well. Sending only the sentence gives worse results than sending the sentence plus its neighbours. I ended up sending a windowed context that does not count against the user's word quota.

[Add here: one concrete failure from your own testing — e.g. a specific input that broke it and what you changed.]

Accomplishments that I'm proud of

• The fact-preservation layer. Losing a number silently is the kind of bug users never forgive, and catching it before the text reaches the user was worth more than any quality improvement.
• Selective rewriting. It is the difference between "this sounds like a different person wrote it" and "this sounds like a person wrote it."
• Getting the no-signup trial to actually work as a funnel without becoming an abuse vector.

What I learned

Detecting AI text and writing human text are not inverses. A detector scores surface statistics. Producing text that scores well does not mean you understood how to write well — it means you understood the detector. Building this made me much more careful about claiming a tool "makes text human" versus "passes these specific checks."

Constraints improve output more than prompts do. Every quality jump came from adding a hard rule (preserve facts, keep sentence count, do not touch short sentences) rather than from a better prompt. Prompts are suggestions; the verification layer is what actually holds.

[Add here: something you learned about your users — e.g. which use case turned out to be the majority, and whether it surprised you.]

What's next for HumanizerAI

• Per-document style consistency. Right now each sentence is optimised independently. The next step is a document-level pass that checks the whole piece reads as one voice.
• Visible diff view. Show the user exactly what changed and why, sentence by sentence. People trust the tool more when they can audit it.
• Bring your own model. Some users want to run the rewrite against a specific model they already pay for.
• API access. Several people asked to call this from their own publishing pipeline instead of pasting into the web app.

Built With

• react
• supabase