The Rise of Codelets: How AI Changed the Way I Think About Throwaway Code

For most of my career, when I hit a problem I needed to solve with code, the first instinct was to go looking for something that already existed. Search GitHub, check NuGet, find a Stack Overflow thread, grab an open-source project and tweak it. The cost of writing something from scratch, even something small, was high enough that reuse almost always made sense.

AI has quietly changed that calculus. And I think it’s more significant than most people are giving it credit for.

The old model

The economics of software reuse was simple: writing code takes time, debugging it takes more time, and maintaining it takes the most time of all. So when someone else had already solved your problem, even 80% of it, you took their solution. You accepted their abstractions, their dependencies, their opinions about how the problem should be solved. You worked around the gaps.

Open source made this enormously better. The ecosystem of libraries, tools and utilities we have today is remarkable. But it also meant that “solving a problem” often became “finding the right library and learning how it works.” Sometimes that learning cost was worth it. Sometimes you spent two hours learning an API to save thirty minutes of writing code yourself.

The threshold for writing something yourself was high. And throwaway code, scripts you write once, use once, and delete, felt wasteful. Why invest in something disposable?

Codelets

I’ve started calling them codelets. Small, targeted pieces of code, usually a script, sometimes a tiny app, that an AI agent writes to solve a specific problem. Not a library. Not a framework. Not something designed to be reused. Just a precise solution to a precise problem.

The key shift is the cost. When an agent can produce a working codelet in thirty seconds, the economics completely change. Writing something bespoke is no longer the expensive option. It’s often cheaper than finding, evaluating and adapting an existing solution.

A good recent example is how I manage my projects. I track everything in Obsidian, markdown files with YAML frontmatter; each project in its own folder with supporting notes. It works well, but navigating and updating project status across a bunch of files is friction. So I had an agent build a small site that reads those files and renders them as cards. From there I can update the metadata directly, and when a project is done it moves to an archive folder. It does not replace Obsidian, it sits on top of it and makes a specific part of my workflow faster.

That one proved useful enough that I went back and had the agent extend it. Now there is a simple edit form for other notes in the project folder, and you can update the task list in the main project file without opening Obsidian at all. Whether it keeps evolving or stays exactly as it is until I no longer need it, I have no idea. Either outcome is fine.

The point is it solved a real problem, it is well structured enough that an agent can modify it later, and it cost me a fraction of what it would have taken to find, evaluate and adapt something off the shelf.

These still need to be correct and secure. They need to solve the problem properly, for my environment. That is a different bar than “good enough to ship to others”, but it is still a real bar.

The throwaway shift

This is the bit I keep coming back to. The word “throwaway” is actually a bit misleading. The shift isn’t that the code is low quality or disposable, it’s that the commitment is disposable.

A codelet still needs to be well structured, secure and understandable. If it touches real data or runs on real systems, the usual rules apply: validate inputs, handle errors, don’t hardcode credentials. What’s changed is that producing code to that standard no longer requires a significant time investment.

And here’s the part I find most interesting: some codelets stop being throwaway. You use one, it works well, you keep it. You want to tweak it six months later, or have an agent tweak it. That’s easier when the code is readable and well structured to begin with.

So the approach I’ve settled on: build every codelet as if it might last, but recognise that many won’t, and that’s completely fine. A script that runs once to migrate data between two systems, does its job correctly, and is never needed again isn’t a failure. It’s exactly what it was meant to be. The point isn’t permanence. It’s fitness for purpose.

The spectrum looks something like this:

• One-shot, runs once, solves the problem, done. Still needs to be correct and secure, but you’re not thinking about future maintenance.
• Short-lived, used for a period, then retired. Worth a bit more structure so you can understand it if something goes wrong mid-run.
• Evolved, proves useful, gets kept, gets tweaked. This is where good structure really pays off, especially when you’re asking an agent to modify it later.

The key is that you’re not deciding up-front which category something falls into. You build it right, use it, and let its usefulness determine its lifespan.

What this doesn’t replace

I want to be clear about what codelets aren’t. They’re not a replacement for well-engineered software. They’re not what you use when you’re building something that needs to scale, be maintained, or be understood by other people. The cost of that kind of code isn’t just in writing it, it’s in all the decisions, the architecture, the edge cases. AI helps there too, but differently.

Codelets are for the long tail. The hundreds of small, specific, one-off problems that previously fell below the threshold of “worth automating”. That tail just got a lot shorter.

The skill shift

What’s changed for me personally is where I spend my attention. Less time searching for libraries and reading their docs. More time thinking clearly about what I actually need, describing the problem precisely, reviewing what the agent produces, understanding it well enough to know if it’s right.

But there’s a compounding effect that I think gets underappreciated. Over time, as you build codelets, you also build up the instructions and agent skills that produced them. You refine how you ask for things. You create reusable patterns, “always validate inputs this way,” “always structure error handling like this,” “here’s how I want security handled in scripts that touch the filesystem.”

The result is that each successive codelet gets cheaper to produce and better quality. The agent isn’t starting from scratch, it’s working from an evolving set of your own hardened preferences. That’s not just automation. That’s a feedback loop that compounds.

The skill isn’t writing less code. It’s getting better at knowing exactly what you need, being precise enough to ask for it, and investing in the instructions that make the next ask even easier.