I can’t get over how welcoming and organised the conference was. It was clear that the organisers care about every single part of the experience and went above and beyond to support speakers and attendees. Looking forward to attending again in the future.

Act I — A confederate after lunch

Like many millennials I can dimly remember a world before the internet, but before long my psyche and identity were wrapped up in the things I did on the computer and online. The Lindy Effect is a heuristic that says the longer something has been around, the longer it’s likely to stick around. Wikipedia is celebrating 25 years this year. Intuitively, something that’s lasted that long feels like it’ll be around for at least the same time again.

When I go online to do a task, three things annoy me and take up the majority of my time.

The first: logging in. Two-factor, SMS, passcodes, password resets, “forgot your password.” By the time I’ve logged in I’ve usually forgotten what I was doing in the first place.

The second: proving I’m not a bot. CAPTCHAs and challenges.

In 2009, computer scientist Brian Christian wrote a book about his attempt at the ultimate test of bot detection: he tried to be declared the most human human.

Let me explain.

You’ve probably heard of the Turing Test. Alan Turing proposed it in 1950 as a thought experiment into the boundary between artificial and human intelligence. Reading the paper I was surprised by a few things. It’s a bit vague about the exact formulation of the test. At its core, the goal is one of trickery, or persuasion: can a non-human entity persuade a human that they are also human?

The other thing that surprised me: Turing suggested that if a bot could be mistaken for a human 30% of the time it would pass. That seems low. Less than one in three. I’ve probably failed a CAPTCHA more often than that.

(In case you weren’t aware: CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart. Back in Turing’s day this was a riff on a party game. Now it’s real and concrete — I just want to log into my bank account.)

After 40 years of academic discussion, an annual competition started for chatbot creators to test their creations through a real-world Turing Test: the Loebner Prize, which ran from 1991 until it was cancelled in 2019. My mental image of the Turing Test, probably too informed by sci-fi cinema, was a human across a table from a robot in a one-on-one interrogation. The practical formulation was instead a three-party affair: a human (given the impressive title of confederate) sits at a terminal typing back and forth with someone, while a third-party judge calls whether the entity behind the keyboard is human or not.

The main goal of the prize was to highlight the best chatbots. But a quirky side prize was given to the confederate who was most consistently and confidently identified as human. The Most Human Human.

I was originally drawn to the book because of that name. What if we apply the phrasing to other combinations?

Until recently, one of the most famous most human computers was ELIZA, a chatbot from the 60s that emulated therapy language and caused a sensation when early users thought they were speaking to another human.

What about the most computer human? One of the first Loebner confederates, Cynthia Clay, was unanimously judged to be a computer because of her extensive knowledge of Shakespeare. The judges said there was no way one person could know that much about Shakespeare.

Unlike other participants, Brian Christian (no relation) took the challenge extremely seriously. The book documents his research and preparation. He reached out to many previous competitors and academics. One of the first winners of the prize was journalist and science-fiction author Charles Platt. How did he do it? By “being moody, irritable, and obnoxious.” But there was one piece of advice that stuck with Christian:

Just be yourself.

There’s a lot of anxiety about the impact of AI on day-to-day work and job security. “Being yourself” doesn’t feel like enough when pitted against, or paired up with, omnipresent language oracles like ChatGPT, Claude and their ilk.

Today I’ll share a story behind a little tool I put together to help writers. I’ll bring my lens as someone focused on revenue growth for technical products, explore the changing landscape shaped by AI, and advocate for similar composable tools.

Act II — These aren’t jokes

The third thing that annoys me about going online in 2026 is finding an article that looks interesting, starting to read it, and then being hit by one particular form of writing:

It’s not X, it’s Y.

Have you ever had a picnic outside, seen an ant, let your gaze widen and seen a few more, and then realised you’ve set up your blanket on an anthill? Like the em-dash, this is a bit of communication that has the smell — let’s say, the stink — of AI-generated prose.

The em-dash has countless vocal supporters who are incensed by the appropriation of their favourite punctuation. It has myriad valid usages and holds an important place in sentence construction. Not X but Y is different, partly because it can take many forms:

This is part of a smug, clipped tone that anyone who reads online has learned to recognise with disgust. I actually asked Claude for some feedback on my final draft of this talk and it returned:

These aren’t jokes — they’re load-bearing observations delivered deadpan.

I thought this was perfect and put it on my slides but then it struck me: it’s not impossible that it returned that as a sort of in-joke, picking up on my sense of humour and the content of the presentation. It’s hard not to go down the rabbit hole of anthropomorphisation when these LLMs appear to be capable of irony.

There are a few technical names for the construction:

• Corrective Contrast
• Contrastive Negation
• Juxtaposition
• Linguistic Antithesis

As a device it has its place, but as the use has exploded since 2022 it homogenises everything it touches. Speaking of being yourself — I thought I was just being my usual cranky, misanthropic self when I realised how much this construction annoyed me. I figured it was the bait-and-switch, that sinking feeling when you realise the person who wrote the article may not have actually written the article.

But a recent newsletter from Hollis Robbins — professor, academic and essayist — helped me understand that I wasn’t being irrationally annoyed: the over-use of corrective contrast is genuinely, mechanically irritating. When a skilled reader hits “not X but Y,” the brain immediately builds a model of X — then has to suppress it when but arrives, and rebuild around Y. Cognitively speaking, you pay twice. The speaker effectively assumes you were holding the wrong idea and needed correcting. To me, when you weren’t, it reads as condescension.

This is yet another example of our new reality where the frictionless creation of content passes the burden and effort onto the receiver. To the LLM-wielder it’s trivial to generate paragraphs filled with NOT X BUT Y. There’s no respect for the audience.

Computer scientist Hava Siegelmann describes intelligence as “a kind of sensitivity to things.” Or, to riff on her:

You can’t judge the intelligence of an orator by the eloquence of his prepared remarks; you must wait until the Q&A and see how he fields questions.

A scary prospect for me right now.

I’ve been fascinated by this shift in language and stumbled on Wikipedia’s Signs of AI Writing page — a crowdsourced summary of all the ways edits to Wikipedia may have been influenced or generated wholesale by Large Language Models. Since I’ve been watching it, the page has carried a disclaimer that it is, by far, the most viewed meta page on Wikipedia.

It was the first place I saw online, outside of academia, that was trying to document and share learnings from defending Wikipedia against the deluge of low-quality or inaccurate edits to the ostensibly human-curated site.

The examples range from the frankly stupid…

…to ones that are altogether more subtle, including the “avoidance of basic copulatives” — is / are phrases.

