DEV Community: Tetsuo TANAKA

Five Months Without Writing a Line of Code: The Basic Loop of Agentic Coding

Tetsuo TANAKA — Tue, 10 Nov 2026 00:22:46 +0000

In short:

For five months, I built a tool that visualizes JavaScript execution using only instructions to Claude Code. I did not write a single line of code.
The basic pattern: delegate the broad strokes of a new feature, then give detailed instructions when something feels wrong in use. You can reject an approach as early as the plan stage.
You don't need to know the name of a technique to give detailed instructions. Describe the behavior in your own words, and the AI can tell you what the technique is called.

Introduction

I'm building JSVisualizer, a web app that runs a JavaScript program one step at a time and shows what happens through 12 different views. You can watch variables change, see the tree of function calls, inspect arrays, and step forward and backward. A separate series introduces the tool itself. This one is about how it was made.

Here is the scale of the work as of November 2, 2026:

JSVisualizer: 147 commits and 48 ADRs, started May 25, 2026
JSInterpreter, the JavaScript interpreter it depends on: 52 commits, started May 23
In use in a first-year university class since September 30, 2026

I did not write a single line of code in these projects. Everything was done through natural-language instructions to Claude Code and documentation in CLAUDE.md and ADRs (Architecture Decision Records).

Terms used in this post

Agentic coding: a way of developing where an AI agent reads and writes files and runs commands itself, while a human gives instructions in natural language and checks the results
Claude Code: Anthropic's coding agent, used from a terminal or an editor
CLAUDE.md: a project guide that Claude Code reads at the start of a session
ADR: a short document recording one design decision and the reasons behind it
Plan mode: a Claude Code mode that has Claude present a plan before implementing anything

Before going further, here is my background and how I checked the work.

I spent more than 20 years in software research and development in industry, and I have now been teaching software at a university for more than 16 years. Later in this post, I'll describe where that experience helped and where I relied on asking Claude.

I have read almost none of the code Claude wrote. I skimmed it at first out of curiosity, then stopped reading it entirely. When I had a question about how something was built, I asked Claude in natural language and gave instructions the same way. I checked behavior by using the software myself, and I also asked for tests. However, I left the test cases to Claude and have not verified their coverage.

In this series, I look back on that way of working and try to put it into words. My materials are the git history, the ADRs, the history of CLAUDE.md, and the Claude Code session logs. I reread them together with Claude and checked them against my memory. Several times, that rereading overturned what I thought I knew. Those moments are part of the story too.

The first half of the series will cover:

The basic loop of agentic coding (this post)
The first step was CLAUDE.md: how to start a project
I let the AI decide whether to write an ADR
The AI reads old documents and writes new mistakes
Reviewing AI-assisted development with AI: the limits of logs, memory, and git

The quotes from my sessions below are translated from Japanese.

The basic loop

Over those five months, I repeated this loop for each feature:

In August, when Claude interviewed me to help put this approach into words, I said:

For a feature being implemented for the first time, I gave only the broad strokes. For changes to existing features, I was specific.

The principle was the same whether the decision was about an algorithm, the look of the UI, or what to document. I didn't change how much I delegated based on the kind of decision. I applied the same rule everywhere: delegate first, then give detailed instructions if something feels wrong in use.

Let's go through each stage of the loop with real examples.

Delegating the broad strokes

On the day I started JSInterpreter, this was my entire first instruction about step execution:

It shall provide an API for step execution (step in, step out, step over, step back).

It says nothing about how to implement it. When I'm exploring, I find it faster to see a proposal first and then decide than to write a complete specification up front. (I have also started a project by pinning down the requirements first. I'll cover that in the next post.) I left much of the algorithm selection and UI layout to Claude as well.

As a result, to be honest, I don't know everything that's in the tool I built. On June 14, I asked this:

I don't see how useful the information in the Timeline and Bar Chart tabs is. When would you use them?

I quickly corrected myself: "I meant Lifetime, not Timeline." I had confused the names of tabs in my own tool. At the time, Lifetime was a chart of horizontal bars showing how long each variable existed. Claude reread the source, explained how to use it, and even added a table comparing it with other views, but I still didn't find it useful because its role overlapped with theirs.

