Agentic coding: how product builders work with coding agents

Agentic coding means a coding agent does the typing while you do the choosing, specifying, checking and deciding. You hand Claude Code, Cursor, Codex or Grok a clear job with a check it can run, and you judge the result before it ships.

TL;DR

• When the agent writes the code, your job moves upstream (what to build, and how to describe it) and downstream (did it work, and should it ship).
• The work runs in a loop: plan, spec, build, verify, ship, learn. The agent owns the middle. You own both ends.
• Give the agent a short spec with checkable Done When lines, a rules file it reads every session and only as much autonomy as you can review.
• Running several agents is a management problem, not a model problem. One list, one holder per job, short handoff notes.

New to the words? The short definitions live in the glossary: agentic coding, agentic engineering and coding agent. This guide is about how to work with one, day to day, when you are the person responsible for the product.

What changes when the agent writes the code?

Typing stops being the slow part. A change that once took a developer an afternoon now takes an agent a few minutes, and the agent will happily write the next one, and the one after that. Simon Willison titled a 2026 chapter on this "Writing code is cheap now", and that is the shift in one line.

What doesn't get cheaper is knowing what to build, saying it clearly and telling whether the result is right. Those three now take most of your time. So your job changes shape:

• Choosing. Out of everything customers asked for and everything you'd like to try, which job goes next?
• Specifying. What should be true when it's done, written so an agent can check it?
• Checking. Did the change do what the spec said, on the real product, not just in the agent's summary?
• Deciding. Ship it, send it back or drop it. Plus the calls along the way that only you can make.

Anthropic's guidance for Claude Code puts the risk plainly: without a check the agent can run, "you become the verification loop". Every mistake waits for you to notice it. The same holds for Cursor, Codex and Grok. The more you can turn "looks right to me" into a check the agent runs itself, the more of the day you get back.

The other change is speed in both directions. A vague idea used to stall in a backlog, and that delay gave you time to rethink it. Now a vague idea becomes a finished wrong feature by lunch. Agentic coding rewards people who decide carefully and then let go.

What does the agentic coding loop look like?

Every job runs through the same six steps. The agent does most of the build and much of the verify. You lead the rest.

Plan: pick the job

Start from one ranked list, not from whatever is on your mind. Put what's broken first, then what customers asked for, then your own ideas. If you are unsure how to order them, the prioritization frameworks guide walks through the options. One row is one problem, small enough to finish and check in a day or so.

Spec: write down what should be true

A spec is one short page per job. It says the problem, the evidence behind it, what to build, which files to touch and the Done When lines. You can draft it yourself, or ask the agent to read the code and draft it with you, then edit. Anthropic's Claude Code guide suggests letting the agent interview you about edge cases before it writes anything, then starting a fresh session to build from the spec. Spec-driven development covers the habit in full, and the spec template gives you the five sections to copy.

Build: let the agent work

Ask for a plan first on anything that touches several files, and read it before any code is written. If you could describe the change in one sentence, skip the plan and let it go. Then let the agent edit, run the tests, fix what it broke and open a pull request. Your job during the build is mostly to stay out of the way and answer real questions.

Verify: check against the spec

The agent runs its checks and records what passed, one Done When line at a time. Then you look at the evidence: the test output, a screenshot, the page on a staging site. Read the diff if you can. If you can't yet, read the evidence closely and try the change yourself.

Ship: put it in front of customers

Merging is not shipping. A change is shipped when it's live where customers use it and the Done When lines still hold there. Keep this step for a person. It is the one that is hardest to undo.

Learn: did it work?

Look at whether the change did what you hoped, and tell the people who asked for it. This step feeds the next plan, which is why it's a loop and not a line. It's also the step most builders skip when agents make shipping feel endless.

What does a product builder still own?

Four things. None of them can be handed to an agent, however good it gets, because each one depends on knowledge the agent doesn't have.

