Yap: a particular kind of slop
41 points by lilac
41 points by lilac
Okay, yes, thank you. I am adding this to my vocabulary immediately (and expect that in six months, we'll all be sick of people misusing "yap" to mean "stuff I dislike").
ahaha damn it. you’re probably right, and I had not considered that as a potential outcome when I wrote this.
I like the term yap, for just casual chatter and or casual infodumping, and I would rather not delegate another good term to LLM usage after we have already lost "vibe" to it.
I’ve recently taken to requiring the robots write all prose in STE100. It’s not perfect, and models that gradually forget AGENTS.md instructions over a session need reminders of this, but forcing the robots to write in STE really cuts down on yappery for me so far. I also forbid them from referencing any ephemeral planning artifacts or the chat session in any written documents or comments, which has cut down a lot of the “per plan-5 section 42 decision 1 (USER APPROVED 2026-08-28)……….” BS.
I could guess what STE100 was, but here's the wiki link to make it easier.
Interesting that it has a bunch of writing rules in addition to being a vocab list of simple words. I'll have to have a look at this in more detail! Evaluating English text against a rubric seems like it would be exactly the sort of thing that LLMs would be good at. (But apparently you first need to ask them to write clearly!)
A lot of people think the solution to this is to have LLMs review the code, so that humans don't have to spend as much time on it. I remain unconvinced that this alone is sufficient.
I'm glad my team doesn't operate like that. We use LLMs for code reviews, but only as a first step / canary. That is to say as long as even the sycophant machine finds obvious issues in your code, you shouldn't loop in another human, but once you're reasonably confident that you've ironed out all the "ah crap, how did I not think of that"-s, then it's time for another actual, flesh and blood person to take a look for all the less easy to spot things the LLM did miss.
I got tired of writing out dozens of thoughtful and polite review comments a day to tell robots that their code comments weren't up to snuff. Now I just say "yap" and they get what I mean.
This is a fun solution, but you haven't actually described how you implemented this into your use of LLMs. With an AGENTS.md? A customized system prompt? Some totally different mechanism?
At work (where I have to use LLMs) I've found that Sol generates much better prose of all kinds than Opus and does a reasonable job of cleaning up Opus-generated garbage comments (to the point where I can do a quick final pass of my own without having to wade through inscrutable, nonsensical slop).
It's funny that LLMs are decent at summarizing documents and answering natural language questions about code—yet they're nearly universally terrible at writing comments. I wonder if that's an artifact of LLMs being trained to write working code first (if the code doesn't compile, it's useless), with comments being an afterthought with no inherent feedback on their quality.
In your experience, does Sol write good comments? Or is it more that it cleans up garbage and is less bad than Opus?
I find that Opus is also terrible at say summarizing a commit in a paragraph suitable for a commit message (which to be clear I think humans should be doing anyway), while Sol is at least mediocre at that task. And yeah, I wouldn't call Sol's comments good, but at least they're not terrible.
I find that Opus is also terrible at say summarizing a commit in a paragraph suitable for a commit message
This is incidentally a great motivator to write commit messages by hand and not delegate this task to a model, no matter how tempting it could be. It is much easier to keep your laziness in check when you know the end result will be atrocious unless you do it yourself.
Now I just say "yap" and they get what I mean.
I'm interested in an example, since this seems like it demands a level of insight not usually demonstrated by such models. How does they change the wording once you've "yap-slapped" them, to coin the phrase?
I’d guess it’s a mix of AGENTS.md/CLAUDE.md/harness memory systems. Now that this has been mentioned and given a name though I’m tempted to try making it a skill so that /yap actually defines a set of comment and documentation cleanup guidelines that doesn’t have to live in the context full-time.
I saw somewhere else in this thread where someone was talking about STE100. I’ve played with this a little bit for the test cards I put together for actual physical system testing. What I found, subjectively, was that forcing STE100 early seemed to… I’m hesitant to use this phrase, but I’m going to: stifle creativity. I still ended up having yappy-but-STE100-complaint test cards, but they seemed like they took a lot more steps to validate the objective than necessary and missed a lot of “kill two birds with one stone” opportunities.
What I found worked better for my specific use case was to do a two-step:
generate test cards in whatever yappy language
simplify and STE100-ify them
LLMs use words that we recognize, in sentences that we can understand.
It often already fails on the second part. LLM code comments, in my experience, tend to be written in difficult to read/parse sentences, aside the from problem of redundant or irrelevant information.
“No yapping” is also a great system prompt for chat-based interfaces. Really cuts down on the filler in responses.
I’m pretty sure this exists because LLMs increasingly write for their own benefit, to reconstruct their state later.