One interesting quirk of the AI-written READMEs these days is how they can include every detail on how it works, thoroughly document every optional flag, known limitation, experimental result, and still not communicate the essence of the project and the problem it solves.
I have read through the project and I still don't understand what this thing is for and why it is to be preferred over the harness's native memory management tools.
Yeah, I've started dialing back my use of AI for READMEs because of this.
My previous rule was that I never use AI for writing that expresses my own opinions or tries to be convincing (anything on my blog for example) but I'll let it do technical documentation.
The top of a README is about convincing and explaining why I built something though, which means it should fit my no-AI policy after all.
My pet theory is that while the pretraining -> RL pipeline achieves very impressive results, it does not reward clarity of thought or elegance. It's not obvious whether it even should for most tasks, but it does grind on me as a human who needs elegance in order to keep everything under control. You give astra/codex many tasks, it retires them all more efficiently than I could by hand. But you look under the hood and every bugfix is another codepath, it just hammers away at things with admirable persistence and vigor until the tests pass. Similarly in discussions and docs, I've noticed many LLMs like to "beat around the bush."
AI readme should be a starting point. I typically remove at least 50% of the details (without any particular skill use, it goes into extremes like "x clears the edit" and writes a related wall of text in the middle of the important explanation).
I once told the agent explicitly not to write like it's trying to impersonate Hemingway and it started writing like a normal human being. It's surprising how a writing style that was once revolutionary is now a hallmark of sloppyness.
Maybe give it a try next time you write a readme with agents. That and giving it an example of good README in real world repos can increase dramatically the likelihood of synthesizing a serviceable README.
It's a function of scarcity. Generation (or "writing" as it used to be known back in the day) is now cheap, so judgement and taste are the new bottleneck and therefore the difference between slop and effort.
> When you change your mind, the old line is marked superseded, not deleted
To me, this seems like a design error. You're polluting context with false/outdated information (even if the LLM is instructed to ignore it). The biggest issue with the memory systems built into Claude et al. is that they're terrible at pruning old/conflicting information as the project evolves, so I'd hope a replacement would do something to improve that.
I’m looking at the LLM-generated SECURITY.md and this thing seems to pump a LOT of information back to some place called TypeSafe AI. That and the AI-generated comments from OP here make a few red flags go up for me.
TypeSafe AI are the providers for Jev. This complaint is like saying it’s a red flag that Claude Code sends lots of information to somewhere called Anthropic.
jevmem watches Claude Code, Cursor & Codex chats and keeps a JEVMEM.md in your repo up to date. After each message, Jev (TypeSafe) decides whether anything is worth remembering — a decision, a bug, a change of mind — and writes the keepers to that file. Reversed decisions get marked superseded.
Install: npm i -g jevmem (needs a TypeSafe API key)
Held-out check on 66 messages (23 Sep 2026) vs six frontier LLMs: save/skip 98.5% (tied with Astra); save+correct kind 95.5% (Astra 98.5%, Opus 97.0%); changes of mind 5/5; median 0.30s via Jev API (~0.6s end-to-end) vs 2.8–4.3s for the LLMs; cost $0.000127/decision. Single run by me — treat 1–2 message swings as noise.
Limits: early v0.4; fully automatic only in Claude Code today (Cursor/Codex via agent/MCP); messages go to the TypeSafe API with secrets stripped; if the API is down it skips.
I have read through the project and I still don't understand what this thing is for and why it is to be preferred over the harness's native memory management tools.
My previous rule was that I never use AI for writing that expresses my own opinions or tries to be convincing (anything on my blog for example) but I'll let it do technical documentation.
The top of a README is about convincing and explaining why I built something though, which means it should fit my no-AI policy after all.
Maybe give it a try next time you write a readme with agents. That and giving it an example of good README in real world repos can increase dramatically the likelihood of synthesizing a serviceable README.
To me, this seems like a design error. You're polluting context with false/outdated information (even if the LLM is instructed to ignore it). The biggest issue with the memory systems built into Claude et al. is that they're terrible at pruning old/conflicting information as the project evolves, so I'd hope a replacement would do something to improve that.
Everything is inundated with info about other things tried.
Comments and docs flooded with things found out in the process when you want something about the info you need to know now.
> Next session, the relevant lines are added to Claude's context.
At least that's how I interpret it? If it is adding superseded decisions, that does seem bad.
I will have to give it a run-through today.
I haven't used Jev yet so this should be interesting. I'd be interested to see if any Deciduous users have opinions, too.
Install: npm i -g jevmem (needs a TypeSafe API key)
Held-out check on 66 messages (23 Sep 2026) vs six frontier LLMs: save/skip 98.5% (tied with Astra); save+correct kind 95.5% (Astra 98.5%, Opus 97.0%); changes of mind 5/5; median 0.30s via Jev API (~0.6s end-to-end) vs 2.8–4.3s for the LLMs; cost $0.000127/decision. Single run by me — treat 1–2 message swings as noise.
Limits: early v0.4; fully automatic only in Claude Code today (Cursor/Codex via agent/MCP); messages go to the TypeSafe API with secrets stripped; if the API is down it skips.