AI-Assisted Coding — Pine Script and Python You Can Actually Audit

Most software fails loudly. It throws an error, returns nothing, or produces output that is obviously wrong. Trading code has a quieter failure available to it. It can produce output that is wrong only in the sense that it could not have been known at the time — and that kind of wrong looks like accuracy. It looks like edge. It looks like the thing you were hoping to find.

Two words cover most of it. Repainting: a signal that changes after the bar it appeared on has closed, so the historical chart no longer shows what the indicator actually said in real time. Look-ahead: the code reads a value from a bar that had not completed at the moment the decision is claimed. Both produce a historical record that is better than reality, and neither raises an error.

AI introduces these bugs at a higher rate than a careful human would, for a structural reason. A language model produces code that resembles code it has seen. An enormous amount of publicly posted indicator code contains exactly these defects, because they are the mistakes beginners make and beginners post the most code. The model is not being careless. It is faithfully reproducing the distribution it learned from.

There is also a subtler asymmetry. When AI writes a web page, you see the result and judge it. When AI writes an indicator, you see a chart — and the chart is generated by the same code you are trying to evaluate. You are checking the work using the work. That circularity is why the audit has to be procedural and specific, rather than a glance at whether the arrows look right.

Work in a fixed loop and most of the risk drains out of the exercise. Write the specification before you open the model. Generate against it. Audit the code against the specification line by line. Then test in a way designed to expose timing bugs rather than to confirm that the thing plots.

The order is not decorative. Writing the specification first means you have a document to check against that was not produced by the model — which is the only way the audit is independent. If you describe what you want loosely and then read the code to find out what you asked for, the code becomes the specification, and there is nothing left to audit it against.

The loop is also where you enforce a rule that saves an enormous amount of time: reject the first answer that skipped a line of your specification. Not fix it, not patch it — say which line was ignored and ask again. Code that ignored one instruction has usually ignored the reasoning behind it too, and patching that by hand leaves you owning a file you did not write and do not fully understand.

Expect to run the loop more than once for anything non-trivial. The first pass typically gets the arithmetic right and the timing wrong. The second pass, after you have quoted the exact bar-reference problem back at it, is usually much closer. Three passes on a small indicator is normal and still far faster than writing it yourself.

A vague request produces code that cannot be wrong, because there is nothing to be wrong against. “Give me a breakout indicator” has no failure condition. “The close of the current bar is greater than the highest high of the previous twenty completed bars, where the current bar’s own high is excluded from that window” has exactly one meaning, and the code either implements it or does not.

Four things have to be pinned down every time. The series: which price, which timeframe, regular session or extended. The bar reference: which bars are inside the window and whether the current bar is one of them. The condition: the comparison itself, stated as a sentence that has a true or false answer. And the warm-up: what the indicator outputs on the first bars, before enough history exists to evaluate the condition at all.

That last one is quietly important and almost always omitted. On the opening bars of a chart there is no twenty-bar window. The code has to do something. If it silently returns an undefined value that later gets treated as a signal, you have a defect that only shows up on the left edge of the chart — which is the part everybody scrolls past. Specify it: on the first bars, the condition is false, not undefined.

Being concrete costs one extra sentence per item. In Pine, “the highest high of the previous twenty completed bars” is not the same expression as “the highest high of the last twenty bars” — the second includes the bar you are standing on, and a close cannot exceed a maximum it is part of. That single distinction is the difference between an indicator that fires and one that never fires, and it is exactly the kind of thing a loose prompt leaves to chance.

Repainting is the first and worst. A signal repaints when it can change after the bar it appeared on has closed. The classic cause is evaluating a condition using values that are still moving — an unconfirmed bar’s close, or a higher-timeframe value that has not finished forming. On the historical part of the chart everything looks settled, because history is made of closed bars. Live, the arrow appears, vanishes, and reappears somewhere else.

Look-ahead is the second. Here the code reads a value from a bar that had not completed at the moment the decision is claimed. In Pine this shows up most often in higher-timeframe requests, where a lookahead setting can hand you the weekly value before the week has finished. In Python it is usually a rolling window that includes the current row — a twenty-row maximum computed with no shift is a maximum the current row is inside, so a comparison against it is partly a comparison against itself.

