I started building Atlas on July 31. It's now on its third version, and the one running today finally looks like the platform I have been envisioning for a long time. Getting here took two restarts, a reset in the middle of the third attempt, and a few changes of tools. This is what happened, including the parts I'd do differently.
Commits per day, Jul 31 to Sep 25. The dashed line is the Sep 23 reset. Source: Atlas git history. (Interactive version on victorike.me)
Version one: the agent picked the structure
The first version was also my first real project with an AI coding agent, and I didn't know how to set one up. The agent decided the folder structure, and it came up with something I couldn't follow. By the time I understood how the pieces were supposed to fit together, it was too late to fix the foundation. After eleven days and about 117 commits I stopped and started over, this time with a structure I had chosen myself.
Version two: the trade Atlas lost track of
The second version lasted about a month and got further. At one point it placed a paper trade on an OANDA practice account. The trade ended up losing, but the bigger problems were that it wasn't the strategy I had described, and the order reached the broker without its take profit attached. Atlas couldn't match that order against its own records, so I closed it by hand, and then it couldn't account for my manual close either. The architecture for keeping Atlas and the broker in agreement didn't exist yet, so as far as the system was concerned, that trade was simply lost. It showed me that an agent can write code that runs and still not understand what it's building, at least with the coding agents I was using at the time. It's also a big part of why the current version checks every order against the broker's own records and stops when the two disagree.
First paper trade, Sep 3. The take profit never reached the broker.
We fixed it. The second paper trade reached OANDA with its take profit attached. It lost too, but this time it was reconciled properly.
Other things went wrong in that version too. The agent hard-coded EUR/USD and OANDA all over the codebase, as if I would only trade one market with one broker. My goal is to plug in any supported broker someday, and I couldn't get there without a major refactor. That's a big part of why I started over. The agent also versioned everything as though the system were in production, so I ended up with a version 2 and then a version 3 of the same pieces. I had to tell it plainly that we weren't in production, that nothing in the database mattered yet, and that everything could be reset. Documentation piled up faster than code, a lot of it had to be maintained and ended up going stale, and the agent stopped following directions I had already given it. The historical backtesting that the whole platform depends on never worked well.
Experiment form in the second version, Aug 25. Code names on screen, with OANDA and EUR/USD built into the data. Strategy name hidden.
Version three: 27 workstreams
Around September I switched to Codex, and the results got somewhat better. I also rebuilt the project from scratch as atlas-next. My mistake there was modeling the new version on the old one. I carried over its assumptions along with its good parts, so the baggage came with me. The workflow I built didn't help either. It grew into 27 separate workstreams, and at one point the repository had about 41,000 lines of documentation against 18,000 lines of code. It felt like progress while I was writing it. Looking back, a lot of it was ceremony.
Workstreams opened in atlas-next, Sep 10 to 23, then archived in the reset. Source: Atlas git history. File counts sampled Sep 12, 15, 18, and 22. (Interactive version on victorike.me)
The reset
On September 23, I reset that process and switched to Claude, and things started to work. The plans were better and I rewrote less. It asked better questions before building, understood what I needed, stayed on long tasks and picked them back up, and checked in when it needed a decision from me instead of guessing. I should say that Claude also helped me write this post, so weigh that however you like. The bigger change was that my workflow finally had room for what I actually bring to Atlas.
What I bring that the agent doesn't
I'm a trader, and there's knowledge in trading that you don't get from reading code. What should happen to a setup when the market closes for the weekend? How long should a system wait after the market reopens before it starts trading again? Someone building a trading platform without that experience wouldn't know to ask, and an agent won't ask on its own. Those decisions are what make Atlas mine. Once I spent my time on them and let the agent do the building, it started to look like what I had imagined.
Today the third version runs deterministic backtests on stored data, and on September 27 I started its first paper run on my OANDA practice account. It isn't ready for real money yet. It trades on paper through Friday, and I'll write about how that first week goes.
I was skeptical about using AI to build a trading system. Earlier this year, I took a 30-hour Udemy course on writing forex trading algorithms in Python, hoping I could build something like Atlas someday. It never turned out quite like I wanted. AI agents are what finally let me turn what I know about trading into working software, and that's the part I didn't believe on July 31.
Originally published at victorike.me. I write about building Atlas, the times the AI agents get it wrong, and the economic news that moves the markets I trade.
Atlas is a tool. Nothing here is financial advice. I am not a registered financial or investment adviser.
Top comments (2)
The take-profit that never reached OANDA is the clearest example I've read of "the code runs, but the system doesn't know what it did." Checking every order against the broker and stopping when they disagree is the right shape: the broker is the source of truth, and your database is a cache of it that has to prove itself.
41,000 lines of docs against 18,000 lines of code is a number worth remembering too. What's worked better for me is one short architecture note the agent can't change without asking (where broker-specific code is allowed to live, which modules exist), plus a plain line in the standing instructions like "pre-production, the database is disposable". That second line alone stops a lot of the v2/v3 versioning you described.
Looking forward to the first paper week. The weekend close and reopen will be the interesting test of the parts only you could specify.
Thanks for your comment. And I agree. My first go at building the system was a mess, but I’ve learned so much after rebuilding it three times.
To your point about having a line that the agent can’t change: It’s not necessarily about the agent changing or not changing something. I found that early in my development, switching different agents or workflows really hindered my development. I started with OpenCode and using open-source models, then started using OpenAI models. GPT 5.6 Luna wrote a bulk of my code, so you can imagine how that went. When I abandoned all that ceremonial stuff I saw on YouTube that said spec-driven development was the way, it freed my project from the baggage it was carrying. It also helped that I upgraded to the Claude Max plan — that was night and day for me.