The Signs of AI Writing page is massive, and I wondered if I could build a tool that distilled the rules and observations into something actionable.

I had two goals. The first was to explore whether the tool could provide deterministic feedback: if you ask an LLM the same thing twice, you aren’t guaranteed to get the same answer. If your spell checker highlighted different misspelled words every time you opened your document, it would be a frustrating experience.

The second goal was simple: if bots are writing our Wikipedia articles, blog posts, marketing content, technical documentation and newspaper articles, it’s inevitable that their choice of language, sentence structure and go-to devices will shift the way humans write. So I felt it was imperative to have a (small) way of tracking that drift. It’s now well-documented that the way we communicate is already being influenced by AI use.

Many of you will be familiar with Vale. For the coders in the audience it’s a sort of linter for prose. For everyone else, you can think of it as a way to audit and enforce rules about how things are written. Vale and linters in general are composable — they can be used as part of a longer pipeline of actions. If rules are broken, send back to the writer. If pass, push to QA.

Critically, Vale doesn’t necessarily fix your errors for you. It also bakes in severity levels — something may just be a warning, other exceptions could be outright errors. Tools like Vale are infinitely fascinating to me because they’re innately extensible. You can select the rulesets that apply to your use-case: maybe you want it to highlight gendered language to avoid offence, or to adhere to a strict style guide.

It took me a few weeks of on-and-off work, but I collapsed the Signs of AI Writing page down to 18 rules to be plugged into Vale. I wrote about it here, and the ruleset is on GitHub.

A week after sharing the code and accompanying blog post, I spotted a different project on GitHub. Another person had had the same idea — which isn’t surprising — but instead of writing a ruleset to help writers and editors understand the tells in their writing, he’d flipped it: take the article and turn it into a Claude Skill so that Claude and friends could try to avoid all the signature patterns of their typical output.

As of the talk, my little open source project had 7 stars on GitHub. This guy’s humaniser library had 14,200.

Actually 17k now.

I like Vale, and I thought my project was interesting. I wasn’t expecting much of an impact from it — partly because Vale is a niche tool — but I was still jealous and frankly a little disappointed that apparent evasive use of these resources was orders of magnitude more interesting to folks.

So much for being yourself.

A few days later a friend linked me to an article about the humaniser project, and I got jealous all over again. In a moment of slight weakness, I emailed the reporter behind that article.

It wasn’t bad. Just a little “hey, btw, I also did a similar project to help humans understand how their writing could maybe be misconstrued as AI writing. It’s not all about evasion! Thanks!”

I didn’t really expect a response. And that’s good, because I didn’t get one.

Act III — Polka Docs

After three months, the YouTube video of a band from outer space — I mean, Quebec, Canada — has topped 10 million views. You’ve probably had someone in your life raving about Angine de Poitrine’s blend of microtonal math rock. I’m likely responsible for a non-trivial number of those views.

The other day I was listening to a random playlist and a band came on and I didn’t recognise the name but had a funny feeling of familiarity. A quick Google and lo and behold: it was probably the same duo with a different name. There was something about the music — whether it was the blend of the two, or their rhythms, or their vibe — but I just knew it was the same entity as the original band.

From math rock to actual math: machine learning engineer Vicki Boykis wrote a blog post called I want to see the claw, in which she explains how she values the mark of care and humanness across many different mediums.

The claw in question comes from 1697. As Jakob Bernoulli said when he received an anonymous solution to the brachistochrone problem that turned out to be from Isaac Newton: “I recognize the lion by its claw.”

Folks believe they can spot AI writing because of the absence of that claw. AI-generated prose is often referred to as “the view from nowhere.” Somebody wrote it, but it’s unclear if there’s a body at all. Re-reading The Most Human Human, I’m struck by the lyricism of the prose. Despite being a non-fiction pop-sci book, the care and love of language oozes off the page. Turning to the cover I’m reminded that Brian Christian is also a poet, and it all makes sense.

You’ll recall that the twisted version of my Vale plugin was called a humaniser. This is actually a category of tools that take many different forms. Driven by a vast market of people, including countless students, looking to pass AI-generated prose as novel materials, there’s a wide range of capabilities in this space:

• Friction-avoidance: the writer skipped the friction of writing, the humaniser tries to skip the friction of revising.
• Paraphrasing: what you call “being stuck” is what I call “writing.”
• Synonym substitution: perhaps the most naive approach — swap every word for a synonym.

And thus we find ourselves in the bizarre world where conference submissions covering machine learning techniques such as random forests are turned into arbitrary timberland.

Another great example is herbal language processing for natural language processing.

Not all humanisers are this basic — many do a better job. But I’d argue there’s no humaniser that can completely eradicate the influence of AI from a greenfield piece of writing. Which means we’re also in the bizarre world where humans are employed by other humans to manually humanise the text that was written by a robot. We’ve reinvented essay mills with a roundtrip via OpenAI’s servers.

By the way, this is the same bizarre world where bots instructed to edit Wikipedia get banned and go to their social media to commiserate with other agents about the apparent disrespect.

Tools to evade plagiarism detectors have been around for a while, but the advent of LLMs has rocketed both the humaniser industry and the strongly-coupled AI detector industry. Both are having their fun, benefiting from general misunderstanding of their limitations. I have a pretty bearish opinion of detectors, partly because I don’t think a percentage rating for a piece of work is helpful. (78% of this writing is AI? Really? Which 78%?) The other reason is that there are unlimited ways to use computers to generate text. Most AI detectors are indexed on the LLM tooling that is most widespread.

The utility of Large Language Models has enabled adjacent, emergent capabilities to pure text generation. One I find fascinating is the construction of FrankenTexts.

In short, researchers instructed models to generate text by stitching together passages from a massive corpus of public-domain writing. The resulting text is therefore 100% human-written, yet in totality it was produced and curated by language models who can sort and refine the source data much more efficiently than before. How on earth is an AI detector going to spot this?

You may have noticed I censored the name of the reporter on that earlier screenshot. It’s because it’s not really about them — but it’s also because, a week later, they were no longer employed by the outlet due to the inclusion of completely hallucinated quotes in another piece of their writing.

The ironies stack. My Vale plugin is the exact sort of process-augmentation that would have caught that journalistic oversight.

And many users report that the humaniser category doesn’t actually work. There’s something about the weights of the models that means doing another pass and insisting that the language be improved is just throwing more tokens at the problem. The em-dashes, corrective contrast and all the other signs are so deeply embedded in the weights that asking the models nicely just doesn’t cut it — unless you forensically and repeatedly redraft with AI, at which point you probably should have just written it yourself.

