Agentic Coding Tools

## The question is about the work, not the catalogue Most arguments about which of these tools to use are conducted in the wrong units: model quality, interface, who else uses it. Those matter at the margin. What decides whether a given shape is a good idea on a given task is a handful of properties of **the task**, and you can read them off a ticket before opening anything: 1. **Is there a check fast and trustworthy enough to catch a wrong version of this change?** A build, a test suite, a type system, a linter — anything deterministic that fails when the change is wrong. 2. **Is the change wide and mechanical, or narrow and subtle?** The same transformation repeated in many places is a different animal from one conditional whose behaviour is the product. 3. **Do you know this code well enough to review a large change at speed?** That is a fact about you, not about the code. 4. **Will the change be questioned later?** If someone will ask why, what the session leaves behind stops being optional. ## Why the check carries most of the weight Execution reach is worth roughly what the check behind it is worth. A shape that can run the tests turns a task into something with a signal to work against; where the tests are thin, that same shape produces unverified change faster, which is a worse position than producing less of it. So the presence of a trustworthy check is usually the strongest single argument for wide reach, and its absence the strongest single argument against — whatever the tool is capable of. Driving an agent from a failing signal is a separate discipline; here the check is only being used to pick the shape. ## A four-person team and a decade-old claims codebase Consider four engineers who have inherited a claims-processing system old enough that parts of it are their own specification. The batch path has real coverage; the corrections path has very little; nobody remembers why several branches exist. Four tickets, four different answers: | ticket | properties of the work | shape that fits | why | |---|---|---|---| | rename a concept used across hundreds of files | wide, mechanical, covered by the build | wide reach, with execution | a wrong version fails loudly and cheaply, so review is pattern-checking rather than judgement | | change how a late-payment charge is computed | narrow, subtle, weakly covered | the narrowest shape that still helps, approving steps as they happen | no check here reliably catches a wrong rule, so a person is effectively the only detector and needs small units | | work out why the corrections path double-counts | exploratory, unfamiliar, no change yet | wide reading reach, no writing | the value is in what it can see; letting the same session write the fix at that width produces a change nobody can review | | adjust a figure an auditor may ask about | small, but must be explainable for years | whatever shape records what it was asked and what it did | reconstructability is a hard requirement here and merely a preference elsewhere | Notice what does the work in every row: the check, the shape of the edit, the reviewer's capacity, and the obligation afterwards. The tool's name never appears. ## The binding constraint is usually review capacity Four people can supervise a certain amount of change per week and no more. When a shape produces change faster than that, the excess does not evaporate — it queues, or it gets waved through. This is why an unfamiliar codebase argues for a narrower shape even when the tool is plainly capable: in code you do not know, nothing looks odd, because you have no prior against which anything could look odd. Small units let you build that prior as you go, and you can widen the reach later, once you can spot a wrong answer at a glance. ## What this rule does not say - It does not say wide reach is dangerous and narrow reach is safe. A well-covered mechanical migration is among the safest things to hand over, and a small change to a rule with nothing checking it is among the least safe. - It does not say you should never standardise. A team standard that names a property of the work — anything in the corrections path is reviewed step by step — survives a change of tool, while one that names a product does not. - It does not say the answer is permanent. Coverage improves, familiarity grows, and the same ticket deserves a different answer a year later. - It does not say the tool's capability is irrelevant. It says capability is the second question, and asking it first is what produces the confident wrong choice. ## Answering this in an interview Describe the task before naming anything. State the check, the shape of the edit, your own ability to review it, and what happens afterwards — then choose, and say what the choice costs you. The strongest version of this answer names a case where you deliberately took the narrower option and expresses the reason as review capacity rather than as distrust of the tool.