Three ways to change a strategy
"Editing a strategy" is three different actions. They live in different places, they survive different things, and choosing the wrong one is how a change quietly disappears.
| Change | Where it lives | Survives re-adding to a chart? | Travels with the file? |
|---|---|---|---|
| an input value | this chart's settings | no | no |
| the source | your saved script | yes | yes |
| a re-export | a new file entirely | yes | yes, and overwrites |
Changing an input is not changing the strategy
The Inputs tab changes "the settings which the script's author has decided to make editable" [1] — and those values belong to this instance on this chart. They are not in your Pine file.
So if you find a parameter that works and only change it in Inputs, you have a result you cannot reproduce, cannot share by sending the file, and will lose the next time you add the script to a chart. Record it, or move it into the source as the declared default.
This is the right place to change things while you are exploring, and the wrong place to leave them once something matters.
Changing the source means re-adding the copy
Built-ins are read-only; you press "Create a working copy" to get an editable one [1]. And a working copy is a separate script:
Because the working copy is a different version of the script, you need to use the Editor's "Add to chart" button to add that new copy to the chart. [1]
Which produces the classic confusion: you edit, you save, and the chart shows no change — because the chart is still running the other script. If an edit appears to do nothing, check which script is attached before you check your logic.
Re-exporting replaces everything you hand-edited
If the strategy came out of a builder, a fresh export is a new file. Anything you
changed by hand in the previous one is gone — including costs you added, an
indicator call you hoisted out of an and chain, and a minval you tightened.
That is not a flaw in exporting; it is what "generated" means. But it decides where your changes belong:
- parameter values and thresholds → change them in the builder, so the next export carries them
- anything structural you fixed by hand → either get it fixed at the source or expect to redo it, and keep a note of what you did
The practical rule: hand-edit an export only for things you are willing to redo. Everything else goes back into the builder.
And after any of the three
Re-check the strategy() declaration. It is where costs, sizing and
pyramiding live, and it is the part a re-export rewrites and a source edit can
disturb —
the cost parameters
lists what to look at.
Did your edit do what you meant?
"It compiles and the equity curve moved" is the usual test, and it is not a test. The curve moves for many reasons, several of which mean you broke something.
Write down the trade count before you change anything
One number, taken before the edit. It is the most diagnostic thing available, because it answers a question the equity curve cannot:
| After your edit | Means |
|---|---|
| trade count unchanged | you did not touch the decision logic — if you meant to, the edit did not land |
| trade count slightly different | you shifted a threshold; expected for a parameter change |
| trade count very different | you changed when the strategy acts, not just how much |
| trade count zero | a condition is now permanently false |
The last row is the one people spend an hour on. A condition that can never be true produces no error, an empty trade list, and a flat line — which looks like a bad strategy rather than a broken one.
Then check it changed for the reason you think
Two edits produce the same trade count for completely different reasons, so compare the trade list, not the total:
- do the first few entries fall on the same dates as before?
- if you tightened a filter, did trades disappear rather than move?
- if you changed an exit, did entries stay identical? They should — an exit
change that moves your entries means the two are coupled somewhere you did not
intend, usually through
pyramidingor position state.
The three edits that silently do nothing
Worth knowing because each produces a confident-looking result:
An input that is declared but never referenced. The control exists, it moves, and the threshold is compiled in as a literal. Move the input to an extreme — if the trade count does not change, the logic is not reading it.
A ta.* call left inside an and chain. In v6 the operators evaluate
lazily [2], so the call is skipped on bars where the earlier condition is false
and its internal history breaks. Editing its parameters then changes less than
you expect, unpredictably. Hoist it to global scope.
A change to the source while the chart runs a different copy. Covered in the previous section, and it is the first thing to rule out when an edit appears to have no effect at all.
Keep the version you started from
Before a structural change, save a copy. Not for safety — for comparison. The useful question is rarely "is this good" but "is this better than what I had", and that needs both to be runnable side by side on the same instrument, the same timeframe and the same date range.
And if you end up trying several variants this way, the number you tried is part of your result: why the count matters.
Tactix AI — Studio vs Guide
Tactix AI is AlfaTactix’s product assistant brand (open Tactix AI).
- Tactix Studio turns a one-sentence strategy description into a draft across Timeframe, Signals, Filters, and Risk in the visual Strategy Builder. You review and edit every field before Code Generator writes MQL5 or Pine Script.
- Tactix Guide explains the step you are on — what to fill, what a control means, or how to phrase a rule — without dumping untested source code.
That is form-first automation: the LLM never replaces Code Generator, and you keep plan limits and real-time validation.