Agentic coding as a working practice

An online-learning day again, this one on talks about Claude Code and agentic coding tooling generally. I came in assuming I already knew this area, which should have been the warning. I have spent real time wiring agentic tools into other things – a Discord relay for Claude Code, an MCP server that feeds coding agents accurate API documentation – and I use them most days. It turns out I was using them like a cleverer autocomplete.

Autocomplete with ambition

The old pattern: a completion appears, I accept or reject it, I stay the author and the tool stays a shorthand. That is fine for a line of code. The mistake was letting it set my mental model for the whole category, because an agent is not a faster typist. Anthropic’s own description of the tool bears that out: Claude Code works the same loop repeatedly – gather context, take action, verify results – reading files, editing several of them, running commands and reporting back on what it found, not just completing the line under the cursor. The difference from autocomplete is not speed. It is that you can delegate a task rather than a keystroke – Anthropic’s own phrase for the shift is “delegate, don’t dictate” – and delegation was the part I was not doing.

Delegating badly looks like this: type a vague instruction, get back a diff, review every line of it suspiciously, fix the wrong bits, repeat. That is not less work than writing the code. It is the same work with a review pass added on top. Anthropic’s own published guidance for the tool is blunt about this: explore the code before you let anything touch it, keep changes small enough that a bad one costs a keystroke to undo rather than an afternoon – Claude Code snapshots a file before it edits it specifically so a change can be rewound – and verify against something mechanical rather than against your own impression.

The spec, then the checks

The working practice I took away: do not prompt an agent until there is a written spec. What the change is. What it must not touch. What proves it worked. That last line matters most, and it is the one I used to skip. If the check is “looks right”, the agent will oblige me with something that looks right. If the check is the typechecker, the test suite or one command with a defined exit code, verification becomes the agent’s job instead of mine – Anthropic’s own guidance calls this giving Claude “a check it can run”, the difference between a session you sit and watch and one you can walk away from.

Two things fell out of writing specs this way. First, the spec has to be finished before the agent starts, because mid-task I am the least qualified person to judge scope – “also fix that related thing you noticed” is how a small change becomes an unreviewable one, and the agent will always comply. Anthropic’s guidance for larger features lands on almost the same shape: interview the agent until the plan names the files and interfaces involved, states what is out of scope and ends with a verification step, then implement in a fresh session so it isn’t carrying the back-and-forth that produced the plan. Second, the spec is worth writing even when I do the work myself, because it forces the definition of done to exist before any code does. That was true before these tools; the agent just makes the cost of skipping it visible.

There’s a quieter version of the same habit already sitting in one of the projects above. remote-claude has carried its own CLAUDE.md in the repo since before this course day: a standing note on the bot’s architecture, its Discord commands and the Windows stdin quirks that aren’t obvious from reading the code cold. A spec is written once and thrown away; a project file is read at the start of every session and meant to accumulate. I hadn’t connected the two before this, but they’re doing the same job at different timescales: moving what I’d otherwise re-explain out of my head and into something the agent reads first.

Where it stays slower

This is not a tool review, so the honest limits: for a one-line change the spec ceremony is overhead and I keep doing those by hand – Anthropic draws the line in almost the same place: if you could describe the diff in one sentence, skip the plan. The agent does not live with the consequences – whatever it leaves behind, I maintain – so I trust its output exactly as far as the checks reach, and I still read the diff myself. Anthropic’s guidance goes a step further there, recommending a second agent in a fresh context to review the diff against the spec, on the reasoning that a reviewer who didn’t write the change catches what the author is blind to. What changed over the day is not how good the tool got. It is that I stopped treating it as a typing aid and started doing the two parts only I can do: defining the work, and defining what finished means before any code exists.

Sources

Read on 25 August 2026, from Anthropic’s own Claude Code documentation rather than from any specific talk.

• Best practices for Claude Code – “explore, then plan, then code” as the recommended workflow; “give Claude a way to verify its work” (a check it can run, tests, a build, an exit code); the spec-by-interview workflow (“the most useful specs are self-contained… state what is out of scope, and end with an end-to-end verification step”); the guidance to skip planning when “you could describe the diff in one sentence”; and the adversarial diff-review step run by a second, fresh-context agent.
• How Claude Code works – the three-phase agentic loop (gather context, take action, verify results), the built-in tool categories (file operations, execution, search), “delegate, don’t dictate”, and file-edit checkpoints as the reason changes are reversible.
• Checkpointing – how the pre-edit file snapshot and rewind mechanism work, behind the “small enough to undo with a keystroke” claim above.
• How Claude remembers your project – CLAUDE.md as a persistent, every-session instructions file, as distinct from a one-off task spec.
• remote-claude and its CLAUDE.md on GitHub, checked at HEAD – confirms the project carries a standing instructions file with the content described above.