Small AI-Built Tools: Set the Boundary Before You Build

Give a coding agent one bounded job before asking it to replace a whole system. A useful small tool might prepare copies of selected files and produce a reviewable manifest. Its first specification should say what it accepts, what it creates and what it must leave alone.

Small should describe the responsibility, not the number of screens or lines of code. A tiny application that silently becomes the only place important records are stored has already taken on a large obligation.

The worksheet below describes a hypothetical file-preparation utility. It creates renamed copies of selected assets and lists the mapping for review. It does not edit the source library or publish anything. These are proposed requirements, not the report of a tool we tested.

An agent can write a deterministic utility: software that follows fixed rules once it is built. Renaming according to an agreed pattern does not necessarily require a model call at runtime. The agent’s role in creating the tool and the tool’s need for AI are different decisions.

Anthropic’s guidance on building agents recommends starting with the simplest adequate solution and adding complexity when needed. We apply that principle here as a design choice; the guidance does not measure the cost of the example utility.

Use a runtime model when the task actually requires interpretation, and specify how uncertain interpretations are reviewed. If a fixed rule is enough, write down the rule and ask the coding agent to implement it directly. That gives the reviewer a smaller set of behaviors to inspect.

For files, “keep a copy” can mean more than preserving visible content. Filenames, timestamps, permissions and embedded metadata can affect how another application uses the result. Decide which properties matter for this job and verify them explicitly.

The Python file-operation documentation warns that even high-level copying functions cannot preserve all file metadata. That is a concrete reason not to treat a successful copy operation as proof of complete preservation. The behavior depends on the operation and platform.

For the hypothetical utility, keep source files untouched, write outputs to a separate location and show the mapping before anyone adopts them. Where metadata preservation is essential, either verify the required properties or reject the unsupported transformation. Avoid describing a convenience copy as a backup system.

A bounded utility should be allowed to say that an input is unsupported. That is often a better first release than adding a partial converter, background sync, account system and shared database because one file did not fit the rule.

Review the rejected cases after using the utility on a representative selection. If many legitimate inputs fall outside the contract, change the scope deliberately. If only a rare exception needs manual handling, document that route instead of making every user depend on a more complex application.

This differs from the system-replacement rollout pattern , which assumes an enduring application and a migration. A file utility can remain a separate, limited tool for its entire useful life.

For a disposable tool, retain the source, the input contract and enough instructions to reproduce the result until the work is accepted. Then archive or remove the tool according to the project’s needs. Repeated use is a new maintenance decision, not an automatic consequence of a successful demonstration.

For a maintained utility, name who receives failure reports, how dependency changes are checked and what happens when the input format changes. A named owner need not create a large support process, but users should know where unresolved work goes.

Use the file-output acceptance reference to inspect the deliverable. If the requirement expands into an enduring application, revisit the build-versus-buy framework with that larger scope.