Two days later, Lifetime was rebuilt as a stack of horizontal bars showing when each function call started and ended, what's usually called a flame chart. As I remember it, my instruction was along the lines of "If you put the call stack on a timeline, you get this, right?" That is the version in the tool today, and I use it in class.

What I learned is that asking the AI "What is this feature for?" can itself reveal that something is wrong. If the explanation doesn't convince you, that's a signal worth acting on.

You can reject a plan before any code exists

Back to the step execution API. Claude asked one question about the intended use and then presented its first plan. The interpreter would be built with generators and pause at each statement boundary. To step back, it would rerun the program from the start and stop one step earlier.

I rejected the plan. Not one line of code had been written yet. In Claude Code's plan mode, you're asked whether to proceed with the plan, and I simply said no.

Then I wrote out the approach I had in mind:

Here is how I'm thinking about step execution. First, step through the program. Store the state at every step. For step execution, retrieve the appropriate state according to the type of step: step in, step over, step out, or step back. Is this implementation reasonable?

Claude withdrew its plan and adopted mine:

Compared with my original proposal (generators plus replay), the implementation is more intuitive and simpler. In particular, making stepBack O(1) is a major advantage.

My point is that the "use it" in "use it and notice something off" doesn't only happen after you've touched working software. If you read a plan and think "this isn't right," you can stop there and offer your own idea. That is far cheaper than fixing things after the code is written.

You don't need to know the name of the technique

My proposal above doesn't name a technique. Claude's reply began like this:

This is a very good design. This approach corresponds to a technique called omniscient debugging.

My reaction at the time was "What's omniscient debugging?" But I didn't ask. I decided to look it up later and immediately moved on to my next request:

Please revise the plan. I'd also like finer granularity (higher resolution). I want to be able to execute, or rather evaluate, by expression, not just by statement.

I learned something new and got what I wanted, which helped a lot.

To give detailed instructions, you don't need to know the names of techniques or algorithms. If you describe what you want specifically in your own words, the AI can map it to an existing concept and tell you its name. The Lifetime instruction above works the same way. I never said "flame chart." I just combined two terms I knew, "call stack" and "timeline."

What matters more than the name is thinking concretely about what you want and writing it down. When that's hard, you can ask the AI questions to sort out your thinking. Keep in mind, though, that the names and explanations an AI gives you aren't always correct. I didn't stop at hearing the name; I looked it up afterward.

This "record the state of every step" approach became the foundation of JSVisualizer. It's why you can move freely forward and backward through the steps (ADR-001, in Japanese, like the other ADRs linked here). It comes at a cost: because every step is recorded up front, programs that exceed the limit (50,000 steps as of November 2026) are cut off partway. That was acceptable because the tool targets small educational programs.

When something feels wrong, give detailed instructions

This is the heart of the loop. What does "detailed instructions" actually mean? Here are three recent examples from October.

1. The symptom and the desired result (call tree appearance, ADR-045)

In the call tree, I want the arguments next to the function name, not on the line below it. I also want the display to be more compact. There's a lot of empty space inside the call boxes, so please reduce the margins on all sides and make the boxes smaller.

"A lot of empty space" is the symptom. "Next to the function name" and "smaller boxes" are the desired result. I didn't specify any pixel values. Claude reduced the node height from 80px to 34px and made the width fit the text.

2. What feels wrong, a proposal, a request for an opinion, and the scope (tab name)

The Japanese name of one tab used the word for "assignment," although the view has nothing to do with assignment in JavaScript. It shows function calls being replaced with their values (the substitution model).

That Japanese term is a strange translation of "substitute." I think the tab should be renamed to the word for "substitution." What do you think? If that's OK, please fix it everywhere, in the tool's display and all the documentation.

The name had been there since the view was added in June. For four and a half months, nobody, including me, said it was odd. It finally bothered me once the tool was in use in class. I asked "What do you think?" because my idea might not be right. The last sentence sets the scope: not just the screen, but all the documentation.

3. Adding the reason (the sample on the initial screen)

