Agentic coding as a working practice
How a day of talks on Claude Code and agentic coding tooling moved me from using these tools as autocomplete to running them against a written spec with verification steps.
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. It reads the repo, edits several files, runs commands and reports back. The difference from autocomplete is not speed. It is that you can delegate a task rather than a keystroke, 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. The talks were blunt about this, and so is the published guidance around these tools: plan before editing, keep changes small and reversible, 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.
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. Second, the spec is worth writing even when I end up doing 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.
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 will keep doing those by hand. 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. The diff is smaller now, because the spec keeps the change contained. What changed 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.