⚙️ Productivity & Craft · Chapter 3
Using AI without outsourcing your thinking
AI makes a competent engineer much faster and a learning engineer much slower — unless you change how you use it.
Study this lesson free in the app →
The basics
Using AI well means treating an assistant like ChatGPT or Claude as a reviewer, explainer and sparring partner — not as the thing that does your thinking while you are still learning.
The problem it solves: AI makes a competent engineer much faster and a learning engineer much slower. Paste the answer every time you're stuck and you skip retrieval — the act of pulling something from memory, which is how memory forms. Three months later you have a working project and an interview you can't pass.
The mental model: a satnav versus a taxi driver's map of the city. Experienced drivers use satnavs constantly and are faster for it — because they have the map underneath and can tell when the satnav is wrong. AI is the satnav; the interview tests the map.
The discipline: try for 10 minutes → ask for a hint, not the answer → solve it → ask for a critique → rewrite from memory tomorrow.
Words you must know 4
- Recognition vs recall
- following a solution you're shown versus producing one from nothing. Interviews test recall.
- Hallucination
- a confident, invented fact: a pandas parameter or config key that never existed. Wrong parts look exactly like right parts.
- Verification cost
- how cheaply you can check an answer. AI is strongest where checking takes seconds.
- Blast radius
- how much damage a wrong answer does; it decides how much review the output deserves.
Explained
You're stuck on a window function. You ask an AI, get correct SQL in four seconds, paste it, and move on.
You saved fifteen minutes and learned nothing — because you never retrieved anything from memory, and retrieval is the entire mechanism by which memory forms.
Do that for three months and you will have a working project and an interview you cannot pass. The tool isn't the problem. When you reach for it is.
The satnav and the taxi driver
Give someone a satnav on day one and they will drive the city competently for years without ever learning it. Take the satnav away and they're lost at the second junction.
A London cab driver spends years building the Knowledge — the map in their head. Slower to acquire, and they can reroute around a closure instantly, judge whether a suggested route is nonsense, and answer a question the satnav wasn't asked.
The useful part: experienced drivers use satnavs constantly. It makes them faster. The difference is that they can tell when it's wrong, because they have the map underneath.
AI is the satnav. The interview tests the map.
When to reach for it
The ten-minute rule is the whole discipline. Struggle then assistance produces learning; assistance instead of struggle produces dependence.
Where AI genuinely earns its place
Strong — use it freely:
- Explaining someone else's code — "walk me through what this 200-line Spark job does"
- Reviewing your work — "what edge cases does this validator miss?" It's better at critiquing than creating
- Boilerplate you already understand — a Dockerfile skeleton, argparse setup, a test scaffold
- Being the interviewer — "ask me system design questions about a ride-hailing platform, one at a time, and push back on weak answers." This is the highest-value use in the whole lesson
- Rubber-ducking — explain your bug to it. Half the time you solve it mid-sentence
- Translating between dialects — "the Snowflake equivalent of this Postgres query"
Weak — verify everything:
- Specific API surfaces. It will confidently invent a Pandas parameter that has never existed
- Anything version-dependent. Library behaviour changes; training data is frozen
- Performance claims. "This is faster" without a benchmark is a guess in a confident voice
- Numbers, thresholds, costs. Plausible and frequently wrong
The reliable test: it's strongest where you can verify the output in seconds — run the code, read the explanation against docs. It's weakest where verification is expensive, which is exactly where a wrong answer costs the most.
The invented parameter
You ask for help reading a large CSV efficiently. You get:
df = pd.read_csv("rides.csv", low_memory=False, engine="pyarrow",
dtype_backend="pyarrow", chunk_optimize=True)It looks entirely plausible. Three of those are real. chunk_optimize does not exist and never has.
You paste it, get TypeError: read_csv() got an unexpected keyword argument 'chunk_optimize', and lose twenty minutes trying to work out which package version has it. There is no such version.
This is the failure mode to internalise: the wrong parts look exactly like the right parts. There's no hedging, no uncertainty marker, no visible seam. A model that's right 90% of the time and indistinguishably wrong 10% of the time is dangerous precisely because of the 90%.
The defence is cheap and non-negotiable: run it, or check the docs. If neither is possible, treat it as a hypothesis rather than an answer.
Two learners, same tool
Both spend three months on the same curriculum with the same AI assistant.
A asks for the solution whenever stuck, reads it, understands it, moves on. Ships a big project fast.
B tries for ten minutes first, asks only for hints, then asks the AI to critique the working solution. Ships a smaller project.
Both genuinely understand their code when they read it.
Prompts that teach instead of solve
✗ "Write a SQL query to dedup ride events keeping the latest."
✓ "I need to dedup keeping the latest row per ride. I think I need
ROW_NUMBER but I'm not sure where the filter goes. Don't give me
the query — tell me what concept I'm missing."
✗ "Fix this code."
✓ "This returns 0 rows and I expected ~1000. Here's my query and a
sample of the data. What are the three most likely causes, in order?"
✗ "Explain Kafka consumer groups."
✓ "Here's my understanding of consumer groups: [your explanation].
What's wrong or missing?"
✓ "Act as a senior data engineer interviewing me. Ask one system design
question about a ride-hailing platform, wait for my answer, then
challenge the weakest part of it. Don't be generous."
✓ "Here's my working solution. What edge cases does it miss? What would
break at 100x volume? Don't rewrite it — just list the problems."The pattern in every good one: you supply the thinking, it supplies the pressure. The third prompt is the most under-used — stating your understanding and inviting correction is retrieval practice with a tutor attached.
Using it at work, honestly
Once you're employed the calculus changes — shipping matters more than learning, and AI is genuinely a large productivity gain. Three rules keep it from becoming a liability:
1. You own the output. "The AI wrote it" is not a defence in a post-mortem. If you can't explain a line, it doesn't go in the PR — that's the same bar as code copied from Stack Overflow, and it always has been.
2. Mind what you paste. Production data, credentials, customer records, unreleased schemas — check your organisation's policy before any of it goes into a third-party tool. This is a real disciplinary issue at real companies, not a hypothetical.
3. Verification scales with blast radius. A throwaway script: run it, done. A migration touching a production table: read every line, test on a copy, have someone else review. The cost of a wrong answer decides how much checking it deserves.
And the durable version of the skill: learn to write the prompt that produces a verifiable answer. "Give me three approaches with the trade-off of each" beats "give me the answer", because you can evaluate three options against your own context — which is the part no model has.
Words to know
| Retrieval practice | Recalling from memory — the mechanism by which memory strengthens. Reading an answer bypasses it. |
|---|---|
| Hallucination | A confidently stated, entirely invented fact — an API, parameter or number that never existed. |
| Recognition vs recall | Understanding something you're shown, versus producing it from nothing. Interviews test recall. |
| Verification cost | How expensive it is to check an answer — the thing that should decide how much you trust it. |
| Blast radius | How much damage a wrong answer causes; determines how much review it deserves. |
| Rubber-ducking | Solving a problem by explaining it aloud; works with a duck, a colleague or a model. |
| Prompt for critique | Asking what's wrong with your solution rather than asking for a solution. |
In two minutes
- While learning, struggle first: retrieval forms memory, and reading an AI's answer skips it.
- Ten-minute rule: try alone, then ask for a hint, then a critique of your working solution.
- Test learning by rewriting yesterday's solution from memory; recognising it isn't knowing it.
- AI is strongest at explaining code, critiquing your work, mock interviews and boilerplate you understand.
- It is weakest at exact APIs, version-specific behaviour, performance claims and numbers — verify those.
- Hallucinations look identical to correct output, so run it or check the docs; scale checking with blast radius.
- At work you own every line you merge, and you never paste secrets or production data into third-party tools.
Test yourself
1. You're stuck on a query. What is the highest-learning move?
- Ask for the solution and read it carefully
- Try 10 minutes, then ask what concept you're missing
- Skip it and come back next month
- Copy a similar query from an old project
Show the answer
Try 10 minutes, then ask what concept you're missing — Struggle followed by a hint produces retrieval; a handed-over solution produces recognition, which feels like learning and isn't.
2. Where is an AI assistant genuinely strongest?
- Recalling exact library parameters
- Critiquing a solution you already wrote
- Estimating performance numbers
- Choosing your architecture
Show the answer
Critiquing a solution you already wrote — Critique is its best mode and the least used. It's weakest on exact API surfaces and any number it can't verify.
3. Generated code uses a parameter that doesn't exist. What does that tell you?
- The model is broken
- Wrong output is indistinguishable from right output — always verify specifics
- You used the wrong version
- It only happens with rare libraries
Show the answer
Wrong output is indistinguishable from right output — always verify specifics — There's no uncertainty marker on the invented parts. Being right most of the time is exactly what makes the exceptions dangerous.
4. What is the honest test of whether you learned something?
- You understood the explanation
- You can rewrite it from memory the next day
- It ran without errors
- You bookmarked it
Show the answer
You can rewrite it from memory the next day — Recognition is not recall. If you can't reproduce it without the material, you recognised it — which is what an interview will expose.
5. Which is a genuine professional risk, not just a learning one?
- Asking for boilerplate
- Pasting production data or credentials into a third-party tool
- Asking it to explain unfamiliar code
- Using it for a mock interview
Show the answer
Pasting production data or credentials into a third-party tool — Data leaving your organisation's boundary is a policy and compliance issue at real companies — check before you paste.
6. Which prompt is most likely to make you better at SQL, not just finish the task?
- 'Write a query to get each rider's latest ride.'
- 'Fix this.'
- 'Here's my attempt with ROW_NUMBER — it returns duplicates. Don't rewrite it; what am I missing?'
- 'Give me 10 SQL queries to memorise.'
Show the answer
'Here's my attempt with ROW_NUMBER — it returns duplicates. Don't rewrite it; what am I missing?' — You supply the thinking and the model supplies pressure. The first two outsource the retrieval; memorising queries builds recognition, not the skill of producing one.
There are 11 questions, 3 puzzles and 7 recall cards for this lesson in the app — the recall cards come back on later days, just before you would forget.
Start this lesson →