11  11. AI-Assisted Development: From Chatbots to Coding Agents

In just a few years, AI help for programmers grew from chatbots that write snippets into coding agents that work inside your project. This page explains what changed, what makes a tool an “agent”, and the habits that separate careful AI-assisted work from guesswork. It also explains why the rest of this book teaches the command line, Git, and the web.

11.1 From chatbots to coding agents

As of Oct 6, 2026 · Official docs: Claude Code overview

AI help for programming comes in four stages. Each stage lets the AI see more of your project and do more on its own. The stages overlap in time (GitHub Copilot’s autocomplete appeared in 2021, before ChatGPT was released in late 2022), and all four are still in use today.

Stage	What the AI sees	What the AI does	Your job
1. Chat, copy, paste (e.g. ChatGPT, claude.ai)	Only what you paste into the chat	Writes code in a chat window	Copy the code into your files, run it, paste any errors back
2. Autocomplete (e.g. GitHub Copilot)	The file you are typing in	Suggests the next line or function as you type	Accept each suggestion (usually with Tab) or ignore it
3. AI editors (e.g. Cursor)	Many files in your project	Proposes changes across several files	Accept or reject each change, then run and test the code
4. Coding agents (e.g. Claude Code)	Your whole project, plus the output of the commands it runs	Reads files, edits them, runs commands such as tests, checks the results, and repeats	Give clear instructions, decide what it may do without asking, review the result

The big jump is stage 4. In stages 1-3, you run the code, read the error, and report back to the AI. An agent closes that loop itself. Today, many editors and chat apps include agents too; the next chapter, The AI Coding Tool Landscape, surveys the current tools.

11.2 What makes a tool an agent

As of Oct 6, 2026 · Official docs: How Claude Code works · Glossary

An agent is an AI system that can take actions, look at what happened, and decide what to do next. A coding agent has three ingredients:

1. A large language model (LLM) that reads the situation and decides the next step (see How Large Language Models Work).
2. Tools: actions the model is allowed to request, such as “read this file”, “edit this file”, “run this command”, or “search the web”. The model only asks; the program around it carries out the action and sends back the result.
3. A loop: the model keeps choosing actions and reading the results until the task is done or it needs your input.

 You: "The signup test is failing. Please fix it."
         |
         v
 +-> The model decides the next step ---------> Tool call: run the tests,
 |                                              read a file, edit a file ...
 |                                                      |
 +---- The result goes back to the model <--------------+
          (repeat until done, then report back to you)

The program that wraps the model, supplies its tools, runs them, and manages what the model sees is called the harness. As Anthropic’s glossary puts it, Claude Code is the harness and Claude is the model inside it. Asked to “fix the failing tests”, Claude Code might run the test suite, read the error output, search for the relevant files, read them, edit the code, and run the tests again to verify the fix. You can interrupt and redirect it at any point.

Because an agent runs real commands on your computer, it needs rules about what it may do without asking you. In Claude Code these rules are called permission modes (see Permissions, Modes, and Safety).

11.3 Vibe coding vs. AI-assisted engineering

As of Oct 6, 2026 · Official docs: Best practices for Claude Code

In February 2025 the AI researcher Andrej Karpathy coined the term vibe coding: you describe what you want, accept whatever the AI writes without reading it (“forget that the code even exists”, in his words), and judge the result only by whether the app seems to work. He called it “not too bad for throwaway weekend projects” (background).

Vibe coding is fine for a quick experiment. For anything other people will use, it is risky: nobody understands the code, nothing checks that it is correct, and security holes go unnoticed. AI-assisted engineering keeps the speed but adds discipline:

	Vibe coding	AI-assisted engineering
What to build	The AI fills in the gaps	You write it down first (a spec)
Reading the code	Rarely	You review every change
“It works” means…	It seemed fine when you clicked around	Tests and other checks pass, and you tried it yourself
Safety net	Hope	A Git commit after each working step
Good for	Throwaway prototypes, exploring ideas	Anything real: class projects, products, client work

11.3.1 Spec-driven development

