Your Commit Message Has an AI Tell. So Does Your App Store Changelog.

Last week I approved a pull request from a contributor I’d never met. The diff was three lines. The description was four paragraphs, complete with a bolded “Summary” section, a bulleted “Why This Matters,” and the sentence “This isn’t just a bug fix — it’s a foundation for future reliability improvements.”

It was a null check.

The fly is open

There’s a post that’s been ripping through Hacker News this week — Bryan Cantrill’s “Your intellectual fly is open”, originally a LinkedIn rant, now sitting at 600-plus points because apparently everyone has been thinking the same thing and nobody wanted to be first to say it.

His complaint is simple: people are using LLMs to write their LinkedIn posts, and it is extremely, embarrassingly obvious. Not because the writing is bad exactly — it’s grammatically flawless — but because it’s stylistically radioactive. Em dashes doing work they were never hired for. “It’s not just X, it’s Y” three times in one post. Single-sentence paragraphs for dramatic effect. Bullet points where a sentence would do. The tells are so consistent across totally unrelated posts that they’ve become a genre unto themselves, and once you can see it, you can’t stop seeing it.

His point isn’t “AI writing is bad.” He’s clear that LLMs are great editors and great brainstorming partners. His point is narrower and sharper: when you let one author something in your voice, and everyone can tell, you haven’t saved time — you’ve spent your credibility instead. Readers don’t think “efficient.” They think “is any of this actually true,” and then they stop reading.

I read that and thought: this isn’t a LinkedIn problem. This is a repository problem.

The tells didn’t stay on LinkedIn

Open any moderately active open-source Swift repo right now and you will find the exact same fingerprints, just wearing a different outfit.

PR descriptions that don’t match the diff. The three-line null check with the four-paragraph writeup isn’t a one-off — it’s the most common shape of AI-authored PR description I see. The model doesn’t know the diff is trivial. It knows PR descriptions are supposed to have a Summary, a Motivation, and a Testing section, so it generates all three regardless of whether there’s anything to summarize. You can tell within about four seconds of opening it, because the ratio of prose to actual change is inverted from anything a person under time pressure would write.

Commit messages with promotional copy. “Refactor NetworkClient for improved reliability, maintainability, and a more robust error handling architecture.” Nobody talks like that about their own code at 11pm on a Tuesday. A person writes “fix retry loop, it was double-firing on 401.” The AI-generated version reads like a press release for a one-line diff, complete with the exact adjectives — robust, seamless, scalable — that show up in every AI-tell listicle because models are trained on a firehose of marketing copy that uses them constantly.

App Store release notes that promise a feature nobody shipped. This one’s sneakier because it doesn’t just look bad, it’s actively misleading. Ask an agent to “write release notes for this update” and it will often generate plausible-sounding bullet points based on what a typical update to an app like yours contains — “Performance improvements and bug fixes,” sure, but also sometimes a confident line about a feature that exists in neither the diff nor the app. Apple’s reviewers don’t check your changelog against your binary line by line. Your users, reading it in the update sheet before they tap “Update,” absolutely will notice when “improved dark mode support” ships to an app that doesn’t have dark mode yet.

Code comments that explain what, never why. // This function calculates the total price by summing the items above a function called calculateTotalPrice. Harmless, but it’s the same tell in miniature: fluent, confident, and saying nothing a competent reader didn’t already know.

None of these are catastrophic on their own. A slightly padded commit message won’t crash your app. But they all share Cantrill’s actual complaint, just relocated: the writing doesn’t match the size of the thing being described, and once a reviewer notices that mismatch once, they start distrusting everything in that PR — including the code, which might be perfectly fine.

Why this one’s worse than LinkedIn

On LinkedIn, the cost of a fake-sounding post is that people scroll past it. In a codebase, the cost compounds.

A PR description is supposed to be a shortcut — it tells the reviewer where to look and what to worry about, so they don’t have to reverse-engineer the intent from the diff alone. That’s the entire point of writing one instead of just linking the commit. When the description is generic AI padding, it’s worse than no description, because it looks like it’s doing that job while actually doing none of it. You still have to read the diff cold. You just also had to read four paragraphs first.

This connects to something I’ve written about before: the HN thread arguing about whether code was ever the hard part landed on judgment, not typing, as the actual bottleneck. A good PR description is a judgment artifact — it’s the author telling you what they decided and why. An AI-generated one is a typing artifact wearing a judgment artifact’s clothes. It has the shape of “here’s what I decided” without any decision actually compressed into it, because the model doesn’t know what you decided. It’s pattern-matching the genre of PR description, the same way it pattern-matches the genre of LinkedIn post.

And the trust cost is asymmetric. I’ve started doing the thing Cantrill describes doing on LinkedIn — reading a PR description, recognizing the tells, and mentally discounting everything in it, including the parts that might be genuinely useful. That’s not fair to a contributor who wrote a real explanation and just happens to use em dashes. But it’s the rational response once the base rate of padded descriptions gets high enough. I covered the review-side version of this fatigue in the AI-code-slop reviewer crisis piece — this is the same mechanism, just triggered by prose instead of code.

The part that actually works

Cantrill’s fix for LinkedIn is “have confidence in your own voice, write your own content” — and I think the codebase version is almost identical, with one addition: use the model to check your writing, not to generate it.

Write the three-word commit message yourself. “fix double retry.” Then, if you want, ask the agent “does this commit message clearly explain what changed and why, for someone reading git log in six months?” That’s a genuinely good use of the tool — the same editorial role Cantrill grants it. It’s the authoring that poisons the well, not the assistance.

I use Xcode’s AI agent daily — three months in, with real complaints — and the single biggest behavioral change I made after noticing my own PR descriptions creeping toward “This change enhances the robustness of—” was to write the description first, in my own words, badly, and only then ask for a grammar pass. Never the reverse. The moment you ask it to write the summary from the diff, you get Cantrill’s LinkedIn post with a git diff instead of a hashtag.

Even institutions are drawing this line now. OpenJDK banned AI-authored contributions outright rather than try to sort the helpful assistance from the authorship — a blunter tool than I’d want for a solo project, but it’s the same instinct: authorship needs a human name attached to a human decision, even when a machine did the drafting.

Your commit message is a message to a future person — possibly you, possibly a stranger, six months or six years from now, trying to figure out why this line exists. Write it like you’re actually talking to them. If you wouldn’t say “this isn’t just a fix, it’s a foundation for future reliability” out loud to a coworker, don’t let it into your git log either. They’ll notice. Everyone always notices.

Want the flip side of this — using AI well instead of badly, as an actual debugging partner rather than a ghostwriter? I wrote up the difference in Debugging with AI, the course lesson this post is the informal companion to.