AI Agent Safety Starts With Small Software

Matt Sephton published Fits on a Floppy in April 2026 with a deliberately absurd constraint: useful software should try to fit inside 1.44 MB, the capacity of a standard 3.5-inch floppy disk.¹

The size limit matters less than the posture behind it. Sephton argues for fast downloads, instant launch, low memory, low CPU, native code, older-system support, and tools that do one thing well.¹ The obvious reading says small software respects the user. The agent-era reading goes further: small software gives AI coding agents fewer places to hide mistakes.

AI agent safety starts with small software because small, inspectable systems shrink the space an agent can misunderstand, mutate, authorize, and fail to test. Sandboxes and permission prompts still matter. Small software moves the safety boundary upstream, into the shape of the artifact itself.

TL;DR

Coding agents work best when they can read the relevant files, run the relevant checks, and explain the relevant diff before context degrades. Anthropic’s Claude Code guidance says context fills quickly and that performance degrades as context fills; the same guide calls verification the most valuable practice and describes CLI tools as context-efficient interfaces.² OpenAI’s local-shell documentation warns that agents running shell commands need sandboxing or strict allow and deny lists before execution.³

Small software does not replace those controls. It makes those controls easier to apply. A small tool has fewer commands to permission, fewer files to inspect, fewer dependencies to trust, fewer tests to run, and fewer branches where a wrong assumption can hide. The old Unix lesson did not age out: McIlroy traced “do one thing” to early size constraints, then explained why text streams became useful universal interfaces for both programs and people.⁴ Agent systems rediscover the same pattern because agents need inspectable, composable surfaces.

Key Takeaways

For agent builders: - Prefer small tools with explicit inputs, explicit outputs, and plain-file artifacts before adding broad APIs or large tool schemas. - Treat file paths, diffs, logs, and tests as safety surfaces. The agent can inspect them, the reviewer can inspect them, and automation can gate them.

For software teams: - Small software reduces review cost. A reviewer can understand a 400-line tool and its tests in one sitting; a sprawling framework forces trust where evidence should exist. - Keep permission scope near the action. A small command can run read-only, write one directory, or deny network access. A general command usually asks for more authority than the task needs.

For product leaders: - Small software is not nostalgia. It is a governance pattern for a world where machines can produce too much code too quickly. - The bar should move from “can the agent build it?” to “can the team verify, own, and roll it back?”

Why Small Software Became Relevant Again

Software bloat used to look like a user-experience problem: slow downloads, heavy memory, delayed launch, dead batteries, and old devices left behind. Fits on a Floppy makes that critique visible through an intentionally physical standard. A 1.44 MB badge turns restraint into a test the user can understand.¹

AI coding agents change the reason restraint matters. The machine can produce files faster than a human can read them. That speed weakens quality when the surrounding system accepts volume as progress. A 2,000-line feature with four new dependencies can look impressive in the transcript and still increase the defect surface more than it increases product value.

Small software gives the agent a harder target and the reviewer a better one. The prompt can ask for one executable, one data format, one test file, and one rollback path. The result leaves fewer degrees of freedom. A model can still make a mistake, but the mistake has less room to camouflage itself.

Niklaus Wirth published a paper called A Plea for Lean Software in 1995, long before coding agents entered the workflow.⁵ The title still lands because the underlying failure survives: teams spend hardware, dependencies, and abstraction layers to avoid making hard design decisions. Agents lower the price of adding code, so the refusal to add code becomes more valuable.

Context Is a Safety Budget

Agent safety often gets framed as a permission problem: which commands can the agent run, which files can it edit, which secrets can it see, which network calls can it make. Those questions matter. They do not cover the first constraint the agent hits while working: context.

Anthropic’s Claude Code best-practices guide says the context window holds the conversation, messages, files read, and command output, and that a single debugging session can consume tens of thousands of tokens.² The guide also warns that Claude can start forgetting earlier instructions or making more mistakes as the context window fills.²

That warning turns size into a safety property. A small codebase lets the agent read the relevant surface without drowning the session in irrelevant files. A small tool lets the agent keep the function, tests, permission model, and edge cases in view at the same time. A small diff lets the reviewer find the actual change instead of scanning a pile of generated motion.

The context budget has three practical limits:

Large systems can still be safe. They need stronger decomposition. If a codebase cannot be small, the agent-facing surface should be small: one package, one bounded subsystem, one public command, one test target, one owned directory.

Plain Files Beat Hidden State

McIlroy’s oral history gives the old lesson a sharp practical edge. He described “do one thing” as a principle born from not having room to do more than one thing, then said teams stuck with the pattern after the original constraint passed.⁴ He also explained why text streams mattered: human-readable data made debugging less of a chore, and evolving text fields required less work than changing fixed binary layouts.⁴

Agents need the same kind of surfaces. A file can be listed, searched, diffed, read in ranges, committed, reverted, linted, and reviewed. Hidden IDE state, opaque local databases, and broad hosted tools can be useful, but they force the agent and reviewer to trust a surface they cannot easily inspect.