A spec (short for specification) is a short document that says what to build before any code is written: who it is for, what it must do, what is out of scope, and how you will check that it works. Product managers call a business-oriented version a PRD (product requirements document). In spec-driven development you write the spec first, then have the AI build from it one piece at a time. The Claude Code docs suggest a handy trick for larger features: ask Claude to interview you about your idea, then have it write the spec to a file such as SPEC.md.

Deeper dive: What a short spec looks like

A spec does not need to be long. Here is one for a small club app:

# Spec: Club Event Sign-up (version 1)

Who it's for: members and organizers of the Finance Club (about 60 people)
Problem: sign-ups happen in a group chat and get lost

Must have:
1. A page that lists upcoming events
2. A sign-up form for each event (name, email)
3. An organizer page, behind a password, that shows who signed up

Out of scope for now: payments, email reminders

Done means:
- A new sign-up appears on the organizer page
- The form rejects an email address without an @
- Visitors who are not organizers cannot see the sign-up list

Notice the last section: each line is something you (or the agent) can actually check. That is what turns “build me an app” into work an agent can verify.

11.3.2 Context engineering

A model only knows what is in its context window, the text it can see at once (see How Large Language Models Work). Context engineering means choosing that text on purpose: the spec, a project instruction file (such as CLAUDE.md or AGENTS.md, which the agent reads at the start of a session), the files that matter, the exact error message, a screenshot. With too little context the AI guesses; with too much it gets distracted. The Claude Code docs warn that performance drops as the context window fills up. Anthropic’s engineers describe context engineering as curating “the optimal set of tokens” for the model (Effective context engineering for AI agents).

11.4 A disciplined workflow

As of Oct 6, 2026 · Official docs: Best practices for Claude Code

Whatever tool you use, careful AI-assisted work follows the same cycle. Anthropic’s advice for Claude Code is to explore first, then plan, then code, then commit, and above all to give Claude a way to verify its own work. This book uses five steps:

1. Plan. Decide what you want (write a spec for anything big). Let the agent read the relevant code and propose a plan before it changes anything, and correct the plan.
2. Build. Have the agent implement one small, well-defined step.
3. Verify. Give the agent a check it can run, such as tests, a build, or a screenshot of the page in a browser, and ask for the evidence (for example, the test output). Then try it yourself.
4. Review. Read the diff, the list of exact changes. Do you understand each change? Did it touch files it shouldn’t have? Did it “fix” a problem by hiding it?
5. Commit. Save the working step with Git, with a clear message, so you can always return to it. Then start the next step.

The more specific your request, the less you have to correct afterwards:

Vague request	Specific request
“make the signup page better”	“On the signup page, show an error under the email box when the address has no @. Add a test for this, run the tests, and fix any failures.”
“the build is broken”	“The build fails with this error: [pasted error]. Find the cause, fix it, and run the build again to confirm. Don’t just silence the error.”

Think of the AI as a very fast junior developer. It works quickly, knows a lot, and never gets tired. But it doesn’t know your unwritten requirements, it can be confidently wrong, and it sometimes takes shortcuts. Like a good manager, give it clear instructions and review its work. This is what people mean by keeping a human in the loop. And you remain responsible for everything you submit or ship: “the AI wrote it” is no excuse for a bug, a security hole, or an academic-integrity problem. The full Claude Code version of this workflow is in Working Effectively with Claude Code.

11.5 Benefits and limitations

Benefits	Limitations and risks
Speed: boilerplate, prototypes, and routine changes in minutes	Wrong but plausible: code that looks right but has subtle bugs, or uses functions and packages that don’t exist
A patient tutor: explains unfamiliar code, error messages, and frameworks	Security: insecure code, secrets (such as API keys) leaked into files, and agents tricked by instructions hidden in a web page or file they read (prompt injection)
Debugging help: reads errors and traces them to the cause	Missing context: the AI doesn’t know requirements that exist only in your head
The tedious parts: tests, documentation, commit messages	Cost: agents read many files and take many steps, so they use far more tokens (the units AI usage is measured in) than a chat answer. That shows up as usage limits on a subscription or as a bill on a pay-per-use plan.
Access: people who are not professional programmers can build working prototypes	Over-reliance: if you never read the code, you can’t fix it when the AI can’t

