Automate repeatable work rather than repeated reasoning

Once an operation is understood and repeatable, prefer an established capability over asking an agent to invent the procedure again.

Why this matters

A coding agent can perform development tasks that used to require a person navigating tools and interfaces. But doing the same operation through fresh language-model reasoning every time introduces cost and variability. The agent might select different options, skip a step or misunderstand the current state.

The better answer is often to engineer the environment in which the agent works.

The mechanism

Identify frequent or high-risk operations: generating fixtures, checking contracts, creating assets, performing migrations, setting up environments, inspecting dependencies or validating build outputs. If the operation can be described with stable inputs, outputs and failure conditions, capture it in a script, command-line tool, API or workflow.

The agent can decide when to invoke the operation and interpret its results, while the tool owns the repeatable mechanics. Good tools validate inputs, fail clearly, produce machine-readable output when useful and can be tested independently.

Tools become reusable capabilities available to different people and models. The agent no longer has to remember a fragile sequence of instructions.

Illustrative example

A product team repeatedly prepares request-ingestion test fixtures. Initially, an agent hand-writes JSON examples, sometimes omitting required fields. The team introduces a fixture validator and a generator that uses the canonical schema. Every agent can now call the same operation; failed validation produces a specific error instead of a vague review comment.

This complements the runtime architecture; it is not another business layer. A tool pipeline supports design, implementation and verification at several points.

What to measure

• How frequently the operation recurs and how often it previously failed.
• Whether the tool gives the same result for the same inputs (where determinism is appropriate).
• Whether failures are explicit and actionable.
• Whether the tool reduces repetitive agent work without creating an unreasonable maintenance burden.

Limits

Not every repeated action deserves its own framework. Automation has a development and maintenance cost. Some tasks require exploration or creative judgement and should not be over-constrained. A deterministic tool can also be consistently wrong if its contract is wrong, so it needs tests and ownership.

See the worked example: tool pipeline and runnable fixture validator.