I struggled a bit with what to point to as signs that it's not an LLM conception. Someone else had commented on the headlines as something that was AI-like, and since I could easily imagine a writing process that would lead to headlines like that, that's what I chose. A little too confidently perhaps, sorry.
But actually, I think I shouldn't have needed to identify any signs. It's the people claiming something's the work of an LLM based on little more than gut feelings, that should be asked to provide more substance. The length of sentences? Number of bullet points? That's really thin.
I don't think people should be obligated to spend time and effort justifying their reasoning on this. Firstly it's highly asymmetrical; you can generate AI content with little effort, whereas composing a detailed analysis requires a lot more work. It's also not easily articulatable.
However there is evidence that writers who have experience using LLMs are highly accurate at detecting AI generated text.
> Our experiments show that annotators who frequently use LLMs for writing tasks excel at detecting AI-generated text, even without any specialized training or feedback. In fact, the majority vote among five such “expert” annotators misclassifies only 1 of 300 articles, significantly outperforming most commercial and open-source detectors we evaluated even in the presence of evasion tactics like paraphrasing and humanization. Qualitative analysis of the experts’ free-form explanations shows that while they rely heavily on specific lexical clues, they also pick up on more complex phenomena within the text that are challenging to assess for automatic detectors. [0]
Like the paper says, it's easy to point to specific clues in ai generated text, like the overuse of em dashes, overuse of inline lists, unusual emoji usage, tile case, frequent use of specific vocab, the rule of three, negative parallelisms, elegant variation, false ranges etc. But harder to articulate and perhaps more important to recognition is overall flow, sentence structure and length, and various stylistic choices that scream AI.
Also worth noting that the author never actually stated that they did not use generative AI for this article. Saying that their hands were on the keyboard or that they reworked sentences and got feedback from coworkers doesn't mean AI wasn't used. That they haven't straight up said "No AI was used to write this article" is another indication.
> Also worth noting that the author never actually stated that they did not use generative AI for this article.
I expect that they did in some small way, especially considering the source.
But not to an extent where it was anywhere near as relevant as the actual points being made. "Please don't complain about tangential annoyances,", the guidelines say.
I don't mind at all that it's pointed out when an article is nothing more than AI ponderings. Sure, call out AI fluff, and in particular, call out an article that might contain incorrect confabulated information. This just wasn't that.
Fair point, we appreciated that courtesy, and I should have reached out first. That was a miss on my part.
My thinking was that it became public pretty quickly once your post went viral (folks were already connecting the dots in the replies), and it felt awkward to respond to the substance without being direct about the context.
But you're right that a heads-up would have been the better move.
(I wrote the response) Just because it's marketing, doesn't mean it can also be educational?
I am a marketer and a developer. But I also know that you don't get far by trying to trick people into your product. As a marketer, I also get front row seat seeing how software plays out for a lot of businesses out there, and I have done so for a lot of years. I wanted to share those perspectives in response to Lee's write-up.
So yes, obviously both these pieces make a case for how the software we're employed by solves problems. And anyone who has been in developer marketing for a while knows that the best strategy is to educate and try to do so with credibility.
But in that bias is a ton of experience in the CMS field and a lot of observation of actual teams trying to solve for content operations challenges. I think that's valuable to share, even if we happen to also sell a solution to these things.
She's our recruiter at Sanity. Never coded. Wanted a pottery portfolio. 7 hours with Cursor later, she had a live site. Didn't know what "deploying" meant when she started, debugged until 4AM, maxed out Vercel's deployment limit. But she shipped!
I wrote a piece a few years ago that still reflects a lot of my thoughts on the tension between Markdown as a format and the actual experience of writing and publishing on the web: [“Thoughts on Markdown” – Smashing Magazine](https://www.smashingmagazine.com/2022/02/thoughts-on-markdow...).
What Apple seems to be doing with Notes—embracing Markdown syntax but not treating it as a source format—feels like a pragmatic move. It acknowledges Markdown’s familiarity without overcommitting to it as a canonical format. That distinction matters: many people like typing emphasis or `code`, but few need or want to version-control or export that exact syntax. It’s the gesture of Markdown that carries value for most users, not the fidelity to a plain-text artifact. "Even" Google Docs implemented it recently.
In my article, I argue that Markdown is increasingly a “source language” for interfaces, not documents, and this Apple Notes move seems to align with that trend. Curious how others feel about Markdown as an authoring experience vs. a content format.
And if you only knew how much those headings and the structure of this post changed as I wrote it out and got internal feedback on it ^^_