AI as Copilot, Not Pilot — How I Actually Use AI in Trading Tool Development

Last week I used AI to generate a complete trailing stop module in 45 seconds. Then I spent 25 minutes fixing the three ways it would have blown up a client’s account in live trading. AI accelerates trading tool development when a domain-expert developer drives the process — it generates code fast, but only human expertise in broker edge cases, state management, and live execution makes that code survive production. That ratio — fast generation, careful correction — is exactly how AI works when you actually ship MQL code to real accounts.

This is not an opinion piece about whether AI is “good” or “bad” for development. I use AI every day. This is a process reveal — what the workflow actually looks like when you build Expert Advisors for live markets, and why the human in the loop is the part that matters.

How AI Actually Fits Into Professional EA Development

AI is a productivity multiplier for trading tool development, not a replacement for domain expertise. I use it daily for MQL4 and MQL5 work — scaffolding functions, writing boilerplate, exploring implementation approaches. But every line of output goes through my domain filter before it touches a client project.

Here is what a typical cycle looks like. I describe a trailing stop function in natural language: “Trail the stop loss by 20 pips once price moves 50 pips in profit, check on every tick, enforce the broker’s minimum stop level.” AI generates a first draft in under a minute. The structure is usually correct. The function signature makes sense. The basic logic flows.

Then I spend 20 minutes fixing the three things it consistently gets wrong:

• Broker stop level enforcement. AI generates `OrderModify(ticket, price, newSL, tp, 0)` without checking `MarketInfo(Symbol(), MODE_STOPLEVEL)`. In live trading, the broker rejects that modify call silently or throws error 130. I add the pre-validation: calculate the effective stop level before the comparison logic, not after.
• Floating-point precision in pip calculations. AI subtracts two close `double` values to calculate pips — a textbook floating-point precision trap. The result drifts by fractions of a pip, which compounds across operations. I replace the subtraction with the source value: if the configured deviation is 20 pips, I use the integer 20 directly, not `(price1 - price2) / Point`.
• State persistence across terminal restarts. AI writes trailing logic that tracks state in global variables — variables that vanish when the terminal restarts. I add file-based or global variable pool persistence so the EA resumes correctly after a crash, a VPS reboot, or a weekend restart.

None of these fixes require genius. They require having shipped EAs to production and watched them fail in specific ways. AI has never shipped anything to production.

Where AI-Generated Code Delivers: Repetitive, Well-Documented Patterns

In my experience across 30+ client projects over the past two years, AI-generated MQL code works on the first pass roughly 4 out of 5 times when the task is mechanical and the pattern is well-documented. Array iteration, string formatting, indicator buffer setup, standard order management loops — these structures are heavily represented in training data, and the output usually needs only minor adjustments.

A concrete example: I recently built a multi-timeframe dashboard indicator that needed to scan six timeframes for a specific candlestick pattern. Each scanning function follows the same structure — call `iCustom()` or read the appropriate timeframe data, check conditions, return a signal value. The logic differs only in the timeframe constant passed.

AI generated all six functions in minutes. Each one was structurally correct. I reviewed for the usual edge cases (what happens when the higher timeframe has fewer bars than expected, what happens when the symbol is offline), made minor adjustments, and moved on. Manually, this would have been an hour of copy-paste-modify — the kind of work where human attention drifts and typos creep in.

This is where AI earns its keep: high-volume, pattern-based code where the structure is predictable and the edge cases are minimal. Indicator buffers, input parameter blocks, comment formatting, string-building for dashboard labels.

The key distinction: these are closed problems. The requirements are fully specified, the patterns are well-known, and the failure modes are obvious at compile time. When the problem is open-ended — when failure only shows up at 3 AM on a thin market — AI’s reliability drops sharply.

Why AI-Generated Trading Code Fails in Live Markets

AI-generated trading code typically fails in production due to three blind spots: a lack of state persistence across restarts, missing broker-specific execution constraints, and timing assumptions that only hold true in a backtest environment. These are the exact problems that separate a profitable Strategy Tester report from a system that survives real money.

A client approached me with an EA generated entirely through AI prompting. The code compiled without warnings. The backtest showed solid equity curves across five years of EURUSD data. In live trading, it opened duplicate positions after every terminal restart.

The root cause: the AI had no concept of persisting trade state. The EA tracked open positions in a runtime array. On `OnInit()` — which fires on every restart — the array initialized empty. The EA scanned the market, saw its entry conditions were still valid, and opened new positions. The previous positions were still running. After three restarts over a weekend, the account had triple the intended exposure.

The fix was not a patch. It required architectural changes: on every `OnInit()`, scan `OrdersTotal()`, map existing tickets to internal state, reconstruct the position tracker from live data. This is not something you add as an afterthought — it changes how the entire EA manages its lifecycle.

