The Second Time Is the Signal to Automate, Not the Fifth

I shipped a diagram that was wrong and didn’t notice for two days. It looked completely fine. The boxes sat in the right places, the labels were correct, and the lines connecting them pointed at the wrong boxes. On one too many hand edits, a connector had quietly slipped one slot over, and nobody caught it, because at a glance there was nothing to catch. That little mistake gave me a rule I now use far beyond diagrams: the moment to stop doing something by hand is the second time you do it, not the fifth.

TL;DR

• I kept hand-editing a growing diagram. On one edit a connecting line slipped to the wrong box and looked fine anyway: the manual version could be wrong while still looking right.
• The fix took one afternoon: describe the structure once in plain text and let a small script place everything and draw the lines. They physically can’t point at the wrong box anymore.
• The usual “automate after the third time” advice is too slow for structured work. The second time is already the signal.

The thing I kept redoing

The diagram is a structured one: labelled boxes with connecting lines, arranged in rows, growing as I add boxes. Every time something new needed to go in, I opened the file and nudged coordinates by hand. The first time, that’s a perfectly reasonable way to work. The second time it’s mildly annoying. By the third or fourth, I was spending more attention on the bookkeeping of positions than on the actual content. And each edit touched things that depended on each other: adding one box in the middle pushed everything around it, so every connecting line needed re-aiming by eye.

What actually broke

On one of those edits I added a new row near the bottom. Everything below it shifted, I dragged the connectors to follow, eyeballed it, and called it done. It looked correct. It was not correct. One line now ran to the neighbour of the box it was supposed to reach.

The mistake wasn’t loud, and that is the whole point. A broken layout that collapses into a mess gets fixed in thirty seconds. A layout that’s subtly wrong while looking polished passes the glance test, ships, and sits there being quietly wrong until someone reads it carefully.

The fix that took one afternoon

Instead of moving pixels around, I wrote a short description of the structure: which box exists, and which other box it connects to. Then a small script reads that description and does the placement itself, drawing every line from the structure I described, not from where I happened to drag things.

The difference is not mainly about speed, though it is faster. It’s that the new version cannot make the mistake I made. A line is drawn from “A connects to B,” so it goes from A to B. To add a box now, I write one line of text describing where it belongs, and re-run.

The dangerous task isn’t the one that’s hard. It’s the one that’s easy enough to look right while being wrong.

The math nobody runs

People judge “should I automate this” by how long one instance takes. One instance is always cheap, so the answer is always “not worth it.” That math ignores two costs that don’t show up in a single edit: the silent errors, and the low-grade dread of knowing you have to go re-do the fiddly thing again.

The script cost more up front and paid it back within a couple of changes. The up-front number is the only one most people look at, which is exactly why so much repetitive hand-work never gets retired.

Why the second time, not the third

The common advice is to automate something after you’ve done it three times. For one-off tasks that’s fine. For structured, repetitive work where the pieces depend on each other, three is already late, because by the third manual pass you’ve probably shipped at least one quiet mistake without knowing it. The trigger I watch for now isn’t “I do this a lot” but “I redo this by hand, and it sometimes comes out subtly wrong.” The second time you feel that, build the small tool.

Where this applies if you don’t write code

None of this is really about diagrams. Think about the artifacts in your week that someone keeps rebuilding by hand and that quietly depend on their pieces lining up: an org chart redrawn after every reorg, the monthly status slide reformatted from scratch, the report where a number in one place has to match a number three places over, and occasionally doesn’t.

For each of those, the question isn’t “do we do this often enough to bother.” It’s “does the hand-made version ever come out looking fine while being wrong.” If yes, that artifact is a candidate for the describe-it-once treatment, and you can ask whoever builds it, or an AI assistant, to turn the manual ritual into a small generator you feed a plain description.

What I’d do differently

I’d switch on the second edit. I waited until a wrong diagram had already gone out, which is the most expensive way to learn that “it’s only a few minutes” is the wrong measure. The right measure is whether the manual version can fail silently. When it can, the few minutes were never the real cost.

What’s the thing you keep rebuilding by hand that could quietly be wrong right now, and what would it take to describe it once instead?