In the fib sample on JSVisualizer's initial screen, the if condition is n <= 1. Please change it to n == 1 || n == 2. My course materials use this form. If the condition differs, the number of function calls differs too, which is likely to confuse students.

When you include the reason, Claude can make judgments beyond the instruction itself. In this case, Claude decided on its own to leave another sample with the same condition unchanged, and it told me why: the sample came from an earlier evaluation experiment, so changing it would make things inconsistent with the experiment's results.

To sum up, my detailed instructions included what's wrong (the symptom), what I want (the desired result), and why (the reason). In most cases, they didn't say how to implement it.

You don't have to get it right the first time

Some things took many rounds:

The view that shows variables changing in a table went from two panes to one, back to two, and finally to one again. Two panes duplicated the code display on the left, narrowed the table, and required complicated scroll syncing (ADR-012).
The view that draws object references started with a force-directed layout. It worked, but it left a lot of empty space, and arrows of the same kind pointed in different directions each time, so you couldn't read the shape of the data structure. I replaced it with a hierarchical layout (ADR-021).

There were also plenty of small fixes that never became ADRs. As of August 9, about 20 of the 103 commits started with "fix:".

When I reverted Claude's fix

Sometimes Claude changed the whole approach in response to a bug report. On May 24, I reported this about JSInterpreter's web page:

I tested it, but the samples don't work. When I choose a program from the samples, it doesn't appear in the editor.

Claude concluded that the cause was my opening the file directly. As a "root fix," it changed the bundle format from ES modules to an IIFE and committed the change, so the page would work when opened directly. All 185 tests passed.

But that wasn't the direction I wanted, so I had it reverted with this instruction:

Still, I want to go with ESM. Requiring an HTTP server is fine.

Passing tests won't reveal this kind of difference in judgment. You need to check not only whether a bug was fixed, but also how. Since I don't read the code, my clue was Claude's report.

At a stopping point: "Document this and commit"

At a stopping point, all I said was "Document this and commit." Claude decided what went into CLAUDE.md and what became a separate ADR.

That means I had delegated the editorial decision of what to record, the last step of the loop, just as I had delegated implementation decisions. I'll discuss whether that was a good idea in part 3.

The limits of this approach

My software experience helped in places. It's why I could propose the step execution approach myself. At the same time, when my memory was uncertain, I asked Claude, as with "Please explain the contents of package.json line by line in detail." I think being able to ask about what you don't know as you go helps, however much experience you have.
I haven't verified test coverage. Bugs have often surfaced later, and I expect more will. Even so, I consider the tool good enough to use in class.
You only notice what feels wrong when someone looks at it. That odd tab name stayed for four and a half months. Problems on screens I don't look at go unnoticed.
I don't know everything about what I delegated. As with Lifetime, I sometimes learn what a feature is for only by asking.
Some session logs no longer exist. I checked the timeline against session logs and git history, but the wording of my instruction for rebuilding Lifetime is from memory. I'll explain why the logs disappeared in part 5.

Checklist

[ ] When exploring a feature, give only the broad requirements and let the AI implement them. Don't try to write a perfect specification up front.
[ ] If a plan looks wrong, reject it on the spot and offer your own idea.
[ ] Use the implementation, and write down what feels wrong or unsatisfying.
[ ] If you don't know what a feature is for, ask the AI to explain it. If the answer doesn't convince you, treat that as something wrong too.
[ ] When giving new instructions, include the symptom, the desired result, and the reason. You don't need to know the names of techniques.
[ ] Look up the names and explanations the AI gives you to confirm them.
[ ] Check behavior by using the software yourself, and ask for tests too. Don't assume that passing tests means full coverage.
[ ] For bug fixes, read the report to check not only that the bug was fixed, but how.
[ ] At a stopping point, explicitly ask the AI to document the work and commit.

Next time

This post was about the loop, but the first thing that stumped me when I started was "What should I do first?" For JSInterpreter, I ran /init in an empty directory and answered Claude's questions.

Next time: "The first step was CLAUDE.md." I'll cover how to start CLAUDE.md both from an empty directory and with existing code, and how it changed over time.

