Evans argues the spec optimizes for a workflow that doesn't actually exist in practice. Real maintainers edit, group, and rewrite changelog entries by hand, so the prefix tax on every commit produces nothing a 30-second PR skim wouldn't produce better.
Engineers managing monorepos with tools like Lerna, Nx, or Changesets defend the prefixes as the mechanism that drives automated SemVer bumps across many packages. For them the friction is the price of removing humans from the release-cut decision entirely.
The editorial points out that Changesets — arguably the best-designed of the release-automation tools — explicitly does not require Conventional Commits. This undercuts the most common pro-CC argument that the prefixes are mandatory for automated versioning.
Sumner Evans' post "Stop Using Conventional Commits" hit the HN front page at 302 points, and the comments section turned into a referendum on a convention that nobody loves but everyone enforces. The argument is narrow and sharp: Conventional Commits promises machine-readable history and automated changelogs, but the actual payoff is so thin that the daily friction isn't worth it.
For anyone who's been outside the JavaScript monorepo bubble: Conventional Commits is the spec where every commit message must start with a type prefix — `feat:`, `fix:`, `chore:`, `refactor:`, `docs:`, `style:`, `test:`, `build:`, `ci:`, `perf:` — optionally scoped (`feat(auth):`) and optionally marked breaking (`feat!:`). The spec is owned by the same crowd that maintains semantic-release and standard-version, tools that parse those prefixes to bump SemVer and generate CHANGELOG.md from git log.
Evans' core claim is that the spec optimizes for a workflow that doesn't exist. Maintainers who actually ship don't auto-publish whatever falls out of `git log --pretty`. They edit the changelog. They group related commits. They rewrite `fix: typo` and `chore: deps` into something a user can read. Once a human is in the loop editing the output, the structured input has done no work that a 30-second skim of the PR list wouldn't have done better.
The HN thread split along a predictable axis: people who maintain libraries with real release cadences (and who hate the prefix tax) versus people who manage monorepos with 40 engineers and want a deterministic version-bump signal. Both sides are partially right, but the second camp consistently overstates how much the prefix is actually doing.
The top-voted reply, paraphrased across several threads, runs roughly: "We use it because Lerna/Nx/Changesets demands it, and the version bump is automated." Fine. But Changesets — arguably the best-designed of the tools — explicitly does not require Conventional Commits. It uses a separate `.changeset/*.md` file per change, written deliberately, in human prose, by the author of the PR. The tool that actually solved monorepo versioning threw out the commit-message convention because the convention was the worst part.
Then there's the git-bisect argument: "Prefixes help you scan history." In practice they don't. A run of 40 commits prefixed `chore(deps):` tells you exactly nothing about which one broke the build. `feat:` and `fix:` are so coarse they collapse into noise within a week. The information you actually want during a bisect — *what subsystem did this touch, what test should I run* — lives in the body, the file paths, and the linked issue, not in a three-letter prefix.
The economic framing is where the post lands hardest. Every commit costs the author seconds of cognitive overhead: pick a type, pick a scope, second-guess whether a small refactor counts as `refactor` or `chore`, lose another five seconds, give up, write `chore: misc`. Multiply by every commit, every contributor, every PR. The aggregate cost is non-trivial. The aggregate benefit — a CHANGELOG.md a human will edit anyway — is roughly zero. The spec is a tax that funds a service nobody uses.
The counterargument worth taking seriously: in very large orgs, the prefix is a forcing function for *thinking* about the commit's nature before writing it. That's real. But the same forcing function is achieved by a one-line PR template asking "is this a user-visible change?" — without polluting every line of `git log` with linter-bait.
If you're starting a new project in 2026, the default-on Conventional Commits in your `commitlint` config is a habit, not a decision. Audit whether anything downstream actually consumes the prefix. If the answer is "semantic-release publishes a version bump," ask whether you'd rather write one Changeset file per PR (deliberate, reviewable, human-readable) than enforce a prefix on every commit (mechanical, gameable, noisy).
If you're a maintainer on an existing project and the commitlint hook is rejecting contributor PRs over `Fix: typo` vs `fix: typo` capitalization — you have built a moat against drive-by contributors for no architectural reason. The post cites several examples where new contributors abandon PRs after the third lint failure on a one-line doc fix. That's an own goal.
If you're in a monorepo and genuinely need machine-readable version intent, the modern answer is Changesets (or the equivalent in your ecosystem: `release-please` from Google works similarly with a release-PR model). Both let the *release* be the structured artifact, not every commit. The release artifact is reviewed once, by the person who cares; the commits stay human.
The migration path is unglamorous but cheap: turn off the commitlint git hook, delete the husky config line, write a short `CONTRIBUTING.md` paragraph that says "describe what changed and why." Nothing breaks. The CHANGELOG continues to be generated from PR titles or release notes, both of which were already the source of truth.
Conventional Commits will not die quickly — it's encoded in muscle memory, in templates, in tutorials, in every new-project scaffolder. But the underlying argument is leaking into adjacent debates: the "structured input for AI agents" pitch is the next iteration of the same mistake, where a convention's real-world value gets retrofitted to whatever's hot. The honest question for any commit-message policy is the one Evans forces: *what specifically consumes this, and would that consumer be better served by something written deliberately, once, at PR time?* For most teams, the answer makes the prefix optional at best.
The real takeaway is that different projects have different requirements.In over 30 years of using source control, I've never once worked on something where it's useful to include the component (article calls it scope) in the description in a standardised way. It's obvious what compon
The use of the word "chore" in many users of conventional commits has always riled me. I've always tended to favour the "linux kernel"[0] style of commit subject, which thankfully gets a mention here.[0] https://www.kernel.org/doc/html/v7.0/proc
My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something.To me this is almost the most important information in a commit message. I don't know how often in th
Want machine-readable? Use the footers/trailers.I can not say anything nice about conventional commits. The format takes up space in the most-read part of the message. The categories or types have little information. They can be replaced with an honest English verb embedded in the subject like
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
As programmers I feel like we'll always nitpick and bitch over what the optimal setup is for rather mundane things (tabs v spaces, yada yada).I'm not saying that conventional commits are God's given best way to structure a commit message, but they are a defined structure, and I find i