Rewind: I Asked Claude for a Debugger, Then Deleted Most of It

Every developer alive has stared at a stack trace and thought: yes, but what were the values?

A stack trace tells you where your program died. It almost never tells you why. The variable that was null had a value at some point, and something changed it — and that something happened in a moment you can no longer see.

Magic can now show you that moment. It is called Rewind, and it lets you step through an execution after it has finished, seeing your program's entire state at every single step.

Rewind stepping through a recorded execution, with the current statement highlighted in the code

On the left is every operation your code performed, in order, with how long each took. On the right is your entire program at that instant. Click any step, and the code jumps to the line that was executing.

How you use it

Open a file, click Execute, and fill in your arguments exactly as you always have. Then click Debug instead of Invoke.

The execution dialog, with a Debug button beside Invoke

That is the whole of it. Same form, same arguments, one different button. Invoke runs your code and shows you the answer. Debug runs it and shows you the working.

Once the recording opens you can click any step, drag the slider, or simply hold an arrow key and watch your program build itself.

Why this is worth having

You see values, not guesses. In the first screenshot, limit:long:3 is sitting in the arguments where the code is about to read it. Not a value I typed into a log statement — the actual argument, in the actual program, at that actual moment.

You see what changed, and when. Watch a total accumulate. Watch a database result arrive. Watch a variable get overwritten by the line you did not suspect. Debugging is mostly the question when did this become wrong?, and this answers it directly.

You stop writing log statements. No sprinkling the code with logging, running it, reading the output, removing the logging. The recording already contains everything a log statement could have told you, and a great deal it could not.

You did not have to plan ahead. Traditional debugging requires deciding in advance what to inspect. Here you make that decision afterwards, when you already know what went wrong.

When something breaks

This is where it earns its place.

A failed execution in Rewind, with the statement that threw marked in red and the state it had built up still visible

The statement that threw is marked in red, in both the step list and your code. The error message sits at the top — click it and you jump straight there.

But look at what else survived. .total:long:460 — the loop ran, correctly, adding 120 and 340 and skipping 55, right up until the next line reached for a customer that was never loaded. Everything that happened before the failure is still there.

That is the part a stack trace can never give you. A trace tells you the last thing that happened. A recording tells you everything that led to it, and lets you look at any of it.

What it costs you

Nothing, which is the point.

Recording only happens when you press the Debug button. It lives in memory for as long as you are looking at it and is then gone — never written to disk, never sent anywhere, no log files to clean up and no secrets left lying around. Code running normally on your cloudlet is completely unaffected, because when nobody is debugging there is nothing switched on to slow it down.

There is nothing to install and nothing to configure. It is simply there, in Hyper IDE, on every Hyperlambda file you own.

The part I did not expect

Claude built this, as it has built a good deal of Magic lately. What surprised me was how much of the work was removing things.

The first design was ambitious. It recorded in production with sampling rules. It stored recordings in a cache with expiry policies. It compressed them with a keyframe scheme borrowed from video encoding. It had a bespoke serialiser written specially to survive values that could not be converted to text.

I said no to all of it.

Record only when a developer asks, and only in memory — and suddenly there are no secrets to redact, because nothing is ever stored. No storage means no cache, no expiry, no cleanup. No production recording means no sampling rules, and no performance question to answer. The compression scheme existed to solve a size problem that only occurred at production volume, so it went too. And the special serialiser was defending against a failure that could not actually happen.

Five pieces of clever machinery, all deleted, and the feature came out better — smaller, faster, and impossible to leak anything with.

There was one more, and it was the one that mattered. Hyperlambda expressions can navigate upwards through your code's structure. Run somebody's code inside a debugger without care, and those expressions resolve one level differently than they do in production — which means you would be debugging code that is not quite the code you ship. The fix is a single step: detach the program before recording it, so it runs exactly as it would have anyway.

The model had not spotted it. It is the sort of thing you only see if you know the language in your bones.

The lesson I keep relearning: an AI will happily build you the impressive version. Knowing which parts to throw away is still the job.

Honest limits

Lambdas running on background threads are not recorded — they are not part of the execution you asked about, and a debugger that shows you a different number of steps each run is worse than one that shows none.

Very long recordings are capped, and say so when they have been truncated rather than quietly stopping. And since every step carries your whole program, a program that loops thousands of times produces a large recording. Debug the part you care about, not the whole nightly batch.

Try it

One command:

curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up

Open localhost:5555, point it at localhost:4444, and log in with root / root. Open any Hyperlambda file in Hyper IDE, click Execute, then Debug.

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.

Your code already knows what it did. Now it can tell you.