A coding agent is an AI tool that works inside your project: it reads files, edits them, runs commands like the tests and checks what happened. A plain chat tells you what to change; the agent changes it. Well known examples are Claude Code, Codex and Cursor. Reviewing what it did is still your job.
✅ Tests pass
A question from the app. Pick an answer.
You asked to fix a typo. The diff also changes the price calculation. What do you do?
Maybe, but nobody asked for it or reviewed it. A change to prices deserves its own review.
It was not part of the request. If it thinks prices have a bug, it can say so separately and you decide.
Tests check what they check. The problem is different: it is a change you did not ask for, in something sensitive.
You ask it to fix a bug in the sign up form. A chat hands you a block of code to paste yourself. An agent finds the file, edits it, runs the tests and tells you the result. Inside there is usually a language model with tools: it decides which one to use, looks at what happened and keeps going. That makes it a kind of AI agent. For a long search it can launch a subagent with its own context.
"Done, it works" is a claim, not proof. What backs it up is a result: tests that were run and read, with failures in plain sight. Even then, passing tests prove what they test, not the whole app.
Many tools read an instructions file in the repo, like CLAUDE.md or AGENTS.md; which one each reads depends on the tool and its settings. That is where you put what the code does not say: "all copy ships in English, Spanish and Portuguese", "run the tests before finishing". The file is usually loaded every session and takes up room in the context window, so keep it short.
Instructions guide, they do not guarantee: the agent can forget them. What actually limits it are permissions, which actions it may take and which need your approval. To change a line of copy in the app, it does not need access to the production database.
For a big or risky change, ask for a plan and review it before it touches anything. If the whole plan says "I will fix what is needed", ask for detail. If it proposes adding a column and your team does not touch the database, correct it there. For a typo, skip the plan.
Afterwards, the diff shows what really changed, requested or not. Example: you asked to change a button color and the diff also touches the login validation. That was not part of the request: drop it and, if needed, discuss it separately. Watch out for new files, which sometimes do not show up in the diff.
Many people call it "vibe coding" when you ask the agent for everything and accept whatever comes out without reading it. For an afternoon prototype you will throw away, it can work. In a project with users, payments or personal data, a change nobody read is a risk: the model can make up a function that does not exist or "fix" something you did not ask about.
If you are learning to code, there is one more reason: reading the diff is the fastest way to understand what the agent did and why. If you accept without looking, the code moves forward and you do not.