heavymemory

I built a tool that learns structural code transformations from a single before/after example.

It isn’t a transformer or LLM — it doesn’t generate code. It extracts the structural pattern between two snippets and compiles a deterministic rewrite rule. Same input → same output, every time.

Examples: • console.log(x) → logger.info(x) generalises to console.log(anything) • require(“x”) → import x from “x” • ReactDOM.render → createRoot • custom project conventions

The rules apply across an entire codebase or through an MCP plugin inside Claude Code, Cursor, or plain CLI.

It runs entirely on CPU and learns rules in real time.

Tool: https://hyperrecode.com I’d really appreciate feedback on the approach, design, or failure cases.

I built a tool that learns structural code transformations from before/after examples.

Show it console.log(x) -> logger.info(x) and it learns the pattern, then applies it across your entire codebase. Deterministic, same input, same output, every time.

Not a transformer, not generative, not probabilistic. It parses code into AST, extracts the structural pattern, and executes exact rewrites.

Works as an MCP plugin for Claude Code, Cursor, and Claude Desktop.

https://hyperrecode.com

Would love feedback.

I have been experimenting with structural reasoning and built a small engine that learns rewrite rules from only two examples. You provide a pair of before and after expressions and it works out the transformation and applies it to new inputs. There is no LLM, no regex and no hard coded logic.

The demo includes:

TEACH (learn a rule from two examples)

COMPOSE (several learned rules used together) TRANSFER (a rule learned in algebra also works in logic and sets)

SIMPLIFY (multi step deterministic rewriting with a visible trace)

CODEMOD (teaching a codemod from two examples)

It runs on a CPU and produces a reasoning trace for every step. I would be interested to know what people think or where it breaks.

Demo: https://re.heavyweather.io

Key door puzzle. Grid: 8 by 11. Two rooms. One key somewhere in the left room. Two coloured doors in the wall. Goal on the far side.

Train PPO or DQN on one layout and it solves that layout. Shift the key, add or move a wall passage, alter the distractor key setup and performance collapses. The usual story of memorising geometry instead of the rules.

Instead, I train a small set of skills, like find the correct key, go to the passage, open the correct door, reach the goal. Each skill trained once, then frozen. When the layout changes, nothing updates. It retrieves the right skills from longterm memory and composes them.

State space is already large if treated symbolically. Roughly 50 reachable cells for the agent, 50 for the key, 4 door configurations, multiple passage layouts, 3 inventory values, 4 headings. Around 360,000 distinct logical states from conservative counting.

At composition time, the system only reuses states it actually encountered during skill training. No gradients. No online policy adaptation.

Benchmark: 2500 zeroshot episodes with randomised keys and randomised passages. No retraining. Solve rate about 94%.

Frozen skills. New layouts. Still works.

So here's the real question: If hierarchical RL should solve this, why does it still struggle with such a tiny, structured world unless you train it across every variation? Or am I wrong?

And what’s actually being learned when a system generalises to layouts it has never seen?

I'm interested in that discussion. The gap between, this looks trivial and most agents don't generalise, feels like the interesting thing here.