Chapter 1: What changes, what does not
An AI coding assistant is a very fast, very well-read junior engineer with no memory of yesterday, no stake in the outcome and no way of knowing whether what it just wrote is true. Every useful practice in this course follows from taking that description seriously.
What got cheaper
Producing code. Boilerplate, adapters, test scaffolding, migrations, one-off scripts, the fourth CRUD endpoint that looks like the other three: these now cost minutes instead of hours. This is real and it is the reason the tools are worth adopting.
Reading unfamiliar code. Asking "what does this module do and where is it called from?" and getting a reasonable answer in thirty seconds changes how you approach a legacy codebase.
Exploring alternatives. Generating three implementations of the same function and comparing them is now cheaper than writing one by hand. Design by comparison becomes practical.
Translation between layers. OpenAPI spec to client, SQL schema to TypeScript types, a paragraph of requirements to a first draft of acceptance tests. Anything that is mostly a mechanical mapping is a good candidate.
What got more expensive
Review. You are now reading far more code than you write, and code you did not write is harder to review than code you did. The assistant produces plausible output, and plausible is exactly the property that makes mistakes hard to spot.
Knowing what you want. When typing was the bottleneck, vagueness was cheap: you discovered the requirements by writing the code. When generation is instant, vagueness is expensive, because the assistant will confidently fill every gap with a guess.
Keeping the codebase coherent. Ten engineers each generating locally optimal code produce a codebase with ten styles, three HTTP clients and no shared conventions. Coherence has to be engineered on purpose (Module 3 covers how).
Accountability. "The AI wrote it" is never an acceptable sentence in a post-mortem, a security review or a conversation with a customer. Somebody merged it. That person is the author.
What does not change
Three responsibilities remain with the engineer in every version of this technology we have seen:
- Deciding what to build. Intent, scope, trade-offs, and the word "no". The assistant will build whatever you describe, including the wrong thing.
- Judging whether the result is right. Correctness, security, performance, fit with the rest of the system. A model can help you check, but it cannot be the final check, because it has no access to the truth outside the text it was given.
- Owning the outcome. Production incidents, data leaks, licence violations and broken promises land on a human name.
If you remember one thing from this chapter: the assistant changes how you work, not what you are responsible for.
Three failure modes you will meet in the first week
| Failure mode | What it looks like | The check that catches it |
|---|---|---|
| Confident fabrication | A library function that does not exist, a flag that was removed two versions ago, a test that asserts the wrong thing with a reassuring name | Run it. Compile it. Read the actual documentation for anything you did not already know. |
| Scope drift | You asked for a bug fix and received a refactor of three files, a renamed interface and a new dependency | Diff size and file count against the request. Reject anything you did not ask for, even if it looks good. |
| Local optimum | The code is correct in isolation but duplicates a helper that already exists, ignores the project's error-handling convention or bypasses the auth middleware | Grep before you accept. Ask the assistant "does something similar already exist in this repository?" before you ask it to write anything. |
None of these are exotic. All three show up in the first week. All three are caught by the same habit: verify before you trust, and verify with something other than the model that produced the output.
A short vocabulary
- Assistant - any tool that generates or edits code from natural language: inline completion, chat, or an autonomous agent.
- Agent - an assistant that can take several steps on its own (read files, run commands, edit, re-run) before coming back to you.
- Context - everything the model can see when it answers: your prompt, the open files, the rules you configured, the output of commands it ran. Models do not see your repository; they see their context.
- Verification - any check whose result does not depend on the model: compiler, tests, linter, a human reading the diff, a production metric.
Summary
- Generation got cheap; review, intent and accountability got expensive.
- Three responsibilities stay human: deciding, judging, owning.
- The three everyday failure modes (fabrication, scope drift, local optimum) are all caught by verification that is independent of the model.