How to Build an Automated Trading System That Doesn't Blow Up (Sierra Chart + Claude Code)

Published September 2026: the four pieces between a signal and a live order — send it, manage it, an emergency stop, an arming switch — built in Sierra Chart with Claude Code writing the C++, verified in sim. This is the written companion to the video above, including the starter prompt shown on screen and every failure that put a line on it.

Every Sierra Chart coding tutorial I could find stops in the same place. The study draws a line, or prints a number to a log. None of them sends an order. So if you feel stuck trying to use AI to automate your strategy into the market, you're not alone. That's where the content stops.

What you need is four pieces. One sends the order. The second manages it once it's live. The third is an emergency stop, for when the system can't tell what's true any more. The last is an arming switch, so none of it happens by accident. Miss one and you find out the hard way, with a real trade on.

With today's tools you can build an indicator in an afternoon. That's step one of four. This post is the other three.

Step 1: sending the order is the part that matters least

In one sentence: the study calls an order function when the signal is true. A green arrow fires, the signal reads long or short, and the order manager executes in that direction. One requirement, one function call, and the order is live in the market.

This is the part everyone wants and YouTube hypes up. A study that can execute live. It's also the step that matters least. Anyone can get in. The question is what happens after, and how you manage the trade. If you watched the last build, you already have the signal study. This picks up where it left off.

Step 2: the order manager

When the signal fires, the stop and the target go out on entry, attached to the same order. Not as follow-ups once the fill comes back. If you don't know the term, that's a bracket order, or OCO (one cancels the other). The position is protected no matter which side goes first.

If you trade a thick market with wide stops this sounds like an edge case. The orders go out in milliseconds and you'll probably never notice the difference. But if you send the stop after the fill, there is a window where you're holding a position with nothing protecting it. It's small. It is not zero. And the day it matters is the day the market is moving fast enough that you really wish you'd had something in place.

I call the second piece my order manager. It's its own study in Sierra Chart. It checks continuously whether the conditions are still true and acts on that. The way I think about it: it's the person you hand the trade to. It has to know when to add, when to get out, where the stop and target are, and follow them faithfully.

One position at a time, and the bug that teaches it

I run a one-at-a-time policy. Enter on one signal, and while that position is open, every other signal does nothing.

Here's why that has to be explicit. In Sierra Chart the studies run constantly. If the condition is true and the signal fires on the next tick, nothing in the code prevents it from sending again and again. What stops it is the order manager's check for an existing position before it executes. I also gate the signal so it's only evaluated once per closed bar.

I found this one the hard way. It wasn't a bug in the sense that something threw an error. The code did exactly what it was told: enter when the condition is true. The condition stayed true. So the size kept climbing on every signal until I saw it myself and closed the trades out.

Size is an input

One more thing the order manager does: position size is an input, not a number hard-coded in the middle of the signal. That's what lets me go bigger or smaller as conditions change, and it's what lets the same signal run on a different instrument or in a different regime without touching the signal code.

The broker is the record of truth

Once you automate, you're running two systems. Sierra Chart has one picture of your position; your broker has another. Which one is the record of truth?

For me it's always whatever is live on the broker. Always. Sierra Chart is an external system. After a disconnect, its job is to find the position again, not argue with what the broker says.

Part of my validation is pulling the network cable and watching what happens when Sierra Chart reconnects. One time I did this in a live position. It came back, reconciled, found where the trade entered and where the stop should be. Then it added back the scaling positions I'd already exited. Four contracts where there should have been one.

The detail that matters: this was not a restart. Not a reload. A simple network pull made the chart recompute from scratch, and it recomputed itself into a position it shouldn't have had. No crash, no error. It just woke up with a clean memory and did what the code said to do with a clean memory.

How I solved it: on recovery, the study now assumes it already consumed every additional add, even if it hasn't. I'd rather be wrong in the boring direction, on purpose.

All of this is testable, and it's part of validating your own order management. Plan for it, write the recovery into the code, then pull your internet or restart Sierra Chart and watch what comes back.

Step 3: the emergency flatten