Hallucinations and privacy are covered in more depth in Limits, Risks, and Responsible Use, and legal questions in Legal and Ethical Questions About AI.

11.6 Why the command line, Git, and the web still matter

If an AI writes the code, why learn the basics? Because your job shifts from typing code to directing and checking the AI’s work, and you can’t check what you don’t understand. That is why this book is organized the way it is:

Part of this book	Why it matters when an AI writes the code
The Command Line (Bash)	Coding agents live in the terminal and run shell commands for you. Before you let one run rm -rf build, you should know what that does.
Git and GitHub	Git is your undo button and your review tool: it shows exactly what the agent changed and lets you return to any earlier version.
How the Web Works	To ask for a web app, and to spot a bad design, you need the vocabulary: front end, back end, database, API, hosting.
Claude: The Big Picture and Claude Code Essentials	How our main AI tool works, what it costs, and how to stay in control of it.

11.7 Key takeaways

• AI help grew from chat and autocomplete to AI editors and agents that read files, run commands, check the results, and repeat.
• Agent = LLM + tools + a loop. The program around the model is the harness.
• Vibe coding is fine for throwaway experiments. Real projects need a spec, verification, review, and Git.
• Work in small steps: plan, build, verify, review, commit.
• Treat the AI like a fast junior developer: clear instructions, careful review. You remain responsible for the result.

Practice Questions

Easy

Question 1 · Short answer

What three ingredients turn a large language model into a coding agent?

Suggested answer

1. An LLM that decides what to do next.
2. Tools: actions it can ask for, such as reading a file, editing a file, or running a command.
3. A loop: after each tool result, the model chooses the next step, until the task is done or it needs your input.

Question 2 · Matching

Match each stage of AI help with its description.

Stage		Description
1. Chat, copy, paste		A. Suggests the next line as you type; you accept or ignore it
2. Autocomplete		B. Reads files, runs commands, checks the results, and repeats until done
3. AI editor		C. Writes code in a chat window; you move it into your files yourself
4. Coding agent		D. Proposes changes across several files of your project for you to accept or reject

Suggested answer

1 → C, 2 → A, 3 → D, 4 → B.

Question 3 · Multiple choice

Which description best fits vibe coding?

1. Writing a detailed spec before asking the AI for any code
2. Accepting the AI’s code without reading it, and judging it only by whether the app seems to work
3. Using AI only for autocomplete, never for whole features
4. Having a classmate review every change the AI makes

Suggested answer

b. That is the definition Andrej Karpathy gave when he coined the term in 2025: “forget that the code even exists”. Option a is spec-driven development, the opposite approach. Option c describes a different, more limited stage of AI help (autocomplete). Option d is code review, a habit of disciplined AI-assisted engineering.

Question 4 · True or false

A coding agent can only suggest code. You always have to run the tests yourself and tell it the results.

Suggested answer

False. That describes the older chat and autocomplete stages. An agent has tools that let it run commands, such as the test suite, read the output, and fix what failed, all on its own (depending on its settings, it may ask your permission first). You still review the result and should try it yourself, but the agent can run the checks.

Question 5 · Fill in the blank

A short document that describes what to build (who it is for, what it must do, what is out of scope, and how to check that it works) is called a ________. A business-oriented version is often called a ________.

Suggested answer

A spec (specification). A business-oriented version is a PRD (product requirements document). Writing it first and then having the AI build from it is called spec-driven development.

Question 6 · Short answer

In the world of AI agents, what is a harness? Give an example.

Suggested answer

The harness is the program around the model. It supplies the tools, actually runs them, manages what the model sees (its context), and keeps the loop going. Example: Claude Code is the harness, and Claude is the model inside it.

Medium

Question 7 · Scenario

Sam pastes an error message into a chatbot, copies the suggested fix into his file, runs the program, gets a new error, and pastes that one back too. Which stage of AI help is this? What would be different with a coding agent?