What to build. The agent can build almost anything you describe. It can't tell you which customer is about to leave, which bet you're making this quarter or which idea you already tried and dropped. A coding agent reads code. It doesn't read your customers. Keep the ranked list yourself, with the evidence behind each row: the customer's words, the account and why it matters.

The spec. You can let the agent draft it. You still sign off on what "done" means. A spec is a promise about the customer's experience, and you are the one who knows what that experience should be.

The calls. Along the way, real choices come up. Should the new setting be on by default? Is it fine to change how existing data is stored? Does this go to every customer or just the ones who asked? An agent can make a guess. It shouldn't. The human in the loop guide shows how to write down which calls come to you and which don't.

The review. Reading evidence and deciding to ship stays with you. An agent's "done" is a claim. Your review turns the claim into a fact. If you are a founder new to coding, this is the skill to build first. You don't have to write the code to judge whether it does what the spec says.

What you can hand over: the typing, the reading of unfamiliar code, the first draft of a spec, running tests, fixing what the tests catch, writing the pull request and the first pass at a review in a fresh session.

How much should you let an agent do on its own?

Autonomy is a dial, not a switch. Most coding agents offer some version of the same four levels. Claude Code calls them permission modes, and Cursor, Codex and Grok each have their own settings for when the agent stops to ask. The names differ. The levels are the same.

A few rules of thumb:

• Move up a level when the check is good, not when you're bored of approving. After the tenth approval in a row, people click through instead of reading. That is worse than no approvals. If you're clicking through, either give the agent a real check and step up, or narrow what it's allowed to touch.
• Match the level to the job, not to the agent. The same agent can run in the background on a well-tested copy change and stay at "suggest" on a change to how payments work.
• Background runs need the best specs. You aren't there to answer questions, so the spec has to answer them first.

Anthropic's documentation is blunt about the top of the dial: its mode that skips every check is meant for isolated containers and VMs only. If you don't know what that means for your setup, you don't need it yet.

How do you give a coding agent enough context?

Every session starts with an agent that knows nothing about your product except what you give it. Give it too little and it guesses. Give it too much and the important parts get lost: Anthropic notes that an agent's performance degrades as its context fills.

Think of context in three layers:

1. Rules that never change. How to run the project, how to test it, the conventions and what never to touch. These go in one short file at the root of your repo. AGENTS.md is the shared name several agents read, and Claude Code reads it too when there's no CLAUDE.md. Start from the AGENTS.md template.
2. What this job needs. The problem, the evidence, the files and the Done When lines. This is the spec, and it changes every job.
3. What was decided. Calls you've already made, so no agent asks again. "We don't send email without a person reviewing it" is a decision. Write it down once.

The common mistakes are putting the weekly stuff in the rules file, which bloats it, and putting the standing rules in each chat, which means you retype them forever. If an agent keeps asking you the same question, the answer belongs in one of these three places.

Context engineering covers each layer in depth, including how much is too much and how to keep it current. For the product side, the part agents most often lack, see how to give coding agents product context.

Two habits help inside a session. Start a fresh session for each job, so failed attempts from the last one don't steer the next. And if you've corrected the agent twice on the same thing, stop. Start again with a better first message that includes what you learned. A clean start with a clear brief beats a long chat full of corrections.

How do you know the agent is done?

When the Done When lines are checked and each one has a receipt. Not when the agent says so.

An agent stops when the work looks finished to it. That's a reasonable signal, but it's only one, and it comes from the party that did the work. You need lines written before the build starts, each one checkable on its own, and evidence that each one passed.

Compare these:

A receipt is whatever proves the line: a test name and its result, a link to the staging page, a screenshot. If a line can't be checked, say so and leave it unchecked. Don't count it.

Two levels of done help here. The job's Done When lines are specific to this change. Your standing definition of done (tests pass, no new warnings, nothing outside the job's files changed) applies to every job and lives in your rules file. The definition of done for AI agents guide covers both, and why "merged is not shipped" matters.

