Building an Autonomous Options Bot in Public
A while ago I bought this domain with a product idea in mind. What I actually ended up building is stranger and, honestly, more interesting: an autonomous options-trading system that runs against a paper (simulated) brokerage account, makes its own decisions on a schedule, and is developed almost entirely through a human-plus-AI engineering workflow.
This journal is where I document that build — the architecture, the process, and the things that break. It's a software story. If you're here for trade ideas, this is the wrong site, on purpose.
What this site will never publish — and why
Before writing a single post, I defined a content policy, and it's worth being upfront about it because the constraints are the design:
- No market data. The system consumes licensed data feeds to make its decisions. The derived
- No trades, no performance. No tickers, no entries and exits, no profit-and-loss, no win
- No advice. Nothing here is a recommendation. The educational strategy pages on this site
readings it computes from them — volatility measures, positioning classifications, and so on — are contractually the providers' derived results, not mine to republish. So you will never see a number or a market read here, not even in prose.
rates. Partly because the account is simulated and the history is far too short for any of it to mean anything — publishing it would be noise dressed as signal — and partly because a recurring "here's what the bot did in the market" feed starts to look like investment advice no matter how many disclaimers you staple to it.
describe mechanics the way a textbook would; this journal describes software.
What's left is the part I think is genuinely under-documented on the internet: what it actually takes to make an autonomous trading system reliable — and what it's like to build one with AI collaborators doing much of the engineering.
The system, in one honest paragraph
The bot is a Python service that talks to a brokerage API for execution and account state, keeps its own record of every position it opens, and runs on a fixed daily rhythm of analysis cycles. Each cycle, a large-language-model agent reviews system health and the account, and proposes actions — but every action it proposes has to pass through deterministic, code-enforced risk gates before anything reaches the broker: position-size budgets, portfolio-exposure caps, defined-risk structure checks, and a global kill-switch that can halt everything. The LLM reasons; the code decides what it's allowed to do. That boundary is the single most important design decision in the system.
The development process is its own experiment. The codebase is built spec-first — every change starts as a written specification with a plan and acceptance criteria — with a hard 100% test coverage gate, and most of the implementation is done by an AI coding agent, with a second, different AI model used as an adversarial reviewer for high-stakes decisions. The two argue; I referee. Several of the system's better design choices came out of one model tearing apart the other's proposal. I'll write that workflow up properly, because it's the thing people ask about most.
Where the project actually stands
I want this journal to be honest, so here's the unvarnished status: the system is young. It has only recently started placing its first simulated trades, and its early sessions surfaced a string of reliability bugs — including several distinct ways the bot could falsely convince itself it needed to halt trading entirely, and an order type that intermittently just… sat there, never reaching the exchange, until a watchdog cancelled it.
Each of those turned into a genuinely interesting debugging story: state that existed in the database but not at the broker, a filtered query that made the system forget it owned its own positions, a safety system so eager it became the main source of downtime. Fixing them produced the pattern I now consider the core lesson of the project so far: in an autonomous system, false alarms are not conservative — they're outages. A bot that halts on phantoms doesn't trade, and a bot that doesn't trade can't be evaluated at all.
That first postmortem — three false-halt bug classes in one week, and how each was hunted down — will be the next post.
What to expect here
Posts will land when something worth writing about ships: a bug class resolved, an architecture decision worth defending, a lesson from the human-plus-AI workflow. No fixed schedule — I'd rather publish four honest postmortems a year than fifty status updates. Everything goes through a review checklist before it's published, which is itself part of the story: treating content with the same discipline as code is what makes a project like this publishable at all.
Thanks for reading. The next post gets into the mud.