Hands-On: Your First Agentic Tool

Big idea

The fastest way to understand agents is watching a real one tackle a real task — look for whether it reads before writing and verifies its changes, and whether it asks before doing anything hard to undo.

The exercise

Reading about the plan → act → verify loop only gets you so far — the fastest way to actually understand it is to hand a real coding agent a real, slightly open-ended task and watch what it does. Pick something small but genuine: "add a dark mode toggle to this page," "fix the failing test in this file," "find and remove the unused imports in this project."

Think of it like

When you hire a new plumber, you learn a lot by watching them work. A good one looks under the sink and asks a few questions before touching anything, explains what they think is wrong, makes the fix, then runs the tap to confirm the leak has stopped. A poor one starts unscrewing pipes right away and leaves without testing. A careful one also checks with you before cutting into a wall. Running your first coding agent is the same kind of observation: you are watching for orientation, a stated plan, a real check at the end, and respect for steps that cannot be undone.

What to actually watch for

• The plan — does it explain what it's about to do before doing it, or just start editing blindly? A good agent tells you its plan in plain language first.
• The actions — which files does it read before it writes anything? Reading before writing is a strong signal it's actually orienting itself, not guessing.
• The verification — after it makes a change, does it run something to check the change worked (a test, a type-checker, a build), or does it just declare victory? This is the single best tell for whether you're looking at an agent or a chatbot wearing an agent's tools.
• What happens when it's wrong — introduce a task with a subtle catch (a test that's failing for a different reason than the obvious one) and see whether it notices the real cause or patches the wrong thing.

Watch it

Watch the plan, act, verify loop on the lesson's example task, and what to look for at each stage.

Why this matters more than reading about it

Every concept so far — hallucination, context windows, the plan/act/verify loop — is abstract until you watch it happen in front of you at normal speed. Seeing a real agent correctly diagnose a bug by reading an error message, forming a hypothesis, and checking it is a genuinely different kind of understanding than being told that's what agents do. It's also the fastest way to build calibrated trust: you'll see exactly where it's fast and reliable, and exactly where it still needs you watching.

A note on judgment

Nothing here means "let it do anything unsupervised." A well-built agent still asks before doing something hard to reverse (deleting files, pushing code, spending money) — noticing that boundary, and whether the agent respects it, is as important a thing to watch for as the loop itself.

Give it the context a new teammate would need

Coding agents read a project instructions file at the start of every session — CLAUDE.md for Claude Code, AGENTS.md for several other tools. A useful one is short and specific:

# Project: expense tracker (Next.js + SQLite)

- Run `npm test` before saying a change is done.
- Database access goes through `lib/db/`; never query from components.
- Money is stored in paise as integers — never floats.
- Don't edit files under `migrations/` that are already committed.

A good first task

The "Export CSV" button on /reports downloads an empty file when the date range
spans two months. Find out why, fix it, and add a test that would have caught it.
Show me the failing test first, then the fix.

It names the symptom and the exact place, says what "done" means (a test), and asks for evidence in an order you can review. Compare "fix the export bug" — the agent has to guess all of that.

Key terms

• Plan, act, verify loop — The cycle where an agent decides what to do, does it, and checks whether it worked.
• Verification — Running something real, like a test or a build, to confirm a change actually worked.
• Calibrated trust — Knowing from experience exactly where an agent is reliable and where it still needs watching.
• Hard-to-reverse action — A step such as deleting files, pushing code, or spending money that a good agent asks about first.