LLMs are very powerful when it comes to backtesting trading strategies. However, they still make mistakes unless they operate within a robust workflow - and building such workflows usually requires a more complex setup.
A significant part of my current work therefore focuses on developing more advanced research environments in which LLMs follow clearly defined processes, pass through multiple validation stages, and work with specialized tools.
But not every useful workflow needs to be complex.
In this article, I want to share a very simple technique that has made my strategy prototyping significantly more efficient. I use it whenever I want to test an idea quickly before deciding whether it deserves more detailed research.
I can give an LLM an idea that I find described somewhere online and let it process the idea largely autonomously. The result is often a very good first backtest that saves me a lot of initial work. I can then focus my attention on developing the strategy only after obtaining some basic validation.
One Model Codes, the Other Audits
The trick is to involve two different LLMs.
One model thinks and codes. The other audits its work.
For coding, I use Claude Code. For the audit, I use OpenAI Codex.
The strength of this setup is that the audit happens automatically. Claude Code sends its plan to Codex, Codex audits it and returns its findings, Claude Code corrects the problems, and the process continues.
In my experience, this eventually leads to a significantly more refined result.
A Simple Example
Let’s look at a straightforward example.
I recently came across this article on Beyond Passive.
I wanted to replicate the results - to backtest the idea using my own data and potentially prepare the code for RealTest.
If I simply ask Claude Code to script the system described in the article, the result will probably not be completely accurate. There is a relatively high probability that Claude Code will take its own path and produce an implementation that does not fully match the original description.
But consider the following example.
In Claude Code, I use the /goal command, which is designed to help complete more complex projects.
In a simple prompt, I ask Claude Code to replicate the article. At the same time, I require it to follow a specific workflow:
- Create an implementation plan.
- Have Codex audit the plan.
- Correct all blocking issues.
- Implement the approved plan.
- Have Codex audit the implementation.
- Run the backtest.
Claude Code works in an environment where Codex is already installed. I will show how to set this up at the end of the article. It also has access to my Norgate Data files.
It therefore has everything it needs and can begin working on the project.
The entire process runs autonomously.
One important detail: it is essential to ask Claude Code to correct only blocking issues.
Codex, acting as an auditor, usually identifies many non-critical issues, such as wording or minor documentation improvements. If Claude Code tried to address every one of them, the audit loop could continue indefinitely.
By contrast, there are usually only a few genuinely blocking issues.
As you can see below, it is also useful to tell Claude Code that it may push back on findings it disagrees with. In practice, this rarely happens with blocking issues.
The Audit Catches Surprisingly Serious Mistakes
The screenshot above shows an example of Claude Code requesting an audit.
The next screenshot shows some of the important problems Codex discovered.
As you can see, these are not trivial issues.
For example, Claude Code implemented a monthly rebalance as a daily rebalance.
In my experience, the audit catches many similar mistakes. Had I allowed Claude Code to implement the system without an independent audit, I probably would not have ended up backtesting the original idea accurately.
It is not unusual for this workflow to run from the initial prompt all the way to the final results without a single intervention from me. Claude Code and Codex exchange messages across several audit rounds, and the backtest is eventually completed without requiring me to do anything.
Of course, we can never know with absolute certainty that a backtest is correct.
However, when the process replicates a method described in a book, study, or online article - and the original source includes its own backtest - we have a useful reference. If our backtest matches the main characteristics of the original results, that is usually a good indication that the implementation is broadly correct.
That was the case in this example. Claude Code, together with Codex, also generated a graphical analysis of the backtest that was very similar to the analysis presented in the original article:
Why This Is Useful for Strategy Research
This is, of course, a powerful tool for research.
Not because we can immediately start trading the strategy, but because we now have a completed first backtest on which we can base our further research.
Instead of spending a lot of time manually creating the initial implementation, I can start with a reasonably validated prototype and focus on the parts that deserve deeper investigation.
How to Connect Claude Code With Codex
How do we make Claude Code communicate with Codex?