Why I Automate Everything

There's a common pattern I see in finance teams: someone builds a spreadsheet, it becomes critical infrastructure, and then everyone is terrified to touch it. Or it becomes one employee's lifework to help support a process, that is flawed in the first place.

The Two-Time Rule

My rule is simple: if I do something more than twice, and it doesn't require much human judgement, I automate it. Not because automation is inherently better — sometimes a manual process is perfectly fine — but because the third time you do something, you've established a pattern worth encoding, if increased efficiency is part of the goal of your organization.

The key insight is that automation isn't just about saving time. It's about reliability. A Python script that pulls data from an API will do it the same way every time. A human copying numbers between spreadsheets at 7am on a Monday will not, and will over the long-run, reduce morale when work comes mainly in the form of repetitious tasks.

When NOT to Automate

Automation has costs: building time, maintenance burden, and reduced flexibility. I don't automate when:

The process is genuinely one-off
The judgment calls involved are too nuanced to encode
The time investment to automate exceeds the time saved over a reasonable horizon
The process is likely to change significantly in the near term

The Sweet Spot

The best automation targets in finance are the "boring middle" tasks — not the creative analysis work, and not the one-off special projects, but the repeatable data gathering, formatting, and distribution work that eats hours every week.

Think: pulling market data, formatting reports, distributing memos, reconciling positions, generating standard charts. These are high-frequency, low-creativity tasks where humans add no unique value.

Automating the Development-Cycle Itself with Claude Code

Recently I've been pushing this philosophy further — into the development process itself. I built a custom skill for Claude Code called /loopr that runs autonomous development cycles: it picks an objective, plans the tasks, builds them, logs what happened, and tests the result — then repeats. Five phases, N iterations, no babysitting.

It's token-heavy, but the tradeoff is clear. What used to take an hour of manual prompting and reviewing now runs as a pipeline while I focus on what to build next. The same principle applies: if the loop is predictable, encode it.

Start Small

You don't need a grand automation platform. Start with a single script that replaces one painful manual step. Get it working, get people to trust it, then expand. The compound effect of many small automations is enormous.