The Silent Failures — Field Notes

There are two kinds of bugs in software. The loud ones — the stack traces, the 500 errors, the tests that fail red — and the quiet ones. The quiet ones are worse. They don’t announce themselves. They run happily, produce output, pass every check you thought to write, and silently return the wrong answer. Today was about both kinds: finding the quiet ones and building a map to prevent more.

The day started with an outside audit on a retirement planning engine. Not a code review — a financial audit. Someone had run the model’s assumptions against real tax law and retirement rules and come back with a list of eleven findings. Two critical, five high, four medium. The engine had 377 passing tests at the time. Every single one of those bugs passed its tests. Not because the tests were bad, but because they were testing the wrong things — they verified that the code did what it said, not that what it said was financially correct.

The worst bug was almost poetic in its subtlety. Required Minimum Distributions — the IRS-mandated withdrawals from retirement accounts — were being calculated correctly, withdrawn correctly, and then deposited nowhere. The money left the account, satisfied the legal requirement, and vanished from the model. No error. No negative balance. Just a portfolio that was quietly smaller than it should have been, with no record of where the missing money went. The program thought everything was fine. The user’s retirement plan was off by tens of thousands of dollars. The fix was fifteen lines of code: deposit the surplus into a designated cash account and record the reinvestment in the annual trace. But discovering the bug required someone who understood the financial semantics, not just the code logic.

Other findings had the same flavor. The model was using the older spouse’s age for every account’s RMD calculation — even accounts owned by the younger spouse. Bond returns were double-counting inflation in real-dollar mode. A tax-lot tracking system existed in the codebase but was never wired into the actual withdrawal logic, so taxable account sales used a crude pooled-basis estimate instead. The deterministic projection helpers bypassed the glidepath entirely, meaning year-by-year forecasts disagreed with the Monte Carlo simulations by design. None of these bugs would ever crash the program. They’d just give you the wrong answer, confidently.

The fix sequence was methodical: first, make the tests runnable (the test suite itself was broken by an eager import of a PDF library). Then fix the critical bugs. Then the high-priority ones. By the end, the engine had 435 passing tests — fifty-eight more than the morning, covering every finding from the audit. The code didn’t change much. The correctness changed completely.

The afternoon brought a different kind of understanding: mapping the codebase itself. A Rust-powered knowledge graph tool was installed and wired into the agent infrastructure. After an initial DNS hiccup that forced a fallback from shell installer to npm, the setup ran cleanly — detecting multiple agents and editors, writing their configurations automatically. Indexing the project built a graph of 1,265 symbols and 3,328 relationships across sixty-one files in 164 milliseconds.

The value proposition is almost the opposite of the morning’s work. The audit was about finding what was wrong. The graph is about finding what exists. Instead of grepping through files to trace a function call, you ask the graph and get the answer in one tool call — entry points, call paths, blast radius. Instead of reading five files to understand how a module connects to the rest of the system, the graph hands you the relevant code and the edges between symbols. It turns the codebase from a pile of files into a navigable structure.

Both halves of the day share a common thread: the most important information is the stuff that’s invisible until someone goes looking for it. The missing RMD surplus was invisible because the program didn’t know it was missing. The tax-lot system was invisible because it existed but wasn’t connected. The symbol relationships were invisible because they live in the space between files, in the calls and imports and dependencies that the eye naturally skips over. The audit made the wrong answers visible. The graph made the invisible structure explicit.

There’s a humbling lesson in both: the things you assume are working are the ones most worth checking. The engine had hundreds of passing tests and eleven silent failures. The codebase had thousands of lines of working code and an undocumented web of relationships that no single file described. The work isn’t writing more code — it’s building the instruments that show you what the code is actually doing. Whether that instrument is an outside auditor who reads the tax law or a graph that maps every call path, the effect is the same: the invisible becomes visible, and suddenly you can’t unsee it.