DEV Community

Peder Aaby
Peder Aaby

Posted on

I built Blume: it turns your coding-agent corrections into rules

Codex, two Claude Code terminals, and the Blume window showing which sessions are finished, running, or idle
Two Claude Code terminals and a Codex session, with Blume on the right tracking all three.

Every coding agent session ends the same way for me. Somewhere in the middle I typed "no, we use the repository pattern here", or "stop adding console.logs", or just "why did you do that again". The agent fixed it, the session ended, and the next session started from zero. I typed the same correction the next day.

Blume is a desktop app that watches those sessions locally and turns the corrections you keep repeating into rules, hooks, and skills for your agent. It works with Claude Code, Codex, and Cursor. It is free, runs on macOS, Linux, and Windows, and nothing leaves your machine.

We launched it on Product Hunt this week. This post is the longer version of the launch comment, plus the questions people asked there.

The problem: agent drift

At my previous startup we shipped fast with agents and paid for it later. Duplicated functions that did the same thing with different names. Three ways of handling errors in one service. Architecture decisions that held for a week until an agent in a fresh session did not know about them. Bugs in production that traced back to the agent not knowing a rule a human had explained five times in chat.

The usual fix is to maintain your CLAUDE.md, AGENTS.md, or Cursor rules by hand. Boris Cherny, who created Claude Code, gives the advice directly: every time Claude makes a mistake, do not tell it to do it differently, tell it to write the fix into CLAUDE.md. That is good advice and almost nobody follows it consistently, because it is a chore that competes with the actual work.

We tried two things before Blume.

Manual maintenance. Someone owns the rules file and updates it after reviews. It works for about two weeks. Then the file goes stale, people stop trusting it, and the corrections move back into chat.

Automating it naively. Have the agent append a rule every time it gets corrected. This produces a context file that grows without bound, full of one-off instructions that contradict each other, and the agent gets worse because its context is now mostly noise. Context bloat is a real cost: a long CLAUDE.md is slower, more expensive, and less likely to be followed.

Neither approach answers the real question: which corrections are signal?

The idea: extract intent from the sessions themselves

Your sessions already contain the answer. If you have corrected the same thing five times across three weeks, that is a rule. If you corrected it once and moved on, it is not. The information about what matters is in the pattern, not in any single message.

So Blume reads the session history that your agent already stores on disk, and looks for three kinds of signal:

  • Corrections. "No, not like that." "Use X instead of Y." A direct reversal of something the agent did.
  • Frustration. Short, repeated, escalating messages. High token spend on something that should have been simple. The "why did you do that again" moments.
  • Nudges. Softer steering that is not a correction but shows up over and over. "Remember to run the tests." "Check the types."

It clusters these by theme. When a cluster crosses a threshold, Blume proposes a concrete change: a rule for your context file, a hook that runs automatically, or a skill that packages a workflow you keep re-explaining. You read the proposal, and you approve or reject it. Nothing is written to your config without you saying yes.

What the thresholds are

This was the first question on Product Hunt, and it is the right one. Taissa asked how we avoid one-off feedback getting hardened into a permanent rule too early.

The thresholds are deliberately conservative:

  • Five occurrences in the same thematic cluster, or
  • Two occurrences that Blume classifies as pain, meaning they came with frustration signals or unusually high token usage.

Everything below that stays as an observation you can look at, not a suggestion. The goal is that a suggestion, when it appears, is one you would nod at rather than one you have to think hard about.

Nivy asked a version of the same thing more bluntly: how does it tell a genuine issue from me being annoyed at 11pm? The honest answer is that it does not try to read your mood in any single message. It waits for recurrence. One bad night is one data point. The same bad night three times is a rule.

What it looks like day to day

Blume sits in the background as a desktop app. The main screen shows every agent session on your machine and whether it is working, finished, or waiting for your approval, so you can run several sessions without watching terminals.

Behind that, it maps the hidden files that shape agent behavior: rules, skills, hooks, and the context files spread across your projects. Most people I have shown this to did not know how many of those files they had, or which ones were still being read.

The Blume Setup tab listing recent projects and global artifacts such as CLAUDE.md and MCP servers
The Setup tab: every CLAUDE.md, skill, hook, and MCP server that shapes your agents, across harnesses and projects.

Then there are the suggestions. Each one shows the cluster of session moments that produced it, so you can see the evidence, and the proposed rule or hook. Approve, edit, or dismiss.

The Blume Improve tab with correction, steering, and frustration gauges and two suggestions: a verification rule and a release-checklist skill
The Improve tab: analytics on how often you correct or steer your agents, and the suggestions those patterns produced.

It also tracks Claude Code and Codex plan usage so you see the weekly limit coming, but that is the least interesting part to me. The point is that your agent setup gets better without you maintaining it.

What it does not do

I would rather say this here than have you find out after installing.

  • It is a desktop app, not a CLI. If you want something scriptable for CI, this is not it. Tools like ccusage are better for usage numbers in a terminal.
  • It needs sessions to learn from. On a brand new project with no history it has nothing to say. It gets useful after a week or two of real work.
  • If you already keep a tight, hand-tuned CLAUDE.md and you are the only person on the project, you may not need it. The pain it solves scales with the number of sessions, people, and agents touching a codebase.
  • Analytics on whether your setup is improving over time is still in progress. The suggestions work today. The trend view is next.

Privacy

All processing happens on your machine. Blume reads the session files your agent already writes locally, and does not send your code or your chats anywhere. That was a constraint from day one because the sessions contain everything: proprietary code, half-formed ideas, and the occasional swearing.

What I want from you

Blume is free. If you run Claude Code, Codex, or Cursor daily, I would like to know two things after a week of use:

  1. Did the first suggestion match something you actually wanted, or did it feel off? That tells us whether the thresholds are tuned right for your style.
  2. What did you correct this week that Blume did not catch?

Download is at blume.codes. The Product Hunt thread is still open if you would rather ask there, and I answer everything.

Peder

Top comments (1)

Collapse
 
russlanramdowar profile image
Russlan Ramdowar

I like how you've separated collecting corrections from deciding which ones actually deserve to become rules. I also like that the proposal shows the moments behind it, so the human isn't just approving a mysterious new instruction.

I'm curious about the other end of that lifecycle: retiring rules. A correction can be completely right for one project phase and become baggage later. Would you consider resurfacing a rule when newer sessions repeatedly work around it, with the old and new evidence side by side? That seems useful for research workflows too, where the assumptions can change before the instructions do.