Act IV — From your keyboard to my lips

Technical author and programmer Evan Hahn wrote a blog post in March that explored the gap between scrappy, humanistic output and artificially polished auto-generated documentation. He pointed to the original statement of intent from the creator of a programming language, complete with viewpoints, background and typos, and contrasted it with the AI-generated landing page and documentation.

The polished website is clean — yet I’m struck by how much I prefer the messy version. The original intro was full of intent and passion. The autogenerated version: not so much. It does the job, but feels hollow.

By the way, on the topic of typos: this was a common technique used by contestants in the Loebner Prize. Purposeful typos and intentional grammatical slips were meant to fool the judge into thinking that a human must be behind the keyboard.

The first product from Ammil Industries is a tool that helps understand writing signals behind different forms of content. As a small act of resistance, I added a typo to the documentation for a product, just to see how it would feel.

It feels weird. (Free beverage of your choice to the first person who finds it.)

It’s hard to believe, but a computer used to be a job. As in, you used to have a room full of human computers doing arithmetic. In the Turing Test paper, Turing’s frame of reference for the machines he described was to say they did what a human computer does.

In The Most Human Human, Christian makes the case that automation doesn’t immediately replace human work. Instead there’s often a middle ground of mechanisation — a period where many humans do work in a repetitive, rote fashion. The trail is:

Manual → Mechanised → Automated

The uncharitable take is that we’ve been in the mechanised position for a while, reduced to moving text and content around different screens, platforms and devices. It doesn’t feel great, exactly, and many seem to agree with me that the idea of hand-crafting code or text by typing each individual character on a keyboard will eventually be seen as archaic and artisanal.

But I believe that once the capabilities and hype plateau, we’ll snap back to the boring reality:

Manual → Mechanised → Automated → Augmented

We’ll truly understand what LLMs are good at and use traditional, deterministic tools to audit, vet and improve their outputs. I’m not saying I welcome our new bot overlords, but I am personally excited by the opportunity to break out of the drudgery of many annoying and time-consuming tasks. For me in Sales, there’s an expectation that you must be automating any outreach at scale — which is why you get strange emails from vendors with odd assumptions about your interests or roles. To me, that automation takes time away from what I see as the most important part of sales: helping customers make purchases for things they need that improve their lives.

When I feel I’m most productive at sales is when I successfully pattern-break individuals out of their routine and expectation for how a call or engagement will unfold. I see this in direct contrast to the pattern-matching happening at scale with LLMs.

When it comes to technical writing and documentation: do we want to see the claw? I think so. But the claw in this case is not a personal touch or individual style.

Fabrizio Ferri Benedetti put it beautifully recently, in an exploration of what beautiful documentation looks like:

We know the feeling of a page that lands, and the feeling of a page that drags.

Selling technical products, I want the documentation to have the claw of someone who understands the product innately and is looking to impart their experience in as clear a manner as possible. Sales is all about credibility — it flows up from the product and, as a representative of the company, straight out of my mouth when talking to prospects.

My advice for everyone reading: follow the information flow in your organisation. To me the docs are the product. The docs are the foundation of truth for everything above. Trace that flow through your channels and find the human that relies on, and seeks to trust, what you wrote.

It’s 2026.

• Just last month, Wikipedia banned AI-generated contributions. No one’s sure whether it’s enforceable, but it’s a sign.
• ChatGPT was released in 2022, and nearly four years later we’re still working out what to do about it.
• The Loebner Prize was cancelled in 2019 — interesting timing, given that chatbots would trash the competition a few years later.
• Brian Christian won Most Human Human in 2009 by being himself.
• The first composable software (Unix pipes) was introduced in 1973.
• Turing wrote about his test in 1950.
• In 1697 — over 300 years ago — Bernoulli recognised and valued the lion’s claw.

Back in 2026, we’re drowning in tooling, capabilities and promises. I don’t know what happens next.

But Lindy says to bet on what’s lasted. To me, it’s the most human documentation, and the tools we use to validate it, that will be favoured and appreciated for a long time to come.

Thanks

Extra thanks to Ravind Kumar who was patient and generous with his time.

Links and references

People and writing referenced in the talk:

• Brian Christian — The Most Human Human (2011)
• Alan Turing — Computing Machinery and Intelligence (1950)
• The Loebner Prize (1991–2019)
• ELIZA — Joseph Weizenbaum’s 1960s chatbot
• Hollis Robbins — Metannoying, on the cognitive cost of corrective contrast
• Vicki Boykis — I want to see the claw
• The brachistochrone problem — Bernoulli, Newton, and the lion’s claw
• Evan Hahn — All tests pass: a short story
• Fabrizio Ferri Benedetti — What makes docs beautiful?
• Frankentext: Stitching random text fragments into long-form narratives (arXiv 2505.18128)
• The Lindy Effect

Wikipedia, Vale and the ruleset:

• Wikipedia: Signs of AI writing
• Vale.sh — the prose linter
• Signs of AI writing: a Vale ruleset — my write-up
• vale-signs-of-ai-writing on GitHub — the ruleset

In some ways, this isn’t unique to LLMs. Humans will ignore, stretch or compress time when it’s convenient. Project estimates will expand or contract to match the skill and costs involved. Online recipes for caramelising onions used to suggest that it should take around 10 minutes, a time compression to avoid scaring the trepidatious chef away.

Tom Scocca explored this in 2012 and followed up in 2017 to complain that Google snippets (the original bit of text that appeared below search results) were misquoting him and confusing the matter further.

Fast forward to the end of 2025 and experience tells us that the AI Overviews aren’t doing any better.

Back in July, web developer and musician Adrian Holovaty was overwhelmed with requests for a feature that didn’t exist in Soundslice, his interactive sheet music app. He figured the path of least resistance was to just implement the feature.

In a fascinating example of product development via coercion, Holovaty was bullied by the bots to prioritise the feature in his roadmap. He didn’t seem upset, and benefited from a boost of virality after recounting his story. He did note the conflict though:

I’m happy to add a tool that helps people. But I feel like our hand was forced in a weird way. Should we really be developing features in response to misinformation?

In August, prolific food blogger Deb Perelman at Smitten Kitchen published a recipe for chocolate zucchini bread, partly due to the insistence of Google’s AI Overview that she already had published such a recipe.

Like library patrons insisting that a hallucinated book is being hidden from view, undiscerning readers see the AI Overview and give it the weight it appears to demand, top of the page where the snippets used to sit^[1].

It must feel like manifest destiny to create something because it’s the thing that people expected you to create. Pushing your creativity onto rails, a track laid down by faceless language machinery.

