The trap: what you must never hand over
Lesson 7 of 12
7The trap: what you must never hand over
The last part is not about a tool, it is about you: four real traps, dependence, plausible invention, the invented package, and the responsibility that stays in your name, plus a seven-question personal protocol to leave this track with.
What the picture shows: Four questions in order: do you understand it, did you run it, does the package really exist, and would you put your name on it.
Map of this part
The concepts in order, click any one to jump to it:
Two ways into the same idea
The assistant writes fast, but you are the one who signs the work. Like an accountant using a machine: if the machine errs, the accountant answers to the owner. This lesson gives you short questions to ask yourself before accepting any code you did not write.
Common traps: code you do not understand, invented or untrusted dependencies, leaked secrets, and tests that test nothing. The protocol is seven questions: can I explain it? did I run it? does the test fail when I break it? does every package exist? is there a secret in it? is the licence fine? can I maintain it?
Required fundamentals
Parts 1–6
You have seen a tool write, run and get things wrong. This part turns what you saw into a habit.
Honesty with yourself
The one hard question here: how many files in your project can you not explain? The honest answer is where the cure starts.
A real project in front of you
The protocol at the end of this part is read once and used at every merge. Try it on the last change you wrote.
Core concepts
Not using the tool a lot, but merging what you cannot explain. Skill does not atrophy from speed; it atrophies from skipping the understanding step. The test is simple: close the assistant and explain the file out loud.
The model generates likely text, not correct text. And because flatten() is entirely plausible next to flat(), it will write it with total confidence. The confidence in an answer's tone is never an indicator of its correctness.
The most dangerous form of invention: a package name that does not exist. Anyone watching those names can publish a real package under one, so your install becomes a stranger's code running on your machine. Verify every new package name before installing.
The commit is in your name, the review is in your name, the production outage is in your name. “The assistant wrote it” is not a professional sentence. And with it: never paste secrets or user data into any chat, and know your company's policy before sending private code.
Hand over typing, review logic, and never hand over defining correctness or the decision to merge. This whole track has been practice for that one line.
How it works
Diagram 1, The dependence loop: notice it closes on itself, and the only exit is outside the loop
Diagram 2, The handover line: what you delegate, what you review, and what stays yours alone
Trap two with real output, then the protocol
Let us make trap two concrete. Four pairs of functions: in each pair one exists in JavaScript and one merely looks like it does. Try to guess before you read the output:
$ node probe.js
[1,[2,[3]]].flat(2) -> [1,2,3]
[1,[2,[3]]].flatten() -> TypeError: [1,[2,[3]]].flatten is not a function
"7".padStart(3, "0") -> "007"
"7".padLeft(3, "0") -> TypeError: "7".padLeft is not a function
Object.fromEntries([["a",1]]) -> {"a":1}
Object.toEntries({a:1}) -> TypeError: Object.toEntries is not a function
[3,1,2].toSorted() -> [1,2,3]
[3,1,2].sortBy(x => x) -> TypeError: [3,1,2].sortBy is not a functionflatten, padLeft, toEntries and sortBy are all good names, and some exist in other languages or in well-known libraries. The model is not “lying”; it is completing a plausible pattern. Which is exactly what makes the bug invisible in a visual review.The practical exercise: audit your project in three steps
The protocol you leave this track with
Seven questions, ninety seconds, before every merge. Pin it where you can see it, or put it in your AGENTS.md:
Before you merge - seven questions (90 seconds) 1. Can I explain every line in one sentence? No -> do not merge 2. Did I run it myself and see the output? No -> run it 3. Is there a check that fails if I break the code? No -> write it 4. Did I test the edges: empty, missing, wrong type? No -> test them 5. Does every function and package called exist? No -> verify 6. Did I send no secret and no user data? Sent -> report it now 7. Would I sign this with my name? No -> do not merge
Myth vs. reality
| The myth | The reality |
|---|---|
| “If the model explains confidently, the answer is right.” | Tone and reality are unrelated. padLeft is explained with total confidence and does not exist. |
| “Using an assistant weakens my skill.” | What weakens it is merging what you do not understand. Use with understanding expands it faster than any book. |
| “I'll just ask the model: are you sure?” | The confirmation is generated the same way. Evidence is a run or official documentation, not a second question. |
| “An invented package is just a typo.” | It is a door for a stranger's code to run on your machine. Always verify the name before installing. |
| “Responsibility is shared with the tool.” | The commit is in your name alone. There is no co-signature in the git log. |
| “Professionals do not need checklists.” | Professionals are the ones who use them: pilots and surgeons. A checklist protects against a bad day, not against ignorance. |
Try it yourself
The assistant wrote arr.flatten() and confidently explained that it flattens the array. First step?
A run or the documentation are the only two forms of evidence. The second option generates a confirmation the same way it generated the error, and the fourth turns a trivial mistake into a new dependency.
Which of these must never be handed to the assistant?
Because defining correctness expresses your intent and your contract with the user, and the merge decision carries your professional responsibility. The rest is typing and explanation, delegate freely and review the result.
Quick review flashcards
Check your understanding
1. In one sentence: what is the difference between “the model lies” and “the model invents”?
Lying requires intent and knowledge of the truth. The model has neither: it generates the most likely continuation of a text, so if an invented name looks more natural than the real one, it writes it. Which is why scolding it or asking for confirmation achieves nothing, running the code does.
2. Why is “are you sure?” not verification?
Because “yes, I'm sure” is produced by the same mechanism that produced the error: textual likelihood, not a check against reality. Worse, models tend to agree with the framing of your question, so your confidence grows while your information does not. Real verification lives outside the conversation: a run, or official documentation.
3. (Spot the bug) A teammate pasted a production error into a chat, and it contained an API key and a customer's email. What now?
Treat it as an incident, not a slip: the key is revoked and rotated immediately, your security and privacy owners are notified per your company's policy, and exactly what left is written down. Then fix the cause: a clear rule that messages are redacted before pasting. Assuming a chat is private is not a guarantee, and a secret that left is burned.
4. How do you use an assistant in a way that grows your skill rather than shrinking it?
Three habits: write the first version of anything conceptually new to you yourself, then ask how to improve it; ask for the explanation before the code whenever you do not know something (“explain the idea, then show me an example”); and treat every suggestion you accept as reading material rather than paste material. The assistant is an excellent teacher when you ask “why?”, and an obstacle to learning when you ask “give me”.
5. (Decision) Your company wants to measure the impact of these tools and proposes “lines merged” as the metric. Your answer?
That it measures the wrong thing and rewards the worst behaviour: whoever merges without understanding will top the list. Metrics closer to value: the share of changes that were reverted, time to fix an incident (because it exposes the code nobody understands), coverage by tests that actually fail when the code is broken, and reviewers' sense of how reviewable the work is. What is measured is reinforced, so measure understanding, not volume.
Resources for this part
Sorted by kind: start with the official docs when you want the precise reference, or with an article or video when you want the explanation first.