DEV Community: Muhammad Abdullah Shah

I built a debugger two people can watch at the same time

Muhammad Abdullah Shah — Sun, 25 Oct 2026 07:51:43 +0000

I built a debugger two people can watch at the same time

I have lost count of the debugging sessions that went like this. I share my screen, I run the code, and I narrate what it is doing line by line while the other person nods at a video feed. They cannot pause it. They cannot rewind it. They cannot point at a variable and ask what it held two steps ago.

So I started building Trace. The short version is Figma, but for debugging. Two people join the same run, watch the same code execute live, and scrub back through it on a timeline when something looks wrong.

I gave it four days before my exams forced a pause. Here is what actually shipped.

Day 1: the tracer

A Python tracer built on sys.settrace, a Pydantic trace schema to keep every step honest, and a Next.js scaffold to show it in. Ten commits, 22 of 22 backend tests green. Nothing to look at yet, but the foundation was real.

Day 2: the runner

A sandboxed runner behind POST /execute, traces retrievable at GET /traces/{id}, and a JavaScript tracer using acorn so it is not a Python-only toy. Five more commits, 60 of 60 tests green.

Day 3: the multiplayer part

Rooms joined by code. A Yjs relay running inside FastAPI, not a Node sidecar, because one process and one deploy beats babysitting a second service. Presence with remote cursors, and a shared run button so either person can kick off the execution. Ten commits, 73 of 73 tests green.

Day 4: the part you actually look at

An SVG execution graph with time on the x axis and line number on the y axis. A timeline scrubber with play and pause, 0.5x to 4x speed, and arrow-key stepping. A variables panel (text only, dunders filtered out), a stack panel, and a stdout view. I verified it with Playwright screenshots of a real 10-step loop trace, on desktop and mobile. Still 73 of 73 tests green.

What is not built yet

The AI co-pilot that explains each step as it runs. That is the plan, and I am saying so plainly instead of letting the pitch imply it exists. Exams pause the build until October 31, then Days 5 to 7 finish it.

The part I keep coming back to is the scrubber. Debuggers show you the present. A timeline lets you argue about the past, and when two people are staring at the same bug, the past is usually where the answer lives.

I priced my own dead code and got a $775 bill

Muhammad Abdullah Shah — Sun, 18 Oct 2026 07:51:40 +0000

I priced my own dead code and got a $775 bill

Every developer has a graveyard. Mine was 35 files and 2,317 lines, and I couldn't have told you what half of it did. So I built GhostCode, a dead-code analyzer that reads your AST instead of guessing from text, and the first repo I ran it on was my own.

Here is what I built, how it works, and what the numbers said.

Dead code is a P&L line item, not a vibe

Dead code doesn't just sit there. Someone reads it during onboarding, debugs around it, and keeps it passing CI. That's real time, so I wanted a number: how much does this code cost me per year?

The crude version I started with: every dead line costs $0.50, scaled by complexity. Crude on purpose. A precise-but-wrong number is worse than a crude-but-directional one.

How it works: four layers

1. Ingestion. tree-sitter parses Python and JS/TS into real ASTs. No regex guessing, no string-matching for "import". If the parser can't see the symbol, it doesn't count.

2. Graph. Everything becomes a NetworkX graph: files, functions, classes, imports. A "ghost node" is any node with zero incoming edges. Nothing calls it, nothing imports it, nothing references it. That's dead code by construction, not by opinion.

3. Scorers. Three of them:

Dead-code scorer: how confident are we this is actually dead (deletion confidence)?
Debt scorer: how tangled is the code that IS alive? Circular imports, complexity hotspots.
Cost scorer: dead LOC x $0.50, scaled by cyclomatic complexity. A simple dead utility is cheap. Dead code wrapped in nested conditionals that future-me has to read is expensive.

4. Dashboard + auto-PR. A Next.js dashboard over a FastAPI API (Docker, deployed on Render), and PyGithub opens the deletion PRs for you.

Dogfooding: my own repo first

35 files, 2,317 lines. The scan found 10 ghost files and 21 ghost symbols. Three circular import chains I didn't know about. Total: $775.49 of annual maintenance burn.

Some of it stung. A helper module I was "keeping in case I need it later" turned out to have zero incoming edges from day one. It was never needed. Deleting it took one PR and the tests stayed green, 91 out of 91.

What I'd tell you before you build this yourself

Start with tree-sitter, not regex. Regex-based "unused code" tools lie to you the moment a dynamic import shows up.