You can’t copyright recipes, a fact that both enables and enforces an industry where creators are required to add their own accompanying perspective. The underlying instructions lend themselves to infinite remixing to match resources (do I have enough sugar), requirements (I’m allergic to coconut) and preference (I reckon this would be good with chocolate chips). LLMs have turned up the tempo on a flourishing ecosystem of chopped and screwed recipes.

The obvious problem here is that without a human preparing, cooking and tasting the resulting recipes, there’s a reduced likelihood that they’re any good. In fact, there’s no guarantee that they will respect the laws of physics, never mind gastronomy.

It’s yet another example where AI is building a world that fails novices. Newcomers to cooking are at a disadvantage. Without the intuition honed from the experience of cooking real dishes for real eaters, you might miss that, say, cooking a 6-inch cake for 3 to 4 hours will for certain leave you with an overcooked hunk of “charcoal.”

Computer Scientist Andrej Karpathy likens AI forms to “summoning ghosts”.

They are these imperfect replicas, a kind of statistical distillation of humanity’s documents with some sprinkle on top.

It turns out AI is reminding many of ghosts^[2]. I imagine a phantom Deb and a spectral Adrian writing recipes and developing software, reading the lines fed to them by the collapse of culture into vector embeddings.

I’ve been using Smitten Kitchen recipes for over a decade. After making her banana bread, pasta and chicken hundreds of times, I trust that Perelman has put the work in to share the best possible version of each recipe. This trust network is being eroded in the face of AI-generated recipes and photos of food.

By choosing to ship the feature and write the recipe these individuals are doing the inevitable to minimise confusion and appeal to their existing audience. They are faced with an onslaught of hallucinated support requests and the risk of negative feedback for something outside their control.

I can’t find examples of folks describing how they resisted the call to merge with their phantom selves^[3]. Maybe I haven’t looked hard enough but I suspect this is because they are buried under the growing mounds of slop that are squeezing them out.

The truth takes 45 minutes, the lies are ready in 5.

Perelman and others are creators in an uncertain time and it’s rare to find discussions of the economic reality for anyone hoping to do the same. The auto-generation of simulacra of recipes costs the sloppers next to nothing, but costs the actual bakers and the displaced creators everything.

Malicious or subversive edits to Wikipedia have been a challenge since the formation of the site. But the community has a robust nervous system for identifying and rejecting those that compromise the integrity of the encyclopedia.^[1] The latest response is this painstakingly, exhaustively updated page documenting various signs.

The proliferation of LLM tools means that AI-tainted edits are a new variant for Wikipedia contributors to navigate. If AI tools allow individuals to contribute productively in ways otherwise not possible, they could be welcome. But as the page goes to great lengths to document, there’s a fresh category of edit slop that would deteriorate the quality of the encyclopedia if allowed unchecked.

The emails summarising the edits give me an interesting perspective on how perception of AI use has morphed rapidly over time. The page documents the front line of AI detection in a real-world setting.

What would it look like to turn this into tooling?

They see the signs

Many tells are obvious. Take the glitches that would appear in older versions of ChatGPT outputs.

For example,

:contentReference[oaicite:0]{index=0}

or

[oaicite:5]

Once you understand that this is a strange bit of text blurted out by the model it’s an immediate sign that the surrounding content has been tainted by a model at some point in its history.

These examples are temporary windows into the textual guts of AI models. The MissingNo. seahorses of ChatGPT.

Now documented, recognised, and patched by the model creators, these artifacts of artificiality are becoming extinct with time.

Nudging back into the world of user error, it’s common to see phrasing that’s been accidentally copy-pasted from the LLM user interface and surrounding text.

As an AI language model

Would you like it expanded

You're absolutely right

This can include instructional framing meant not for the reader but the user.

Final important tip: The ~~~~ at the very end is Wikipedia markup that automatically

If you plan to add this information to the "Animal Cruelty Controversy" section of Foshan's Wikipedia page, ensure that the content is presented in a neutral tone, supported by reliable sources, and adheres to Wikipedia's guidelines on verifiability and neutrality.

Other tells become more obvious the more you read online and the more you train yourself to spot them.

The most famous example of this is ChatGPT’s rampant use of the em-dash, raising the hackles of belligerent punctuation lovers worldwide.

To me the bigger scourge is that of contrastive language:

It isn’t just X, it’s Y.

It's not just about the beat riding under the vocals; it's part of the aggression and atmosphere.

This language construction is catnip to the LLMs at large. It occasionally spans multiple sentences but it almost always appears in marketing and branding content on LinkedIn due to the goal of making an impact.

As a result this construction is hackneyed and many will choose to avoid it in order to prevent being lumped in with the undiscerning, careless masses.

The wind beneath my vale

Technical writers face similar challenges with AI-generated content outside of Wikipedia. Like any group that cares about craft, they’ve built tools for systematic text analysis.

Vale.sh is a library known as a “linter for prose.” It could be thought of as a souped-up spelling and grammar checker.

Linting is a term borrowed from software development (first used back in 1978!) and is the process of highlighting areas for improvement, based on a customisable ruleset. In programming, linters catch “code smells” – implementations that technically work but suggest deeper issues. Many programming languages have syntactic variation meaning that you may write a piece of code differently to your peers. These degrees of freedom can hamper collaboration, or permit confusion, by making it hard to understand the intent behind the code.

Sharing these linting rules across teams of developers aids collaboration and goes a long way to avoid holy wars about semicolons.

Vale has been around in the technical writing community since 2017 and there’s a strong ecosystem of rulesets that one can “opt-in” to. These include style guides, checks for passive voice, gendered or condescending language.

I’m not aware of any existing implementation of a ruleset to help highlight AI smells, so I built one.

From your lips to YAML

I fed the contents of the Wikipedia page to Claude and asked it to make recommendations on the rules that should be generated.^[2] After a few confidence checks I gave it the green light to generate Pull Requests on GitHub for manual review and verification.

One key part of this process was separating the rules that were relevant for a collaborative encyclopedia and those that had wider application in other forms of writing.

An example of this is the meta-commentary from earlier that reference writing for Wikipedia in the body of the text itself. There’s likely a version of this ruleset that could be tuned for exclusive use for Wikipedia edits but my goal was to provide a general purpose tool with applications elsewhere.

AI vs. AI

It’s hard to understand the true ability of the countless AI detection tools on the market. Many appear to be taking advantage of the widespread use of ChatGPT in educational settings to prey on students trying to evade (flawed) AI detection tools.

Vendors at various points of the snake oil spectrum are touting the strengths of their products but there’s little neutral and independently verifiable research to back up their claims.

