AI as Your Pair Programmer

AI can feel like a shortcut around learning. Used well, it is closer to a pair programmer: useful beside your judgment, risky in place of it.

An AI assistant is a tool that responds to ordinary-language requests by predicting useful text, code, explanations, or edits. A pair programmer is a second developer working beside you while you still own the decisions. Treat AI like a sharp second chair at the workbench: it can hand you tools quickly, but it should not decide what you are building.

Where AI fits in the workflow

Your modern Python workflow already has a shape: understand the task, make a small change, inspect the diff, run checks, then commit or ask for review. AI fits between those steps, not above them.

Good places to use it:

• Before coding: ask it to restate a vague task, list edge cases, or point out files that might matter.
• While coding: ask for a first draft, a small refactor, or a clearer name for a messy function.
• While reading: ask it to summarize unfamiliar code, explain a traceback, or translate dense library docs into plain language.
• After coding: ask it to review your diff, suggest missing tests, or find places where your explanation and code disagree.

AI is most useful when there is a concrete artifact to inspect: a function, a traceback, a test failure, a pull request, or the Git diff habit you practiced in Working with Changes.

The weak workflow is "AI, build this whole project." The strong workflow is "Here is the goal, here is the file, here is the failing test, suggest the next small change." You keep the steering wheel. AI gives options.

What AI is genuinely good at

AI assistants are strongest when the work has patterns. Much of programming is pattern-shaped: naming a function, writing a test skeleton, converting one data shape into another, explaining an error message, or remembering the usual command shape for a tool.

Use AI for:

• Boilerplate, the repetitive setup code around the interesting part, such as a test class, a CLI argument parser, or a docstring outline.
• Translation, turning "I need a list of players sorted by score" into a rough Python shape you can read and improve.
• Explanation, especially when you paste a traceback, a small function, or a confusing condition.
• Alternatives, such as "show me two simpler ways to write this loop" or "what trade-offs am I missing?"
• Review prompts, where you ask it to look for unclear names, untested branches, or code that violates your project's style.

An autocomplete is an assistant feature that suggests code as you type. A chat assistant is a conversation-style tool where you ask questions or request edits. Autocomplete is fast and tied to the code near your cursor; chat is better when you need a plan, an explanation, or a comparison.

The practical trick is to ask for the smallest useful unit. A five-line helper function is easy to judge. A 500-line generated file is where beginners lose control.

Where AI fails

AI assistants do not understand your project the way a responsible developer does. They predict likely answers from patterns, plus the context, the files and text the tool is allowed to read.

Think of context as the desk surface. If the right notebook, test file, or project rule is on the desk, the assistant can use it. If it is still in a drawer, the assistant may guess.

A hallucination is a confident answer that sounds real but is false. In programming, that can look like an invented package option, a method that does not exist, a security rule stated backward, or a command copied from a different tool. A hallucination is like a polished map with a road drawn through a lake: the lines look professional, but you still cannot drive there.

Common failure modes:

• It invents APIs, flags, filenames, or error causes.
• It ignores project constraints unless you state them or the tool can read them.
• It optimizes for code that looks plausible, not code that is tested.
• It may copy a bug from nearby code if that bug looks like a pattern.
• It can miss security, licensing, privacy, or performance risks.
• It can give stale product advice, especially for fast-moving tools and services.

This is why AI output belongs in the same review path as your own code. Read it. Run it. Test it. Compare it against project commands. If the assistant says "this should work" and your test says it does not, believe the test.

Setting up tooling without overfitting to today's UI

You will see tools such as GitHub Copilot, Claude, and AI integrations inside editors. Use them as examples, not as a permanent ranking. Names and menus change; a sensible setup flow looks like this:

1. Install or enable the assistant in the editor or app where you already work.
2. Sign in with the account your school, company, or personal project expects.
3. Choose what the tool can read: current file, open tabs, selected text, terminal output, Git diff, or the whole workspace.
4. Review whether it can make edits directly or only suggest them.
5. Keep secrets, tokens, private data, and production credentials out of prompts unless your organization explicitly approves that workflow.
6. Learn how to turn suggestions off when you need quiet focus.

Workspace permissions are settings that control what files and project information an assistant can access. More context can produce better help, but broader access also raises privacy and noise concerns.

Start with one editor integration and one chat assistant. More tools do not mean better judgment. They often mean more notifications.

A sane first AI workflow

Here is a workflow that keeps you in charge:

1. Write the goal in your own words before asking AI.
2. Give the assistant the smallest relevant context: the function, error, test, or diff.
3. Ask for a plan or explanation first when the area is unfamiliar.
4. Ask for one small edit, not a full rewrite.
5. Read every changed line.
6. Run the same checks you would run for human-written code: tests, formatter, linter, type checker, and any project-specific commands.
7. Commit only work you can explain.

That last step is the professional line. If you cannot explain what the generated code does, it is not ready for your repo. You learned in Testing Fundamentals that tests preserve examples. With AI in the loop, tests also preserve your independence.

AI is now part of the developer's workshop, like formatters, linters, debuggers, tests, Git, and CI. The next lesson turns from "where it fits" to "how to ask": prompts that generate, explain, refactor, debug, test, and document without handing away your judgment.

Checkpoint ✦

Answer all three to mark this lesson complete