Off-by-one bar indexing is the third, and it is the most common of all because it is so easy to write and so hard to see. A reference to the previous bar’s value versus the current bar’s value differs by one character. Both compile. Both plot. One of them is the indicator you specified and the other is an indicator that is systematically one candle early or one candle late — which is more than enough to turn a useless idea into a beautiful one.

The fourth is behaviour that differs on the live bar. The last bar on a chart updates continuously while it is forming; every other bar is frozen. Code that does not distinguish between the two runs one way over history and another way in real time. That is the bug that makes people say the indicator “worked in backtest” — it did, because in backtest every bar was already closed.

The audit is a reading exercise with a fixed set of questions, not a general review. You are not asking whether the code is elegant. You are asking, for every line that touches a bar other than the current one, which bar it resolves to and whether that bar had closed at the moment the signal is claimed. Everything else in the file is secondary.

Use the model to audit its own output, but constrain it hard. An unconstrained “review this code” request produces a rewrite, and a rewrite means you now have a second version you have not read either. Tell it explicitly not to improve anything, and require it to quote the exact line it is talking about in each answer. Quotation is what stops the audit from becoming a summary of what the code was supposed to do.

Then read the answers sceptically, because this is still the same machine. The audit prompt is not a proof. What it does is force the timing assumptions out of the code and onto the page, where you can check them yourself against your specification. If an answer says a value is final on bar close and you cannot find the line that makes that true, the answer is wrong, not the question.

Delete everything you did not ask for. Generated code arrives with helpful extras — an extra filter, a smoothing parameter, an alert condition, a second confirmation rule. Each one is a piece of logic you did not specify and cannot audit against anything. They also quietly do the thing you are trying to avoid: adding parameters until the historical chart looks good.

Testing generated trading code means something narrower than testing software. You are not checking that it runs. You are checking that what it says today about a past bar is identical to what it said on that bar at the time. Three techniques cover almost all of it, and none of them requires any tooling beyond the chart you already use.

First, plot the raw condition as its own series. Not the arrows, not the shapes, not the entries — the underlying boolean, in a separate pane, as a line that is either up or down. Arrows hide things; a plotted condition does not. You will immediately see whether the condition is on far more often than it should be, or whether it turns on mid-bar and off again, which no arrow-based display will ever show you.

Second, replay it bar by bar. Every serious charting platform has a bar-replay mode. Step forward one candle at a time through a stretch that contains several signals and watch when the plot changes. A repaint is obvious here and effectively invisible everywhere else: the condition turns on inside a forming bar and then turns off when the bar closes, or a past signal moves as you advance.

Third, hand-check a handful of signals against the candles. Pick five or six across different conditions — a trending stretch, a sideways stretch, a gap, and the left edge of the chart. For each one, count back the bars yourself and verify the level. This is tedious and it is the step that catches off-by-one indexing, because an indicator that is systematically one candle early looks perfectly reasonable until you count.

There is a clean line between a tool that shows you something and a system that acts. Generated code that highlights bars matching a condition you specified is a labour saving device; you still read the chart and make the decision. Generated code that decides and executes is a system, and a system built from output you cannot fully audit is a system nobody is accountable for. That is a bad place to arrive at by accident, and it is very easy to arrive at by accident, one convenient addition at a time.

Be equally sceptical of the second-order use: asking the model to improve a condition until the historical chart looks better. This is curve-fitting with a conversational interface. Every parameter tweaked in response to how history looks is a parameter fitted to that history, and the process is so frictionless that you can do in an afternoon what used to take weeks of self-deception.

There is a language trap worth naming too. Ask a model whether your indicator is good and it will tell you it looks reasonable, because agreement is its default posture. Ask it which bar index a reference resolves to and it has to produce something specific and checkable. Keep every question about generated code in the second form, and the whole exercise stays honest.

Used inside those limits, this is genuinely one of the strongest applications of AI for a trader. Writing a clean scan by hand takes hours if you code occasionally, and the language barrier stops a lot of people from testing ideas they could otherwise examine. Getting to a checkable draft in minutes is real. It is just that the minutes you save on writing get spent on auditing, and that trade is the point, not a tax on it.