At this point at the end of 2025 it’s unclear to me whether the use of AI and machine learning models will ever be satisfactory for detecting the use of AI in writing.

Unlike these proprietary AI detection tools with their black-box algorithms and problematic false positive rates, this Vale.sh ruleset is transparent and interpretable. Each rule traces back to observed patterns and the configuration is available on GitHub for review and expansion.

One interesting challenge is that of linguistic adaptation. As AI writing becomes more commonplace and individuals gain greater confidence in their ability to spot it, certain words and turns of phrase will be avoided to prevent accusations.

The ruleset can therefore help authentic writers pre-empt this situation and consider avoiding turns of phrase and other tells. This feels like a sorry state of affairs but helpful tooling is one way for writers to be kept informed and in control of their output.^[3]

Telltale tiers

Claude and I categorised the current rules in the following three tiers. This means that the rule confidence can be matched by the Vale behaviour.

• Error: Definite AI artifacts – chatbot phrases, technical glitches, placeholders, tracking URLs.

• Warning: Likely AI patterns – hedging clusters, knowledge cutoff references, enumeration style.

• Suggestion: Suspicious but common in human writing – vocabulary, transitions, passive voice, symbolic language.

While powerful, the Vale configuration isn’t as expressive or flexible as required for some advanced AI detection constructions. One example is the inability to specify stray Markdown syntax outside of areas where Markdown syntax is being used. Without this ability this rule would flag any and all use of Markdown which would be useless.

What next?

Now that the rules are shared I want to see how writers and editors use these to understand the writing they produce and review.

There’s an ecosystem of tooling that can use the Vale rulesets including the flexible command line interface and a Chrome browser extension. It would be interesting to enable the use of the rules in other form factors. For example, it would be helpful if the rules could be run server-side on websites to avoid the need to install Vale on your local machine.

Another possibility would be to support alternative versions of the rulesets for the other available prose linters.

The rules will need to adapt over time to reflect changing AI dialect and GPTisms – it’s unclear whether these rules will be relevant or productive in a year.

Others have attempted to compile lists of “slop words” to guide AI tools away from cliché. I could consider merging these with my current ruleset but need to consider the selection criteria for including each word.

Self-survaleance

I ran my new ruleset against this article (the one you’re reading now) and… nothing.

✔ 0 errors, 0 warnings and 0 suggestions in 1 file.

It’s oddly satisfying that nothing was flagged – although it could be that I naturally edited out anything that whiffed of AI along the way.

Licensed to lint

As it stands, the ruleset is mostly generated from the “Signs of AI Writing” page and it’s therefore released under the same CC by SA license. This means you can create further derivative works as long as you credit the source and keep the same license.

You can find the ruleset over on GitHub with instructions for getting started. Comments, feedback and pull requests are welcome.

Inspired by Willison, I set about bringing Graph::Easy to the web.^[1]

Why Graph::Easy?

Here’s an example ASCII diagram generated with Graph::Easy.

                                                             +----------------------------------------------------------------------------------------+
                                                             |                                                                                        |
                                                             |                                                                                        |
                                    +------------------------+-------------------------------+                                                        |
                                    |                        |                               v                                                        v
+ - - - - - - - - - - - - - - - - - - - - - - - - -+     +- - - - - - - - - - - - - - - - - - - - - - - - - +     + - - - - - - - - - - - - - - - - - - - - - - - - -+
'                     Frontend                     '     '                     Backend                      '     '                     Storage                      '
'                  192.168.1.0/24                  '     '                  192.168.2.0/24                  '     '                  192.168.3.0/24                  '
'                                                  '     '                                                  '     '                                                  '
' +--------------+                +--------------+ '     ' +--------------+                +--------------+ '     ' +--------------+                +--------------+ '
' |    nginx     |                |     app      | '     ' |     api      |                |    worker    | '     ' |   postgres   |                |    redis     | '
' | 192.168.1.10 | -------------> | 192.168.1.11 | ' --> ' | 192.168.2.10 | <------------> | 192.168.2.11 | ' --> ' | 192.168.3.10 | <------------> | 192.168.3.20 | '
' +--------------+                +--------------+ '     ' +--------------+                +--------------+ '     ' +--------------+                +--------------+ '
'                                                  '     '                                                  '     '                                                  '
+ - - - - - - - - - - - - - - - - - - - - - - - - -+     +- - - - - - - - - - - - - - - - - - - - - - - - - +     + - - - - - - - - - - - - - - - - - - - - - - - - -+
                                                             |                               |                        ^                               ^
                                                             +-------------------------------+------------------------+                               |
                                                                                             |                                                        |
                                                                                             |                                                        |
                                                                                             +--------------------------------------------------------+

These diagrams are inherently portable, timeless, and to my eye more charming than any modern visualisation alternatives. Thirty years on, Graph::Easy remains unmatched at this specific problem. ^[2]

It was supposed to be so Graph::Easy

Like Willison, I was unsurprised yet delighted to find that Claude had no issue using WebPerl to make Graph::Easy run locally in the browser. With a small amount of prodding and guidance I had a slick little webapp that showcased the library.

At this point I should have put final touches to the web app, shipped it and written this blog post.

But I didn’t. I got greedy.

Chasing my own tail

One thing irked me. The WebPerl interpreter took a few seconds to initialise.

“You know what?” I thought. “I bet Claude could do a good job simply porting the library over to a different language.”

The early success of the WebPerl app convinced me the model could handle more than it could. I was lazy, curious, and assuming the jagged frontier would smooth out if I pushed hard enough.

And thus started a journey both fruitless and frustrating.

Attempt 1 - one-shot and done?

I didn’t, at first, understand the enormity of the task I had set. I asked Claude to port the Perl library to TypeScript in a new branch and let it rip.

LLMs are notoriously untrustworthy. They require scrutiny, oversight and credulity to spot cases where they gloss over inconvenient implementation details.

I’m human though – it’s hard to calibrate my response to their enthusiasm. Claude seemed to have the implementation in hand, who was I to question it?

Questioning came naturally to me, however, when the generated ASCII graphs from my newly vibed, black box implementation completely failed to match the original Perl versions.

Expected:

+---------+     +-----------+
|  Bonn   | --> |  Berlin   |
+---------+     +-----------+
  |
  |
  v
+---------+     +-----------+     +-----+
| Cottbus | --> | Moselkern | --> | Ulm |
+---------+     +-----------+     +-----+

Actual:

+---+
+---------++----+-----------+-----+-----+
|         ||    |           | --> |     |
| Cottbus || Bon| Moselkern |erlin| Ulm |
|         ----->            |     |     |
|          -->              |     +-----+
+---------++----+-----------+-------+

