Using a Coding Agent to Build Market Analysis Tooling

Split the work before you start

Two different activities get bundled under building a trading system, and they have opposite risk profiles.

The first is engineering: fetching and storing price and fundamental data, handling adjustments and gaps, computing indicators, running a strategy over history, producing reports, and sending alerts. This is ordinary software work with a domain attached, and an agent accelerates it substantially.

The second is methodology: deciding what to test, whether the test is valid, whether a result means anything, and whether the process that produced it would have been available at the time. This is where money is lost, and it is where an agent is least reliable, because the failures do not raise exceptions. They produce good looking equity curves.

The practical rule is to delegate the first aggressively and to keep the second under human review, with the same discipline you would apply to any code where being wrong is expensive and being wrong looks exactly like being right.

Where an agent genuinely helps

Data ingestion and normalization. Different sources, different timestamp conventions, different treatment of splits, dividends, and holidays. This is fiddly, high volume work with a clear correctness check, since normalized data either reconciles against a known reference or it does not.

Indicator implementation. Well specified transformations with published definitions. Easy to generate and easy to verify against a reference implementation, which you should do rather than assume.

Backtest harness plumbing. Iterating over periods, tracking positions, computing costs, and producing metrics. The harness is engineering. Whether the harness is honest is methodology, and the two need separate attention.

Reporting and monitoring. Dashboards, alerts, and reconciliation between what a system believes it holds and what it actually holds, which is a class of bug that costs real money and is entirely mechanical to check.

Test coverage for edge cases. Halts, missing bars, corporate actions, timezone transitions. An agent will enumerate these thoroughly if you name the category, and they are exactly what breaks a system at the worst moment.

The failures that look like success

Lookahead bias. The most common and the most dangerous. Code that computes a signal using information not available at that timestamp: a value that includes the current bar's close, a normalization computed over the entire dataset, or a fill assumed at a price that only existed after the decision. All of it produces correct-looking code and excellent results.

Survivorship. Testing on the instruments that exist today rather than the ones that existed then. Agents will happily build against whatever universe you hand them without asking whether that universe is historically honest.

Overfitting through iteration. Every parameter you tune against the same history buys you a better result and a worse expectation. An agent makes tuning fast, which makes this failure cheaper to commit and therefore more likely.

Cost and slippage assumptions. Default to pessimistic. A strategy that only works with optimistic fills is a strategy that does not work.

Notice that none of these are code defects. The code is fine. The experiment is invalid, which is exactly the category of error that automation accelerates rather than catches.

Keeping your own research retrievable

There is a second, quieter problem in this kind of work: your own accumulated knowledge is scattered.

The reason you rejected an approach eighteen months ago, the data quirk that cost a week, the parameter range that turned out to be meaningless, the source whose adjustments are unreliable. That material is what makes your tenth experiment better than your first, and it typically lives in old notebooks, notes, and closed sessions where neither you nor an agent can find it.

RDK covers that layer. Files from local vaults, docs, and code are indexed as encrypted private chunks, and agents search those chunks before querying a model. Your research notes, data caveats, and past conclusions get retrieved when the current question touches them, so an agent stops proposing the approach you already ruled out. Token spend drops 80 to 90 percent on repeated or reference-heavy work because the answer is retrieved rather than regenerated, and the material stays private, which matters when the notes are the actual asset.

One closing note, stated plainly: everything above is about building tooling. None of it is a claim that any strategy works, and good engineering around a bad idea produces a well tested bad idea.