The order manager assumes Sierra Chart can track the position from beginning to end and reconcile it on a disconnect. The bigger question is what happens when it can't. When it loses track of the position completely.

Your app crashing is not an emergency. If you did it right, you have a stop resting on a server doing its job. The emergency is when your automated system and your account disagree about what you're holding.

Sierra Chart and most platforms have a flatten-all button. The button only helps if you're sitting there. The emergency flatten gives the automated system that same ability when nobody is at the desk, so I write it into the code itself. Some event happens: a disconnect, a crash, a rejected order, a position nobody can explain. The code tries to reconcile and figure out where the position actually is. If it can't, the flatten fires.

The limit order I forgot

This piece exists for me because I trade both ways: discretionary in the morning, then I hand off to the automated system. One day I made the handoff and forgot to cancel my limit orders. The strategy crossed one of those price levels while executing. From there the day diverged from anything the system should have been managing.

Luckily I was on a prop account, still validating. I almost blew that account. And it gets worse: if you cancel on one account but not another, and your automated strategy is executing in the opposite direction of a position elsewhere, you can get flagged for hedging.

So: an emergency flatten, for when the strategy cannot reconcile exactly where it is. Extremely important, in my opinion.

It isn't watching the market

Another way to think about it: the order manager isn't watching the market. It's watching whether it still knows what's true. The moment it can't answer, it gets flat. Being wrong about your position is worse than being out of it.

Everything else in the build is your edge. This piece isn't. I would rather it flatten a good trade by mistake than hold a bad one it doesn't understand. If it can't tell whose position it is, the answer is nobody's, and it flattens right away.

I do give myself a switch for this. I call it the reconcile guard. Off when I'm trading by hand, on when the automated system is running, because I run both. With the guard on, it cleans up stale limit orders I might have forgotten about the moment it enters off one of them.

One study finds, one study manages

My signals and my order management are two distinct studies. Same rule as any code: one thing does one thing. One study finds the trade, one study manages it. They should never be the same file. I take it a step further and run a separate study per signal, per strategy, per instrument, all talking to one order manager.

If I were starting from scratch and had to pick where to spend most of my time, it would be order management. Without it, I would not have an edge.

Submitted is not applied

My trades are one-shot. If the broker rejects the entry, that's it. No retry, no chase. It waits for the next signal. On startup the only thing it looks at is open positions, and that is what reconcile means.

I struggled with this early. Orders were getting rejected because I wasn't submitting them properly, and I had to learn that submitting an order doesn't mean it applied. One example: fast Nasdaq market, I tried to place my stop, and by the time it arrived the stop was above where price already was. The broker rejected it. The position was naked. Without the emergency flatten there was no backup for a stop that didn't take. That day could have blown the account.

Validation takes months, and that's the job

For me this isn't maintenance and it isn't updates. It's an essential piece of the trading system. I still review and watch it. I've eliminated most bugs, and I wouldn't be surprised to run into another one.

Plan a few months for validating your order management. The market keeps throwing conditions at you that you haven't seen, and as you work through more of them you get more confident the code can handle them. Read the comments on any older automation video and people are still asking, years later, whether the code works. What's different now is you have Claude Code. The thing that writes and fixes the C++ is on your desk, in the afternoon. You don't have to find someone to hire.

Sim proves the plumbing, not the fills

I film in sim. I don't validate in sim. They're two different things. Sim proves the plumbing. It doesn't prove the fills you'd get live.

And before any of this: it works is not the same as it's real. Your backtest can lie about fills. It can lie about whether the signal fired at all. I've covered the fills lie already, and there's more coming on backtest bias, because that's where most people get stuck. Watch those before you arm anything.

My process to go live is four stages:

1. A backtest you believe. Do the due diligence; the strategy has to survive its own history.
2. Chart-ingest parity. Use the backtest to validate the live signals in Sierra Chart. I track the historical signals through a chart's history and run a script through each one as if it were live. It deserves its own video.
3. A prop account. They're cheap, about $50 for an evaluation, and you get execution as if you were live. Fills are where you'll notice the biggest gap between backtest and live, so a prop account is a perfect place to validate them, especially through Rithmic, which executes the way a live account would. If your goal is to run prop accounts, you can stop here. You never have to put your own money in.
4. Your own capital. Whether you take this step is your call. It took me many months to trust my own capital in the market, and even now I trade small, one contract, until I can prove the strategy to myself.