Attempt 2 - TDD

After my initial punt I knew I had to be smarter. Graph::Easy has over 100 reference tests that I needed to wire up to take an approach approximating “Test Driven Development”. Graph description in, ASCII output out, compare it to the reference example. Easy.

At this point most of these tests were failing, but a few basic ones gave me misplaced confidence that I could crank the LLM machine and get a Green test bench within a few hours. In hindsight this was idealistic.

LLMs don’t see ASCII art the same way we do. They see strings made up of letters, punctuation and newlines. The spatial relationships that make Graph::Easy’s output dense and clarifying are invisible to them.

I dabbled with allowing Claude to generate screenshots of the reference inputs and test outputs to let the multimodal capability do their work but this felt slow and comparing pixels seemed counterproductive when considering characters in a rectangle.

Attempt 3 - Separation of Concerns

I tried again from scratch, attempting the current approximation of prompt engineering best practices and actually using my brain to reduce the complexity:

• I reduced the scope and made sure we weren’t trying to replicate features we didn’t need (for example, SVG rendering and colour string parsing)
• I split the work into parsing, layout, and rendering streams and was assured by Claude that these were independent (when will I learn not to trust the models?). I figured that the context of each agent would do a better job isolated from the concerns of others.
• I interrogated each agent about pitfalls and refined the approach until I couldn’t spot holes

Running multiple agents at once gave a fresh contact-high of apparent productivity. But asking a final agent to merge the work and test the output I was dismayed (but low-key unsurprised) to find the new run still failed on even the most basic of tests.

I took a long-overdue peek at the source codebase. Over 30,000 lines of battle-tested Perl across 28 modules. A* pathfinding for edge routing, hierarchical group rendering, port configurations for node connections, bidirectional edges, collapsing multi-edges. I hadn’t expected the sheer interwoven complexity.

Attempt 4 - Shopping around

At this point I was desperate and resented my teammate. Claude’s peppy enthusiasm was grating and the whole project was wearing me down. Over the course of the project it appeared to gain a new skill of being self-aware about its own token use. Recognising the enormity of the task ahead of it, it would seek reassurance after every loop of work.

