Coding with AI: the analyst's assistant

AI has collapsed the cost of writing analysis code. An economist who can describe an analysis clearly can now get runnable Python in seconds, without the years of practice that used to be the price of entry. That is a genuine unlock — and a trap. Code that runs is not code that is correct. This module is about being productive fast and staying honest: fast enough to automate the tedious parts of your month, sceptical enough that you never ship a number you have not checked.

AI coding help comes in two families. Chat assistants — ChatGPT, Claude, Gemini — take a description of the task and a sample of your data, and hand back a script you run yourself. In-editor assistants live inside your code editor: GitHub Copilot autocompletes and chats inside VS Code, and Cursor is an AI-native editor that can see your whole project and edit across files. For an analyst starting out, the fastest on-ramp is a chat assistant plus a notebook — Jupyter, or Google Colab, which runs in the browser with nothing to install. For the two libraries you will live in — pandas for data manipulation and matplotlib for visualisation — AI is an excellent pair-programmer, because both are large, stable, and heavily represented in every model's training data.

Prompt patterns that produce runnable code

The model cannot see your file, your column names, or your Python version unless you tell it. Ask vaguely and you get generic code that breaks the moment it meets your actual data. A good code prompt carries five things:

• The goal in one plain sentence: 'Compute the average monthly lending rate for each bank.'
• The data: paste the first few rows (the output of df.head()) and df.dtypes, so the model knows the exact column names and types rather than guessing them.
• The environment: 'Python 3.11, pandas 2.x, matplotlib, running in a Jupyter notebook.'
• The output you want: 'Return a DataFrame with one row per bank, sorted by average rate descending, plus a bar chart.'
• The constraints, including the awkward cases: 'Do not drop any bank. If a bank is missing some months, average over the months it has and tell me explicitly how you handled it.'

import pandas as pd

# rates.csv columns: bank, month, lending_rate
df = pd.read_csv('rates.csv')

# What did we actually load? Check this BEFORE computing anything.
print(df.shape)                          # (rows, columns)
print(df['bank'].nunique(), 'banks in the file')

# Average lending rate per bank, keeping every bank
avg = (
    df.groupby('bank')['lending_rate']
      .mean()
      .sort_values(ascending=False)
      .reset_index()
)
print(avg)

# Count in, count out: the output must have one row per bank
assert len(avg) == df['bank'].nunique(), 'A bank went missing during aggregation'

Never run code you cannot explain

This is the non-negotiable rule of coding with AI: if you cannot say what a line does, you cannot tell when it is wrong. The fix is not to avoid AI — it is to make the same model teach you the code it just wrote, because reading that explanation is where the learning actually happens. Being productive with AI's help is not the same as knowing Python; when you want to close that gap for good, LeadAfrik's Python for Economists course is built to take you from AI-assisted to genuinely fluent. Until then, never run what you cannot explain.

Explain this pandas code to me line by line, as if I am an economist who is strong on statistics but new to Python. For each line, tell me two things: what it does, and what would happen to my results if that line were wrong or removed. Be specific about how it handles missing values, and tell me plainly whether any rows or groups get dropped.

[paste the code here]

Debugging: hand over the whole picture

When code throws an error, the traceback is the most useful thing you own — and beginners instinctively hide it, pasting only the last line or a screenshot. Do the opposite. Give the model the full traceback (the whole stack, not just the final line — it shows where the failure started), the exact code that produced it, and what you expected to happen. With those three, a model will usually name the root cause and the fix in one pass. With only 'it does not work', it guesses.

I am getting an error running this pandas code and I do not understand it.

What I expected: a table of the average lending rate per bank.
What happened instead: the traceback below.
Environment: Python 3.11, pandas 2.1, Jupyter notebook.

--- CODE ---
avg = df.groupby('Bank')['lending_rate'].mean()

--- FULL TRACEBACK ---
Traceback (most recent call last):
  File '<stdin>', line 1, in <module>
  ...
KeyError: 'Bank'

Give me the root cause in one sentence, then the one-line fix, then how to avoid this class of error next time.

Automating the monthly report

The highest-return use of AI for a working analyst is turning a manual, repeated task into a script. If you rebuild the same lending-rate summary by hand in Excel every month — download the CSV, delete the header junk, compute five aggregates, paste them into a table, redraw the chart — that is an afternoon a month you can get back. Describe those manual steps to the model and ask for a single script that does them end to end, saving the matplotlib chart to a file. Next month you change the filename and re-run. But there is a sting in the tail: automate a wrong calculation and you now produce the wrong number every month, faster and with more confidence. So the first time, you run the new script and your old manual process side by side and confirm they agree to the decimal. Only then do you trust it.

Running is not correct: the four failure modes

• Invented functions. The model calls a method that simply does not exist — df.average_by(), a made-up pandas function that 'sounds right'. You get an AttributeError. Annoying, but at least loud: the code refuses to run, so you know at once that something is wrong.
• Deprecated APIs. It reaches for an old argument or method that has been removed or changed in current pandas — the classic is df.append(), gone since pandas 2.0. Loud if the call was removed outright; quietly wrong if the behaviour merely changed under the same name.
• Runs, but computes the wrong thing. The code executes cleanly and returns a number — the wrong number. It averaged the wrong column, or took a mean of monthly means when the honest figure is a weighted average, or double-counted rows in a merge. Nothing errors. The result simply is not what you asked for.
• Silently drops rows. The quiet killer. A merge on the wrong keys, a stray dropna(), or a groupby on a column that contains missing values discards data without a word. The script runs, the table looks tidy, and three banks have vanished.

• Count in, count out. Print df['bank'].nunique() before and len(result) after. If a groupby that should give 12 banks gives 9, stop and find the missing three before you read a single number.
• Re-compute one value by hand. Pick one bank, average its rates in Excel or on a calculator, and confirm it matches the code's figure to the decimal.
• Look for missing data first. Run df.isna().sum() before aggregating, so you know how many values are missing, in which column, and whether missing-value handling even matters here.
• Read the assumptions out loud. Find every dropna(), merge, and groupby, and say what each does to rows with missing or duplicated values. If you cannot, ask the model to explain exactly those lines.
• Sanity-check the extremes. Sort ascending and descending and eyeball the top and bottom rows. A Kenyan commercial lending rate that is negative, zero, or 400% is a bug, not a finding.