Show dev: before you refactor, see what's load-bearing

I keep seeing the same advice for design patterns: learn the catalog, then match a pattern to your problem. After two weeks of actually asking working engineers, I don't buy it.

One engineer's words stuck: "you don't choose design patterns, they choose you." Another: the failure isn't picking the wrong pattern, it's overuse - adding an abstraction that stops fitting the code you actually have.

So the hard part may not be picking a pattern. It's not knowing which parts of your system lean on the thing you're about to change.

That's the bit I built for. loadbearing takes a git diff and a repo, and names the downstream code most at risk from the change, each with a reason (cross-file references, arithmetic coupling, a changed value). It proposes candidates. It never gives a verdict: a static read can't prove liveness, only deleting the candidate and re-running the build can.

The part I care about most: it refuses to print a clean bill. Unread files are reported as UNKNOWN, not empty, and if anything couldn't be read, the flat "nothing outside this change references it" never prints. A tool that reports only what it can prove should never lie by omission.

curl -O https://pub-a941bfd863a24f91a60e6c4979c18a84.r2.dev/pi-sandbox-uploads/360859574271479808/2026-10-09/1791575183961-295a8b45-b2a2-4818-8511-0bbdc92e75f1-loadbearing.py
git diff | python3 loadbearing.py --repo .

One file, no dependencies. Every run ends by asking the only question that matters to me: run it on your own change, and tell me what it missed. Misses are the point - a peer already found four bugs I couldn't see.

If you try it: [e-mail], one line.