Blume Turns Agent Corrections Into Rules

Blume is a Show HN project from its creator, Peder Aaby, that turns repeated coding-agent corrections into rules/skills. It deals with agent drift: the slow slide from “helpful generated code” into duplicated functions, broken architecture, and bugs that look plausible in review. The useful idea is simple: don’t ask humans to remember every correction, and don’t let agents endlessly rewrite the rulebook. Capture the repeated correction, shrink it, and make it reusable.

Agent drift is when a coding agent gradually stops matching the shape, constraints, and habits of the codebase it is editing. That matters in Cursor, Anysphere’s AI code editor, because a strong agent can make large changes fast enough that small architectural misunderstandings compound before a reviewer sees them. This is why the Blume story landed inside the broader agentic coding governance conversation without feeling like policy theater. Gemini Workshop is part of Harness Institute.

Watch the correction loop, not the prompt

The interesting part of Blume is not that it has “rules.” Everyone with a serious AI coding workflow has tried rules, docs, memory files, review prompts, or some combination of all three.

The pain Peder described is the maintenance loop. You correct the agent once. Then again. Then someone writes a rule. Then the rule grows. Then another agent edits the rule. Eventually the guidance becomes a second codebase, except nobody reviews it with the same care.

Blume’s premise is that repeated corrections are the signal worth extracting. If the agent keeps creating a duplicate formatCurrency() helper instead of using src/lib/money.ts, the correction should not stay trapped in chat history.

A Cursor version of that correction might become a tiny rule like this:

---
description: Use the shared money formatting helpers before adding currency formatting code.
globs: ["src/**/*.{ts,tsx}"]
alwaysApply: false
---

Before adding a currency formatter, check `src/lib/money.ts`.

Do not create local `formatCurrency`, `formatPrice`, or `currencyLabel` helpers in feature components unless the shared helper cannot represent the behavior.

If the shared helper is missing an option, extend it with tests instead of adding a new formatter.

That is small enough to review. It is scoped enough to matter. It also avoids the common trap: one giant “project architecture” rule that fires on every task and teaches the agent to skim.

Turn rules into skills only when there is a workflow

A rule is best for a boundary. A skill is better for a repeatable workflow.

SKILL.md files, as used in Anthropic’s public skills examples, package instructions, scripts, templates, and reference material behind a named capability. The description is part of the activation surface, so a skill with a vague description is almost the same as a skill that does not exist.

Here is the practical distinction.

Use a rule when the correction says “don’t cross this boundary.” For example: do not import from app/api into packages/ui; use getServerSession() only in server code; put generated Prisma types behind the repository wrapper.

Use a skill when the correction says “follow this procedure.” For example: adding a billing plan touches the Stripe fixture, the entitlement table, the admin copy, and the regression test. That is not a one-line rule. It is a path.

The trap is promoting every annoyance into a skill. If the agent misspells one env var once, fix the code. If it repeatedly ships partial billing changes across three pull requests, write the skill.

Keep the repo boundary local

Cursor users already have a useful place to apply this idea: local rules and repo instructions. The trick is to keep the boundary close to the code that needs it.

For a monorepo, a root instruction like “respect package boundaries” is too broad. A better artifact is an AGENTS.md file or rule near the package that owns the boundary.

Example:

# packages/email/AGENTS.md

This package renders transactional email only.

Do not import from `apps/web`, `apps/admin`, or server route handlers.

Shared copy lives in `packages/email/copy.ts`.
Shared React email components live in `packages/email/components`.

When adding a template, include a fixture render and snapshot test.

This is the kind of guidance a coding agent can actually obey because it has a local scope and visible files to inspect. It also gives a human reviewer a clear question: did the agent stay inside the package contract?

The limitation is that scoped guidance will not save a messy architecture. If the real problem is that ownership is unclear, the rule will become a polite description of chaos. Blume is interesting because it points at the correction pattern, but it cannot decide the architecture for you.

Try it safely on one annoying drift pattern

Do not start with a grand cleanup. Pick one drift pattern that has already wasted review time.

A good first experiment is a repeated correction that is specific, visible in diffs, and easy to test. Duplicate helpers are perfect. Cross-package imports are good. “Make the code better” is not.

Here is a lightweight checklist you can copy into a PR or issue:

## Correction-to-rule experiment

Drift pattern:
- The agent repeatedly creates local currency formatting helpers in React components.

Canonical place:
- `src/lib/money.ts`

Rule or skill:
- Rule. This is a boundary, not a workflow.

Cursor rule draft:
- Add `.cursor/rules/use-shared-money-formatters.mdc`
- Scope it to `src/**/*.{ts,tsx}`
- Mention the exact helper file and forbidden duplicate helper names

Review check:
- Search diff for `formatCurrency`, `formatPrice`, and `Intl.NumberFormat`
- Confirm tests were added or updated if `src/lib/money.ts` changed

Stop condition:
- Delete or rewrite the rule if it fires on unrelated UI work twice.

The stop condition matters. Rule rot is real. A rule that activates too often becomes background noise, and background noise is just another form of drift.

This is also where Blume connects to nearby experiments like Skills MCP Searches Thousands of Agent Skills: the ecosystem is moving from “one prompt per task” toward reusable agent capabilities. The open question is how much of that reuse should be automatic.

Common questions

Is Blume a replacement for Cursor rules?

No. Blume is better understood as a way to find and refine the corrections that should become rules or skills. Cursor rules still give you the in-editor enforcement surface; Blume’s interesting contribution is the correction-mining loop before a rule becomes durable repo guidance.

When should a correction become a rule instead of staying in review?

A correction should become a rule when it repeats, has a clear canonical answer, and can be checked in a diff. One good threshold is three similar corrections in the same area of the repo; below that, you may just be documenting a one-off mistake.

When is a skill better than a rule?

A skill is better when the correction includes a sequence of steps, not just a constraint. Adding a new payment plan, migrating an API route, or preparing a release note may need scripts, templates, and examples; a one-paragraph rule will usually under-specify that work.

Can agents maintain their own rules safely?

Only with tight review. The failure mode Peder called out is rule bloat: agents can add plausible instructions that make future behavior worse. Treat rule changes like production code changes, with small diffs, owners, and a deletion path.

Is this overkill for a small repo?

Often, yes. If one developer can remember the convention and the repo has few repeated agent mistakes, a checklist in the PR template may be enough. Blume-style capture makes more sense once the same correction appears across multiple tasks or contributors.

Best ways to use this research

• Best for: developers using coding agents on codebases where the same review comments keep coming back.
• Best first artifact: one scoped Cursor .mdc rule for a repeated boundary mistake, such as duplicate helpers or forbidden package imports.
• Best comparison angle: compare “chat correction only” against “reviewed rule or skill” over the next five agent-generated PRs.
• Best caveat: do not automate rule creation without review; the rule layer can drift just like the code layer.

Further reading

• Turn repeated coding-agent corrections into rules/skills — source
• Cursor — Agent
• GitHub — anthropics/skills
• Model Context Protocol — specification

Next step

Pick one correction you have typed twice this month and turn it into the smallest reviewed rule you can. If it still helps after a week, promote the pattern; if it fires at the wrong time, delete it without ceremony.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.