Preparing an error to be fixed

a minimal reproduction instead of a pile of detail

What it is

Article 3.5 says how to word a fix request. This one is about what to gather before writing it.

The difference matters: a well-worded request with poor evidence will not help. And good evidence is not "as much as possible" but the opposite: the smallest case on which the error still reproduces.

What it looks like in code

The error showed up in a bot: the /stats command crashes sometimes. Here is what you do with it before calling the AI.

Step 1. Reproduce it

An error you cannot repeat cannot be fixed — its fix cannot be verified. If a command crashes "sometimes", you have to find out on which data.

for user_id in [1, 2, 3, 17, 42]:
    try:
        build_stats(user_id)
    except Exception as e:
        print(user_id, "->", type(e).__name__, e)

Three lines of iteration often turn "crashes sometimes" into "crashes on user 17".

Step 2. Trim it

Now remove everything from the case that has no bearing. Telegram, the database, the handlers — if the error reproduces without them, they are not involved.

# Minimal case: no bot, no database
rows = [{"date": "2026-10-01", "amount": 100},
        {"date": "", "amount": 50}]
print(build_stats_from_rows(rows))     # crashes

A trimmed case is doubly valuable. It points at the cause more precisely, and it gives you a ready test: it is exactly what you later ask to be turned into pytest (article 3.9).

Step 3. Gather three things

And only now — the request, using the template from article 3.5.

What to tell the AI

Trimming the case can be done with the AI too; it is good at that:

Here is a function and the data it crashes on. Shrink the data
to the smallest example on which the error still reproduces.
Don't fix the code, I only need the example.

When the error is intermittent:

This function crashes about one time in five, on the same
arguments. What can cause inconsistent behaviour?
Name the three most likely.

Inconsistency almost always means one of three things: an external source (network, time, random numbers), shared state between calls, or parallel execution. The AI will name them, but checking is on you.

What not to hand over

The whole file when the function would do. Extra context spreads attention thin — yours and the AI's.

A day of logs. What is needed is the chunk around the error: a few lines before and a few after.

Secrets. Tokens, keys, users' personal data. Before sending a log, check what is in it (article 4.2).

Your diagnosis instead of the facts. "I think the problem is in the database" leads the AI astray if the guess is wrong. Facts separately, guesses separately — and mark the guesses as guesses.

What to look for

An error "fixed" that never reproduced. If you could not reproduce it before the change, you cannot verify that it is gone. Reproduction first, fix second.

The minimal case not kept. Trimmed it, fixed it, threw it away — and a month later, on a similar error, you start over. A trimmed case is worth turning into a test right away.

The symptom fixed instead of the cause. The pairing of articles 2.12 and 2.13: the crash site and the cause are different places.

The fix not checked against the original case. The most galling outcome: fixed, tests green, and that very user 17 still crashes it.

Cheat sheet