ServicesLabProcessAboutBlogFAQGet in Touch
HomeBlog

Disposable by Default

Agents made building cheap and maintenance exactly as expensive as before. Most of what I build now gets deleted. Here's the bar for what gets to stay.

The cost of building software dropped. The cost of keeping it alive did not move at all.

That gap is the whole story of agentic coding, and most of the discourse around it is pointed at the wrong half. People keep asking whether an agent can build the thing. It usually can. An afternoon of prompting gets you a working version of most scripts, dashboards, one-off migration tools, and small internal services. That question is basically settled.

The question that matters is different: should this exist in six months? Because six months from now, someone still has to read the code, understand what it assumes about its inputs, patch it when a dependency ships a breaking change, and explain to the next person why it’s shaped the way it is. None of that got cheaper. An agent will happily hand you five hundred lines of working code in ten minutes. It will not attend the incident review in March when an edge case it never considered takes down a workflow, and it will not know why a decision was made the way it was, because there wasn’t really a decision. There was a plausible-looking completion.

Maintenance doesn’t compound the way generation does

Generation is parallel. You can fire off ten variations of a tool, throw away nine, and keep one. The marginal cost of a wrong attempt is close to zero, which is exactly why building feels free now.

Maintenance is the opposite. It’s serial, cumulative, and personal. Every dependency you pull in is a promise to track its changelog. Every edge case you didn’t handle is a bug report with your name on it, eventually. Every script without a comment explaining its assumptions is a trap for whoever opens it next, and frequently that’s you, eight months later, having forgotten why it exists. Agents don’t read changelogs on your behalf or get paged, and in a one-person shop the only person who understands a system is still just one person.

That’s the part that doesn’t get automated: bus factor of one. I run Arclight alone, which means every piece of software I keep around is something only I can answer for. Agentic tooling doesn’t change that math. It makes it much easier to accumulate things I’d have to answer for. If I kept everything an agent helped me build, I’d spend my maintenance budget on tools nobody asked me to maintain.

So the sane default is: most of it eventually gets deleted.

Write throwaway tools so deletion is cheap, too. One file, no shared state, no import from your real codebase, comment at the top saying what it’s for and that it’s disposable. If it’s annoying to delete, you built it wrong for its intended lifespan.

Deleting a script you used once and don’t need again is the same discipline as closing a terminal tab. The waste is the opposite failure mode: agent-assisted sprawl, a graveyard of half-adopted internal tools nobody owns, each one a small tax on every future change because now there’s one more thing that might break silently. Cheap generation without a deletion habit is how teams end up maintaining code nobody remembers writing. It’s a strange kind of technical debt: no one struggled to write it, they just failed to notice it was time to throw it away.

What earns a tool a second life

Occasionally something built quickly is worth keeping past its first use. The bar for that shouldn’t be “it worked.” Almost everything an agent produces works at least once, on the input you happened to test. The bar is whether it’s ready to be infrastructure. Concretely, before I let anything graduate from throwaway to maintained, it has to clear all of these:

  • It’s used more than once, by more than the person who wrote it, or it has a concrete, near-term second use already identified.
  • Someone owns it. A name is attached to “if this breaks, I fix it,” which in a shop of one means I’ve consciously accepted that job for this specific thing.
  • Its failure modes are known. I’ve thought about what bad input does to it, beyond watching it succeed once.
  • Its dependencies are ones I’m willing to track. Every added package is a future changelog I’m committing to read.
  • It has enough documentation that a version of me without current context could pick it up. Full docs aren’t needed, just enough that six-months-later me isn’t reverse-engineering intent from code.

That list is short and strict on purpose. Building is cheap and getting cheaper, so the failure mode now is not trimming when it’s time. Anyone doing serious AI integration work right now should be more worried about what they’re choosing to keep than what they’re choosing to generate. The agent will build you the next version in ten minutes if you need it again. It won’t clean up after the version you didn’t need.

If you’re trying to figure out where agentic tooling actually pays off versus where it just generates more surface area to maintain, that’s a conversation worth having before you commit engineering time to it. It’s a fair chunk of what fractional engineering engagements end up being about.

Content may be edited with the help of AI. All content has been reviewed by a human before being published.

Work with Arclight

Have a project in mind?

I design and ship custom software — from early concept to production. Tell me what you're building and we'll figure it out together.

Start a ProjectView Services
NavigateServicesLabProcessAboutBlogFAQMoreFractionalColorado SpringsTech StackBrandGet in Touchhello@arclight.build+1 (719) 337-4490Colorado Springs, COStart a Project