README, not
ENOSUCHBLOG
Programming, philosophy, pedaling.
Home
Tags
Series
Favorites
Archive
Main Site
TILs
README, not
Jul 16, 2026
Tags:
ai,
oss
(Thanks to Facundo Tuesca for the name inspiration).
If you’re like me, you spend a lot of your working day (and a good chunk of your<br>personal time) reading code online. Increasingly, that means accidentally reading<br>a lot of “slop”1.
Personally, slop isn’t annoying per se2: it’s okay for personal software3,<br>for example, to be slop. What makes slop annoying is the feeling of being<br>bait-and-switched: much like the written word, I want to be informed4<br>before I spend my human attention on machine outputs.
I’m a big believer in giving people a way to express honest intentions. For example,<br>I do sometimes want to drop some slop on the Internet (to save for myself later,<br>or for others to reuse without reading), but I don’t want to mislead people about<br>the intent or effort behind it.
So: what if we gave people a way to express their honest intentions with slop?<br>We use README files to tell users where to start when reading a project;<br>I think we should have a READMENOT5 file that users (or their agents)<br>can add to their projects when they’re slopping it up. The presence of that<br>file would serve as an unambigous warning that the code within the project<br>is unsuitable for unwitting human comprehension6.
A READMENOT could contain anything, but it seems to me like a good default<br>would be a short human-friendly explanation of why the project shouldn’t be read.<br>For example:
Warning!
You're reading a project that isn't intended for direct human consumption.<br>You may wish to use an LLM or another tool to interact automatically with<br>this project.
What is or isn’t “slop” in the context of programming is currently a matter<br>of energetic (and sometimes emotionally charged) debate. I personally draw the line<br>with either of two sufficient qualities: to me, a codebase is slop if it either<br>(1) is developed primarily without human supervision, or (2) reflects a fundamental<br>lack of operator understanding. These are qualities sometimes occur at the same time,<br>but either suffices.
It’s also worth noting that LLMs are getting better; 2026’s slop is not 2025’s slop.<br>That makes it hard to grant “slop” as a static qualifier; this post reflects reality in<br>July 2026. ↩
I personally think about slop like generated code: it’s not annoying<br>for generated code to exist, but it is annoying to find yourself reading it<br>because it lacks the appropriate @generated (or whatever) marker. ↩
Meaning software that solves a personal problem, is bespoke, is single-use or<br>“disposable,” &c. ↩
I often choose to read machine-generated things. Being able to make<br>an informed decision to do so is what matters to me. ↩
I don’t really care what this file is named, or that it’s a file at all:<br>any kind of consistent marker would suffice. But calling it READMENOT is funny,<br>so that’s what we’re going with for this post. ↩
There are lots of good reasons to still read slop as a human, not least of<br>which is performing security research. The idea behind READMENOT not to tell you<br>to never read a codebase, only to inform you about you what might expect to see if you<br>do decide to read it. ↩
Discussions:
Mastodon
Bluesky
Previously