Everything I document on this site — the v6 of the BTC bot, the v1.30 filters of Kimera, the two-phase research on 210,240 bars — was developed in collaboration with state-of-the-art AI models. Not "helped occasionally": developed with, the way you develop with a senior colleague who writes at lightning speed, knows every API and doesn't take offense when told they're wrong.
But this article is the opposite of default enthusiasm. AI applied to trading has two modes of use, and the difference between them is the difference between a multiplier and an accelerator of ruin.
Oracle mode vs colleague mode
Oracle mode (wrong): "give me a winning strategy", "predict where price goes", "write me a profitable EA". Used this way, you get syntactically perfect code built on premises never verified — the most efficient way ever invented to industrialize overfitting. The AI doesn't know the edge: if there is no edge (and often there isn't), the AI will still manufacture, on request, the best-polished illusion in history.
Colleague mode (right): the human owns the question, the hypothesis and the verification criterion; the AI multiplies the execution speed of every step — implementation, analysis, review, research. The bottleneck of quant work has never been intelligence: it has always been the time needed to discard wrong ideas. AI compresses the cost of each iteration from days to minutes.
The 5-rule working contract
Rule 1 — I write the spec, and it contains the financial logic
The prompt for a module is not "write a trailing stop": it's a spec with the what, the constraints, the edge cases and the financial why. If I can't explain what a module must do, the problem isn't programming. A real example, for an EA's risk guardian:
Implement in MQL5 a "risk guardian" module for my EA with these exact specs: FINANCIAL CONTEXT: I trade a prop account with a 4% daily loss limit and 10% max drawdown. My internal limit must trigger BEFORE the firm's (3% daily), because overnight spreads, gaps and slippage can violate the contractual limit even with the market "still". REQUIREMENTS: 1. Daily loss limit: if equity <= day_start_equity × (1 − 3%), close ALL positions and block every new entry until the next day. 2. Max drawdown: if equity <= historical_equity_peak × (1 − 8%), same procedure, but the block is permanent until I remove it manually. 3. The block must have a LATCH: once triggered, it stays triggered. No automatic intraday re-arming. 4. Checks must run on EQUITY, never balance: live risk lives in open positions. 5. The equity peak must survive EA restarts (crash, recompile, VPS reboot). EDGE CASES to handle explicitly: day change with positions open; EA restart with latch active; which timezone the server uses for the "day" rollover. Before the code: explain in 5 lines how you plan to structure it, so I can verify we understood the same thing.
Note the difference from "write me drawdown protection": every number has a motivation, the edge cases are listed, and I ask for the structure before the code. The 3% vs 4% margin isn't pedantry: violation by a spread spike at 11pm is a documented classic.
Rule 2 — The AI proposes, the data disposes
Every idea — mine or the model's — goes through the same funnel: data feasibility, in-sample/out-of-sample, robustness. No exceptions for charisma. The AI's ideas have an advantage (they're instant and numerous) and a symmetric danger: they are plausible by construction. The model is trained to produce things that sound right — and plausibility is not evidence. The feasibility prompt:
I have this trading hypothesis: [hypothesis in ONE sentence, with the edge source: who pays and why]. Write a Python script that verifies it on the attached data (OHLCV CSV, closed bars) BEFORE any implementation: 1. Compute the average gross edge per trade in basis points, over all horizons from 1 to 48 bars. 2. Subtract a realistic round-trip cost of [X] bps. 3. Compare against the baseline "always long on every bar": the pattern must beat THAT, not zero. 4. Split the results: first 70% of data (in-sample) vs last 30% (out-of-sample). If the edge's sign flips between IS and OOS, declare a negative verdict. ABSOLUTE CONSTRAINT: every feature must use only information available at the close of the previous bar. At the end of the script, list every place where look-ahead could have crept in and how you avoided it.
Rule 3 — Adversarial review
After every delivered piece of work, the next session starts with the opposite assignment. The AI is an excellent reviewer of itself if you ask explicitly — and a terrible spontaneous reviewer, because by default it optimizes to please you:
You are a hostile reviewer. This code/analysis was written by someone else and your job is to demolish it: 1. Find the errors, especially: hidden look-ahead, float comparisons without tolerance, local state diverging from server/broker state. 2. List every unverified assumption. 3. Tell me why the result could be an artifact rather than an edge. 4. Find the number that betrays the contract: is any constant (baseline, limit, threshold) inferred from current state instead of being written as a contractual constant? Don't be diplomatic. Every problem you don't find now, the market will find with my money.
Point 4 isn't theoretical: a bug of exactly that kind — the drawdown limit computed on a runtime-read balance instead of the prop account's contractual baseline — survived three human readings on my BTC bot. It only surfaced in an adversarial review requested with that explicit mandate.
Rule 4 — Code is read line by line before touching money
All generated code going into production, I read and understand. Not out of romantic distrust: because responsibility cannot be delegated. The AI's error on my account is my error. Generated-code errors cluster in predictable places — I've turned them into an MQL5 checklist.
Rule 5 — Decision log
Every non-obvious choice (why 2× costs in the cost-gate? why a 120-second max hold?) leaves one written line with its motivation. Six months later, when a number looks arbitrary, the line is there. The AI is excellent at maintaining this documentation — if you task it with it:
From now on, whenever we fix a numeric value that isn't mathematically derived (thresholds, multipliers, timeouts), append a line to DECISIONS.md in the format: [date] [parameter=value] [one-sentence motivation] [discarded alternative and why]
Where AI excels and where it fails, in this trade
Excels: fast implementation from a clear spec; translation between languages (a filter's Python prototype → MQL5); exploratory data analysis ("find the anomalies in these 590 trades"); academic literature synthesis (36 papers read and filed in hours, not days); refactoring existing code.
Fails systematically: invents plausible details when information is missing (API versions, tester behaviors) instead of declaring uncertainty; introduces silent look-ahead into backtest scripts if the spec doesn't explicitly forbid it; tends to add complexity rather than remove it; degrades in long, messy sessions.
The complete flow, with true timings
| Phase | Who | Time |
|---|---|---|
| Analysis of the 590 trades, identifying the cuts | AI as analyst on exported data | half a day |
| Decision on the filters to adopt | Human | 10 minutes |
| Written spec of the filters and guardian | Human | 30 minutes |
| MQL5 implementation, edge cases included | AI | 1 hour |
| Adversarial review + line-by-line reading | AI + human | 1 hour |
| Confirmation re-backtest | Tester | tester time |
Total: one working day for an upgrade that halved a system's drawdown. Before AI, the same cycle cost one to two weeks — when I could find the will, which is the real point: AI didn't make the method possible; it made it cheap enough to be practiced always.
For the data pipeline all of this runs on: Quant research with Python and Binance API feeds.