An AI assistant can now read a codebase, trace a feature through five layers, write the change, run the tests and draft the pull request. That is not a prediction; it is what happened while this series was being written, and every post shows the session it came from. What it has not changed is who answers for the result. When the code ships, the name on the merge is yours.
This series is about working well under that arrangement. It follows one real feature, on one real app, from the ticket to an open pull request, and at every step it asks the same two questions: what is the assistant good at here, and what do you still have to do?
What actually changes
The obvious change is speed of typing, and it is the least interesting one. A competent engineer was never bottlenecked on keystrokes. The real change is in the shape of the work: you spend less time producing a first draft and much more time judging one.
Before, a typical feature went: understand the code, decide what to build, write it, test it, review someone else's version of the same thing. Now the middle part is mostly delegated, and the two ends grow. Understanding and deciding become more important, because the assistant will build exactly what you described, including the parts you described badly. Reviewing becomes most of the job, because there is far more code to review, and it was written by something that does not get tired, does not get bored, and does not know when it is guessing.
That last point is the one to hold on to. An assistant is fluent in a way that makes wrong answers look as finished as right ones. A human colleague who is unsure tends to write hesitant code and say "I'm not sure about this bit". A model can be unsure and still produce clean, confident, well-commented code. The confidence of the output tells you nothing about its correctness. Only reading it does.
What does not change
Responsibility does not transfer. "Claude wrote it" is not an answer in an incident review, any more than "the compiler accepted it" was. If you merge it, you own it, which means you must be able to explain every line of it to a reviewer without opening the chat log.
Judgement does not transfer either. The assistant can tell you that a ticket is ambiguous and list the questions; it cannot decide what the product owner meant. It can propose three designs; it cannot know which one your team will still be happy with in a year. Those decisions stay with people, and this series is explicit every time one comes up.
And the fundamentals still matter, arguably more. You cannot review a SQL query you could not have written, or spot a race in async code you do not understand. Engineers who skip learning the basics because "the AI knows it" end up unable to tell when it does not.
The new split of the job
A useful way to think about it: the assistant is a very fast, very well-read junior engineer who has never seen your codebase before every session, never pushes back unless asked, and never says "I don't know" on its own. You are the senior engineer pairing with it. Concretely, that splits the work like this:
- The assistant reads code quickly and widely, drafts plans, writes the change, writes tests, runs commands, and summarises what it did.
- You decide what to build, approve the plan, read every diff against that plan, check its claims, run the thing, and own the decision to merge.
The habits that separate engineers who get faster from engineers who get sloppier all live on the second line. The fast ones give the assistant clear context and a written plan, keep each change small enough to read, and verify claims instead of trusting summaries. The sloppy ones paste a ticket, skim the summary, click Accept, and find out in production what the diff actually said.
The feature this series follows
Every example comes from the pizza ordering app used across this site: a Spring Boot backend and a React frontend, with Stripe for payments. Its own project notes listed one open item: customers can save cards on their profile, but checkout never offers them. So that became the ticket.
PIZZA-42: As a signed-in customer, I want to pay with one of my saved
cards at checkout so I don't have to type my card every time.
That one sentence turned into an analysis of the existing payment flow, nine questions for the product owner, a seven-step plan, three backend commits, three frontend commits, a Playwright suite, a pull request and a review. The posts follow it in order:
- Read before you accept: the habit the rest of the series depends on
- Setting the assistant up with the context a codebase needs
- Analysis, requirements and planning, before any code exists
- Writing code and tests in small, verifiable steps
- Debugging, investigating AWS, and walking through the UI
- Pull requests, code review and customer support
- Guardrails, and a capstone that runs the whole thing end to end
All of it uses Claude Code, the terminal-based assistant. If you have never installed it, the setup guide covers that; this series assumes it is installed and focuses on how to work with it.
Honest numbers
Since every session in this series really ran, it is worth being concrete about what that looked like. The analysis of the existing checkout, which traced eleven hops from the button to Stripe and back with a file and line number for each one, took the assistant under two minutes. Checking eight of those claims by hand took longer than producing all of them. That ratio is typical and it is the point: the assistant's time is cheap, and yours goes on verification. Budget for it.
The sessions were also not flawless, and the posts do not pretend otherwise. The assistant wired in a dependency "for later" that nothing used. It wrote a test expecting a different status code than the plan said and flagged the change, correctly, but a reader who skimmed would never have noticed. It reported four failing tests as "probably not mine" and could not prove it; proving it took one command. Each of those is small. The habit of catching them is not.
Before you accept
Every post ends with this section: what to read and check before you take the assistant's work for that step. For the series as a whole, it is this:
- Can you explain every line you are about to merge without the chat open? If not, read more.
- Did you decide what was built, or did you accept the assistant's defaults without noticing they were decisions?
- Did you check at least one claim in the summary against the code, rather than trusting it?
- Is the change small enough that you actually read it, rather than scrolled it?
- If this breaks at 2am, are you comfortable being the one who is paged for it?