Vibe Coding: Being Result-Oriented Is Fine. Being Result-Only Is the Problem.

I’m a software engineer. I do vibe code.

I’ve been writing software for a long time, long enough that reading code is more natural to me than reading prose. And somewhere in the last year I became a vibe coder. I describe what I want, the AI writes it, the tests pass, I ship. It’s fast, it’s fun, and I’m not going back.

But there’s an old habit I can’t shake, and I don’t think I should. I want to know how it works. Not every line; I gave that up happily. But when a user hits “place order,” I want to know what runs, in what order, where the retry lives, and whether the AI quietly went around a layer I care about. For years that knowledge came for free, because I was the one typing. Now I ship things I could not draw on a whiteboard, and that bugs me.

Vibe coding isn’t broken; it’s doing what it promised. It’s result-oriented. I judge the output, the AI optimizes for the output, and the path in between becomes something nobody looks at. I just happen to be the kind of engineer who still wants to look. And a normal code diff doesn’t help me there: it shows which lines moved, not what the app does differently.

There’s a newer wave of tools that hand the AI (and you) a map of the codebase instead of a pile of files. Graphify and CodeGraph are the big names. They build a graph of what connects to what, and they’re great at it. But a graph tells you that A talks to B. It doesn’t tell you when, in what order, or only-if-something-failed.

So, inspired by Graphify, I built VibeSequence. Where Graphify maps your codebase as a knowledge graph, VibeSequence maps it as a list of user sequence diagrams, one for each thing a user can do. It adds the part a graph leaves out: the order of calls, drawn as a sequence that both you and your AI can read. This post is about why I wanted it and how I use it to get the process back without giving up the speed.

A quick demo of VibeSequence: building the diagrams from a codebase, zooming into one flow, and playing it step by step.

What VibeSequence actually does

You point it at a project (vibesequence build .), it reads the code without running anything, finds the entry points (web routes, CLI commands, that kind of thing), and draws each one as a flow you can zoom in and out of. Zoomed out you see which parts of the app talk to each other. Zoomed in you see individual functions. I didn’t set out to replace a graph; I set out to add the thing a graph can’t show, which is order, and the branches around each step.

Three things make it useful when an AI is doing the typing:

Play mode. Step through a flow one arrow at a time, each pointing at the exact file and line. It’s like a debugger, except you’re reading instead of running.

Live diff. While the AI edits, the steps that changed turn green, and you can play just those. So code review stops being “which lines changed” and becomes “what does the app do differently now.”

A text version for the AI. The same diagram comes out as a compact text tree, so the AI can read one flow instead of opening eight files. There’s also a “who calls this?” command that tells you which user-facing flows would break if you changed something.

Fair warning: it’s tiny and young. Sixteen stars, one maintainer (me), Python and JavaScript/TypeScript only. I ran a small test with Claude Code and I’ll be honest about the numbers: when the AI had to understand a flow, it used about a quarter fewer tokens and finished in half the turns. For small edits it actually cost a bit more, because the AI still has to read the files it changes. Go, Java and a few other things are on my roadmap, not shipped yet. There’s a one-line install that teaches Claude Code to check the flows on its own after each edit.

All of that is from the project README as of today.

My loop: vibe code, then look at the sequence

Here’s the routine. It adds maybe two minutes a session, and it plays fine alongside a graph tool if you already use one: the graph helps the AI find code, the sequence shows you what it did.

Snapshot before. Build the diagrams before the AI touches anything. That’s the shape you want to keep.

Vibe code. Paste an existing flow into the prompt if you want the new one to follow it. Leave the viewer open; changed steps turn green on their own.

Diff the sequence after. Rebuild, play the green steps, and ask: did anything skip a layer, grow sideways, or lose a step it needed? If not, ship.

Step 3 is the one I never skip. Steps 1 and 2 I scale with how much the session could bend the shape; for a one-line fix the map barely helps, and my own numbers say so.

Wrapping up

Wanting to understand your own system doesn’t make you a dinosaur. It’s the part of being an engineer I want to keep while the AI does the typing. “It works” only describes the result, and I’ve watched the result stay green while the process underneath quietly went wrong. A sequence diagram that redraws itself after every AI edit is the closest thing I’ve found to seeing the process without giving up the speed. That’s why I built VibeSequence. It’s early and narrow, but if you’re the same kind of engineer, it’s a pip install away, and a free afternoon is enough to try it on one of your own projects. Issues and PRs welcome.

Links: VibeSequence. The graph tools mentioned along the way: Graphify and CodeGraph.