Skip to content

Strategy Code and API Examples: What Code Quality Reveals About Process

Algorithmic trading strategy code is not production trading infrastructure. The gap between the two is one of the most consistent misunderstandings in how managers present their technical work to investors, and one of the most consequential.

Sample code, research notebooks, and backtesting scripts show signal logic. They rarely show the error handling, state management, execution integration, and operational controls that determine whether that signal logic can be traded at scale. A beautifully written backtesting script can coexist with a fragile production system, and the script itself will not tell you which one you are looking at.

That distinction is not a criticism of any specific tool. Backtrader, Zipline, QuantConnect’s LEAN engine, and similar research platforms are designed for signal development. They do very well at what they are designed for. They also carry documented limitations in fill modeling, delisting handling, and live-state management that matter considerably when interpreting results they produce.

This page covers what code quality signals about a manager’s process, where research code diverges from production systems, and what to ask before treating a code demonstration as operational evidence.

On this page
  1. What strategy code can and cannot tell you
  2. Known gaps in common backtesting frameworks
  3. What code quality signals about a manager’s process
  4. What investors should ask before treating code as evidence
  5. Questions investors ask

What strategy code can and cannot tell you

Well-written strategy code demonstrates signal design and model structure. It shows how the manager translates a hypothesis into rules, how positions are sized relative to signal strength, how entry and exit conditions are defined. For understanding the manager’s thinking, code is a useful artifact.

What it does not demonstrate is production quality. Production quality is determined by how the system handles bad data, missed callbacks, partial fills, connection failures, and the many failure modes that a backtesting framework either simplifies or ignores entirely. None of those appear in a research notebook. They appear in an incident log from a system that has been live long enough to encounter them.

Research frameworks
Signal
Backtrader, Zipline, LEAN, vectorbt are designed for signal development. They are not production infrastructure, and their own documentation is explicit about this.

Fill model accuracy
Assumed
Most backtesting frameworks assume fills happen at the bar price. LEAN’s known fill-model limitations include execution at historical bar prices that would not have been achievable in practice.

Delisting handling
Critical
LEAN’s documented delisting behavior can produce artificial final-day fills at prices that do not reflect real liquidation costs. Survivorship bias lives here.

Known gaps in common backtesting frameworks

Every serious backtesting framework carries documented limitations that affect how research results should be interpreted. These are not obscure issues. They appear in the platforms’ own documentation and issue trackers.

Fill modeling. Backtrader’s Cerebro and LEAN’s default execution models fill orders at bar prices, which assumes the strategy can trade at the period’s open, close, or VWAP without moving the market. For small, liquid strategies this assumption is approximately correct. For anything with meaningful size relative to daily volume, it is materially optimistic. Backtests that do not model market impact explicitly are producing gross-of-impact numbers and presenting them as if they were net.

Delisting and survivorship handling. LEAN’s documented behavior on delisted securities can produce final-day fills at prices that do not reflect real liquidation costs. Zipline carried a known issue with how it handled alpha and beta computation near corporate events. These are not obscure bugs. They are documented limitations that affect every backtest run on those platforms without explicit corrections. The practitioner literature is consistent on this: without real delisting histories applied to the backtest, the survivorship adjustment is weak regardless of how it is described.

Event timing. Research frameworks typically process events at bar boundaries, which is cleaner than the real-time asynchronous environment production systems operate in. Backtrader’s documentation notes that live trading introduces data latency and event ordering that does not exist in backtesting mode. A strategy that looks timing-insensitive in research may not be in production.

From our conversations · What to inspect before entry rules in any code review
  • The fill model and its assumptions: at what price are fills recorded, and what market impact model, if any, is applied?
  • The delisting and corporate action handling: does the backtest include securities that were subsequently removed from the index or exchange?
  • The event timing assumptions: does the code process events synchronously at bar boundaries, or does it model asynchronous real-time execution?
  • The gap between research code and production code: are they the same codebase, or is the research code a separate artifact from the system that trades?
Algotrader.ch editorial observations drawing on Backtrader, LEAN, and Zipline platform documentation, 2026.

What code quality signals about a manager’s process

Code quality is not just about signal elegance. It is about whether the development process would catch the errors that cause live underperformance. The signals worth looking for are not stylistic. They are structural.

A manager whose research code and production code are the same codebase has a continuous evidence chain from research to live. A manager whose research code is separate from production has a translation step, and translation steps are where assumptions get quietly changed. Which set of assumptions is running live is not always obvious from the research code.

Version control and commit history are more informative than the code itself. How often does the strategy code change? What types of changes are most common? A commit history showing frequent parameter adjustments on a live strategy is a different signal from one showing steady structural improvements with stable parameters. Neither is automatically good or bad. Both are informative about how the manager treats the separation between research and production.

Exception handling and logging in the code reveal how the developer thinks about failure. Code with no error handling assumes the happy path. Code with specific exception handling and structured logging was written by someone who has thought about what breaks and built a record of it.

Algorithmic trading strategy code quality signals showing what fill modeling, delisting handling, event timing, version control and exception handling reveal about a manager's development process

What strategy code quality reveals about a manager’s development process. Algotrader.ch, 2026.

What investors should ask before treating code as evidence

The core distinction to keep in mind: code that demonstrates a signal is not the same as code that demonstrates a tradable process. The first shows the hypothesis. The second shows whether the hypothesis can survive contact with execution, infrastructure, and live market conditions.

From the field · Code demonstration questions that surface what matters
  • Is this the research codebase or the production codebase? If they are different, what are the differences?
  • What fill model does the backtest use, and how is market impact handled for larger orders?
  • How are delistings and corporate actions handled in the backtest, and is real delisting history used?
  • Can you show the commit history for parameter changes made while the strategy was live?
Algotrader.ch editorial observations from manager technical reviews, 2026.

A manager who can answer all four questions specifically is showing a development process that has been thought through. A manager who cannot distinguish their research codebase from their production codebase has not yet been asked that question carefully enough, or is running a process where the distinction does not exist.

Questions investors ask about algorithmic trading strategy code

What is the difference between research code and production code in algorithmic trading?
Research code is written to test a hypothesis in a backtesting environment. It typically runs on historical data, fills orders at bar prices, and ignores the asynchronous, failure-prone reality of live markets. Production code is written to operate in real time, handle missed callbacks, manage partial fills, reconcile positions across systems, and degrade gracefully when something goes wrong. The two can share the same signal logic and still be entirely different in terms of what they handle. A manager who cannot explain the difference between their research and production codebases is running one of them without full awareness of what it is.
Why does fill modeling matter in algorithmic trading backtests?
Because the fill model determines what price the backtest assumes orders execute at, which directly shapes the apparent returns. Most research frameworks default to filling orders at bar prices — open, close, or VWAP — without modeling the market impact the order itself would have caused. For small, liquid strategies this simplification is approximately harmless. For strategies with meaningful size relative to daily volume, it systematically overstates returns. LEAN’s documented fill-model limitations and Backtrader’s bar-based execution are explicit about this. A backtest that does not model market impact explicitly is presenting gross-of-impact numbers as if they were net.
Should I ask to see a manager’s code as part of due diligence?
It can be useful, but the inspection should start with fill modeling, delisting handling, event timing assumptions, and the gap between research and production code, not with entry and exit rules. Entry rules tell you what the strategy is trying to do. The other four tell you whether the evidence the strategy has generated is credible. A beautifully written signal function inside a backtest with optimistic fill assumptions and no survivorship correction is showing you less than it appears to.