One more trick from Anthropic's guide: ask a second agent, in a fresh session, to review the diff against the spec. It hasn't seen the reasoning that produced the change, so it judges the result on its own terms. Tell it to report gaps against the spec only, not style preferences, or it will invent work.

Can you run more than one coding agent at once?

Yes, and many product builders do: one agent on a bug, one on a feature, one drafting the next spec. It's also where agentic coding gets messy fastest.

The usual problems:

• Two agents start the same job, because nothing said who had it.
• One agent undoes another, because both edited the same files.
• Every new session starts from zero, so you explain the project again and again.
• You become the router, answering every question from every agent.

The fixes are the ones any small team uses. Keep one ranked list. Make each agent claim a job before starting, so one holder per job. Give each agent its own branch, and its own working copy (a git worktree) when they run at the same time. Have an agent leave a short note when it stops partway: what it did, what failed and the exact next step. A good handoff note is five lines, not a pasted transcript.

The guide to managing multiple AI agents walks through each fix. The short version: start with one agent until the loop runs well, then add a second on a job that doesn't share files with the first.

How do you keep agentic coding safe?

Safety in agentic coding is mostly about two questions: what can the agent touch, and what does it do before asking you? Here it is in plain words.

Keep it in its lane. Run each agent inside the project folder, on its own branch. Most coding agents can be set to ask before reaching outside your project or onto the network. Turn that on and leave it on.

Keep secrets out of reach. Don't paste passwords, API keys or customer data into a chat. Keep keys in the place your project already uses for them, and add a line to your rules file saying the agent must never print or commit them.

Protect the things that are hard to undo. Your live database, your payment setup, anything that emails customers and your production deploy. Write these into your rules file as "stop and ask". An agent should never change customer data, send a message to a customer or release to production without a person saying yes.

Use version control as your undo button. If every change lands on a branch as a pull request, a bad change is a pull request you don't merge. Several agents also take checkpoints you can rewind to, but those aren't a replacement for git.

Be careful with what the agent reads from outside. A web page, a pasted document or a tool description can contain instructions. An agent that reads them may follow them. The more an agent can reach, the more this matters, which is one more reason to raise autonomy one level at a time.

Decide which calls are yours, once. Write a short "ask me only if" list: anything touching customer data, revenue, scope changes or a choice between two real options. Everything else, the agent settles and notes. The human in the loop guide has rules you can paste.

None of this needs a security team. It needs a branch per job, a short rules file and the habit of saying "no, ask me" on the few things that matter.

What does agentic coding look like on one feature?

This is a hypothetical example.

Say Maya runs a small booking tool for yoga studios. She has 30 paying studios, she's a founder new to coding and she builds with Claude Code. Three studios have asked the same thing in the past month: they want to export their class bookings to a spreadsheet for their accountant. One wrote, "I copy every booking by hand at the end of the month."

Plan. Maya's list has one broken thing on it (a time zone bug, already in progress) and then customer asks. The export has 3 studios behind it. It goes next.

Spec. She opens a fresh Claude Code session in plan mode and asks it to read the bookings code and interview her about the export. It asks good questions she hadn't thought about: which date range, whether cancelled bookings count, whether teachers can export or only studio owners. She answers, and they write a spec together:

• Problem: Studio owners copy bookings by hand for their accountant every month.
• Evidence: 3 studios asked, with their words.
• What to build: An "Export to CSV" button on the bookings page. It downloads bookings for the chosen date range, including cancelled ones marked as cancelled. Owners only.
• Files to touch: the bookings page, the bookings data file and a new test file. Out of scope: any change to how bookings are stored.
• Done When:
  1. An owner can download a CSV for a date range, one row per booking.
  2. Cancelled bookings appear with status "cancelled".
  3. A teacher account doesn't see the button, and a direct request returns an error.
  4. The full test suite passes.

