Launched this week
diff-tour
AI writes the code. Learn to read it like a senior engineer.
91 followers
AI writes the code. Learn to read it like a senior engineer.
91 followers
Now that AI writes the code, what should engineers learn? Understanding code still matters, and understanding code means learning how a senior engineer thinks. diff-tour turns a git diff into a tour you step through with → and ←: what the change is for, where to look, what a senior asks (what if it runs twice? can it roll back?), what must be fixed and what is a nit, and where they'd say "wait", asked as questions so you guess first. Runs on your AI coding CLI. Read-only, open source.
Free
Launch Team / Built With
Atlassian LoomTalk it through in Loom. Ship with AI
Promoted
Hi Product Hunt 👋 I'm Dai, the maker of diff-tour.
I also run WebTerm Learn, which launched here in August, and I talk with a lot of people who teach software engineering. One question comes up again and again: now that AI writes the code, what should engineers learn?
People rarely write code by hand anymore. AI often reviews it too, and software moves so fast that reading every line is hard. Still, I'm sure of one thing: understanding code matters as much as ever. And understanding code means learning how a senior engineer thinks. That is what lets you give AI the right instructions, notice what really matters in a problem, design well, and keep a project moving in the right direction.
So diff-tour teaches that thinking on real changes. Point it at a branch, and the AI coding CLI you already use writes a tour of the change. Then you step through it with → and ←:
What the change is for, and which files to read next, including ones that didn't change
What a senior engineer asks: What if this runs twice? Can it be rolled back? Would the tests fail if the code broke?
What must be fixed, what's only a nit, and what looks risky but is fine
The moments they'd stop and say "wait", asked as questions so you can guess before you see the answer
Getting started is just this: install with the one-line script in the README, then run it in any git repository:
The first run asks for a language and an AI CLI, with recommended choices already selected. Press Enter three times and the tour starts being written.
Things I cared about:
It's read-only. The AI gets a copy of the files git tracks and read-only tools, enforced by command-line flags, not only by the prompt
The code on screen is read from git at the right commit, never copied from the AI's reply
No server, no telemetry, MIT licensed. It runs on your own Claude Code, Codex, Gemini, OpenCode or Copilot plan
diff-tour keeps growing, and what you say today shapes what comes next. I'd love to hear: which part of reading a change do you wish someone had taught you? And if a tour got something wrong, tell me where.
To your question, I've mostly stopped reading the code myself, so for me it would be the data model. What's stored and how it connects is the one thing I still keep a close eye on.
@simon_moxon
That makes sense. A data model is often painful to redo once real data lives in it, so changes there deserve extra care.
Today a tour stops at risky schema changes, but it doesn't really walk you through what's stored and how it connects. That's a gap I'd like to close.
Issues are always open, so if you notice anything, please file one. I'll do my best to improve it quickly:
https://github.com/init-co-jp/diff-tour/issues
I think it's still useful to understand the code so you got my upvote. However to chime a response to your question, software engineers should focus on modelling, planning, scoping and more importantly architecting the code building. The coding tool is here but designing what the code does is my focus. Even AI will push back on some implementation for design or architectural direction.
@richatsealedvault
Thanks for the upvote! I agree. Writing the code is getting cheaper, but deciding what it should do and how it fits together is still our job.
That's also why a tour doesn't stop at the lines that changed. It asks design questions too: does this belong here, and does it make the next change easier or harder?
The guess first part is the whole thing for me. We're building learning stuff too (nutrition, not code) and making people commit to an answer before they see it is what actually makes it stick. Do you track if people's guesses get better over time?
@dan16
Thanks! Totally agree, committing to an answer first is what makes it stick. Not yet: diff-tour doesn't track guesses over time, since it keeps no telemetry and saves nothing between runs. Whether guesses improve is a great question though, and I'd love to hear how you'd measure it in your nutrition tool.
really matters not only for engineering but also for managers
@andrey_grigoryev1
Thanks Andrey!
Agreed — reviewing AI written changes isn't just an engineer's job anymore.
Would love to hear how it works for you if you give it a try.
The guess-first part is what sets this apart from another AI review summary for me. When an agent hands me a big diff, my weak spot is skimming until something looks off instead of asking the runs-twice and can-it-roll-back questions up front. Pointing me at files that didn't change is the other smart bit — that's usually where the real risk is hiding. Read-only, no telemetry, and running on the CLI I already use is exactly how a tool like this should ship.
@jcbuilds
Thanks, JC!
Skimming until something looks off is easy to slip into with a big diff, so diff-tour puts the questions before the code and asks you to take a guess first. It's not for approving a change, but for learning how a senior engineer reads one.
It's open source, so you can see how those perspectives are written (internal/generate/lessons), and it runs from the AI CLI you already use.
If you try it on a real diff, I'd love to hear what felt off.