There's an idea that's been rattling around in my head for a few weeks now: we've all spent the last two years getting better at prompting, and it's the wrong skill to be getting better at. What actually matters is the stuff that gets reused: the review rubric, the research summarizer, the CLAUDE.md, the checklist. Those things shape dozens of runs, not one.
And because they get reused, they rot. Quietly. A rubric picks up a constraint from a project that ended six months ago. A checklist grows until the agent starts skipping half of it. Nothing breaks exactly, the output just gets a little worse every week until one day you notice it feels off and can't tell you when it started. Your artifacts drifted, and nothing was watching them.
The fix has a five-part skeleton: a trigger, an action, proof, memory, and a stop condition. Something starts the loop. It does the work. You find out whether the output was better. You save what you learned. And the loop knows when to quit.
What struck me is that almost everything anyone builds has the first two and none of the last three.
I want to take that one layer down, because the same thing is happening in the product itself, and it's a lot more expensive there.
Most of the code landing in your repo right now was written by an agent. Not all of it, but the share goes up every month, and the ones writing it are extremely good at satisfying the things you can point a checker at. Tests pass. Types check. Lint's clean. The PR description is honestly better than the ones I write.
None of that stack knows that four thousand returning users reach for a particular button without looking at it. That's not in the tests, because nobody writes a test for muscle memory. It's not in the spec, because the spec was written before anyone used the thing. It shows up nowhere in CI, and it's real, and it's the kind of thing that gets quietly reordered in a refactor that every gate approves.
So the natural thing is to put a checker on the PR. Plenty of people are building those, and I don't think the idea is wrong. I think it's incomplete in exactly the way Shubham describes.
A checker that reads your diff against a spec has a trigger and an action. It has no proof, because nothing ever tells it whether the thing it flagged mattered. It has no memory, unless you count a config file someone on the team has to remember to update, which is the same maintenance problem the spec had, moved one directory over. And it usually has no stop condition, which is why every one of these you've installed got muted within about a month. It commented on everything, so you stopped reading it, so it may as well not be there.
That's the whole failure. Not that the model was bad. The loop was missing three parts.
Here's what we ended up building, described in those same terms, because it's the clearest way I've found to say it.
The trigger is a PR. The action is scoring that diff against a behavioral load map, an index built from real recorded sessions of which elements carry actual interaction weight, and which sequences returning users run through without thinking. Not what we decided was important. What people do.
The proof is the part I care most about. UXSense already measures what every release does to real users after it deploys; that's the product we started with. So every prediction the PR check makes gets joined to the release that ships it, and graded against the behavior change we actually measured. A signal that keeps flagging things that turn out fine doesn't get to keep its confidence. It gets demoted, by the same evidence that created it.
The memory is a file called BEHAVIOR.md that lives in your repo. It's generated from sessions, not written by a person, which means nobody has to maintain it and it can't drift away from reality, it regenerates from reality. Your agents read it before they edit, which I suspect is more useful than anything we do at review time.
And the stop condition: a clean PR gets a green check and nothing else. No comment. That's not us being tasteful, it's the only way a check survives contact with a team that ships every day.
The honest catch is that none of this works on day one. We can't tell you what your users depend on until we've watched them do it for a few days. There's no version of this where you install it in the morning and get a useful check that afternoon, and I've stopped trying to write copy that pretends otherwise. It's a real cost and the only thing to do about it is start the clock.
But I keep coming back to the framing, because I think it's right well beyond PM artifacts. Anything you're going to run a thousand times should have to find out whether it was right, and should remember the answer, and should know when to say nothing at all.
Most things we build don't. That seems worth fixing.