Build. She lets Claude Code run on its own, on a new branch. Her rules file already says to stop and ask before touching the database or anything that emails a customer. The agent writes the export, adds tests and hits one failure: dates come out in the server's time zone, not the studio's. It fixes that and reruns the suite.

Verify. The agent reports each Done When line with a receipt: test names for lines 1 to 3, the suite output for line 4. Maya opens a second session and asks it to review the diff against the spec only. It flags one gap. Line 3's test checks the button is hidden but not the direct request. The first session adds the missing test. Then Maya clicks through the staging site herself as an owner and as a teacher. She can't read every line of the diff yet, but she can read the evidence, and she can try the feature.

Ship. She merges and deploys, then checks lines 1 and 3 again on the live site with her own test studio. Both hold.

Learn. She writes to the 3 studios: the export is live, here's where it is. One replies the next day asking for a monthly email of the same file. That goes on the list as a new row, with that studio's words attached. The loop starts again.

Total time from picking the job to the note: one afternoon. Most of it went on the spec and the checks, not the code.

What mistakes do people make with agentic coding?

Letting the agent choose the work. "What should we build next?" is a fine question to ask an agent for ideas. It's a poor way to set your roadmap. The agent can't see your customers or your bets.

Starting with a vague goal and fixing it by chatting. Ten rounds of "no, not like that" fill the session with failed attempts. Stop, write a short spec and start fresh.

Skipping the check. A change that looks plausible and that nothing tested is the most common failure. Anthropic's advice is short: "If you can't verify it, don't ship it."

Trusting "done". The agent's summary is not the evidence. Ask for the test output, the screenshot or the link.

A rules file that keeps growing. Every frustration becomes a new rule, and soon the agent ignores half of them. Keep it short. Move job-specific notes into the spec.

Raising autonomy to stop the prompts. If you're approving without reading, the fix is a better check or a narrower scope, not skipping review.

Two agents in one folder. Most "the agents overwrote each other" stories are this. One branch and one working copy per agent.

Treating merged as shipped. A merge is not a customer seeing the change. Check it where they'll use it.

Skipping the learn step. Shipping feels like the finish line, so nobody checks whether it worked or tells the people who asked. Then the next plan is built on guesses.

What should you set up before your first agentic job?

A starter checklist. Each item takes minutes, not days.

• One ranked list of work, with the evidence behind each row
• A short rules file (AGENTS.md) with how to run and test the project, your conventions and what never to touch
• An "ask me only if" list in that file: customer data, money, scope changes and real choices
• A spec for the first job, with 3 to 5 Done When lines an agent can check
• A test suite, or at least one test, the agent can run
• A branch per job, and a separate working copy if two agents run at once
• Autonomy set to "edit with approval" for the first job, raised once the checks hold
• A receipt for each Done When line before you merge
• A check on the live product after you ship
• A note to the people who asked

How does Annsa do it?

Annsa is the source of direction for your team and agents. It holds the plan and spec steps of the loop, and the learn step after you ship. A person makes the call.

• One ranked list. Priorities are ranked inside your bets, in your order: what a person marked broken first, then what customers asked for, then ideas. Each row keeps its evidence: the customer's exact words, the account and its revenue.
• A spec on each priority. The spec has the problem, the evidence, what to build, files to touch and Done When lines. You, your agent over MCP or Ask writes it. Annsa never writes one on its own.
• Agents claim and prove. Claude Code, Cursor, Codex and Grok connect over MCP, with nothing to install. An agent claims a priority, reads the spec and records evidence against each Done When line before it ships.
• Only your calls reach you. Needs You holds the questions that need a person. Decide once, and every agent reads the decision as a principle.
• Learn after you ship. Share Back drafts a note to each person who asked, and you review and send it.

See Direct your agents for how the pieces fit.

Sources

• Anthropic, Best practices for Claude Code (verification, explore then plan then code, context, parallel sessions, failure patterns).
• Anthropic, Choose a permission mode (permission modes in Claude Code).
• Simon Willison, Agentic Engineering Patterns, 23 February 2026.