The New Pair Programmer
You already code with AI every day. Nobody taught you how. This course teaches the part that will still matter in ten years: directing, reviewing, and verifying.
Welcome to AI-Assisted Development 🦾
If you write code in 2026, you almost certainly write it with an AI tool at your elbow: Copilot finishing your lines, a chat assistant explaining errors, maybe an agentic tool like Claude Code or Cursor editing whole files while you watch. You use these tools every day. Odds are, nobody ever taught you how.
Here is the shift this course is built on: memorizing syntax is a dying skill. Directing, reviewing, and verifying AI output is the durable one. The developers who thrive are not the ones who type the fastest. They are the ones who can tell a tool exactly what to build, spot the flaw in what comes back, and prove the result works before it ships.
The journey ahead:
- Under the hood (this module): what these tools actually are and why they fail
- Briefing and context: getting buildable requests and the right information in front of the tool
- Reading, failure modes, and verification: the review skills that catch real bugs
- Debugging, agents, and boundaries: advanced workflows and professional guardrails
- Capstone: one realistic feature, end to end, with planted bugs you must catch
You need beginner-level reading skills in JavaScript or Python. That's it.
Here is the metaphor this whole course runs on.
The AI is a fast, overconfident contractor. You are the general contractor who signs off on every wall before the drywall goes up.
The contractor is genuinely skilled: works at superhuman speed, has seen a million buildings, never gets tired. But the contractor also has habits you cannot ignore:
- Starts building immediately, even when the blueprint is one vague sentence
- Never says "I'm not sure": every wall goes up with total confidence, straight or crooked
- Optimizes for looking finished, not for being right
A general contractor who signs off on walls without inspecting them isn't managing the build. They're just hoping. And hope is not a quality process.
Your job in every AI-assisted session comes down to three verbs:
- Direct: describe the work precisely enough that a fast, literal-minded builder can't wander off
- Review: read what was built before it becomes part of your codebase
- Verify: prove it works by running and testing it, not by admiring it
Every module in this course sharpens one or more of those verbs.
Based on this lesson's thesis, what do AI coding tools actually replace, and what do they leave squarely on your plate?
- AThey replace much of the typing and recall of syntax; they do not replace deciding what to build, reviewing the output, or verifying it works
- BThey replace the need to understand code, since the tool understands it for you
- CThey replace testing, because generated code has already been checked by the model
- DThey replace nothing; they are autocomplete with better marketing
Let's calibrate expectations, because both hype and dismissal will cost you.
Realistic (these happen every day):- A working first draft of a function in seconds, from a good description
- A clear explanation of an unfamiliar error or a legacy file
- Tedious transformations done in bulk: renaming, converting formats, writing boilerplate
- "It knows my whole codebase." It knows what it can see, which is usually a small window (Module 3 is entirely about this).
- "If it compiles, it's correct." Plausible and correct are different properties. The gap between them is where every bug in Module 5 lives.
- "It will tell me when it's unsure." It won't. Confidence is the house style, at every level of correctness.
The professional posture is neither "the AI is magic" nor "the AI is useless". It is: the contractor is fast and talented, and every wall still gets inspected.
A classmate says: "I asked the assistant to write my project's database layer and it compiled first try, so that part of the project is done." Which expectation from this lesson are they getting wrong?
- AThey are treating "it compiles" as "it is correct", skipping review and verification entirely
- BThey are wrong to use AI for database code, which these tools cannot produce
- CNothing; compiling on the first try is strong evidence the code is production-ready
- DThey should have asked the tool to confirm it was unsure about anything first
One more calibration: what happens when you skip the direct step and toss the contractor a one-line wish?
You: Add dark mode to my app.
Agent: I've implemented dark mode! I added a ThemeContext with a
toggle in the navbar, converted your color values to CSS variables
in globals.css, and persisted the choice to localStorage.
All 14 files updated.Fourteen files. Notice what the tool did NOT do: it did not ask which styling system you use, whether the designer has dark palette tokens, or where a toggle belongs in your UI. A vague request has a hundred valid interpretations, and the tool doesn't pick "ask for clarification". It picks one interpretation, silently, and builds it at full speed.
That is the signature move of the overconfident contractor: unstated decisions, confidently executed. Sometimes its guesses match your intent. When they don't, you now own a 14-file diff you have to review or throw away. Module 2 teaches you to make the decisions yourself, up front, in the brief.
A developer sends this one-liner to an agentic coding tool with access to their repo. Based on how these tools handle underspecified requests, what is the most likely outcome?
Add user notifications to the app.- AA plausible multi-file implementation built on unstated decisions: the tool picks the notification types, storage, and UI placement itself
- BA list of clarifying questions and no code changes until the developer answers them
- CA refusal, because the request does not specify enough detail to act on
- DAn error, because agentic tools require a file path in every request
- Syntax recall is a dying skill; directing, reviewing, and verifying AI output is the durable one. That is this course's thesis.
- The AI is a fast, overconfident contractor; you are the general contractor who signs off on every wall before the drywall goes up.
- The three verbs of the job: direct (specify the work), review (read what came back), verify (prove it works).
- Realistic: fast drafts, explanations, bulk tedium. Mythical: "it knows my codebase", "compiles means correct", "it will flag its own uncertainty".
- Vague requests get unstated decisions, confidently executed, not clarifying questions.
Next: the single fact that explains almost every strange behavior these tools have. They don't understand your code. They predict it.