Set up reasoned pair programming with explicit personal rules and no-go zones so that assistance never turns into dependency.
Open this lesson in KodokonThe professional risk of permanent assistance has a name in human factors: automation complacency. Airline pilots know it well - the more reliable the automation, the less the human checks, and the more their manual skills silently erode. For a developer, the symptom is precise: you accept suggestions that are longer and longer, reviewed less and less, and the day the AI is unavailable or wrong on some subtle point, you discover you no longer know how to do it on your own. The countermeasure isn't abstinence: it's an explicit usage contract, written down in black and white, that you impose on yourself.
The central rule of this contract fits in four words: I type, it reviews. You write the code yourself, in a first draft, without assistance; the AI only steps in afterward, as a reviewer. This reversal changes everything: the effort of production - the one that builds and maintains skill - stays with you, and the AI contributes what it does best, an exhaustive, tireless look at your work. It's the exact opposite of the dominant reflex (have it generate, then review vaguely), which inverts the cognitive load: the model produces, and you inherit the hardest role, judging code you didn't think through.
You are a senior code reviewer, demanding but supportive. I just wrote this code myself and I want a review that helps me improve, not a rewrite.
Context: [LANGUAGE, project constraints, what the code is supposed to do].
[PASTE YOUR CODE]
Review rules:
1. NEVER rewrite the code in full, not even a complete function.
2. Classify each remark: likely bug / production risk / readability / style.
3. For each likely bug, describe the exact input scenario that triggers it, WITHOUT giving the fix - I want to find it myself.
4. End by asking me about a design choice I made that seems questionable to you.
Format: numbered list, the most serious remark first. Maximum 8 remarks.Second clause of the contract: no-go zones. Define in advance the parts of the project where the AI never writes a single line, whatever the circumstances. Three categories are essential. First, security-critical code - authentication, session management, cryptography, data migrations - where a plausible but wrong answer costs too much. Next, the business core, the logic that makes your product valuable: that's what you must know intimately. Finally, and this is the least intuitive, any first contact with a new concept: if you let the AI write your first Mutex, your first saga or your first worker, you'll never truly learn it. In these zones, the AI keeps a role: explaining, questioning, reviewing. Never producing.
You are my pair programming partner in navigator mode: you guide, I drive. I'm stuck on this problem:
[DESCRIBE THE PROBLEM + paste the error message or the relevant snippet]
Absolute rules:
1. Forbidden to give me code longer than one line.
2. Proceed with Socratic questions: help me form hypotheses, then design the test that verifies them.
3. If I head in the wrong direction, say so clearly and explain why, but let me find the right one.
4. When I've found it, ask me to restate the root cause in two sentences, and correct my wording if it's imprecise.
Start by asking me what I've already tried and what I concluded from it.Last clause: measurement. A contract with no metric doesn't survive six weeks. The right metric isn't the volume of prompts, it's your comprehension debt: the number of code blocks committed to the repo this week that you couldn't rewrite from memory or explain in detail. Keep this count honestly, every Friday. If it rises two weeks in a row, tighten the contract: widen the no-go zones, go back to strict "I type, it reviews". The ultimate test stays the same as in aviation: turn off the automation one day a week, and observe what you can still do.