ChatGPT drafts a README in twenty seconds and any working developer spots it in two. Welcome to openers, rocket emojis on every header, the parallel three-bullet feature list, the Getting Started in 3 Steps cadence: pattern recognition does the rest, and the reader closes the tab before running the install command. TextSight rewrites the prose around your code, leaves every fenced block byte-identical, and gives you a per-paragraph map of what still reads as ChatGPT. Built for honest project framing, not for tricking OSS users.
Working developers read 200 to 500 READMEs a year. After two years on GitHub the pattern matching is automatic, and ChatGPT's default README structure is identical every time.
If the first line is "Welcome to ProjectName! This project aims to provide a powerful, flexible, and easy-to-use solution for...", the reader has classified the repo as low-effort filler before the second sentence. They will not read paragraph two, they will not run the install command, and they will not star the repo. That single classification costs OSS adoption every day.
Devs scan the opener, the badge row, the feature list, and the quick-start block in roughly that order. If any one reads as boilerplate, the rest is assumed the same. A working install command cannot save a generic feature list, and a clean quick-start cannot save an opener that reads as ChatGPT. The whole file has to read as written, not generated.
Hiring teams reviewing your GitHub for a role infer signal from your READMEs even when the code is good. An AI-drafted README on your top pinned repo reads as low investment in the project, which lowers their estimate of the engineering behind it. The fix is the same either way: rewrite the prose so it sounds like the person who wrote the code.
README files have their own AI patterns, separate from blog posts or marketing copy. These six show up in nearly every ChatGPT-drafted README, and any one of them is enough to lose the reader.
The two most common ChatGPT openers for a README. Variants include "This library aims to deliver", "This package is designed to offer", and the always-rocket "Welcome to ProjectName!". All of them defer the actual description by one clause and signal AI authorship in the first eight words. Real maintainers start with a verb and an object: "Parses YAML config files at 40MB per second." "Wraps the Stripe API for FastAPI projects."
Rocket on Getting Started, sparkles on Features, books on Documentation, wrench on Configuration, handshake on Contributing. Two or three emoji on the same heading. Every section gets one whether it earns it or not. Working maintainers either use no emoji or one specific emoji that means something to the project. The stacked pattern is the giveaway.
ChatGPT defaults to feature bullets that all use the same grammatical shape: "Easy integration with X", "Robust support for Y", "Powerful Z capabilities". Three or six bullets, every one starting with an adjective and ending with a noun. That parallelism is the giveaway. Real feature lists are uneven because real features have different shapes; mix verbs, sentences, parentheticals, and the occasional deliberate exclusion ("no retry middleware, use tenacity if you need it").
Always three steps. Always numbered. Always Install, Configure, Run. The cadence is identical across thousands of AI-drafted READMEs, which is why a working developer scrolls past it before reading. Real getting-started sections are messy: sometimes two commands, sometimes a longer setup with an environment variable note, sometimes a link to a docs page because the setup is too involved for the README.
ChatGPT often invents an install command that looks right but uses the wrong package name, the wrong scope, or the wrong manager. "npm install my-cool-project" when the published name is "@scope/cool-project-utils". A reader who hits a 404 on the install line is gone: they will not debug your README for you, and they will not file an issue. Run every install command from a clean shell after any AI draft.
A Contributing section that paraphrases the standard fork-branch-PR boilerplate without saying anything specific about your review process. A License section that restates the MIT license in prose under the actual LICENSE file link. Each is a sign the README was filled in by template. Cut the boilerplate. Write Contributing in one paragraph about your actual review style. Link to LICENSE and stop.
All three modes available on every paid plan. Tiers differ on monthly word quota and on access to the Chrome extension, file upload, and REST API. Full details on the pricing page.
Billed $89.88/year — Save $30
Billed $179.88/year — Save $60
Billed $359.88/year — Save $120
Yearly billing saves 25%. View full pricing →
A README is a stack of section types and each one has a different AI failure mode. The AI rewriter recognises the structure and adjusts its approach per section.
The first paragraph carries more weight than any other part of the file. The AI rewriter flags hedged AI openers ("Welcome to", "aims to provide") and rewrites them to start with a verb and an object. Library name in backticks the first time it appears, the actual thing it does in plain language, the audience named concretely. This single rewrite usually adds 15 to 25 points to the Authenticity Score.
The prose around the install block gets rewritten; the install command itself stays byte-identical. Phrases like "To get started, simply run the following command" become "Install with" or get cut entirely. The AI rewriter never touches the contents of a fenced code block, so a wrong package name in the command stays wrong; that one is on you to verify by running it.
Usage prose is where the AI rewriter adds the most readable value. ChatGPT writes Usage sections that read as paraphrased docs ("To use this library, first import the main class, then instantiate it with your configuration"). The AI rewriter shifts to a working maintainer's voice: "Pass a config object. The only required field is api_key." Code blocks underneath remain verbatim.
Use Light mode for API reference sections. The prose around each method signature should stay technically precise; the goal is removing the AI cadence ("This method allows you to") without reframing the actual contract. Method names, parameter names, return types stay exact because they are inside code spans. Run Light, read the diff, ship.
The boilerplate fork-branch-PR Contributing section is the second-worst AI tell after the opener. The AI rewriter flattens it into a single paragraph about your actual review process: how fast you usually respond, which kinds of PRs you accept without an issue first, what your test expectations are. If your project does not have a real review process yet, write that. "I review when I can, sometimes a week" reads more trustworthy than a templated workflow that does not match reality.
One line linking to LICENSE. The AI rewriter removes the prose paraphrase of the license terms that ChatGPT loves to insert, because that paraphrase is both useless (the LICENSE file is the source of truth) and a textbook AI tell. Keep the link, drop the paraphrase.
Of every AI tell in a README, a broken code example costs the most. The AI rewriter never touches code; the discipline of running every command after the rewrite is on you.
Triple-backtick fenced blocks (with or without a language tag), indented four-space code blocks, inline code spans inside single backticks, Markdown image syntax for badges and shields, and link reference definitions. All of these pass through the AI rewriter unchanged. The AI rewriter is also conservative on any line that looks like a badge declaration, which prevents it from rewriting the badge alt text into something cute.
Prose paragraphs, bullet points written as full sentences, section headers, and the descriptive text inside HTML comments that some maintainers use as inline notes. The rewrite respects Markdown heading levels (an H2 stays an H2) and bullet structure (a nested list stays nested) so the rendered output keeps the same shape.
Before any README ships, run every command from a fresh shell. Copy the install line into a new terminal. Paste the quick-start block into a clean directory. If anything raises, fix the README. The AI rewriter cannot fix a wrong package name for you and it will not catch a method that was renamed two releases ago; only running the example will. Most repos that lose adoption to AI-drafted READMEs lose it at this step, not at the opener.
A README is not one piece of writing, it is several. The right mode depends on which section you are rewriting, not on the file as a whole.
Use Light on API reference, configuration tables, and any section where exact phrasing matters. It makes mild edits and preserves your existing terminology. The goal here is removing the AI cadence ("This method allows you to specify") without reframing the contract. Score gains per pass are smaller but the technical surface stays intact.
Balanced is the right default for project description, usage prose, motivation sections, and Contributing notes. It restructures sentences and shifts vocabulary while keeping paragraph intent intact. This is the mode you reach for first on a README and the one you will use most of the time.
Maximum runs the most aggressive rewrite across rhythm and vocabulary. The single-pass Authenticity Score gain is the largest, but Maximum can rewrite domain-specific terms if they are not quoted or in a code span, and it can flatten the maintainer's voice into a generic conversational register. Use Maximum only on the remaining flagged paragraphs after a Balanced pass, with your project name and key library terms in backticks. Read the diff before you commit.
Run Balanced on the whole README first. Re-scan. Anything still below 70 gets a Maximum pass on that paragraph alone, with terms protected by backticks. Then a final read-through with a clean shell open so you can run every command as you go.
The opening paragraph and feature list from a ChatGPT-drafted README for a vector database wrapper, then the rewritten rewrite. The actual repo picked up 340 stars in the month after the rewrite shipped.
"Welcome to vecwrap! This project aims to provide a powerful, flexible, and easy-to-use Python library for working with vector databases. Key features include: seamless integration with popular vector stores, robust support for advanced querying, and lightweight yet feature-rich abstractions. Whether you are building cutting-edge AI applications or managing large-scale embeddings, this library has you covered. Getting started is a breeze with just three simple steps!"
"vecwrap is a thin Python client for Qdrant, Pinecone, and Weaviate with one API surface. It exists because I got tired of rewriting the same five wrapper functions every time a project changed backends. What it gives you: one upsert call that works across all three. A batched query helper that respects each backend's rate limits. Async by default. No retry middleware. Use tenacity if you need it."
The "Welcome to" and "aims to provide" openers are gone. The library name is in backticks (so Maximum mode would not have rewritten it). The actual three backends are named instead of "popular vector stores". The parallel three-bullet feature list became an uneven mix, with one deliberate exclusion ("no retry middleware") that signals real design thinking. "Easy-to-use yet powerful" and the cutting-edge filler are cut. The Getting Started in 3 Steps cadence is gone because the project does not have three setup steps; it has one (pip install) and then you start writing code.
The flagship ChatGPT AI rewriter landing page covering essays, articles, and posts.
Open the AI rewriter →The detector view tuned for product specs and technical docs. Sister page for tech-doc audiences.
Open the detector →How the score is computed and what threshold to target before pushing to main.
Read the guide →Full tier breakdown for Free, Starter, Pro, and Business. Annual billing saves 25%.
See pricing →Free to try, no card. Code blocks stay byte-identical across every pass. Built for honest project framing, not for tricking OSS users.