How to Build a TradingView Indicator With AI

AI can write a TradingView script, but we have to define the event each signal marks. On the Sunday stream, Fahad asked Claude to generate an indicator and explained that vague prompts produce vague outputs. Volume, liquidity and market structure need rules the code can test, not labels that merely look convincing on a chart.

Write the rules before the prompt. We would settle these questions first:

• Volume: Which data and period matter, and what counts as a meaningful change?
• Liquidity: Should the script mark obvious highs and lows, or an internal sweep before price reaches them?
• Market structure: What price behavior confirms the event we want marked?

These are questions for a trader to answer, not settings Fahad prescribed. He explained that price can reverse before reaching an obvious liquidity level. A prompt that recognizes only sweeps of major highs or lows would miss the distinction he was making.

The guide to building TradingView indicators with Claude also starts with describing the intended indicator to the AI. We would go further and write a rule we can check against a chart. Our earlier discussion of Bitcoin liquidity levels shows why naming a level differs from explaining how price interacts with it.

Claude generated a Pine Script version 5 indicator, while Fahad said TradingView usually runs version 6. We could identify that mismatch on the stream. We could not attribute every later error to it, especially after Fahad noticed an unexpected change during his attempts to correct the script. Checking the version was a start, not a full diagnosis.

Observed issue: v5 versus v6. Other errors: not identified on the stream. Fahad encountered code errors, requested corrections and then asked, 'What changed? I don't even know.' We cannot give that moment a tidy resolution the demonstration did not provide.

We would read the reported error and locate the line TradingView identifies. Before pasting a revision into the editor, we would compare it with the previous script and check whether it still measures the event in the prompt. Quieting the editor does not help if the signal has changed.

Pine-specific AI coding tools can help generate and revise scripts, as LuxAlgo's Pine Script coding guide describes. Fahad's demonstration showed the limit of that help. Claude could revise the code, but Fahad still had to decide whether the revision preserved his idea.

Copying each Pine Script error into a chatbot can trap a beginner in repeated corrections without resolving the cause. Fahad estimated that the loop could take 5 to 10 attempts. We took a simpler lesson from the demonstration: read the fault, inspect the last change and establish what a suggested repair does before requesting another one.

'If you don't understand the errors, you'll just keep doing copy, paste, copy, paste,' Fahad said. An earlier edit had changed something he did not expect. Pasting the next error back to Claude would not, by itself, explain that change.

• Read the error: Note its message and the line TradingView identifies.
• Find the cause: Inspect the surrounding code and the last revision, not only the named line.
• Check the revision: Compare the scripts and see whether the original signal rule still holds.

Fahad compared debugging to diagnosing a medical problem. Removing something near the pain does not prove you found its cause. Likewise, an error line tells us where to investigate, not necessarily which code to replace.

That is how we approach using AI in trading strategies. The tool can speed up drafting. The trader still has to understand what the code does.

A script that compiles has passed a code check, not a trading test. Fahad said he had made around 25 indicators and excluded many because they lacked practical use. He called Hit Point Wave his best current creation because it automates parts of his CMM process. We would judge a new script's signals separately from whether it runs.

Compiling script: The editor accepts the code. Useful signal: We can explain what it marks and assess whether that information helps with a market decision. Those are different checks.

Fahad described Hit Point Wave as assessing momentum, buyer and seller aggression, absorption, divergence and possible continuation or reversal. He also distinguished an internal sweep from a sweep of an obvious major high or low. The difficult part is deciding which behavior matters before asking code to mark it.

He said indicator accuracy can vary from 60 to 65% to 90 to 95%. He did not present those figures as verified results for an AI-generated script. 'Six months of 100% accuracy? Never,' he said. That is a sound reason to question a signal history that looks too clean.

Our footprint delta guide on false signals deals with the same problem. We want to know what an alert detects, when it can mislead us and what it adds to the chart.

A signal would not have changed the conditions Fahad described in BTC on Sunday. Bitcoin was grinding sideways with low volume and little liquidity, so he favored planning over forcing a trade. We kept his downside levels conditional: 77,000 if the discussed volume range failed, then 74,000 if 77,000 also failed.

'The market is missing its two drivers here: liquidity and volume,' Fahad said. He gave no fresh BTC entry, despite discussing where price might go if the range gave way.

Fahad's conditional Bitcoin read from the Sunday stream

Fahad thought momentum was more likely to develop on Monday or Tuesday. He gave no precise boundary for the volume range, or an entry and stop for either downside scenario. The chart below marks a viewer's 84,800 long entry on BTCUSDT 15-minute candles. That was the viewer's position, not a fresh entry Fahad endorsed.

Our earlier look at Bitcoin range trading with small risk covers the patience a range demands. On this stream, Fahad chose to leave a quiet Sunday alone.