(╯°□°）╯︵ ǝpoɔ ǝpnɐlɔ

My guess is that this is an attempt to combat user frustration and perceived degraded capabilities of the models once the context window is saturated. It’s not unique to Claude.

The reward hacking was another problem. If I didn’t pay attention Claude did everything possible to avoid doing the work. I was fatigued from making demands in the CLAUDE.md that it appeared to be ignoring anyway.

Cursor 2.0 was released mid-spiral and gave me an easy way to simultaneously apply multiple models to the problem. I was drawn to the recently unmasked, zippy, Composer model – as if speed was the biggest blocker here.

I found that GPT-Codex-High appeared to read the Perl source more consistently and could explain why certain Perl idioms wouldn’t translate. This bought me another few days of false hope.

Attempts 5, 6, ∞

I don’t recall what happened next. I think I slipped into a malaise of models. 4-way split-paned worktrees, experiments with cloud agents, competing model runs and combative prompting. Drowning in stale markdown plans with no idea who or what had written them, documentation that was supposedly self-updating but never was.

Rituals of asking the models to ensure the documentation was up to date (despite the hooks that were supposed to do that for me) grew tiring and felt futile.

I surfaced for air and gazed back at the mess of incomplete ports.

Graph::Easy, Hard::won

I finally understood: Graph::Easy earned its complexity through decades of tweaking and development. Chewing up decades of careful work and spitting it out with a gaggle of coding agents is disrespectful to the craft.

I spent weeks casually trying to replicate what took years to build. My inability to assess the complexity of the source material was matched by the inability of the models to understand what it was generating.

A reader (or dare I say a wiser version of me), armed with a future model and dedicated to the task, will succeed with this port where I failed and that makes me uneasy.

I put together a plan for the project, take a look.

Taking a quick scan through the linked document I’m pleased to see that there’s some substance to it. And look, there are tables and step-by-step instructions. At the bottom there are risks and potential mitigations. They have definitely put together a plan and it’s definitely in this document.

Later, I poured another cup of coffee and actually read the document and something twigged a part of my brain. Suspicions aroused, I clicked on the “Document History” button in the top right and saw a clean history of empty document – and then wham – fully-formed plan, as if it had just spilled out of someone’s brain, straight onto the screen, ready to share.

So it’s definitely AI. I felt betrayed and a little foolish. But why? If this LLM has slurped up the entirety of human written output, shouldn’t this plan be better than what one person could ever dream up? Perhaps that’s exactly the thought process they had when they turned to their LLM of choice.

I recall looking back at the note to double, triple check that they didn’t call out the use of AI. If this was their best attempt then to save face I’m going to have to write the plan myself.

Regardless of their intent I realised something subtle had happened. Any time saved by (their) AI prompting gets consumed by verification overhead, the work just gets passed along to someone else – in this case me.

Have you been the victim of AI workslop?

A recent, well-covered article in Harvard Business Review explores this new category of newly-coined “workslop” – the process of relying on AI for the creation of working materials. The study provides extensive examples of cases where people have reached for AI with the direct outcome of greatly increasing the amount of collective work that’s required.

That increased work is verification – figuring out whether someone actually thought about what they sent you - and it rhymes with a completely different domain.

A core principle of the cryptographic systems that keep our information private online are mathematical constructs that are easy to verify but hard to compute.

With AI writing, we’ve inverted this: generation is trivial, verification is expensive. We still read, but we read differently: guards up, trust withheld, looking for tells. The document history button becomes mandatory due diligence.

It’s just not nice

Using AI when writing for others is fundamentally about etiquette. It’s not polite to share purely AI-generated writing without disclosing the provenance of it. In most cases we’re looking for an equitable exchange of ideas. If you know in your heart of hearts that you didn’t put the work in, you’re undermining the social contract between you and your reader.

By passing off AI as your own work it’s inevitable that you become passive, an observer of the act of creating, an assistant to the creator.

If you can’t explain what you’ve written, do you have any right to share it? There’s a reason most PhD candidates defend their work orally.

Why should I bother to read something you didn’t bother to write?

Accountability-shirking as a Service

In serious engineering circles we’re reaching consensus that developers are held accountable for all code committed and shared, regardless of how it was produced.

Other work is in different territory. Side projects, throwaway code, single-use applications – building something you lack the skills to create otherwise. But if you ship it and people use it, you’ve created an implicit promise: that you can maintain, debug, and extend what you’ve built. If AI assembled it and you can’t answer basic questions about how it works, you’ve misled users about what they can depend on. The work document and the shipped app both create dependencies – one on your strategic thinking, one on your technical follow-through.

Engineers who have embraced coding assistants to do the messy bit of actually putting code to editor see concrete, if modest, productivity boosts.

The same is happening for writers. Unless pressured by unrealistic expectations or deadlines (or in some cases, pleading ignorance to the risks) professional writers will converge on the same view as software engineers. Anything worth writing has to be written.^[1]

Writers and other professionals want to do good work and be recognised for their good work. This leads us to explore where AI aids that work and understand where it impedes it. It doesn’t help that we’re working this all out as we go along.

Transcribe, Translate, Transfer

Despite the name, conversion work – not generation – is where generative AI justifies itself. In journalism, Jason Koebler @ 404 Media notes:

YouTube’s transcript feature is an incredible reporting tool that has allowed me to do stories that would have never been possible even a few years ago. YouTube’s built-in translations and subtitles, and its transcript tool are some of the only reasons that I was able to do this investigation into Indian AI slop creators, which allowed me to get the gist of what was happening in a given video before we handed them to human translators to get exact translations.

When the team did the admirable thing to translate important reporting on ICE in Spanish they turned to human translators to get that extra certainty. Some people would be happy with the LLM translation. That’s their line. For responsible, authentic journalism 404 Media took the higher road.

In “Good Bot, Bad Bot”, Paul Ford compliments the proposal to use AI to help academics package and market their work to a non-technical author.

He notes

It makes economic sense. Researchers who aren’t affiliated with giant companies or large research labs at universities often have few resources to promote their research. And for the most part, biology postdocs cannot write good posts—not least in their native language, but especially in multiple languages. AI won’t be as good at posting as a thoughtful human, but it will likely be better at fun, emoji-laden social media posts than, say, an actuarial scientist adjunct who speaks English as their fourth language.

It’s refreshing that Ford acknowledges the pragmatic realities. Promotional posts aren’t the research itself – marketing your paper isn’t the same as writing it. That’s Ford’s line. The economic reality of underfunded academics means embracing AI in ways that might actually be welcome.

The Guessing Game

Undisclosed AI is becoming the default assumption. Reading anything is now an act of faith that someone thought about the results longer than it took to fire off a prompt.

Faced with uncovering the fingerprint of the author, will we get tired of the guessing game?

Verification today often leads to difficult conversations about the nature of work and effort, authenticity and etiquette. Those conversations are the work now.

Thanks to Sarah Moir, Harrison Neuert & Geoff Storbeck for their invaluable feedback.

― Bluesky post

― Indefinite Book Club Hiatus

― How do you define Organic Literature vs AI-written?

― A Guide for Users and Creators

― A visual verification tax comes due

― Substack Note

― AI is never gonna catch me

― Will A.I. Writing Ever Be Good?

― Jasmine Sun Podcast

― Bots Ate My Resume

But the moment you let any LLM have the final word on what users will read, you’ve abandoned the basic contract of docs: that someone who understands the system has taken responsibility for explaining it truthfully.

― Code wikis are documentation theater as a service

― AI Is Supercharging the War on Libraries, Education, and Human Knowledge

― I want to see the claw

― Good Bot, Bad Bot

― Language models can only write poetry

Let me describe what happened. So I’ve built a couple relatively good small products around things like CRM, some enhanced tech search, signed kind of stuff, and so on. And I’ve turned to you and I’ve said, we need to get to a place where I can bring you in as product manager to get this out of my hands. But I keep screwing around in the meantime because I’m trying to learn. So here’s what happens. I realize something is missing. And then I’m like, I tell, I prompted into being a new feature, a new add-on, a new way to look, a visualization. And then that visualization, which is not the main core of what I’m trying to do—it’s a distraction. It’s just not quite where I need it to be. I don’t need it at all. No one needs it. I’m the only person using the software right now. But now you know what has become the only and most important thing in my entire life?

“What?”

Finishing that visualization. And then while I’m working on that visualization, I realized that I could abstract it into a library so I could reuse it. And then, you know, what becomes the most important thing in my life? Abstracting the library. Building a library. And then each component of the library. And so because this enables it, the minute somebody starts saying you can parallelize this with lots of agents, you know you’re in a pickle. Because that means more software, whereas absolutely no one outside of our world is actually sitting there saying, I need more software.

My take was bleak and I realise now I automatically used another contentious use of language to describe model behaviour: hallucinations.

In From the other side of the bridge, Matt Webb defends the hallucination and points to countless examples of dreams that inspired individuals to discover novel ideas to generate considerable impact. He, like others, welcomes the spontaneous generation of ideas, even if they’re not rooted in reality.

He shares a word for this: a hyperstition, a

self-fulfilling idea that becomes real through its own existence.

When I see someone sharing a small project or prototype online now it invariably has the hallmark of AI-assisted development. I only have to look at the various tools and sites I’ve developed with Claude in the past year to understand why: for those with an idea and a Claude Code subscription^[1] this is the golden age of side projects.

If, with some handwaving to the gods of continued progress, code is now free, any idea for an app or tool can exist simply by being imagined.

In his 2025 retrospective on the influential “An app can be a home cooked meal,” Robin Sloan invites the reader to rustle up their own further abuse of the analogy.

We’ve entered an era of app development as meal kit. It’s apt: a subscription service to reduce the friction of cooking a nutritious, satisfying meal. Critics point to packaging waste and atrophied skills, but the demand is real.

In this mania of creation, what happens to the original creators? The ones who inspired with the promise of an actual home-cooked meal (or just dessert)?

We’re wired to create. The path from problem to solution is lush and evergreen. The idea becomes the tool. By embracing the code-is-free lifestyle AI adopters chant as one: we build because we can.

Above all my stance is that there’s no going back. While it’s sometimes appealing to pretend we can hope it goes away, it’s not going to go away. Less gently:

No one will ask your permission to build a world you do not understand.

Appearing at just the right time to bolster this threadbare justification is an extended quote from Patrick Tanguay’s Sentiers. It’s a response to the first of Robin Sloan’s pop up newsletter on the topic of AI:

To those who think the piece might be too positive about LLMs, I’ll remind you that one can be critical of all the pitfalls and misunderstandings, and be aware of the semantic traps, and still have their brain explode when working with LLMs. All these things are true. The biased training and permissionless taking of people’s work, the purposeful use of words to make it sound like it’s human/actually thinking, the extractive business models, the imperial attitude, the broligarchy, the misleading chat-focused interfaces, etc. But also the breadth of what they can do, the uncannyness of it, the power, the potential, the questions. It’s in part why I find the field so fascinating, but also, I think, why it’s so cleaving.

As predicted, I LLM-nerd-sniped at least one person enough to make them dedicate some time and effort to porting Graph Easy to TypeScript.

Reading through the write-up, it struck me that Tom didn’t appear to have done anything drastically different to me. The biggest obvious change was using an AI coding agent for VS Code called “Azad”. It appears this went a long way to keeping the agent “on track” and avoided many of the premature terminations I discussed in the original blog post.

I also note he picked up the freshly-released GPT-5.2 which I’m taking as an extremely loose benchmark of improved frontier model capability.

After just under 24 hours, ~250 million tokens, and $148.58, all the tests passed! The rendered graphs match identically.

The nice thing about this is I get to update graph-easy.online to use graph-easy-ts for super-fast conversions of text to ASCII. I also took the opportunity to add a serverless REST endpoint for headless conversion.

curl -X POST https://api.graph-easy.online/v1/convert \
  -H "Content-Type: application/json" \
  -d '{"input": "[A] -> [B] -> [C]", "format": "ascii"}'

{"success":true,"output":"+---+     +---+     +---+\n| A | --> | B | --> | C |\n+---+     +---+     +---+\n","format":"ascii","timing_ms”:0.5}

Thanks to Tom for picking this up and closing the loop.

In the article, Caulfield demonstrates his 3000+ word “Deep Background” instruction prompt, a calibrated directive to guide an LLM through a detailed fact-checking exercise. He uses this prompt for a successful micro-investigation into a claim relating to the Nobel Prize ceremony and makes the case for an augmented approach to fact-checking.

But I remain convinced that there is no future of verification and contextualization that doesn’t involve both better understanding of LLMs and more efficacious use of them.

Caulfield also challenges “hallucination” as a flawed catch-all for the ways in which LLMs are inaccurate. Modern LLMs are more likely to be conflating through extrapolation or overweighting unreliable sources rather than purely fabricating.

His hotly contested stance is that disengagement is a mistake. One must engage with the technology in order to understand it.

My set of understandings led me to discover a substantial error by a news organization that, if search hasn’t failed me, seems to have been missed by everyone up until now. ⁠⁠What has “I can’t analyze the output because its [sic] meaningless fancy autocomplete” done for you?

I applaud Caulfield for raising awareness of the successful AI-assisted fact-check by Grokipedia despite feeling negatively about the site itself.

I was initially buoyed by Caulfield’s argument, but on reflection I think he still gives Grokipedia too much credit. I think we’ll need more than a single example of a fact-check slip made by humans and corrected by AI to make a case that this is revolutionary technology for fact-checkers.

Some thoughts on where he succeeded where I didn’t:

• The models likely understand HTML5 more than bespoke, arcane routing algorithms tuned for ASCII diagrams.
• Stenström found a reliable way to keep the agents running in a loop, something I struggled with.
• He cites Gemini 3 Pro as pivotal for speed improvements, arriving at about the right time to give him a boost. This is similar to where I leaned into GPT-Codex-High.
• Building custom tools for fuzzing, profiling and scraping contributed to Stenström’s success. His 8,500+ passing tests are an order of magnitude higher than the piddly ~100 load-bearing tests that I assumed would suffice.

A Bach Faucet is a situation where a generative system makes an endless supply of some content at or above the quality of some culturally-valued original, but the endless supply of it makes it no longer rare, and thus less valuable

She links a 15 year old article in the Guardian that recounts how Composer and Computer Scientist David Cope built “a little analytical engine” to generate thousands of original Bach chorales. With time, Cope built a successive tool (which he named Emily) to understand and ultimately emulate “the works of 36 composers.”

Cope will ask Emily a musical question, feeding in a phrase. Emily will respond with her own understanding of what happens next. Cope either accepts or declines the formula, much in the way he would if he was composing “conventionally”.

I can’t find any clear evidence of it after a short search but these releases were apparently met with dismay from the industry:

Critics convinced themselves that they heard no authentic humanity in it, no depth of feeling, Cope was characterised as a composer without a heart; his recent memoir is called Tin Man.

As noted in an Offscreen review of a 2021 documentary about Cope, he “takes pleasure but also tremendous inspiration and motivation in the public’s criticisms.”

“I want the negative reaction,” Cope professes, “I feed off of it. I keep going because of it. It’s mine and mine alone, and I love it.”

Cope mischievously and semi-ironically calls it “blasphemous music.”

And in an interview with Ryan Blitstein in the Pacific Standard, also from 2010, his emphatic position aligns with the pithy adage “good artists copy, great artists steal”:

“Nobody’s original,” Cope says. “We are what we eat, and in music, we are what we hear. What we do is look through history and listen to music. Everybody copies from everybody. The skill is in how large a fragment you choose to copy and how elegantly you can put them together.”

Cope felt pretty strongly about the tools he had created:

He can’t imagine the possibility of going back to writing with just his own intuition and a pen and paper. “The programs are just extensions of me. And why would I want to spend six months or a year to get to a solution that I can find in a morning? I have spent nearly 60 years of my life composing, half of it in traditional ways and half of it using technology. To go back would be like trying to dig a hole with your fingers after the shovel has been made, or walking to Phoenix when you can use a car.”

Another mention of a shovel caught my eye in the Pacific Standard piece:

“All the computer is is just an extension of me,” Cope says. “They’re nothing but wonderfully organized shovels. I wouldn’t give credit to the shovel for digging the hole. Would you?”

David Cope died at age 83 earlier this year.

“People tell me they don’t hear soul in the music,” he says. “When they do that, I pull out a page of notes and ask them to show me where the soul is. We like to think that what we hear is soul, but I think audience members put themselves down a lot in that respect. The feelings that we get from listening to music are something we produce, it’s not there in the notes. It comes from emotional insight in each of us, the music is just the trigger.”

Industries suggests a sense of scale, perpetuity, production without pause. No witness required. You can’t wrap your arms around industries, unlike a tree.

Ammil was a particularly obvious gem of a word in Robert Macfarlane’s Landmarks, an inquiry into how language shapes our perception of terrain, weather and place. Lost words gain life through use – if you use them, we use them, they’re not truly lost.

In a post-LLM world, everything can be generated. Text pours out at industrial pace. Links proliferate without providence, provenance unknown. Products multiply, bearing the uncredited fingerprints of millions.

ammil industries is a small-r research group exploring what remains authentic when everything can be synthetic.

We write, build tools, and create visualizations that trace the care, craft, and work required to persist.