Models changed over this period. The JSInterpreter exchanges in this post (May 2026) used Claude Sonnet 4.6, and the October examples used Claude Opus 5.5.

Which Branch Did My if Take? Seeing if / else if as a Flowchart

Tetsuo TANAKA — Fri, 06 Nov 2026 00:45:45 +0000

In this series, we use JSVisualizer, a free browser-based tool, to understand classic algorithms by watching them run. The first post gave a tour of the tool, and the second looked at for loops.

This time the topic is conditionals — if, else if, and else. The star of the show is the Control Flow view.

Where beginners get stuck

This program turns a score into a letter grade: 80 or above is an A, 60 or above is a B, and anything lower is a C.

let score = 72;
let grade;
if (score >= 80) {
  grade = "A";
} else if (score >= 60) {
  grade = "B";
} else {
  grade = "C";
}
console.log(grade);

It prints B. Short as it is, people who've just learned conditionals often wonder:

When is the else if checked? 72 is "60 or above", so it's a B. But was the "80 or above" condition checked too? What about the else?
Does the order of the conditions matter? What happens if you swap score >= 80 and score >= 60?
Checking which branch ran is tedious. Plenty of us have sprinkled console.log("got here") into every block just to find out.

JSVisualizer's Control Flow view turns your branches into a flowchart and shows, in different colors, the paths the program actually took and the ones it didn't.

Seeing it in the Control Flow view

How to read it

Paste the code into JSVisualizer, press ▶ Run, and open the Control Flow tab. Then press ▷ Human (one "human-friendly" step) twice. You'll see this:

Rows marked with ◇ are conditions. Below each one, the flow splits: the left column is the true path (the condition held), and the right column is the false path (it didn't).
The else if sits inside the false side of the first if. "If it's not 80 or above, then check whether it's 60 or above" — that nesting is drawn right there in the shape.
The ×1 on each row is how many times that row ran.
Gray, dashed boxes are rows that never ran in this run. Here, grade = "A" and grade = "C" are gray.
The blue outline marks the row being executed right now (here, line 2, let grade;).

We're still on line 2, yet grade = "B" already shows ×1, and A and C are already gray. The Control Flow view shows you which paths the whole run takes, and how many times, right from the start. As you step forward, the blue outline follows that path to show where you are.

Stepping forward

Press ▷ Human three more times (five in total):

The blue outline has moved from if (score >= 80) to else if (score >= 60) to grade = "B". A score of 72 isn't 80 or above, so the first if sends execution down the false path, and the else if then sends it down the true path.

What the flowchart reveals

1. An `else if` is checked only when the conditions before it are false

In the flowchart, the else if lives inside the false side of the first if. That means else if (score >= 60) is checked only when score >= 80 turned out false. An if / else if / else chain checks its conditions from the top down and runs only the first branch whose condition is true — exactly one branch runs.

2. Put conditions in the wrong order, and some paths become unreachable

Let's swap the conditions and try a score of 95:

let score = 95;
let grade;
if (score >= 60) {
  grade = "B";
} else if (score >= 80) {
  grade = "A";
} else {
  grade = "C";
}
console.log(grade);

A score of 95 comes out as a B. The Control Flow view shows why:

= 60) has ×1; the else if (score >= 80) row itself, grade = "A", and grade = "C" are all gray" width="800" height="679">

Not only is grade = "A" gray — the else if (score >= 80) row itself is gray. Since 95 already passes the first test, score >= 60, the score >= 80 condition is never even checked.

In fact, this program can never produce an A, whatever the score. Every score of 60 or above is caught by the first if, and anything below 60 isn't 80 or above either. Run it a few times with different scores and you'll see grade = "A" stay gray every time. The rule of thumb: check the strictest (narrowest) condition first.

3. Inside a loop, count the visits

When a conditional sits inside a loop, the ×N counts start to tell a story. Here's the classic FizzBuzz: print the numbers 1 to 15, but print Fizz for multiples of 3, Buzz for multiples of 5, and FizzBuzz for multiples of both.

