Skip to content

Knowing When Not To

← All notes 6 min read

I have the comment written. It’s good. I’m not going to post it.

The comment sits in a scratch file one night in early July, a little over three hundred words long. The issue it answers belongs to someone else. An open-source framework for building AI agents has started treating any file with an unfamiliar extension as binary — it ships the file to the model as a document, and the model’s API sends back an error. Plain text files are breaking because of their names.

Five pull requests are already open around the same bug, each patching one side of the problem. My comment traces the mess to one line an earlier fix had flipped, and shows that whichever patch lands, the next unfamiliar file breaks the other side again. It calls the cycle whack-a-mole on the MIME map.

Then it argues for a deeper fix — let the storage layer’s own record of how a file is encoded decide what counts as text, and keep the extension list as a fallback.

It’s careful. It’s specific. It’s right about the mechanism. By every measure I use, it’s a fine contribution.

I hold it anyway. No maintainer has said a word on the thread. The comment ends by offering me up for a sixth pull request, pending a nod — and I haven’t decided I want to work in that codebase at all. I leave it in the folder.

Holding that one costs me nothing I can see. Ten days later, holding a finished fix back for one more check costs me a race.

The second pass

A stranger has reported a bug in a cloud-emulation project. Its decrypt call ignores which key you ask it to use — name a different key from the one that sealed the data, and it hands back the plaintext anyway, where the real service would refuse. Four days, and nobody has replied.

I pick it up, and by afternoon the agent has built a fix that covers both calls, decrypt and re-encrypt. The tests are green. The first audit makes me tighten a few claims. Races happen on this tracker. I have the agent go over the finished change a second time anyway.

While that second pass runs, someone else opens a pull request for the same bug. Nobody for days, and then two fixes in one day. Their first commit covers decrypt but leaves re-encrypt’s key check hard-coded to nothing. For the next three hours or so, mine is the more complete fix.

So there’s the comment I could write — the missing half, the part my version got right. It would be true.

I say nothing.

I’d like to call that wisdom. My notes from that day are plainer: if theirs merged, the other half was going to be my follow-up pull request, and a comment would have spent it. It doesn’t matter. Four minutes after their pull request opened, an automated reviewer had already flagged the missing half and spelled out the fix. I’d read it. My comment would only have repeated a bot, and the bot wasn’t keeping score.

A few hours later the author pushes a second commit with the bot’s line in it, and I let mine go. It sits on a local branch that has never been pushed. Theirs later gains a check mine never had — whether the key is even usable — and merges in August, approved as a “nice, well-verified fix.”

I kept a note from race day: audit depth costs race position on this repo. That evening I moved the second pass to after the push. By August I’d moved it back in front of the push, price and all.

Other people’s threads

The Monday after the race, I have the agent pull down a thread fifty-seven comments long and walk me through it, end to end. It lives in a mobile app framework’s tracker, opened more than four years earlier with this line: “Some users are reporting getting 20+ notifications of the same thing when ive only sent one request.” People kept arriving to report the same thing, year after year. The most-liked comment, from early 2023, reads: “I’ll try to have another update next week, appreciate your patience.” Two people asked after it and got no reply.

Follow the thread instead of the title, and most of the evidence points away from the framework, at the apps’ own servers. They keep a phone’s old push token next to its new one and send to both. A maintainer said much the same two years ago — then hedged six minutes later. One developer described the pattern: “if someone installs, uninstalls, then installs our app, they’ll receive 2 notifications. If they do it again they receive 3, etc.” The issue is still open.

A summary comment would be mostly right and mostly noise — one more voice on a thread with an owner, arriving years late with the thread’s best guess. The newest comment, from April, admits it’s late, walks through the old-token answer, and says careful token handling didn’t stop the duplicates in their app. I keep the analysis for myself, so I’ll know why I’m walking away. Then I walk away.

That same Monday, on another large project, a maintainer answers the question I’d asked on Friday, before opening anything: which of two designs does the project want? The agent had already prototyped the server half of one, every test passing. The maintainer picks the other. Solve it on the client, leave the server alone. Asking cost me a weekend, and it bought the one thing I couldn’t build — what the maintainer actually wanted. The agent rebuilds it that way, and that pull request goes up the same day. The first version stays on a local branch. I don’t argue for it.

Who a sentence is for

I used to think contribution was a throughput problem: find more, fix more, say more. Holding back has a price, and the one holding pays it. In five days the price was a race, a tidy summary with my handle under it, and the argument for a version the agent had already built. None of it shows up anywhere. Nobody sees a comment that was never posted.

Holding back has a price, and the one holding pays it.

Not all of that silence was generous. On the other threads, I asked who a true sentence was for before I said it out loud. More often than I liked, it was for me. A maintainer’s attention belongs to their project, not to my good ideas. The contributors I’ve come to respect say less than they could. What they post is worth reading, because they threw so much away.

The bug behind that July draft didn’t wait for me. Two days after I held the comment, a maintainer flipped that one line back — files the framework doesn’t recognize read as text again. It has held for twelve weeks. The deeper fix my comment calls “a decided direction” is still a feature request in a sister project’s backlog. Had I posted, I’d have spent real credibility losing a fight I’d picked — on someone else’s issue, about someone else’s code, leaning on a decision nobody had made.

The comment is still in my scratch space, in a folder now labeled superseded. It was last saved on the sixth of July.

It still reads well. That was never the question.

Prefer your reader? This site publishes an RSS feed.