Build
The AI Strategy Builder
The builder turns a plain-English trading idea into a reviewable Strategy Brief and a working, testable code proposal — while keeping you in charge of every step. Nothing the AI produces touches your workspace until you have read it and accepted it.
Opening the builder
The builder is part of the workspace IDE. Open any workspace and click Create strategy with AI in the header (an empty workspace also offers the same button in the middle of the editor). The builder opens in the right rail and walks you through four stages: idea, clarifying questions, Strategy Brief, and code review.
Stage 1 — Describe your idea
Under “Describe your strategy in plain English”, write the idea the way you would tell a colleague. The placeholder shows the level of detail that works well:
Example idea
“Fade failed sweeps of the overnight low on ES: after a sweep reclaims, short the retest of the sweep level, stop above the extreme, take profit at 2R, RTH only.”
You don't need to specify everything — anything you leave out becomes either a clarifying question or a written-down assumption. Press Continue when you're happy with the description.
Stage 2 — Clarifying questions
Instead of guessing, the builder asks. The Clarifying questions stage lists short, specific questions about the parts of your idea that were ambiguous — session boundaries, what exactly counts as a “sweep”, how to size, when to stand down. Each question is a simple text box.
You have two ways forward:
- Continue to the Brief — submits your answers and builds the Brief from them.
- Generate a first draft with assumptions — skips the questions entirely. The AI proceeds, but every choice it makes for you is stated as an explicit assumption you'll review in the next stage. This is a fast way to get a first draft when you'd rather react to something concrete.
If your text looks like instructions
The builder treats your idea as a description of a strategy, not as commands. If part of what you typed reads like instructions to the AI itself, it flags it: “Heads up — some of your text looked like instructions”, with the flagged lines listed, so nothing sneaks into the output unreviewed.
Stage 3 — Review the Strategy Brief
The Brief is the contract between your idea and the code. Its heading says exactly what it is for: “Strategy Brief — review before anything is generated”. Nothing is coded from your idea directly — only from the Brief you approve.
The Brief is a structured, editable form with these fields:
| Field | What it pins down |
|---|---|
| Summary | The strategy in one or two plain-English sentences. |
| Instruments | Which futures contracts it trades (comma-separated). |
| Session rules | When it is allowed to trade — sessions, cutoffs, days. |
| Entry | The exact conditions and order type used to get in. |
| Exits | How positions are managed and closed. |
| Stop | Where protection sits and how it is derived. |
| Target | Profit-taking rules. |
| Sizing | How position size is chosen. |
| Risk limits | Hard guards — max risk per trade, force-flat times, and similar. |
Read every field. If something is wrong, edit it directly and press Save Brief edits — your corrections become a new version of the Brief. When it says what you mean, press Generate code from this Brief. That click is your approval: it is the only way code generation starts. (You can also go Back to questions if the Brief reveals a misunderstanding worth re-answering.)
Stage 4 — Review the generated code
The proposal stage stacks everything you need to judge the code:
- Assumptions first. The section “Generated with these assumptions — read them” lists every choice the AI made that you didn't specify. Read this list before the code — it is where surprises live.
- Consistency checks. If the generated code disagrees with the Brief anywhere, a section titled “Brief vs code mismatches — review before accepting” lists each mismatch. Warnings also appear if the proposal would change tests.
- An automatic type check. The same Python analysis that powers the editor runs over the proposed files; the status line reports either no findings or a count of findings, with markers shown right in the diff gutter.
- The diff itself. Files are listed under two headings — Production code and Test changes — reviewed separately — with new files marked (new). Selecting a file shows a side-by-side diff of your workspace's current content against the proposal.
Production and tests are accepted separately — here's why
There are two accept buttons, and they are never combined:
- Accept production code — applies only the production files.
- Accept test changes (separate) — applies only the test files.
The reason is simple: the tests are the leash on the code. In VeriRun Lab, a strategy cannot run on data until its required tests pass — so if a single click could apply new code and new tests together, generated code could quietly rewrite the very tests that are supposed to catch its mistakes. By forcing two separate, deliberate accepts, the app makes sure a change to the tests is something you consciously reviewed and chose, never a side effect. When you review a proposal, give the test diff the same attention you'd give the production diff: ask “would these tests still catch the failure modes I care about?”
Revise or reject
- Revise — sends the proposal back with your review; a new proposal replaces the current one. Use it when the shape is right but details are off.
- Reject proposal — discards everything and returns you to the idea stage with a clean slate.
After you accept, the files appear in the workspace file tree like any other code — fully yours to read, edit and test. The natural next steps are understanding the files and running the test suite.
What the builder will never do
It never applies code without an explicit accept, never applies production code and test changes in one action, and never executes anything it generated — the proposal is text you review, and the only thing that runs code is you, later, through tests and runs.
Choosing the model
Generation runs on your own AI key, and a Model switcher sits right in the builder header so you can change which model that key uses without leaving the workspace — a faster model for quick iterations, a stronger one for a complex idea. The choice is saved on the connection, so it sticks across reloads. With no key configured the control says so and links you to Settings → AI keys & connections; with more than one key, it also lets you pick which key to use. The model list is derived from your provider's own catalog — never a fixed list baked into the page.
Changing a strategy you already have
The builder is for creating a strategy from a blank idea. Once you have working code, the AI coding agent is the faster way to change it: describe an edit in plain English and it reads your files, proposes a diff, runs the checks, and hands you the same review-and-accept flow — production and tests still accepted separately.