Suggested answer

This is stage 1: chat, copy, paste. The AI sees only what Sam pastes, and Sam himself is “the loop”: he runs the code and carries every error back.

A coding agent works inside Sam’s project. It can read the relevant files itself, run the program or the tests, read the error, change the code, and run it again, repeating until the problem is fixed. Sam’s role becomes giving clear instructions and reviewing the result.

Question 8 · Ordering

Put these steps of the disciplined workflow in order: Commit · Verify · Plan · Review · Build

Suggested answer

Plan → Build → Verify → Review → Commit, then repeat for the next small step.

You decide what to build before any code is written. You verify before you review, so you don’t spend time reading code that doesn’t work. You commit last, so every commit is a working, reviewed step you can return to.

Question 9 · Rewrite the prompt

Users report that logging in with a correct password sometimes shows “Invalid password”. Rewrite this vague request so the agent knows exactly what “done” means: “fix the login page”.

Suggested answer

A model answer:

“Users report that logging in with a correct password sometimes shows ‘Invalid password’. Look at the login code and find the cause. First write a test that reproduces the problem, then fix the cause (don’t just hide the message), and run the tests until they all pass. Show me the test output and explain what was wrong.”

A good answer includes: the symptom, where to look (if you know), a check the agent can run (a test that first fails, then passes), what not to do (hide the error), and a request for evidence.

Question 10 · Multiple choice

Which of these is the best example of context engineering?

1. Asking the same question three times, hoping for a better answer
2. Pasting all 300 files of a project into one prompt, “just in case”
3. Giving the agent the spec, the exact error message, and the two files involved, and keeping standing project rules in an instruction file such as AGENTS.md
4. Choosing the AI tool with the biggest advertising budget

Suggested answer

c. Context engineering means deliberately choosing what the model sees: enough to do the job, without noise. Option b is the opposite mistake: too much irrelevant text fills the context window and distracts the model. Option a just retries without giving the model any new information, and option d has nothing to do with context.

Question 11 · Short answer

AI-written code is sometimes “wrong but plausible”. Give two ways this can happen and one habit that catches such errors.

Suggested answer

Ways it can happen (any two):

• The model produces likely-looking code, so it may call a function or install a package that doesn’t exist.
• It handles the normal case but misses edge cases (an empty form, a duplicate sign-up).
• It misunderstands a requirement you never wrote down.
• It “fixes” a symptom, for example by silencing an error, instead of the cause.

Habits that catch them: have the agent run tests (and write tests for edge cases), read the diff, and try the feature yourself before you commit.

Question 12 · Matching

Match each part of this book with the reason it matters when an AI writes the code.

Part		Why it matters
1. The Command Line (Bash)		A. Shows exactly what the agent changed and lets you go back to any earlier version
2. Git and GitHub		B. Gives you the vocabulary to describe and judge a web app’s design
3. How the Web Works		C. Lets you understand a command before you allow it to run
4. Claude Code Essentials		D. Teaches how our main agent works and how to stay in control of it

Suggested answer

1 → C, 2 → A, 3 → B, 4 → D.

Question 13 · True or false

If an AI wrote the code, the AI company is responsible for any bugs or security problems in your app.

Suggested answer

False. You chose to accept the code and to submit or deploy it, so you remain responsible for it, just as a manager is responsible for work they approve from a junior employee. That is why you plan, verify, and review before you ship.

Hard

Question 14 · Scenario

Maria vibe-coded a club event sign-up app over a weekend. It “works” when she clicks around. Now she wants to put it online and collect real members’ names and email addresses. List at least four risks and what she should do before launching.

Suggested answer

Risks (any four):

• Security holes: for example, anyone might be able to see the sign-up list or change it.
• Leaked secrets: an API key or database password may be sitting in the code, or in a public repository.
• Privacy: she is collecting personal data and is responsible for protecting it.
• Hidden bugs: edge cases (duplicate sign-ups, bad email addresses) were never tested.
• No way to fix it: she doesn’t understand the code, so she can’t repair it when the AI can’t.
• No safety net: without Git history she can’t undo a bad change.