Zero incoming edges is the right definition. It's falsifiable: show me one caller, or it's dead.

Price it crudely early. The $0.50 number is wrong, but it turned "should I clean this up" into "this file costs $120 a year to keep." That's a decision, not a feeling.

My repo now has 10 fewer files. The analyzer runs in CI now, so the graveyard doesn't grow back.

My first open-source PR got closed, and the maintainer was right

Muhammad Abdullah Shah — Sun, 11 Oct 2026 07:51:57 +0000

This week I did something I had been putting off for years: I fixed two real bugs in open-source projects and opened the PRs myself.

The two were repowise-dev/repowise#3251 and sktime/sktime#11437.

The repowise bug: doc_anchors only registered the first anchor when a document had repeated headings. GitHub-style suffixed anchors (slug-1, slug-2) were just missing. The sktime bug: LagLlamaForecaster._update was loading the entire series history on every update instead of keeping just context_length rows. Unbounded memory growth hiding inside a method nobody looks at twice.

Both fixes were small. Both took longer than I expected, because the real work was reading the codebase long enough to be sure I was not breaking something else. The repowise fix needed 2 regression tests to prove the anchors were right. The sktime fix needed 5 direct cases. Ruff clean, existing tests still green.

Here is the part I did not expect. This morning the repowise maintainer closed my PR without merging it.

The reason was fair, and I will give it to him straight. Another contributor had claimed the issue in the thread first, and their version handles an edge case mine missed: a heading that literally reads ## Usage 1 written out. With a plain counter, that collides with the auto-generated usage-1. Their version gives the third ## Usage a proper usage-2. Mine would have shipped a subtle duplicate-anchor bug. So, yes, closing mine was the right call.

And then the maintainer did something I will remember: he personally pointed me at another issue, #3283, and said it was mine if I claimed it. Importing one helper from ingestion.git_indexer drags in the whole package and all of GitPython. The fix is lazy imports. I have already written it in my fork, tests pass, and it is waiting on me to claim the issue and open the PR. The sktime PR is still open, awaiting review.

Two lessons I keep turning over.

First: writing the fix is the easy half. The other half is the process around it. Claim the issue in the thread before you start, read how maintainers respond, and treat every edge case in a review comment as something you should have thought of first.

Second: a closed PR is not a failed PR. Mine found the bug, confirmed the fix shape, and got a maintainer to hand me a better issue. That is a net win by any measure that matters.

If you are thinking about starting: pick a project you already use, look at its good-first-issues, and read more code than you write. The reading is the work.

I built a merge-conflict predictor that ignores lines and reads the AST instead

Muhammad Abdullah Shah — Sun, 04 Oct 2026 07:51:35 +0000

Git's idea of a merge conflict is narrower than it should be. Two branches change the same lines, you get a conflict. Two branches touch the same function from different files and never collide, git merges cleanly and congratulates you. Then production breaks.

That's the merge I've learned to fear most: the clean one. One person refactors a function while another adds a call to it, the merge goes through without a peep, and you find out a week later from a bug report.

I'm building PRISM, an AI-powered git time machine, and this week I shipped a conflict predictor built around a simple idea: lines are the wrong unit. Symbols are better.

The approach

Parse the merge-base and both branch heads into ASTs with tree-sitter, extract the symbols (functions, classes, methods), and flag overlap between the two sides. Both branches touching the same symbol is risk, even across different files. The score saturates so one hot file can't dominate the whole prediction. It's exposed as POST /repos/{id}/predict-conflict, and there's a branch-compare UI with a risk bar and the overlapping symbols listed, so the number is inspectable instead of magic.

The unglamorous parts took most of the time

Tree-sitter grammar packages aren't always installed on the machine. The first version crashed when one was missing, which made it a demo, not a tool. Now the service degrades to line-level scoring when a grammar is missing. Boring engineering, but it's the difference between something you can actually run and something you can't.

Method detection inside class bodies broke twice before my tree-sitter queries finally caught it. Queries for methods are fiddlier than function queries, and I learned that through two rounds of debugging. Skill issue on my part, honestly.

9 new tests, 39 passing overall.

What it's actually for

The predictor doesn't replace tests or review. It answers one narrow question: did these two branches step on the same symbols? That's cheap to answer, and it catches exactly the class of breakage that git itself can't see. Next up I'm working on semantic code ownership with embeddings, which should catch the cases where even the symbol names diverge.

If you merge a lot, you know the feeling of a clean merge that wasn't. What's the worst one you've shipped?