Evans argues from years of repo maintenance that the prefix taxonomy degrades into noise within weeks of adoption. He contends that forcing structure at the commit level means paying the cost 50 times per feature so that semantic-release can read it once, when the meaningful unit for downstream consumers is the release, not the individual commit.
Submitted the post to HN where it hit 170 points, signaling broad agreement among staff engineers and OSS maintainers that the spec imposes real costs without commensurate human-readable value. The submission framing endorses the article's narrow, specific critique.
Evans documents specific failure modes: `chore:` becomes the catch-all for anything not obviously a feature, `fix:` gets applied to refactors so authors avoid code-review scrutiny, and `feat:` quietly absorbs breaking changes because nobody wants to type `feat!:` and trigger a major version bump. The structured taxonomy ends up laundering intent rather than surfacing it.
Reports running `git log --oneline | grep -c '^chore'` on their codebase after adopting Conventional Commits in 2021 and finding 47% of commits fell into `chore:` by 2024. Concludes the taxonomy effectively collapsed into a single category, providing no real signal.
Reports that their auto-generated CHANGELOG.md is unread, while customer-facing release notes are hand-written from Linear tickets. This undermines the primary justification for the commit-message tax: the machine-readable artifact it produces isn't actually consumed by anyone downstream.
Sumner Evans' post "Stop Using Conventional Commits" hit Hacker News this week at 170 points and triggered the kind of thread where staff engineers and OSS maintainers actually agree on something. The argument is narrow and specific: the Conventional Commits spec — the `feat:`, `fix:`, `chore:`, `refactor:` prefixes that have colonized GitHub since around 2018 — imposes a real cost on every commit and delivers almost no value back to the humans writing them.
Evans' core claim, drawn from years of maintaining and reviewing repos: the prefixes degrade into noise within weeks. `chore:` becomes the bucket for everything that isn't obviously a feature, `fix:` gets applied to refactors that the author wants to ship without code review scrutiny, and `feat:` quietly absorbs breaking changes because nobody wants to type `feat!:` and trigger a major version bump. The taxonomy that was supposed to enable machine-readable history instead launders intent.
The HN thread piled on with specifics. One commenter from a 400-engineer monorepo: their `CHANGELOG.md` is generated, nobody reads it, and the release notes that ship to customers are written by hand from Linear tickets anyway. Another: "We adopted Conventional Commits in 2021. In 2024 we ran `git log --oneline | grep -c '^chore'` — 47% of commits. The taxonomy collapsed into a single category."
The deeper point isn't that Conventional Commits is bad. It's that it's a process imposed at the wrong layer of the stack. Commits are a developer's working memory — granular, often rebased, often squashed at merge. The thing customers and downstream consumers care about is the *release*, not the commit. Forcing structure at the commit level means you're paying the tax 50 times per feature so that semantic-release can read it once.
Compare this to how shipped software actually communicates changes. Postgres has no Conventional Commits. Its `git log` is prose, often messy, sometimes a single line, sometimes a paragraph. The release notes are hand-written by committers who actually understand what shipped and why — and Postgres release notes are widely considered the gold standard in open source. Linux kernel commits follow a rigorous *prose* convention (subject line, body explaining the why, Signed-off-by trailer) and the changelog is generated from tags and Reported-by metadata, not prefix grammar. SQLite, curl, Redis — none of them use Conventional Commits. All of them ship better changelogs than the average `semantic-release`-powered Node package.
The contrast is sharper when you look at what Conventional Commits actually *replaces*. It replaces a human writing a paragraph about what they shipped with a machine concatenating commit subjects — and the output reads exactly like what it is, a robotic dump that nobody opens twice. The promise of automation was that humans wouldn't have to write changelogs. The reality is that humans now write *worse* changelogs, because the only natural-language artifact left is a 50-character commit subject written at 4pm on a Friday.
There's also a perverse incentive problem. Because the prefix determines the SemVer bump in tools like semantic-release, the prefix becomes a *political* decision, not a descriptive one. Want to ship something risky without forcing a major version? Call it a `fix:`. Want extra visibility for a small refactor? Call it a `feat:`. The grammar that was supposed to encode truth ends up encoding what the author wants the release pipeline to do — which is exactly the kind of coupling that turns documentation into a lie.
If you're running Conventional Commits today, the test is simple: run `git log --pretty=format:"%s" | cut -d: -f1 | sort | uniq -c | sort -rn` on your main branch and look at the distribution. If `chore:` and `fix:` are more than 60% of your history, the taxonomy has already collapsed. You're paying the cost without getting the signal.
If you keep it, narrow the surface. Enforce prefixes only on the merge commit (the squash subject) rather than every developer commit. GitHub's "Require pull request title to follow Conventional Commits" is a one-line policy that captures 95% of the automation value with 5% of the per-developer friction. PR titles get reviewed; commit subjects don't.
If you want auto-generated release notes without the tax, the path most large repos converge on is PR-label-driven changelogs. Apply a `release-note: feature` or `release-note: breaking` label during review, generate the changelog from labels at release time, and let developers write commits like humans again. Release Drafter, GitHub's native release notes generator, and Changesets (for monorepos) all support this pattern. The label is applied by the reviewer, not the author, which sidesteps the political-prefix problem entirely.
For teams that genuinely need machine-readable commit metadata — say, a kernel or a database where bisecting matters more than changelog generation — write a CONTRIBUTING.md that asks for a prose body with a *why*. "Fix race in connection pool: the previous mutex was held across an await point" is more useful in five years than `fix(pool): mutex bug` will ever be.
The Conventional Commits debate is a useful proxy for a larger question: which process artifacts deserve to exist at the commit layer, and which belong at the release layer? The answer, increasingly, is that commits should serve developers and releases should serve users — and conflating the two with a grammar that satisfies neither has been a quiet drag on developer experience for half a decade. The repos that ship the best changelogs are the ones that treat changelog-writing as an editorial act, not a parsing problem. Expect more teams to quietly drop the prefixes in 2026 — and to discover their `git log` is more readable, not less.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.