The stack behind it isn't a secret: about $100 a month for the Claude Code Max plan, about $50 for Sierra Chart, and $50 or so for any prop evaluation. That's the desk.

Step 4: the arming switch

In my studies there's an explicit on/off switch, so I always know which strategies are armed and which aren't. Off is the default, and off still runs. It logs every trade it would have taken, on the same signals. You get the record without the risk.

On is the only state that routes. The order goes to the broker and executes. Live routing takes a deliberate change that you make on purpose, knowing what you're doing. After that, anything it does is on you. This isn't advice, and the signal is an example, not an edge.

That's four. None of it happens until I arm it.

The starter prompt

This is the prompt I use to start an order management system. Not a sanitised version. Everything I asked for is on it.

I have a Sierra Chart ACSIL study that produces a LONG/SHORT signal. I want it to
place and manage the trade. Assume I am on a SIM account.

Requirements:
  1. An "armed" user input that defaults to OFF. With it off, the study logs what
     it WOULD have done and sends nothing. Nothing routes unless I set it on.
  2. On signal: send the entry with stop and target attached to the same order,
     not as follow-up orders.
  3. One position at a time. If a position is already open, the study does not
     re-enter, and it does not re-send on every tick while the condition holds.
  4. Position size is an input, not a constant.
  5. A separate always-available action that flattens the position and cancels
     all working orders, that does not depend on the strategy logic being correct.
  6. Handle and log: order rejected, no connection, position mismatch between what
     the study thinks it holds and what the account reports.
  7. Only evaluate the signal on a bar that has closed. With sc.AutoLoop the study
     re-runs on every tick of the forming bar, so without a bar-close gate it can
     write a signal on one tick and clear it on the next — the log fires, the chart
     ends up empty, and the two disagree with no error anywhere.

Tell me every place where your code assumes something about my account, my
instrument or my session that I have not told you. Do not invent an ACSIL function
signature — if you are unsure one exists, point me at the documentation page.

What it gets you is a study that places an order in sim. What it does not get you is a study you should turn on. That's not the prompt's fault. That part is the four stages above.

Read it against the rest of this post. Point one is the arming switch. Two is the stop and target going out with the entry. Three is one position at a time. Four is size as an input. Six is the mismatch the emergency stop watches for. Every line is either one of the four pieces, or it came straight out of debugging a live signal. If you already have your own strategy and your own backtest, point it at that instead. The requirements don't change.

Why point one comes first

The reason I start here and not from a blank chat is point one: an arming switch that defaults to off, written before any other code. Ask for the trading strategy first and the safety after, and you get a study that can be traded before you've decided it should be.

Point seven: the silent bug

Nobody asks for point seven. It's the one I'd never leave out now.

The study re-runs on every tick of the bar that's still forming. So it can decide yes on one tick and no on the next, and what you're left with at bar close is whatever the last tick thought. The log records the yes. The chart records the no. Neither one throws an error, and you will not find it by reading the code. It looks correct.

That's what a silent bug is. Not a crash. Two things that should agree, quietly disagreeing. It's the whole reason the switch defaults to off.

Not a bot. Your strategy with you out of the loop.

Some people call this a trading bot. Some people call it an algorithm. Really it's just your strategy, with you out of the loop, and the four pieces above are what go in.

Next on the desk: backtesting in Sierra Chart without fooling yourself. Everything above assumes the signal underneath is real, and that's the part most people get wrong.

One ask: tell me what safety requirement this prompt missed. The best one goes into the next version, with credit.

---

The starter prompt, the chartbook, and the ORB signal study are free — grab them here and they land in your inbox, with the prompt as plain text in the repo. Everything I teach is free: the method and the code. The paid layer is the assembled desk — the execution engine, the validated backtest kernel, the working files — never the methodology. I don't sell signals and I don't post live P&L. New to the desk? Start with how Claude Code writes the Sierra Chart study this wires up, or why your backtest lies about fills.