Before launching: write a short spec, including who may see what; put the project in Git; have the agent explain the code and run a security review, and read the risky parts herself; add tests for the “done means” checks; move secrets out of the code; and test with fake data first.

Question 15 · Compare

When might autocomplete be a better choice than a coding agent, and when is the agent the better choice?

Suggested answer

Autocomplete is better when you are writing the code yourself and want small, fast suggestions: while learning a language, for small edits where you want full control, or when you want to understand every line as you type. It also uses far fewer tokens.

An agent is better for multi-step work: changes across many files, finding and fixing a bug by running tests, repetitive edits, or exploring an unfamiliar project.

The trade-off is control and understanding versus speed and autonomy. The more the AI does on its own, the more important verification and review become.

Question 16 · Long answer

“Now that AI writes the code, Git matters more than before.” Explain why you agree or disagree.

Suggested answer

Agree. An agent can change many files in a few seconds, so you need a reliable way to:

• See exactly what changed: git diff shows every line the agent touched.
• Undo: if a change goes wrong, you can return to the last good commit. Git records every change, no matter which tool or command made it.
• Work in small, safe steps: one commit per working step makes it easy to find which step broke something.
• Try ideas safely and collaborate: branches let you experiment, and pull requests let teammates review AI-written changes before they are merged.

Without Git, a confident but wrong agent can leave you with a broken project and no way back.

Question 17 · Scenario

The agent finishes and reports: “Done! All tests pass.” What should you check before you commit? Give at least four checks.

Suggested answer

Any four of:

1. Ask for the evidence: the command it ran and the test output.
2. Run the tests yourself.
3. Try the feature in the browser or app, including an edge case.
4. Read the diff and make sure you understand each change.
5. Check that it didn’t delete or weaken tests, or silence an error, to make them “pass”.
6. Check the scope: no unrelated files changed.
7. Check for secrets (API keys, passwords) and leftover debugging code.

Then commit with a clear message.

Question 18 · Find the problem

Sam types one request into his coding agent: “Build my whole online store with payments, user accounts, and an admin dashboard.” Two hours later he commits all 80 changed files at once with the message stuff. Identify at least three problems with this workflow and say how to fix each one.

Suggested answer

• No spec or plan. The AI had to guess what “online store” means. Fix: write a spec first, then ask for a plan and correct it.
• One giant step. Fix: build one small feature at a time.
• No verification. Fix: give the agent tests or other checks for each step, and try each feature yourself.
• No review. Nobody read 80 files of changes, and payments and accounts are exactly where security mistakes hurt most. Fix: read the diffs and ask for a security review of those parts.
• One huge commit with a useless message. Fix: commit after each working, reviewed step, with a message that says what changed.

Question 19 · Short answer

Why does an agent session usually use far more tokens than asking a chatbot a single question? Give two ways to keep usage down.

Suggested answer

An agent works in a loop. It reads files, runs commands, and feeds all of that output back to the model, step after step, and the model processes the growing conversation each time. A single chat answer involves one question and one reply.

Ways to keep usage down (any two): give a specific request that points to the relevant files; keep each task small and focused; start a fresh session for an unrelated task instead of continuing a long one; avoid open-ended requests such as “investigate the whole project”.

Challenge

Question 20 · Hands-on

Write a one-page spec for a small app you might build this semester (for example, a study-group finder). Include who it is for, three to five must-have features, what is out of scope, and a “done means” list of checks. Then list three things you would put in the project’s instruction file (CLAUDE.md or AGENTS.md).

Suggested answer

Answers will vary. A good spec:

• names a specific audience and the problem they have;
• lists three to five must-have features, each one small enough to build and check on its own;
• states what is out of scope (for example, payments or a mobile app), which keeps the agent from over-building;
• ends with checkable “done means” items, such as “a student can create a group and it appears in the list” or “a group cannot be created without a course name”.

Good instruction-file items are short, standing rules the agent can’t guess, for example: the command that runs the tests; “make small commits with clear messages”; “never put API keys in the code; read them from environment variables”.