A January 2026 arXiv paper connects Unix’s file abstraction to agentic AI systems. The paper argues that file-like abstractions and code-based specifications collapse diverse resources into consistent, composable interfaces, and may help agent systems become more maintainable, auditable, and operationally sound.⁶ Oracle’s agent-memory analysis makes a related distinction: filesystem interfaces work well because models already understand developer-native surfaces such as repos, folders, Markdown, logs, and CLI interactions, while durable storage may still belong in a database.⁷

The distinction matters. “Use files” does not mean “store everything in loose text forever.” The safer pattern separates the agent interface from the storage substrate:

The agent should see the smallest useful interface. The product can keep the stronger storage layer underneath.

Fewer Tools Means Fewer Permissions

The MCP authorization article made the authorization lesson explicit: validating a bearer token does not prove that a user may call every tool behind the server.⁸ Small software applies the same idea earlier in the design. A smaller tool asks for narrower authority.

OpenAI’s local-shell documentation states the danger plainly: running arbitrary shell commands can be dangerous, and builders should sandbox execution or add strict allow and deny lists before sending commands to the system shell.³ Anthropic’s Claude Code guide gives a practical example at scale: when fanning out across files, use allowed-tool restrictions so unattended runs cannot do more than the job requires.²

A small command is easier to restrict:

Broad tools tend to accumulate broad permissions. A general “publish” command may touch content, translations, database rows, cache purge, deployment logs, and analytics. Sometimes the release command belongs. The safer pattern builds release out of smaller commands with explicit gates between them, then automates the sequence only after each step has evidence.

The goal is not to make work slower. The goal is to make authority visible.

Tests Should Fit the Tool

Anthropic’s first best-practice section tells users to give Claude a way to verify its work: tests, screenshots, expected outputs, and command checks.² Small software makes that advice concrete. A small tool can carry a small verification contract.

For agent-built software, the contract should fit on one screen:

Inputs:
- one source path
- one output path
- one optional flag

Allowed effects:
- read source path
- write output path
- no network unless --verify-sources is present

Evidence:
- unit tests for parsing
- fixture test for output
- dry-run output for the exact file
- git diff limited to owned paths

The contract matters because agents can satisfy vague requests too easily. “Improve the pipeline” invites architecture churn. “Add a dry-run flag to this one command and prove the output does not write files” creates an evidence path.

Tests also get faster when tools stay small. Fast tests change agent behavior. The agent runs them more often, sees failures while the relevant code still sits in context, and fixes root causes before the transcript drifts. Slow tests push the model toward guessing or narrating what it would have run.

Small Does Not Mean Underbuilt

Small software can fail in predictable ways:

The floppy badge measures size. Agent safety needs a different measurement: can a reviewer understand the behavior, permission scope, and evidence path before approving the change?

That question allows a tool to exceed 1.44 MB. It refuses the part that matters: accidental scope. A secure, boring 20 MB native app can beat a 200 KB script that shells out to an unreviewed installer. Small software serves safety only when restraint reaches the actual execution path.

A Smallness Scorecard For Agent Work

Before an agent builds or modifies a tool, score the work on five dimensions. The point is not to punish large systems. The point is to find the surfaces that need decomposition before the agent starts writing.

Any red cell does not mean the work should stop. A red cell means the agent needs a smaller unit of work. Safety improves when the task shape makes the right behavior easy to prove.

The Practical Pattern

The safest agent-built systems I trust share a shape:

1. One narrow command does one job.
2. Plain files carry inputs, outputs, logs, plans, and review packets.
3. Permissions map to the command’s actual effects.
4. Tests run fast enough for the agent to use them during the session.
5. The diff stays small enough for a human to review.
6. The release path composes small commands instead of hiding broad authority inside one button.

The No-Build Manifesto described the same preference from the web-stack side: fewer build layers, fewer generated artifacts, and less distance between source and runtime.⁹ The agent-safety version says the same thing with a different reader in mind. Every extra layer gives the machine another place to produce plausible work that the human cannot quickly verify.

Small software turns restraint into infrastructure. A narrower module improves context fit. A plainer file improves auditability. A faster test improves feedback. A smaller permission set improves blast-radius control. A smaller diff improves human judgment.

FAQ: Small Software And Agent Safety

Does small software make AI coding agents safe?

No. Small software reduces the area that agents can misunderstand or damage. Teams still need sandboxing, allow and deny lists, tests, code review, credential boundaries, and release gates. Small software makes those controls easier to apply and harder to bypass by accident.

How small should an agent-facing tool be?

The useful limit is reviewability, not byte count. A good agent-facing tool has one job, a small input/output contract, a clear permission profile, fast tests, and a diff a reviewer can understand in one sitting.

Should agent memory use files or a database?

Use files for the interface when the agent needs to inspect, search, diff, and write artifacts. Use a database when the product needs concurrency, indexing, access control, durability, or cross-user state. The safer architecture separates the agent-facing interface from the storage substrate.⁷

Where does MCP fit?

MCP fits when the agent needs a typed bridge to external tools or data. MCP does not remove the need for small commands, scoped permissions, and action-level authorization. The server still has to decide whether the specific subject may run the specific action.⁸

Close

AI makes code cheap. Cheap code raises the value of refusal.

Small software gives refusal a form the machine can obey: one command, one output, one permission boundary, one test path, one diff. The form does not guarantee quality. It does make weak work more visible.

The floppy disk is no longer the constraint. Inspectability is.

References