"[Sep 1] Four Stages of Refactoring, a Follow-Up Review, and Automated Restarts"

I asked an AI to review the whole project's structure, and once the fixes were in, I asked it to check its own work

This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).

I asked an AI to review the whole project's structure

The project has grown enough over the past few days that I felt it needed a fresh, top-to-bottom structural review.

So I asked an AI to look over the entire codebase and point out what needed improving.

I took the advice it gave and worked through it stage by stage, all day.

I pulled the serving-engine code into its own module, and unified an ensemble-combining formula that had been duplicated across several places into one.

I built a shared library for reading execution records and migrated several consumers onto it, and I added a new registry to manage account sleeve (allocation compartment) information.

I also added a generator that automatically documents the current state of the operational infrastructure.

After each stage I ran the full test suite to check for regressions, and restarted the resident processes that used the changed code so the fixes actually took effect.

Once the fixes were in, I asked the AI to check its own work

I didn't stop there. I handed the whole day's changes back to the AI and asked for a code review — did it actually fix things correctly?

I split the surface area into five parallel review tracks.

Most of what came back was minor. One finding was a real bug.

There's a check-only mode that inspects operational state without changing anything, and its freshness check wasn't properly excluding a timestamp column from comparison.

So it would pass right after generation, then start throwing false "needs regeneration" alarms after just a minute.

Luckily this check wasn't wired into any enforced pipeline yet, so there was no real damage — but left alone, it would have kept raising false alarms once it was.

I fixed everything that turned up and reran the regression suite to confirm.

The same day, while re-verifying execution safety mechanisms(new tab) separately, one more bug surfaced: the code that finds and kills a process by name was using a regex construct that failed to compile in the first place.

I fixed it as soon as I found it.

The fixes needed a restart, and it happened to be a blackout window

The problem was that applying these fixes required restarting five resident processes.

And the moment I checked, it happened to fall inside a restart-blocked window while overnight production runs were underway.

Instead of forcing it through right then, I set up a scheduled job that would fire the restart automatically once the conditions cleared.

I widened the condition beyond just the time window — it also waits if other overnight verification jobs are still running, even after the window technically opens.

Wrapping up yesterday's ledger-corruption follow-up

Yesterday's post covered a brokerage API field returning a scaled-down value that corrupted the paper-trading ledger(new tab). Today I finished the recurrence-prevention work for that incident.

Of the four measures the AI proposed, I'd finished two yesterday and implemented the remaining two today.

One guard compares the fill price against a live quote at the moment it's recorded to the ledger and rejects it if it looks abnormally scaled down. The other automatically escalates the alert level if a reconciliation block stays unresolved across multiple trading days.

That closes out all four recurrence-prevention measures.