← Emberlern/The Data Diaries With Dee
How to Be a Top-Notch Data Analyst / Module 08

Working with AI without losing the plot

Five lessons, about 55 minutes. AI will draft your SQL, your formulas, your Python — the skill this module teaches is catching what it gets confidently wrong.

Module 8 worksheets Real AI-drafted SQL and Excel formulas, some correct and some confidently wrong — practice catching the difference, plus a three-way reconciliation template. One .docx, five pages.
Lesson 8.111 minutes

What language models are genuinely good and bad at in analysis

An AI tool is excellent at pattern-completing syntax — drafting a plausible SQL query, a plausible Excel formula, a plausible pandas snippet, instantly, from a rough description. It is not reliably good at knowing whether that syntax is correct against your specific schema, your specific data's quirks, or the business rule Chidi actually meant.

Genuinely strong atDrafting syntax fast, explaining unfamiliar code, suggesting approaches you hadn't considered, catching typos in code you show it.
Unreliable atKnowing your actual schema without being shown it, knowing which of two plausible interpretations of a vague request is right, catching its own logical errors, admitting uncertainty unprompted.

The tool is fast and confident regardless of whether it's right. Confidence was never the signal to trust — checking always was, and that hasn't changed.

Keep this
  • Use AI for drafting speed and explanation, not as a substitute for verifying correctness against your actual data.
  • Confident-sounding output is not evidence of correct output — this was true before AI tools and remains true now.
Lesson 8.212 minutes

Drafting SQL and formulas with AI, then proving them correct

An AI-drafted query for "total revenue by branch this month" might genuinely be perfect — or it might quietly omit the VOID filter from lesson 3.2, or join to promotions the naive way from lesson 3.3. It reads exactly the same either way: clean, confident SQL.

A drafted query, and the check it needs

AI drafts: SELECT branch_id, SUM(revenue) FROM transactions GROUP BY branch_id;

This is syntactically correct and will run without error. It is also missing the transaction_type filter entirely — a mistake this whole course has spent modules 3 and 4 training you to catch. The AI didn't know Sahara Mart has VOID rows unless told; it drafted the most generic reasonable-looking version of the question.

The discipline: treat every AI-drafted query or formula exactly as you'd treat one copy-pasted from a stranger online — plausible until independently checked against a small, known-correct case you can verify by hand.

Keep this
  • An AI-drafted query is often missing context it was never given — like a VOID filter it didn't know existed.
  • Check any drafted formula or query against a small case you can verify by hand before trusting it at scale.
Lesson 8.311 minutes

The three-way reconciliation: a habit that catches invented numbers

Before trusting any AI-assisted number that's going to Chidi, check it three ways: does it match a rough mental estimate, does it match a simpler alternative calculation, and does it match what a small manual sample of the raw data shows?

The three checks, worked
  1. Sanity check. Nine branches, roughly ₦4M each per month feels right for revenue — does the AI-assisted total land in that ballpark, or is it off by an order of magnitude?
  2. Cross-check with a different method. If a pandas script and an Excel SUMIFS both compute the same total independently, agreement between two different tools built two different ways is real evidence of correctness.
  3. Spot-check against raw rows. Pull five real transactions for one branch by hand and confirm they sum to something consistent with the reported total's implied average.

Three independent checks that agree is genuinely strong evidence. One AI-generated number that merely looks plausible is not evidence at all — it's a guess dressed in confident formatting.

Keep this
  • Reconcile any important AI-assisted number three ways: a sanity estimate, a second method, and a manual spot-check.
  • Agreement between independently-built checks is real evidence; a single plausible-looking output is not.
Lesson 8.410 minutes

Using AI to explain someone else's query, model or macro

This is the use case AI tools are genuinely most reliable at: given a query, formula, or script you didn't write, ask it to explain what the code actually does, step by step. You're not trusting it to be correct about the business — you're using it to shortcut reading unfamiliar syntax, which is a much lower-stakes, more verifiable task.

Still verify the explanation, lightly

Even here, check the explanation against a small piece of actual output — if it claims a query filters out VOID transactions, confirm that by looking at the actual WHERE clause yourself, rather than trusting the paraphrase blind. It's usually right about mechanical explanation; it's worth the ten seconds to confirm anyway.

Keep this
  • Explaining unfamiliar code is a strong, low-risk use for AI — much safer than trusting it to write new logic unchecked.
  • Still spot-check the explanation against the actual code, briefly, rather than trusting the paraphrase blind.
Lesson 8.511 minutes

What must never be pasted into a chatbot, and why it is your problem

Sahara Mart's raw transaction data likely contains nothing individually sensitive — but a customer loyalty export with names, phone numbers and purchase history is a different matter entirely, and pasting a sample of it into a public AI chat tool to "just check the formula" is a real data exposure, not a hypothetical one.

A safe substitute habit

Instead of pasting real customer rows to debug a VLOOKUP, build three or four fake rows with the same column structure and plausible-but-invented values, and debug against those. The formula logic is identical; the actual data never left your machine.

"It's just for a quick formula check" is exactly how sensitive data ends up somewhere it was never supposed to be. The habit of building a small fake sample takes thirty extra seconds and removes the risk entirely.

Keep this
  • Never paste real customer, financial, or employee data into a public AI tool, even for a "quick check."
  • Build small fake sample data with the same structure to debug against instead — same logic, no exposure.
Before the drill

The worksheet pack has the AI-drafted queries you'll be reviewing — open it before you start.

Module 8 drillabout 45 minutes

Find the three errors

The worksheet pack contains ten AI-drafted SQL queries and Excel formulas against Sahara Mart's data. Seven are correct. Three contain real errors of exactly the kind this module named — a missing filter, a fan-out join, a wrong aggregation choice, a sign error, or similar.

  1. Identify all three flawed ones. Don't assume the count is evenly distributed between SQL and Excel.
  2. For each, state the business consequence — not just "this is wrong" but what wrong number it would produce and what decision that could mislead.
  3. Write the corrected version of each.
  4. For one of the seven correct ones, write the three-way reconciliation check you'd still run before trusting it for something that actually mattered.
What this drill is really testing

Whether you can catch an error in code you didn't write, under the exact condition that makes it hardest — when the code looks completely reasonable and runs without any error message at all. This is the daily reality of working alongside AI-assisted drafting, and it's precisely the skill the rest of this course has been quietly building toward.

Before module 9

Module 9 turns to communicating findings — including how to present a number you've verified this carefully without burying Chidi in the verification process itself.