Introduction to AI coding assistants: prompts, review and tests.

What a coding assistant is

A coding assistant is a language model trained on huge amounts of code and text that proposes code from a description and from the context you give it. There are three ways to use one, which differ in how much it does on its own:

All three share one property: the code they produce is plausible. It looks like code that would solve the problem, with reasonable names and convincing comments. Often it is also correct. But the model does not know your data, does not know at what time your signal is traded and has not run your backtest. Whatever you do not tell it, it decides without warning.

In trading this has a concrete cost. A normal programming error usually breaks something: an exception, an empty chart. A look-ahead error (lesson 0.1.1) breaks nothing: it produces a better backtest. It is the error that is hardest to see and the one that loses the most money, because it is convincing.

Lesson 0.1.3 set three rules for using assistants. They still stand, and this lesson explains the reason behind the second one:

1. Level 0 without an assistant. You write the code for the exercises yourself. You can ask a chat conceptual questions. This lesson does not change that: it teaches you to judge generated code, which is exactly what you cannot do without knowing how to write it.
2. After that, the AI proposes and you decide: first the test, then the code, a full read, tests and commit.
3. Nothing sensitive in the prompt: no keys, no data under a restrictive license, no personal data.

The rest of the lesson is a complete case, of the kind that happens every day.

A case: the signal the assistant proposes

A user asks a chat, with no further context:

Write a pandas function that gives a buy signal when the 20-session moving average of the closing price has a positive slope. I want a smooth average with no lag.

The prices are those of SINT, the course's fictional ETF:

import pandas as pd

precios = pd.read_csv("sint_diario.csv", parse_dates=["fecha"],
                      index_col="fecha")
cierre = precios["cierre"]
rent = cierre.pct_change().fillna(0)
print(len(cierre), "sessions;", cierre.index[0].date(), "to",
      cierre.index[-1].date())

1303 sessions; 2021-01-04 to 2025-12-31

The answer, with the typical look of an assistant's output (docstring, clear names, a comment that justifies the decision):

def senal_pendiente_ia(cierre: pd.Series,
                       ventana: int = 20) -> pd.Series:
    """1 if the moving average rises, 0 otherwise.

    A centered average is used to remove the lag."""
    media = cierre.rolling(ventana, center=True).mean()
    return (media.diff() > 0).astype(int)

The user does what lesson 0.1.1 taught: shifts the position one day so that it trades after the signal, and measures the result against buy and hold:

def backtest(senal: pd.Series) -> pd.Series:
    """Daily return; the signal at the close is traded the next
    day."""
    posicion = senal.shift(1).fillna(0)
    return posicion * rent

def resumen(r: pd.Series) -> str:
    total = (1 + r).prod() - 1
    sharpe = r.mean() / r.std() * 252 ** 0.5
    return f"total {total:+7.1%}   Sharpe {sharpe:5.2f}"

r_ia = backtest(senal_pendiente_ia(cierre))
print(f"{'Assistant':<20}", resumen(r_ia))
print(f"{'Buy and hold':<20}", resumen(rent))

Assistant            total +324.1%   Sharpe  2.10
Buy and hold         total  +43.5%   Sharpe  0.48

A Sharpe above 2 with a moving average, on an asset that over the same period stays at 0.48. The curve in the header figure (in amber) rises with almost no pullbacks. This is the moment to be suspicious: a rule this simple should not beat the market like that, least of all on an asset with a 25% drawdown in 2022.

The highlighted line is the problem: center=True. By default, rolling labels each window with its last day: the average for June 3 uses the 20 closes that end on June 3. With center=True, the label is the center of the window: the average for June 3 uses ten earlier closes, the close of that day and nine later ones. “No lag”, yes, because it looks into the future. You can check which days go into each window by replacing the prices with their position in the series:

pos = pd.Series(range(len(cierre)), index=cierre.index)
dia = pd.Timestamp("2024-06-03")
for centrada in (False, True):
    v = pos.rolling(20, center=centrada)
    primero = cierre.index[int(v.min()[dia])].date()
    ultimo = cierre.index[int(v.max()[dia])].date()
    print(f"center={centrada!s:<5}: from {primero} to {ultimo}")

center=False: from 2024-05-07 to 2024-06-03
center=True : from 2024-05-20 to 2024-06-14

With the centered average, the June 3 signal knows how the market closed up to June 14. Shifting the position one day does nothing: the future is already inside the signal, not in the lag. And nothing in the code gives it away at a glance; the comment even presents it as an advantage.

A test that detects it

Careful reading helps, but it does not scale: there are dozens of ways to sneak the future into a signal (center=True, shift(-1), filling gaps backwards with bfill, normalizing with the mean of the whole sample…). A test that does not depend on the form of the error is better. The idea: a day's signal cannot change when later data is added. If it is computed with the data up to a date and then with all the data, the signals for those dates must match:

