In which nothing gets built, and that turns out to be the entire point.
On the 23rd of May 2026 I made three commits to a repository called algo_trader. Not one of them contained a trading strategy. Not one contained an indicator, a signal, or so much as a moving average. If you had been looking over my shoulder - and this series is an invitation to do exactly that, retrospectively - you would have concluded I was procrastinating with unusual conviction.
What those three commits contained was a constitution, a set of contracts, and a fence.
Three months later that repository holds 604 commits, 395 Python files, 1,152 passing tests and four live trading books, one of which transacts real money on the National Stock Exchange every weekday morning at 09:45 without asking me anything. Two other books are dead - deliberately, autopsied, written up. Sixty-seven separate research studies sit in a folder, the majority of which concluded "change nothing."
The interesting question is not how an AI wrote all that code. It did, and rather well, and by the end of this series you may find that the least remarkable part of the story. The interesting question is why the first two days produced no code at all.
There is a particular fantasy doing the rounds of every board deck I have read this year: that you may now describe a system in a paragraph and receive it, whole, by lunchtime. It is not entirely false. That is what makes it dangerous.
Ask a capable coding agent for a trading system and you will get one. You will get forty files in twenty minutes, and they will be plausible, idiomatic, commented, and quietly incompatible with one another. The regime detector will invent its own notion of what a "signal" is. The execution layer will invent a second, subtly different one. Both will be defensible. Neither will be the same. And you will not discover this until the day the thing is holding a position and the two halves disagree about what it owns.
The failure mode of AI-assisted engineering, in my experience, is almost never that the model writes bad code. It is that it writes excellent code against an assumption you never made explicit - and then writes more excellent code against a different one an hour later.
The bottleneck was never the model's ability to write. It was my willingness to decide what the pieces were before asking anyone, human or otherwise, to build them.
The first established CLAUDE.md - a specification the agent reads before every session. Not a prompt: a standing brief. Permitted structures, forbidden structures, the exact conditions distinguishing one market regime from another, and the rule that every position must have a defined maximum loss before it is opened. No exceptions, no discretion, no "the model thought it was fine."
The second cut the codebase in half and gave each half to a different agent. One owns data/, signals/, regime/ - everything that perceives the market. The other owns strategy/, risk/, execution/ - everything that acts on it. Non-overlapping. Enforced by separate git worktrees, so two agents could work simultaneously without ever touching the same file.
The third - and this is the one I would defend hardest in front of a risk committee - declared a small set of files that neither agent may modify. The dataclasses the two halves pass between them. The broker interface. And the risk limits.
The decision I would make again. The risk percentages - daily loss limit, per-trade risk, margin ceiling - live hardcoded in risk/guardrails.py, deliberately not in the config file. A number in config can be changed by a dashboard, a flag, or an agent having a productive afternoon. A number in code requires a commit, a diff, and a human explaining themselves in the message. That asymmetry is the whole point.
A capable agent hands you enormous leverage. Leverage is indifferent to direction. If you would not let a new hire quietly edit the maximum-loss-per-trade constant on a Tuesday afternoon, do not build a system where an agent can.
In three months every one of those contracts held. The two dataclasses defined on day one - RegimeState and TradeSignal - are still the currency the system trades in, 604 commits later. Not because I am clairvoyant, but because two days of arguing with myself about interfaces is cheaper than three months of two subsystems arguing with each other.
Here is the part I did not expect. Once the seams were fixed, my job stopped being programming. It became refereeing: reading what came back, finding the place where it was confidently wrong, and sending it back. That skill - spotting the plausible-but-wrong at speed - turned out to be the entire job, and it is the through-line of everything that follows.
I will not pretend it was elegant. In Part V you will watch me delete the trading strategy this entire specification was written for, after it failed to demonstrate an edge over seven weeks of live paper trading. The scaffold survived. The strategy did not. There is a lesson in which of those two things I got right on the first attempt, and it is not a flattering one.
But that is to come. What's past is prologue; the rest is 603 commits, several thousand lines of things that did not work, one 6.5% error that invalidated months of measurement, and a small, stubborn, still-running book of iron condors.
This series was written with Claude, the same tool it describes. I supplied the project, the judgement calls and the arguments; Claude supplied the drafting, and dug every figure out of the repository’s own commit history so I could not flatter myself from memory.
Declaring that seems the least I can do given the subject. It would be a peculiar hypocrisy to publish eight posts on harnessing AI while implying I typed them all by hand. If the writing is good, that is partly the tool. If the judgement is sound, that part is mine. Distinguishing between those two things is, as it happens, what the entire series is about.
By day I run product for data strategy and operations at Condé Nast, where the brief is customer identity: the unglamorous business of establishing that the person reading on a phone in Mumbai and the one subscribing on a laptop in London are the same human being. Essentially the ‘slow work’ of turning unknown into known, in various stages. The glamorous parts of my day: developing the single customer view, and harnessing that data to optimise for amplified engagement and revenue across multiple lines and brands.
Twenty-four years of it now, across product, data and technology - client side and agency side, in media and publishing, CPG, insurance, automotive, FMCG and telecom, across North America, Europe and Asia. Enough time in front of CXOs to have learned that a business case travels further than an architecture diagram, and enough time behind them to know the diagram still has to be right.
This project was my evenings. It brings together the triumvirate - my love for the world of finance and markets, my drive to build a production grade system using the latest AI toolset, and the itch to discover first hand what these tools are truly capable of. And the only honest way to find out what these tools can carry is to hand them something that can lose real money.
Questions, disagreements, war stories from your own build, or a conversation about senior product leadership and AI-delivery roles - all welcome.