Same Drawdown: One System Fell 42%, the Other Only 15%

In my spare time I built an automated position-sizing system — rules defined in advance, the program decides how much to put in each time, no on-the-spot judgment from me. The biggest problem with deciding by hand is emotion: win and you want to add, lose and you want to chase. Hard-coded rules remove that.

During a recent review I found one day with an unusually large intraday drawdown, losing close to 40% in a single day. My first instinct was that the strategy had broken — maybe the market changed, maybe a parameter needed tuning. After digging through logs for a while I found it was not the strategy at all. It was a branch of code nobody had ever configured.

The system sorts conditions into tiers by historical performance, with a position ratio per tier. When writing it, I only calibrated the middle tiers — they occur most often and are easiest to test. The extreme tiers at both ends occur rarely, so I figured I would fill them in later, and never did.

Where did the uncalibrated cases go? Not nowhere. The logic requires a return value for every case, so everything uncalibrated fell into the fallback branch. And that fallback happened to return the largest of the middle tiers — not the smallest, the largest.

That day several of the most extreme tiers hit at once, the program went in at maximum size, and the intraday drawdown reached 42%. Another system of mine, designed with different rules that never touch those extreme tiers, drew down 15% on the same day. Same market, nearly three times the difference.

My implicit assumption had been "uncalibrated equals unconsidered equals handled conservatively." That is the naive step. Afterward it became clear: code does not decide what counts as conservative. It executes the line you wrote. Leave something unspecified and it executes whatever line is nearest — and that line is usually not the safest one, just the one that was most convenient to copy and happened to be closest.

This is also not the first time I have tripped over the same class of problem. Further back, a statistical definition in one function was wrong, and across three weeks I discovered and "fixed" it in three separate reviews — because each time I only noted "there is a problem here" in a document, without welding the fix into the code itself, and then reused the broken function in a new script. The note reminded my future self without stopping my future self. What works is making that code impossible to reuse safely: add a warning, rename it, or delete it.

Where you do not handle a case explicitly, the system does not fall back to a safe value. It slides to whichever default carries the most weight and sits closest in the code. This pattern is not limited to my hobby system — a new role that was never configured in a permission system often inherits maximum permissions; an edge case not covered by an approval flow often takes the most permissive path. With many people now writing code via AI agents, the same thing only gets more hidden — an agent will not tell you "I was unsure here," it hands you a plausible-looking default, and unless you read closely you have no idea which tier that line lands in.

When I review my own code now, or code an AI agent generated, I ask one extra question: is there any case in this logic I did not spell out explicitly? If so, what value does the fallback branch actually return, and is it the conservative one I assumed? The question takes under thirty seconds and saves one 42% drawdown.