How I built a 35-bot trading fleet with an AI pair-programmer

Christian Faro — Wed, 01 Jul 2026 18:33:40 +0000

A note before we start: this is about the machine, not the money. I'm not going to show you returns, positions, or a single "this strategy made X%." Partly because that's a regulatory minefield, and partly because the returns aren't the interesting part — the engineering is. If you came for a get-rich screenshot, this isn't that. If you came to see how one person ships production infrastructure with an AI, pull up a chair.

The thing I built
Over the last few months I built, with an AI coding agent as my pair-programmer, a fleet of ~35 automated trading bots. They run across five equity markets plus crypto. Each one is a long-running service. They share a single database, post to a live dashboard, fire alerts to my phone, and — the part that took the longest — they're built to survive restarts, reconcile against reality, and refuse to do anything stupid.

I'm one person. I am not a team. The "team" is me plus an AI in a terminal, working the way you'd work with a very fast, very literal junior engineer who never gets tired and occasionally needs to be talked out of a bad idea.

Here's how it's put together, and the handful of lessons that cost me the most to learn.

The architecture, in one breath
One Postgres database is the brain — every trade, signal, and piece of state lives there. Around it sit ~35 containerized bots, each isolated (its own tables, its own config, its own identity), orchestrated with Docker Compose. A Streamlit dashboard reads the database and renders the whole fleet — open positions, P&L curves, health. A notification layer pushes Telegram alerts on every meaningful event. Schema changes go through migrations so a new bot is never born with a stale database shape.

Each bot is the same skeleton wearing a different hat:

a signal module (the strategy logic),
a trader that turns signals into orders,
a storage layer that persists everything,
a runner loop on a schedule.
Strategies are swappable. The infra underneath them is identical. That sameness is the whole point: I built the hard part once, then cloned it.

The five lessons that actually mattered

If it isn't in the database, it doesn't exist
My first bots kept state in memory — "have I already entered this position today?" as a variable. Then a container restarts at 3 a.m. and the bot wakes up with amnesia. Every flag that affects a trade has to be persisted. The bot should be able to die mid-thought, come back, and reconstruct exactly where it was from the database alone. This one rule eliminated a whole class of ghosts.
The broker is the source of truth, not your code
When a bot goes from fake money to real money, the scariest bug isn't a bad trade — it's a bot that thinks it holds something it doesn't, or vice versa. So on every boot, the live engine reconciles its own ledger against the broker's actual positions. Any mismatch and it halts, loudly, and pings me. It would rather do nothing than act on a wrong picture of the world. "Halt and yell" beats "guess and trade" every single time.
Build the brakes before the engine
Before a single real dollar moved, the live path had a kill switch (a database flag checked before every order), a price collar (reject orders priced too far from the last trade), a max order value, a max position size, and a daily-loss circuit breaker that auto-halts the whole thing. Risk rails aren't a feature you add later. They're the thing you build first, because the failure mode of trading software is measured in real money.
Validate with fake money, religiously
Every bot runs as a paper-trader long before it's allowed near a live account, and the live engine is literally the same code as the paper engine with two methods swapped out — so the strategy can't silently drift between "what I tested" and "what's running." The discipline I keep repeating to myself: validate, don't guess. Pull the data, run it, watch it behave, then ship. A backtest is a hypothesis, not a promise — live introduces slippage, partial fills, delayed data, and a dozen frictions a backtest never sees.
Boring infrastructure is the moat
Nobody tweets about idempotent migrations or restart-safety or reconciliation. But that unglamorous plumbing is exactly what separates "a script that worked once" from "a system that runs unattended for months." The strategies are the part people obsess over; the infrastructure is the part that actually decides whether you're still standing in six months.

Working with an AI pair-programmer
The honest version: an AI coding agent didn't replace the thinking. It collapsed the distance between an idea and a running, tested implementation from weeks to hours. That changes what a single person can attempt.

A few things I learned about the workflow:

I'm still the operator. The AI builds; I decide. Anything that touches real money, real credentials, or production state is a human decision, every time. The agent never holds the keys to the irreversible stuff.
Small, reversible steps win. Big-bang changes are where AI-assisted dev goes wrong. One scoped change, validated, then the next. Same as good engineering has always been — just faster.
"Validate, don't guess" applies to the AI too. The agent is brilliant and confident and sometimes confidently wrong. So nothing is "done" because it looks done — it's done when it's been run and observed.
The mispriced thing right now is velocity. Most people massively underestimate what one person plus an AI can ship. That gap is real, and it's temporary.
What's next
I pulled the infrastructure skeleton out of this — the orchestration, the storage layer, the dashboard, the paper/live engine pattern, the risk rails, the reconciliation — into something other people can build their own systems on. The strategies stay mine; the shovels I'm happy to share, because the infra is what everyone reinvents badly.

It's open source, MIT, and docker compose up gives you a fleet paper-trading against a sandbox broker that invents its own prices — zero external data, zero credentials, zero real money:

→ https://gitlab.com/myicloudmusic/fleet-kit

No hype, no returns, just the build. The next post breaks down the paper-to-live engine: how the same code trades fake money and real money without ever drifting.

Built in public from Montreal. The strategies are private; the engineering is open.

DEV Community: Christian Faro

How I built a 35-bot trading fleet with an AI pair-programmer