For most of the internet’s life, “who wrote this” has stood in for a question we actually cared about: can I trust it? One name at the top of a post was supposed to mean one person’s judgment, one person’s research, one person’s mistakes to own. We built an entire culture of bylines and bios around that proxy.
The proxy was always shakier than it looked. Plenty of “single-author” writing already passed through ghostwriters, editors who rewrote half the paragraphs, interns who did the research, committees who signed off before anything published. The name at the top was never a full account of who actually made the thing — it was a convenient fiction we agreed not to examine too closely.
AI didn’t break that fiction. It just made the examination unavoidable.
Now the seam is impossible to hide, but most people are trying to hide it anyway. Scrub the tells, smooth the voice, ship it looking like it fell fully formed out of one person’s head — the same move as always, just with a new thing to conceal. It’s understandable. It’s also the least interesting choice available, and I think it’s the wrong one.
The seam is more useful than the smooth surface it’s covering up.
If who-typed-it was never a reliable trust signal, the honest question is: what would be? I keep landing on the same answer — supervision. Who directed the work, what they checked before it went out, what they’d catch and what they’d miss. That’s real accountability, and unlike “I wrote every word,” it’s checkable. You can look at the commit history. You can see what changed between draft and publish. You can watch the editing happen instead of taking someone’s word that it did.
That’s the trade this site is built around: instead of a footer disclaimer nobody reads and nobody can verify, the collaboration itself is on display — labeled, dated, and left open to inspection. Not because transparency is a nice value to gesture at, but because it’s the only version of “trust me” that actually holds up when someone checks.
Once you stop treating the process as something to hide, it stops being overhead and starts being content in its own right. A project write-up gets more useful, not less, when it shows the wrong turn before the right one. An instructional post is more trustworthy when it shows what a first draft got wrong and how that got caught, not just the corrected final version pretending it was right all along. A blog is more interesting when you can see the argument being built instead of receiving it pre-assembled, seams sanded off.
This isn’t a claim that AI-assisted work is automatically better, and it isn’t an excuse to skip the editing. It’s the opposite bet: that showing your work is more rigorous than hiding it, not less — because hiding it is exactly how sloppy collaboration gets away with looking finished. A visible process has nowhere to hide a shortcut. A visible process is a standing invitation to catch me being wrong.
So here’s the practical version of the argument, the part that’s actually a decision rather than a mood: every post here says, plainly, whether a human wrote it, whether it was a human-directed draft with a human doing the real editing, or whether a bot generated it start to finish under review. Not as a disclaimer bolted onto the end. As a fact about the post, sitting right there next to the byline, the same way you’d note the date.
None of that changes who’s actually responsible for what gets published. The judgment is still mine. The things I take a position on are still mine to defend. What changes is that the how is no longer a thing to manage impressions around — it’s just true, and stated, and open to whoever wants to go check it.
That’s the bet underneath everything else on this site: that the future of making things in public isn’t about proving a human did all of it. It’s about being specific and honest about which parts a human did, which parts a machine drafted, and who’s standing behind the result either way. The seams aren’t a flaw to sand down. They’re the most honest thing on the page.
Comments run on GitHub Discussions. You'll need a (free) GitHub account — which is rather the point around here.