def comprobar_sin_anticipacion(funcion, cierre: pd.Series,
                               cortes=(250, 500, 750, 1000)):
    completa = funcion(cierre)
    for n in cortes:
        parcial = funcion(cierre.iloc[:n])
        distintos = int((parcial != completa.iloc[:n]).sum())
        assert distintos == 0, (
            f"up to {cierre.index[n - 1].date()}: {distintos} signal "
            "days change when later data is added")

It is a function with simple assert statements: if the condition does not hold, it raises an error with the message. With pytest (lesson 0.4.5) it becomes a test that runs automatically before every commit. Applied to the assistant's function:

comprobar_sin_anticipacion(senal_pendiente_ia, cierre)

AssertionError: up to 2021-12-17: 9 signal days change when later data is added

Nine signals from December 2021 change when the closes after December 17 are added. The test knows nothing about centered averages: it only checks a property that every honest signal satisfies. That is why it also works for the next function an assistant proposes to you, whatever its error.

The fix is to remove center=True: each day's average uses that day and the 19 before it. It has lag, and that lag is the price of not knowing the future. The corrected version passes the test:

def senal_pendiente(cierre: pd.Series,
                    ventana: int = 20) -> pd.Series:
    """1 if the moving average (past data only) rises; 0 otherwise."""
    media = cierre.rolling(ventana).mean()
    return (media.diff() > 0).astype(int)

comprobar_sin_anticipacion(senal_pendiente, cierre)
print("No look-ahead")
r_ok = backtest(senal_pendiente(cierre))
print(f"{'Corrected':<20}", resumen(r_ok))

No look-ahead
Corrected            total   -8.9%   Sharpe -0.07

From +324% to −8.9%. The real strategy does not beat buy and hold; the assistant's never existed. The three curves in the header figure come from these cells. Notice that the corrected version is worse: a well-made test often worsens the result, because it removes a false edge. If your backtest improves after you fix an error, check twice.

The prompt that would have prevented it

The first prompt left the important decisions to the model. A better one gives the context, the data contract, the explicit time rule and the test it has to pass:

Context: daily backtest in pandas 3.0. cierre is a pd.Series of daily closes with a sorted date index and no gaps.

Task: a function senal_pendiente(cierre, ventana=20) -> pd.Series that returns 1 if the simple moving average of ventana sessions rises relative to the previous day and 0 otherwise, with the same index as cierre.

Time rule: the signal for day t may only use closes up to and including t. No center=True, negative shift, bfill or whole-sample statistics. The position is shifted outside the function.

It must pass this test: (paste comprobar_sin_anticipacion).

No new dependencies. Explain in one sentence what each line does.

This is what rule 2 of the course asks for: you write the test, beforehand, and the assistant receives it as part of the task. If the same assistant wrote the test and the function, the test could inherit the same misunderstanding. The last line, asking it to explain each line, guarantees nothing, but it makes the full read you have to do anyway easier.

With an agent: instructions and permissions

An agent does not receive a standalone prompt: it works inside the repository, reads files, runs commands and changes several files at once. That changes two things.

The first is context. What you would repeat in every prompt in a chat is written once in an instructions file in the repository, which the agent reads when it starts: CLAUDE.md in Claude Code, AGENTS.md in Codex and many others11Note 1 · Claude Code Docs, “Cómo Claude recuerda tu proyecto” (How Claude remembers your project, code.claude.com/docs/es/memory), and the open AGENTS.md format (agents.md), which lists the compatible agents; accessed October 21, 2026.. For the course project, a few lines are enough:

# ppt-curso project rules
- Python 3.14 with uv. Dependencies only with `uv add`, never pip.
- Signals: the value for day t uses data up to the close of t.
  The position is the signal shifted one day. Forbidden:
  center=True, negative shift, bfill and whole-sample statistics.
- Every new signal passes comprobar_sin_anticipacion (tests/).
- Before finishing: `uv run pytest`. Do not change a test to
  make it pass.
- Do not read or print `.env`. No keys in the code.

The line about tests is not decoration: an agent asked to “make the tests pass” can do it by changing the test instead of the code. That is why the diff is reviewed in full, tests included.

The second is permissions. An agent that runs commands can read any file you have access to, including .env. While you are learning: paper keys or none, work on a branch and changes that go in through a pull request, like yours (lesson 0.2.5). Never an agent with access to a real brokerage account.

What to review in generated code

When reviewing generated code for trading, this list covers the most common errors:

Exercises

1. Without running it, say whether this signal has look-ahead bias and why; then check it with comprobar_sin_anticipacion: (cierre > cierre.mean()).astype(int).

def senal_sobre_media_total(cierre: pd.Series) -> pd.Series:
    return (cierre > cierre.mean()).astype(int)

try:
    comprobar_sin_anticipacion(senal_sobre_media_total, cierre)
except AssertionError as error:
    print("Look-ahead:", error)

Look-ahead: up to 2021-12-17: 115 signal days change when later data is added

2. An assistant fills the gaps in a price series with cierre.bfill(). Why is that look-ahead? What would you replace it with?

3. Write, without sending it, the prompt you would give an assistant for a function that computes the annualized 20-session rolling volatility from cierre. Include context, contract, time rule and at least one test.