for (let i = 1; i <= 15; i++) {
  if (i % 15 === 0) {
    console.log("FizzBuzz");
  } else if (i % 3 === 0) {
    console.log("Fizz");
  } else if (i % 5 === 0) {
    console.log("Buzz");
  } else {
    console.log(i);
  }
}

Run it to the end and you'll see the following. (When else if chains nest deeply, the flowchart may run past the right edge; just scroll sideways to see the rest.)

Out of 1–15: FizzBuzz once (15), Fizz 4 times (3, 6, 9, 12), Buzz twice (5, 10), and the plain number 8 times — 15 in total.
else if (i % 3 === 0) ran ×14 and else if (i % 5 === 0) ran ×10. The numbers confirm that each one is checked only as many times as the conditions before it were false.
The for row shows ×16 because the condition i <= 15 was true 15 times and then false on the 16th check, which ended the loop. (It's the same "the loop variable goes one step past the end" effect we saw in the previous post.)

The lesson from point 2 applies here too: multiples of 15 are also multiples of 3, so i % 15 === 0 has to be checked first. See what happens when you change the order in the exercises below.

Try it yourself

Open the link below and press ▶ Run; the Control Flow view opens. Step forward with ▷ Human (the h key) and back with ◁ Human (H).

▶ Open in JSVisualizer (letter grade, Control Flow view)

To change the code, press ✏ Edit. Before each run, predict which rows will be gray:

Set score to 85, or to 40. Which path does it take?
Delete the final else { grade = "C"; }. What is grade when the score is 40?

Two more programs to play with:

▶ Letter grade with conditions in the wrong order: try lots of scores. Is there any score that gets an A?
▶ FizzBuzz: move the i % 15 === 0 branch after the i % 3 === 0 one. How many times does console.log("FizzBuzz") run now?

Wrapping up

The Control Flow view draws your branches as a flowchart and shows which paths the whole run took, and how many times. Paths that never ran are grayed out.
An else if lives on the false side of the condition before it. Conditions are checked from the top, and only the first branch whose condition is true runs.
Put conditions in the wrong order and you get paths that never run (they stay gray). For branches inside a loop, the ×N counts let you check the numbers.

Next up: functions. We'll use the Call Stack view to see what actually happens when you call a function, and why two variables with the same name don't clash.

Watch a for Loop Change Your Variables, One Step at a Time

Tetsuo TANAKA — Fri, 30 Oct 2026 09:28:55 +0000

In this series, we use JSVisualizer, a free browser-based tool, to understand classic algorithms by watching them run. (New here? The previous post gives a quick tour of the tool.)

This time the topic is the for loop and the running total: adding numbers up one at a time. The star of the show is the Variable view.

Where beginners get stuck

Here's a program that adds up the numbers from 1 to 5:

let sum = 0;
for (let i = 1; i <= 5; i++) {
  sum = sum + i;
}
console.log(sum);

It prints 15. Simple enough — and yet beginners often trip up on a few things:

sum = sum + i looks wrong. In math, "sum equals sum plus i" is nonsense. In code, = means "compute the right-hand side, then store the result in the variable on the left" — this is called assignment. Knowing that is one thing; actually feeling it is another.
In what order do the three parts of for (...; ...; ...) run? When does i++ happen? When is i <= 5 checked?
What is i when the loop ends? It loops five times, so… 5?

Teachers often have students answer questions like these with a trace table: a hand-drawn table where you write down each variable's value line by line, crossing out and rewriting whenever something changes. It works, but it's tedious, and one slip of the pencil can leave you more confused than before.

JSVisualizer's Variable view builds that table for you, automatically, as the program runs.

Seeing it in the Variable view

How to read it

Paste the code into JSVisualizer, press ▶ Run, and open the Variable tab. Then press ▷ Human three times. (A "human-friendly" step stops only at meaningful changes, such as assignments and condition checks.) You'll see this:

Rows are the lines of your source code. The line being executed (here, line 2, the for) is highlighted in blue.
Columns are the variables in your program (sum and i). A new column appears when a variable is created.
The rightmost column shows the result of the loop condition, i <= 5.
Each cell holds the variable's value the last time that line ran. Lines that haven't run yet show "—".

At a glance: line 1 set sum to 0, line 2 set i to 1, and the condition i <= 5 came out true.

Stepping forward

Press ▷ Human five more times (eight in total):

On line 2, i is now 3, highlighted in orange. Orange means "this value changed on this step."

Now look at line 3. There, i is still 2. That tells you the last time line 3 (sum = sum + i) ran, i was 2, and sum became 1 + 2 = 3. After that, execution went back to line 2, ran i++, and i became 3. The same variable can show a different value on different rows, and that difference tells you the order in which things happened.

Running to the end

Jump to the end (the End key on your keyboard does this in one go):

The console at the bottom prints 15. The total is correct — but the table tells you more than that.

What the table reveals

1. `i++` runs after the loop body

As you step through, compare lines 2 and 3: the i on line 3 is always one less than the i on line 2. That's because a for loop runs in this order:

let i = 1 (once, at the very start)
Check i <= 5 → if true, run the body; if false, leave the loop
Run the body: sum = sum + i
Run i++, then go back to step 2

i++ is written at the far right of the for line, but it runs after the body.

2. When the loop ends, `i` is 6

In the final table, line 2 shows i as 6 and the condition i <= 5 as false. Line 3, meanwhile, shows i as 5.

The body runs five times, for i = 1, 2, 3, 4, and 5. But i itself goes up to 6, and the loop ends because i reached 6 and the condition became false. Keep this picture in mind for the classic quiz question: "What changes if you write i < 5 instead of i <= 5?"

3. Outside the loop, `i` doesn't exist

On line 5, console.log(sum), the i column shows "—". A variable declared with let in for (let i = 1; ...) exists only inside the loop, so it's gone once the loop finishes. Try changing line 5 to console.log(i): a Runtime Error appears below the code, saying 'i' is not defined.

4. `sum = sum + i` means "replace"

On line 3, sum is overwritten with every pass: 1 → 3 → 6 → 10 → 15. Watching the old value get replaced makes it click that = doesn't mean "equals". It means "compute the right side and put the result back into the variable on the left."

Bonus: see the full history with Exec Trace

The Variable view shows the latest value for each line, so the table stays exactly as tall as your code and is easy to compare against it. The trade-off is that older values get overwritten.

When you want to see the values at every single step, in order, switch to the Exec Trace tab. It's essentially the complete hand-written trace table:

Reading top to bottom, you can follow the whole story in one pass: sum grows 0 → 1 → 3 → 6 → 10 → 15, and finally i hits 6 and the condition turns false. Exec Trace gets its own post later in the series, when we look at binary search.

Try it yourself

Open the link below and press ▶ Run; the Variable view opens. Step forward with ▷ Human (the h key) and back with ◁ Human (H).

▶ Open in JSVisualizer (sum of 1 to 5, Variable view)

To change the code, press ✏ Edit. Try these edits — and predict how the table will change before you run each one:

Change i <= 5 to i < 5. What's the total? What is i when the loop ends?
Change i++ to i += 2. Which numbers get added?
Change sum = sum + i to sum = sum * i, and start sum at 1. What does the program compute now?

Wrapping up

The Variable view puts each line of your code next to the values its variables had the last time that line ran. It's a trace table that builds itself.
Values that just changed are highlighted in orange, so you can see what each step did.
Comparing rows reveals how a for loop really runs (check → body → i++) and even what i is when the loop exits.

Next up: conditionals (if / else if / else). We'll run a grading program through the Control Flow view and see, as a flowchart, which branches the program took and which it skipped.

See Your JavaScript Run 12 Different Ways: Meet JSVisualizer (and How It Differs from Python Tutor)

Tetsuo TANAKA — Fri, 30 Oct 2026 09:28:54 +0000

Why "seeing" code matters

If you've ever learned to program — or taught someone who is — some of these will sound familiar:

You copy an example, run it, and get the right answer. But you couldn't explain why it's the right answer.
Recursion makes perfect sense during the lecture. Then you sit down to write a recursive function and your mind goes blank.
You sprinkle console.log everywhere to chase a value, and halfway through you forget what you were looking for.

The root problem is that a program's behavior is invisible. Source code is static text, but when it runs it produces state that changes over time. Most beginner struggles come down to not being able to picture that hidden motion accurately.

This series introduces JSVisualizer, a web app that runs JavaScript one step at a time and shows you what's going on through 12 different views.

https://tntetsu.github.io/JSVisualizer/

It runs entirely in your browser. Nothing to install, no account needed.

The interface follows your browser's language (English, or Japanese if your browser prefers Japanese). You can switch at any time with the EN / 日 button in the top-right corner.

In this first post, I'll give you a quick tour and compare JSVisualizer with the well-known Python Tutor. From the next post on, each article picks one classic algorithm and pairs it with the view that explains it best.

The screen at a glance

The screen has two halves:

Left: your code. Paste in any JavaScript and run it. The line being executed is highlighted in blue, and the expression being evaluated right now is highlighted in orange. When execution is inside a function, the expression that called it (here, fact(n - 1)) gets a dashed purple underline.
Right: the views. Each tab shows the same moment of the same run from a different angle. Above is the Call Stack view, showing calls piling up: fact(4) → fact(3) → fact(2).

To use it, write some code, press ▶ Run, and use the buttons along the top to step forward (or backward). You can also drag the slider to jump to any point in the run.

The user manual explains every button and view in detail. You can also open it with the ? button in the top-right corner.

Feature 1: Step at four levels of detail

You choose how big a "step" is. Each level has its own forward and back buttons:

Buttons	Unit	Use it when you want to…
◀ Expr / ▶ Expr	Expression (finest)	see the order in which something like `a + b * c` is evaluated
◀◀ Stmt / ▶▶ Stmt	Statement	follow the flow one statement at a time
◁ Human / ▷ Human	"Human-friendly" step	stop only at meaningful changes: assignments, condition checks, loop updates (the best place for beginners to start)
⏪ Func / ⏩ Func	Function call	skip over function bodies and watch only calls and returns

A typical workflow: use Human steps to get the big picture, then switch to Expr steps when something puzzling happens. Every level can step backward, so when you think "wait, what just happened?", you can rewind instantly.

Feature 2: Twelve views

The views fall into three groups, depending on what they show:

Group	What it shows	Views
State	What the program remembers at a given moment	Variable, Exec Trace, Call Stack, Lifetime, Memory
Behavior	How execution unfolds over time	Expr, Subst, Control Flow, Heatmap, Call Tree
Data structures	What's inside arrays and objects	Arrays, Objects

Views also differ in how they handle time. Some show only the current moment and redraw on every step (e.g. Variable, Call Stack). Others lay out the whole run and just move your position through it (e.g. Exec Trace, Subst, Heatmap). The first kind answers "what's going on right now?"; the second answers "how did things change?"

For example, here is the Subst view (short for substitution). It rewrites the recursive call fact(4) the way you'd expand it by hand — 4 * fact(3), then 4 * 3 * fact(2), and so on — leaving the whole expansion on screen at once.

Same program, same moment: the Call Stack view shows calls stacking up, while the Subst view shows an expression being rewritten. If one picture doesn't click, another one might. That's the whole reason for having twelve.

How is this different from Python Tutor?

Python Tutor is the best-known program visualizer out there and is used by learners all over the world. Despite the name, it also supports Java, C, C++, and JavaScript. So the first question people ask about JSVisualizer is usually, "How is this different from Python Tutor?"

	JSVisualizer	Python Tutor
Languages	JavaScript only	Python, Java, C, C++, JavaScript
Step size	4 levels (expression, statement, human-friendly, function), forward and back	1 level (line), forward and back
Visualizations	12 views, switchable via tabs	1 (frames and objects diagram)
Which expression is running	Highlights the exact expression	An arrow points to the line
The big picture of recursion (call tree, expansion by substitution)	Call Tree and Subst views	In JavaScript mode, frames disappear once a call returns
Sharing	Links that open specific code (via `?code=`, see below)	Shareable links and embed codes for a specific run

Python Tutor's diagram — frames on the left, objects on the right, arrows for references — is an excellent way to understand how variables relate to memory. JSVisualizer has a view of the same kind, called Memory.

Where JSVisualizer differs is that you're not limited to that one diagram. You pick the view that fits the question you're asking:

How does a variable change as a loop runs? → Variable, Exec Trace
How does a complicated condition turn into true or false? → Expr (stepping one expression at a time)
Which branch of an if did the program take? → Control Flow
Is my recursive function computing the same thing over and over? → Call Tree

So which one should you use?

Honestly, it's not about which is better — they shine in different situations.

Reach for Python Tutor when you…

are learning Python, C, or another language besides JavaScript
want to really understand variables, references, and memory ("boxes and arrows")
want to hand students a single link that replays one specific run

Reach for JSVisualizer when you…

are learning or teaching JavaScript
want to see things a memory diagram can't easily show: evaluation order, which lines ran and how often, how recursion branches out
want to look at the same program from several angles

For instructors: links that open specific code

You can add parameters to the URL so that JSVisualizer opens with a specific piece of code already loaded:

https://tntetsu.github.io/JSVisualizer/?code=<URL of a code JSON>&view=<view to show first>

code: the URL of a JSON file shaped like { "title": "...", "code": "..." }
view: the view that opens the first time the reader presses ▶ Run (trace, subst, controlflow, …)

Put a link like this in your slides or assignments — "open this, press Run, and step through it" — and every student starts from the same screen without retyping any code. Every post in this series ends with a link in this format.

Try it yourself

This link opens the factorial example from this post. Press ▶ Run and the Subst view opens. Use ▷ Human to step forward, and try switching between tabs as you go.

▶ Open in JSVisualizer (factorial, Subst view)

function fact(n) {
  if (n <= 1) {
    return 1;
  }
  return n * fact(n - 1);
}
console.log(fact(4));

Of course, you can also open the home page and paste in your own code.

Wrapping up

JSVisualizer is a web app that steps through JavaScript and lets you watch it run through 12 different views.
You can step at four levels of detail, and step backward at every level.
Beyond the memory diagram that Python Tutor does so well, you can pick a view that matches your question: evaluation order, branching, execution counts, or how recursion unfolds.

Next up: the first big hurdle in programming — the for loop. We'll take the classic "add up 1 through 5" program and use the Variable view to follow sum and i one step at a time.

DEV Community: Tetsuo TANAKA

Five Months Without Writing a Line of Code: The Basic Loop of Agentic Coding

Introduction

The basic loop

Delegating the broad strokes

You can reject a plan before any code exists

You don't need to know the name of the technique

When something feels wrong, give detailed instructions

You don't have to get it right the first time

When I reverted Claude's fix

At a stopping point: "Document this and commit"

The limits of this approach

Checklist

Next time

Which Branch Did My if Take? Seeing if / else if as a Flowchart

Where beginners get stuck

Seeing it in the Control Flow view

How to read it

Stepping forward

What the flowchart reveals

1. An else if is checked only when the conditions before it are false

2. Put conditions in the wrong order, and some paths become unreachable

3. Inside a loop, count the visits

Try it yourself

Wrapping up

Watch a for Loop Change Your Variables, One Step at a Time

Where beginners get stuck

Seeing it in the Variable view

How to read it

Stepping forward

Running to the end

What the table reveals

1. i++ runs after the loop body

2. When the loop ends, i is 6

3. Outside the loop, i doesn't exist

4. sum = sum + i means "replace"

Bonus: see the full history with Exec Trace

Try it yourself

Wrapping up

See Your JavaScript Run 12 Different Ways: Meet JSVisualizer (and How It Differs from Python Tutor)

Why "seeing" code matters

The screen at a glance

Feature 1: Step at four levels of detail

Feature 2: Twelve views

How is this different from Python Tutor?

So which one should you use?

For instructors: links that open specific code

Try it yourself

Wrapping up

1. An `else if` is checked only when the conditions before it are false

1. `i++` runs after the loop body

2. When the loop ends, `i` is 6

3. Outside the loop, `i` doesn't exist

4. `sum = sum + i` means "replace"