People have started telling me that my writing sounds like AI. I published that sentence in a LinkedIn post recently because it kept being true, an...
For further actions, you may consider blocking this person and/or reporting abuse
The irony is that this article is very much the kind of highly structured, polished, carefully argued post that some people would immediately call AI slop 😂—while the post itself is explaining why that judgment is unreliable. 🤣
You can make your work verifiable, disclose your process, and stand behind it. After that, whether someone chooses to inspect it is their cup of tea. 🤸
The irony is load-bearing — I built de-AI guardrails for my own pipeline and they flagged my unassisted sentences, which is half of how this article happened. Verifiability is the part I control; whether anyone inspects is, as you say, their cup of tea.
The receipts point is exactly the thing I've been trying to articulate to people who've flagged my own posts as AI-generated - I've written about systems that are running, and the code is public, but the first response is still a style judgment. The sad part is that prose that reads as "too clean" and prose that reads as "genuinely clear" are the same prose, and there's no friction-free way to surface evidence at the moment someone's already decided. Has showing actual running output or diffs in the post itself changed how people read it?
Honest answer: too early to call — this is the first piece where I put the evidence inline, so the sample size is one. What the older posts taught me is that links to running systems get clicked and quoted back, while the polished summary paragraphs are what get judged. My working theory matches yours: the verdict lands before the evidence, so the evidence has to live in the first screen, not behind a click.
Great article and this debate is happening in my company as well. Other day, I said to someone when Michael Angelo unveiled his David or when Leonardo Da Vinci showed Madonna, did someone say - oh, you cannot be using that new chisel (to chip away marble) or that new brush because that helped you with the masterpiece? Why are folks so upset when a good polished work showed up with AI? Or are folks upset as they have to troll through AI slop. These are 2 different problems. AI slop - yes, real issue. A polished work, you can use whatever tools you use, as long as it’s done ethically, I am good with that. AI is a tool, a polished work shows you know how to use it well. A sloppy AI output is either AI is bad or you didn’t use it right.
Anyway, I have heard this receipt part. I am telling my engineers, the only receipt I need ever would be work is ethically done, as per policy and you reviewed and owned the code. Rest of it, I don’t need receipts. I am not going to come and check which coffee helped you work better or which keyboard improved your typing speed. I trust engineer is using all available tools the best way.
Somewhere deep down the challenge to accept polished work is threatening jobs where ai can do something’s better than how a human would do. But at the same time ai slop or risks are also being troll and downright scary in high trust zones
Thanks for bringing this topic as it is apt and provokes discussions
The chisel question is the clean version of the argument — nobody audited the tool because the work was the evidence. Your two-problems split is where I landed: slop is a real problem, polished work is not, and treating them as one accusation is how the verdict arrives before the evidence. "Reviewed and owned the code" is the receipt that matters — the rest is which keyboard improved your typing speed, as you put it.
Jennifer — reading this together with the August thread, you and I have now built the same principle from two directions. You: "every gate audited intent, none audited the artifact." Me: "verify-on-read checks the anchor, not the referent." Both sentences are the same failure mode — the system validates what it produced, not what actually shipped.
Your four guards are the artifact-side of my VOR. "Unverifiable is not safe" is the same rule as my INCONCLUSIVE state — neither lets silence read as pass.
But your piece adds a class mine doesn't cover: the human explaining away the anomaly. "I saw the broken preview and blamed my phone" — my modification guard never gets to do that; it either catches or it doesn't. Your system did catch it, and the human overrode. That's a different failure mode, and it's why your "name your blind spots out loud" is the fifth guard that matters most — it's the only one aimed at the operator instead of the artifact.
The receipts post is the same argument at the meta level: the detector "audits style," the slop verdict is a gate at the wrong door. Provenance proves processing; receipts prove work. Same sentence, different domain.
One question, since you're two-contour now (public artifacts + private log): when your drafting tool starts watermarking, does the private log become the only record of "what was mine" — and if so, do you version it the way you version artifacts? Because the private log will drift too, and drift without version control is just memory.
Mikhail -
You've put your finger on the seam.
Watermarking moves provenance from the artifact to the record. The moment the drafting tool stamps its output, "what was mine" stops being provable from the shipped thing and starts being provable only from the log. So the log isn't a journal anymore — it's the anchor. And that inverts your own rule in an interesting way: verify-on-read checks the anchor, and now everything I publish gets checked against the log. The log has to be the most versioned thing I own, not the least.
Which answers your question: yes, same discipline as the artifacts, actually stricter. Plain markdown in git, one commit per entry, nothing amended in place. I'm running it through Quartz, which turned out to be the right call for exactly this reason — the log and the public site come out of the same versioned vault, so the private record and the public artifact share a history instead of drifting in parallel. When they diverge, the divergence is dated and visible. That's the whole point.
And your operator point is the one I keep coming back to. The system caught the anomaly; the human overrode it. Versioning the log doesn't fix the human — it just makes the override dated too. The fifth guard names the blind spot; the commit history keeps it honest.
The log is the anchor, and it has to be the most versioned thing you own" — that inverts my own rule correctly, and I hadn't seen the inversion. My verify-on-read assumed the artifact is the thing being checked against the anchor. Watermarking makes the record the anchor and the artifact the thing being checked. Same mechanism, mirrored — which means the discipline follows the mirror: the most versioned, least amendable thing in the system is now the log.
Your Quartz decision is the architectural answer I was missing: one vault, two projections (private record, public artifact), shared history — divergence becomes a dated event instead of parallel drift. My community-memory database is built the same way (append-only versions, nothing amended in place) but yours adds the piece I hadn't connected: the public projection and the private record sharing one git history.
And your operator line closes my question better than any versioning could: versioning doesn't fix the human, it makes the override dated. Named blind spot + dated override = the human stays honest by the same mechanism as the code.
Mirrored is the right word — I had not seen the inversion until you pushed on it. 'Dated override' is going into the vocabulary.