At barmenteros FX, we find that roughly 40% of code rescue projects stem from this exact pattern — AI-generated EAs that look professional, compile cleanly, backtest well, and fall apart in production because no one validated the code against live market conditions.

Other recurring failures I fix in AI-generated EAs:

• Spread handling during news events. AI uses a fixed spread assumption. During NFP, the spread on GBPUSD can jump from 1.5 to 15 pips. The EA enters with a stop loss that is already inside the spread.
• Partial fill management. AI assumes `OrderSend()` fills completely or fails. Some brokers return partial fills. The EA’s position sizing math breaks because it expected a 0.10 lot position but only received 0.06.
• Timer conflicts. AI creates `OnTimer()` functions without considering that timer events fire independently of tick events. State modified in `OnTimer()` gets overwritten by `OnTick()` processing the same data a millisecond later.

Every one of these is invisible in the Strategy Tester. Every one of them costs real money in live trading. Many stem from the same root cause: five runtime queries every production EA should execute that AI-generated code almost never includes.

How to Use AI in Trading Development Without Getting Burned

The safest approach to AI-assisted EA development is to let the human expert define the architecture and edge cases while AI handles implementation boilerplate. Never let AI make architectural decisions — it optimizes for “code that compiles,” not “code that survives Friday NFP.”

My workflow has three steps:

Step 1 — Write the function signature and a detailed comment. Not “make a trailing stop.” Instead:

// TrailStopLoss: Moves SL to (Bid - trailPips * Point) when
// profit exceeds activationPips. Pre-validates against broker
// stop level. Only modifies if new SL > current SL + minDelta.
// Returns true if modified, false if skipped or failed.
bool TrailStopLoss(const int ticket, const int activationPips, const int trailPips, const double minDelta)

The comment is the spec. It includes edge cases. AI fills the function body from this constrained prompt.

Step 2 — AI generates the implementation. The output is usually 70–80% correct. The loop structure works. The basic math works. The `OrderSelect()` and `OrderModify()` calls are in the right order.

Step 3 — Review against a production checklist. Every line of AI output is audited against criteria that only matter in live markets:

What AI produces and what ships to production are different things. AI gives me a first draft in seconds. My domain knowledge turns it into code I would trust with a client’s capital. I estimate AI saves me 30–40% of development time on most projects — but the time saved is on the mechanical parts. The critical parts take exactly as long as they always did.

What “Built With AI” Actually Means When You Are Buying an EA

“Built with AI” is a speed signal, not a quality signal. The question traders should ask their developer is not whether AI was used, but whether a domain expert validated the output against live market conditions.

Here is the economics. A developer without trading domain knowledge uses AI to deliver an EA in two days for $150. The code compiles. The backtest looks promising. Within a week of live trading, the EA misbehaves — duplicate orders after a restart, failed modifications during high spread, or a position sizing error that only triggers on specific lot step sizes.

The trader now needs a rescue. Debugging someone else’s AI-generated code is harder than writing from scratch — the architecture follows whatever pattern the AI defaulted to, there is no documentation of design decisions, and the state management is usually an afterthought bolted on after the first failure.

That rescue costs $400–$800 depending on complexity. The $150 EA just became a $550–$950 EA, and it took longer than if a domain expert had built it correctly from the start.

A domain expert using AI as copilot delivers in five days for $600. The EA handles restarts, validates against broker constraints, logs its decisions for debugging, and runs for months without intervention. The $600 was the cheaper option — the trader just could not see it upfront.

I am not arguing against using AI in development. I use it every day. I am arguing that the developer’s domain expertise is the variable that determines whether “built with AI” means “built fast and well” or “built fast and broken.”

What Improves With Better AI Models and What Does Not

AI will keep getting better at generating syntactically correct MQL code. The models will learn more patterns, handle more edge cases in their training data, and produce cleaner boilerplate.

What AI will not improve at: understanding your broker’s specific execution model, your account’s margin requirements during rollover, or why your EA needs to behave differently during the Christmas low-liquidity session versus a regular Tuesday London open. These are not syntax problems. They are market interaction problems, and they change per broker, per account type, and per regulatory environment.

My concrete prediction: within two years, AI will handle the vast majority of custom indicator development reliably. I base this on what I see today — AI already produces usable indicator code in most cases I test, and the gap is closing fast. Indicators read price data and draw things — the failure modes are visual, obvious, and testable at compile time. EA development for live trading will still require human oversight for the foreseeable future because the failure modes are not in the code syntax. They are in the market.

The copilot gets faster. The pilot remains essential. The traders who understand this will spend less, lose less, and run more reliable systems.