Build and Backtest NinjaScript Strategies with AI

From plain-English idea to verified NinjaScript

In this context, vibe coding means describing a trading strategy in plain English and letting an AI agent draft the NinjaScript, then using compile and backtest feedback to refine it. CrossTrade MCP turns that draft into something a futures trader can actually run.

1. A trader describes a setup in plain English.
2. The agent translates it into a NinjaScript implementation plan with NT8 types and method overloads checked against your install.
3. The first draft is compiled inside NT8 with CompileNinjaScript(in_memory: true).
4. Errors are repaired with tool feedback (LookupNinjaScriptSymbol, GetNinjaScriptHelp), not by another round of guessing.
5. The strategy is tested in Strategy Analyzer with realistic commission and slippage.
6. Deployment stays gated behind explicit approval and a post-deploy GetDeployedStrategyState check.

For the dedicated vibe coding page with prompts and FAQ, see Vibe Coding NinjaScript Strategies with CrossTrade MCP.

The compile loop belongs in the conversation

CrossTrade MCP exposes four tools that turn AI-written NinjaScript from a brittle one-shot into a converging loop:

• GetNinjaScriptHelp returns help text for a symbol or topic.
• SearchNinjaScriptSymbols fuzzy-searches the live NT8 type and member surface.
• LookupNinjaScriptSymbol resolves a single name to its overloads.
• CompileNinjaScript(in_memory: true) compiles against the running NT8 AppDomain without touching disk.

With those, the agent reads, writes, compiles, and repairs in the same conversation. WriteNinjaScriptFile only fires after compile is green and you confirm. RunStrategyBacktest drives NT8's real engine; results are bit-identical to the desktop UI for single backtests.

What goes wrong without MCP

Ask a generic model to write NinjaScript. You get plausible C# that:

• References indicators that don't exist in your install.
• Picks method overloads that were removed two versions ago.
• Misspells CrossAbove or invents EmaCross.
• Calls SetTrailStop with the wrong argument types.

You compile, you paste the errors back, the model swears it understands, and it makes a new set of mistakes. Iteration is slow because the model has no way to look at the truth.

The loop in eight steps

GetNinjaScriptHelp / Search / Lookup    →  ground the model in real signatures
       │
       ▼
Author NinjaScript source
       │
       ▼
CompileNinjaScript(in_memory: true)
       │
       ├──── on failure ────┐
       │                    ▼
       │              LookupNinjaScriptSymbol on unknown identifier
       │                    │
       │                    ▼
       │              Repair source
       │                    │
       └──── recompile ◄────┘
       │
       ▼  on success
WriteNinjaScriptFile (with user confirmation)
       │
       ▼
RunStrategyBacktest
       │
       ▼
Review metrics; gate by profit factor, drawdown, trade count
       │
       ▼
DeployStrategy (with explicit user confirmation)
       │
       ▼
GetDeployedStrategyState (verify is_trading)

One prompt; a full compile-backtest-sweep session

What a healthy iteration looks like

A typical first compile after AI-generated NinjaScript:

CompileNinjaScript(in_memory: true)
   → success: false
   → errors:
       MyEmaCross.cs(42,18): CS0103 The name 'EmaCross' does not exist in the current context.

The agent reads the error, calls SearchNinjaScriptSymbols("ema cross") and LookupNinjaScriptSymbol("CrossAbove"), identifies the right call shape, and rewrites the offending line. Recompile. Often green on the second try.

Bit-identical to NT8 UI for single backtests

The reference parity case lives at the NinjaScript Backtest Benchmark: SampleMACrossOver on MES 06-26, 5-minute bars, April 1 to April 30, 2026, Fast=10, Slow=25, Sim101, no commission, 0 slippage. Running through NT8's UI and running through RunStrategyBacktest produce matching NetProfit, ProfitFactor, Sharpe, and trade counts.

This matters because the agent's decisions on parameter sweeps and deployment gates are only as good as the backtests they depend on. If the backtest is not faithful, the agent's "go" is meaningless.

Sweep responsibly

A sweep is cartesian. Two 11-step ranges produce 121 iterations. The risk is overfitting, not throughput:

• The wider the sweep, the easier it is to find parameters that fit noise.
• Strategy Analyzer treats the entire range as in-sample by default; build your own out-of-sample window.
• A great single backtest with 12 trades is luck, not edge.

Defenses inside the prompt: bound the sweep, require a minimum trade count, require profit factor on an out-of-sample window, refuse to deploy if any gate fails.

The deploy gate is the safety system

On a funded futures account, never let the agent deploy a strategy without:

• The firm's automation policy verified.
• Profit factor above a minimum on the in-sample window.
• Profit factor above a minimum on an out-of-sample window.
• Max drawdown below a hard dollar cap.
• Trade count above a minimum.
• An explicit user confirmation.
• A post-deploy GetDeployedStrategyState that returns is_trading: true.

After deploy, verify

The agent must call GetDeployedStrategyState after DeployStrategy. is_trading: true is the only acceptable post-deploy state. If false, the strategy is registered but not running, and the agent should report the errors field.

One operational note: chart-attached strategies cannot be toggled via StrategiesGrid.StrategyEnable. Deploy through MCP's DeployStrategy rather than chart-strategy enable for that case.

Frequently asked questions