Plain English to Trading Strategy: Turning an Idea Into Testable Code
How to go from a plain-English trading idea to a testable strategy: what to specify, how each phrase maps to a rule in code, how to avoid lookahead, and how to check the result.
By Polarline Markets team
"Buy Bitcoin when momentum turns up and get out if it goes against me" sounds like a strategy. It is not one yet. A backtest needs rules a computer can evaluate on every bar without guessing. This guide shows how to turn a plain-English idea into a trading strategy you can actually test, with examples of how each phrase becomes code.
Why plain English is not enough on its own
An AI model will always produce something from a vague idea. The risk is that it fills the gaps silently: it picks an RSI period, a stop distance, a position size, and a timeframe you never chose, and then the backtest measures its guesses rather than your idea. The fix is not to write code yourself. It is to be specific about the five things a strategy cannot run without.
The five things to specify
Scout's template guide recommends naming the market, timeframe, indicators, risk rules, and what happens when a signal fails. In practice:
- Market and data: the symbol or universe, the bar size, and the date range. "BTC/USD, 4-hour bars, 2022 to 2025" is testable. "Crypto" is not.
- Entry: the exact condition, including what counts as confirmation. "RSI(14) crosses above 50 while price is above the 200-bar average."
- Exit: profit target, stop, time stop, or reverse signal, and which wins if two trigger on the same bar.
- Size: fixed quantity, a share of equity, or volatility-scaled.
- Failure behaviour: what to do on gaps, missing data, or a signal that never confirms.
From phrases to rules
Most trading language maps to a small set of rule types. The right column is the part people forget: what the strategy is allowed to know when it decides.
| You say | Rule in code | Decision-time detail |
|---|---|---|
| "When the trend is up" | Close above a moving average, or a fast average above a slow one | Use averages of prior closes; the current bar's close is not known yet |
| "Buy the dip" | Price falls a set percentage or z-score below a recent mean | Measure against the mean of earlier bars, then fill on the next bar |
| "Momentum is strong" | RSI, rate of change, or returns over a lookback above a threshold | Name the period and threshold so the model does not choose them |
| "Breakout" | Price exceeds the highest high of the last N bars | Compute the channel from bars before the current one |
| "Cut losers quickly" | Stop at a fixed percentage or a multiple of ATR from entry | Say whether stops are checked against the bar's low or the next open |
| "Don't hold overnight" | Flatten before the session close | Needs intraday bars and an exchange calendar |
Three worked examples
A momentum idea
This is the example prompt from Scout's documentation:
Build a momentum strategy for BTC/USD using RSI and trend confirmation. Add a stop loss, a take-profit rule, and run it through a backtest. Show me the generated Python before I run it.
It names the market, the indicator family, and both exits, and it asks to see the code first. To make it fully yours, add the RSI period, the trend filter, and the stop and target distances.
A multi-timeframe intraday idea
Only go long when the 4h trend is up, enter on a 15m pullback to VWAP, hard stop at 1.5 ATR, and flatten before the close.
This one is already close to testable. It has a regime filter (4-hour trend), an entry trigger (15-minute pullback to VWAP), a stop (1.5 ATR), and a time exit (flat before the close). A good assistant should implement exactly these rules rather than swapping in a strategy family it prefers.
A mean-reversion idea
Mean reversion on SPY daily bars from 2015 to 2025. Buy when the close is 2 standard deviations below its 20-day mean, sell when it returns to the mean or after 10 days. Risk 95% of cash per trade. Long only.
What the code should look like
In Scout, every strategy follows the Shape-C strategy contract: a Python class with an on_bar method and an injected broker. Orders fill on the next bar, so the strategy records each close after it decides. A trend-following rule looks like this:
class Strategy:
def __init__(self, broker, params=None):
self.broker = broker
self.params = params or {}
self.closes = []
def on_bar(self, symbol, bar):
fast = self.params.get("fast", 20)
slow = self.params.get("slow", 50)
if len(self.closes) >= slow:
fast_ma = sum(self.closes[-fast:]) / fast
slow_ma = sum(self.closes[-slow:]) / slow
held = self.broker.position(symbol)
if fast_ma > slow_ma and held == 0:
self.broker.buy(symbol, notional=self.broker.cash() * 0.95)
elif fast_ma < slow_ma and held > 0:
self.broker.sell(symbol, qty=held)
# Record the close only after deciding, so indicators use prior bars.
self.closes.append(bar["close"])
self.closes = self.closes[-slow:]Parameters come from self.params.get, which lets a sweep try nearby values without editing the code.
/code shows it, /review checks it for edge cases and common trading mistakes, and /backtest runs it.Check the translation, not just the result
- Does every rule in your sentence appear in the code, and nothing else?
- Are indicators built only from bars before the decision?
- Does the result hold in walk-forward folds and for nearby parameters?
- Does the trade log show trades where you expected them?
Scout runs these checks as part of its AI backtesting workflow, and Scout Cloud, the AI quant research workspace, keeps the prompt, code, and results in one session a reviewer can follow. For research before you write the rules, see the AI quant research assistant overview.
Backtests are research, not investment advice. Past performance does not guarantee future results.