Sign in to keep reading
“AI Fluency” is free with an account. Your progress and bookmarks follow you across devices.
Sign in to continueNEW: ML Mock & Coaching with a 20+ year experience coach. Save $20 on sessions for Premium.ML Mock & Coaching now available
NEW: ML Mock & Coaching with a 20+ year experience coach. Save $20 on sessions for Premium.ML Mock & Coaching now available
Directing the tool rather than following it — what to establish before your first prompt, why a good prompt is mostly transcription, and how to recover from a confidently wrong generation.
“AI Fluency” is free with an account. Your progress and bookmarks follow you across devices.
Sign in to continueThe First Sixty Seconds
Could you answer these today? Tick what you already know.
Fluency Drills
Drill 1 — Find the intent. On an unfamiliar file, four minutes, no AI: write down what the code claims it does, sourced from docstrings, names, and tests. Then look for the gap. This is the reading pass, isolated.
Drill 2 — Transcribe, do not compose. Take a bug you have already diagnosed and write the prompt you would have sent. Notice how much of it is just your diagnosis restated.
Drill 3 — The first-bad-generation rule. For one week at work: when a generation is wrong, stop, read it, and say aloud what is wrong before touching the keyboard. This is the habit that has to survive interview pressure, and it only forms by repetition.
Drill 4 — Count the unread lines. Record a 45-minute session and rewatch it, counting lines you accepted without reading. That number is your fluency score, and it is almost always higher than you expect.
Fluency is not enthusiasm for AI and it is not knowing the newest model. It is the narrow, testable question of whether you can direct the tool — point it at the right thing, get back what you asked for, and recognise immediately when you did not.
It is decided early. In both sessions you read, the outcome was largely determined by what happened in the first four minutes.
The most common fluency failure is pasting the file into chat before reading it. It feels efficient, and it hands the interviewer their answer in the first minute: this candidate outsources orientation.
But "read the code first" is uselessly vague as advice. What you are doing in those four minutes is building the one thing the model cannot have — a statement of what the code is supposed to do, against which what it does can be compared.
Go back to the rate limiter. The reading pass produced exactly one load-bearing fact:
"""Token bucket. capacity tokens max, refill_rate tokens per second."""
Per second. And _refill adds refill_rate flat, with no reference to elapsed time. The bug is the gap between the docstring and the arithmetic.
That is the general shape. Intent is almost always written down somewhere — a docstring, a test name, a field name, a type — and the defect is the distance between the stated intent and the implementation. So the reading pass is a hunt for statements of intent, not a general skim.
| Where Intent Hides | ||
|---|---|---|
| Source | What it tells you | On the rate limiter |
| Docstrings and comments | What the author believed they were building | refill_rate is per second — the whole bug |
| Names of fields and functions | Units, ownership, and intended lifecycle | last_refill implies elapsed time matters somewhere |
| Test names | Behavior someone thought worth protecting | Reveals which cases are already covered |
| Type hints and defaults | ||
Silence during the reading pass looks like being stuck. Narrating it looks like method.
"Let me read this properly before I touch anything — I want to know what it's supposed to do before deciding what it's doing wrong."
Interviewers rarely object to this, and several report it as the moment they decided a candidate was senior.
| Expected shapes and ranges |
| tokens as int vs float decides whether partial refills survive |
| The diff or git history | What changed most recently, and why | Recent edits are where fresh bugs live |