Ephemeral Software

Picking up where I left off

Back in August I closed out A Brief History of "AI" Coding with a theory and a warning. The theory was that software code is really nothing more than cached computation... a solution somebody worked out once and froze in place so the rest of us could reuse it without doing the work again. The warning was that the cache was about to stop mattering, and that if I were you, I'd be ready for it.

I called the idea "ephemeral code" and left it at a paragraph. That was meant to be something of a tease, really, because it's the only part of that post I think really matters. The history was a warm-up. So let me pick it back up and take it seriously, because in the two months since, I've spent a good chunk of my time living inside the thing I was describing.

Here's what I mean. This past week I built myself a set of small dashboards... among them, one that tells me which nights this month are worth dragging the telescope outside, one that picks the three best beach days from the tide tables, and one that keeps an eye on the evening calendar for the kind of lecture events and odd little film screenings my girlfriend and I actually go to. None of them were "developed" in any sense I would have recognized a year ago. For each dashboard, I merely described what I wanted, in sentences, out loud, in a single sitting... a few UI tweaks and adjustments to the type of events to look for and there you go.

Each one pulls from public sources that update on its own, keeps a small private store of my own data and preferences, refreshes itself on a schedule, and is shareable with exactly the handful of people who'd care. No repo. No deploy. No backlog. If for some reason I stop caring about the stars or the tides, or decide that my enthusiasm for indie film was purely aspirational, that dashboard can simply stop existing and nothing else breaks.

That's the shape of it. Software built to order, for one person, for a while.

What I mean by ephemeral software

I've been going back and forth on the name. "Ephemeral code" rolls off the tongue better, and it's what I called it in August. But code is the part that's disappearing from view, so naming the idea after it feels a lot like calling the automobile a horseless carriage. What the person on the other end receives is software... technically. What they really receive is the information or experience they desire... but that's a different topic. So for now: ephemeral software, and I'll let time and the market (or a future blog post) correct present-day me.

Whatever we call it, I think it has five properties, and the dashboards above hit all five, if imperfectly.

1) It is requested, not developed. The specification is a conversation. You say what you want, you look at what comes back, you say what's wrong with it. There is no moment where a requirement gets translated into a ticket and the ticket into a function. The translation is the whole product, and it happens in real time.

3) It is built to the individual. Not "personalized," which is a product word meaning the same software with your name on it. Built for one person's actual criteria. My evening calendar knows that I like silent films with a live organ, and that the jazz I want to hear is on Frenchmen Street in New Orleans, not here. Nobody else's calendar needs to know that, because nobody else wants it to.

3) It lives on public data plus a small private store. The world supplies the facts: tide tables, concert listings, satellite orbits, whatever the thing needs. The user supplies a little customization: which beaches, which venues, what counts as a good night. The private part is tiny and the public part is somebody else's problem to keep current. That's a very different ratio from the software I've spent my life building, where the database was the product and the UI was a window onto it.

4) It is secured to the person, not to a product flow. There's no login because there's nothing to log into. The thing exists inside your agent's account and inherits whatever identity you already have there. Sharing it means handing a link to a friend, not provisioning a user.

5) And it is temporal. It has a reason to exist, and when the reason goes away, so does the software. Nobody archives it. Nobody migrates it. The cache expires.

Shared but not productizable

The property I keep coming back to is the fourth one, because it breaks a reflex I didn't know I had.

For my entire career, the moment something I built was useful to me, the next question was whether it could be useful to a lot of people. That question is where products come from, and it's also where most of the cost of software comes from. The instant you intend to serve strangers you need accounts, onboarding, settings pages, documentation, rate limiting, security, support, billing, a roadmap, and a design that works for the median user instead of the actual, literal, one. Ninety percent of the code in any app I've shipped exists to make it safe and legible to people I've never met, most of whom will either never see that work or simply not care unless I did it poorly.

Ephemeral software skips the question. My tide planner isn't a product, it's a tool for me and for maybe four other people, and the right move is to send those four people a link, not to found a company. There's no median user because there's no audience. It's closer to a recipe card than a product. You make one for yourself, you give a copy to your sister, she changes the oven temperature, a handful of people get a nice treat and nobody files a bug.

That's a strange thought for someone who makes a living building products, and I don't want to pretend it isn't. But I think it's where the real leverage is. Most of what people need from software is not novel; it's a small, specific arrangement of things that already exist, assembled for their situation. We've been treating that assembly as expensive, so we only did it for ideas with a market. When the assembly is cheap and conversational, the market stops being the gate. You build it because you want it, and sharing it costs nothing, so you share it with whoever happens to want the same thing.

Prototype to production and back again

Here's my favorite software architect metaphor, and for the first time the loop closes.

First you build a prototype car in your garage. That car starts with a hand-welded frame, then you add the mechanicals, some rolled metal, a custom wiring harness, a bunch of off-the-shelf parts from whatever source will fit, maybe a few safety features and, of course, a wicked paint job. It's tuned and tested by, and often for, the same person who designed and built it, often at great cost and some real risk. But if you do it right, it runs... and it looks cool.

Then potential buyers and investors come around, and the quest to go to market begins. That doesn't mean building another one just like the first one. It means building 50,000 of them a year, refined, consistent, process and cost optimized, redesigned from the wheels up to meet safety, emissions, mileage and a dozen other standards, with a thousand additions and enhancements to fit a market rather than a driver. Which means you're no longer building cars at all. You're building a factory that builds cars, and a system that can operate that factory at scale, over time, with people you've never met, for people you'll never see. And if you want to keep doing it, at a considerable profit.

That's the trip every piece of software I've shipped has taken, and the second leg is where all the time and money go and why clients (and vibe coders) so often leave the room shocked when you hand them the statement of work and estimate of billable hours.

Here's how the loop closes. We're back to building prototypes... only now the prototype arrives with 80 percent of the fit and finish of the production model, and it's designed, specified and produced for the one person who's going to drive it. It isn't personalized manufacturing, where the factory lets you pick the trim level, paint color and mirror caps. It's a unique car, built to order, meant to last exactly as long as the driver looks and feels good in it. And then it goes back to the garage for scrap... or, in our case, simply disappears.

We're not there yet

I should be honest about the dashboards, because they're the evidence and the evidence is mixed.

They are semi-permanent. I expect to open the sky planner next month and see the same data, in the same layout, picked by the same criteria as this month. There's a page with a URL. There's a schema, even if I never typed it. There's a scheduled job that runs every Friday and a short document describing how it should behave so the next run doesn't drift. That is a lot of persistence for something I'm calling ephemeral. If you squint, it's just a very small app with a very unusual development process.

The temporal part is also mostly aspirational. Nothing expires on its own yet. The software doesn't know its reason for being, so it can't notice when the reason is gone. I'd have to delete it, and I probably won't, because deleting things takes effort and ignoring them doesn't. The eventual version of this doesn't have a page at all... you ask the question, the answer is assembled, you look at it, and the assembly is discarded. Caching happens only if you ask the same question often enough to be worth it, and the cache is the agent's business, not yours.

And the "verbal request" part is still doing a lot of work. Getting those dashboards right took real iteration. Not coding, but the thing that used to come before coding: being clear about what I actually wanted, noticing when the result was technically correct but practically useless, saying so precisely. That skill doesn't go away. If anything it's the whole job now. I've written before about the developer's move from player to coach; this is the same move seen from the user's side. The user becomes the client, in the old architectural sense, and the quality of what they get depends on the quality of what they can articulate, and on the taste and skill of whoever, or whatever, they hand it to.

So: not there. But I built five of these in one week, with minimal adjustments, for the cost of a subscription I was already using for other work... and six months ago I couldn't have. The curve is steep enough now, and getting steeper every week, that "not there" doesn't feel like a very safe place to stand.

What it does to the other side of the table

Everything above is from the user's chair. The more interesting consequences are for the people who've spent their careers on the other side: the ones who build the software that users currently have to use.

Let's be honest with ourselves. Most users don't want to use our software. What they want is information, experience, and desirable outcomes. What we offer them is (hopefully) a reasonably easy and pleasant way to claw those things out of the underlying data. Even when we do it well, what they're likely to see is one more thing standing between them and what they came for, something to learn, remember, and wrestle with when it misbehaves. Ephemeral software isn't for us, it's for them.

If a user can assemble their own view of the world from public sources and a little private data, then a business's job stops being "build the app" and becomes "be a good source." Publish the data cleanly. Expose the actions you're willing to let an agent take. Authenticate the person, not the session. Then get out of the way. The customer's own agent does the assembling, in whatever form the customer prefers, with none of your branding and none of your funnel, and the customer is happier for it because they never wanted your app in the first place. They wanted their package, their appointment, or their account balance... or to just reconnect with an old friend.

I've started to hear versions of this from people who run real businesses, and it's not a fringe position. It's a cost position. A website is expensive to keep accurate and a login is a liability. A well-described interface that any agent can talk to is less surface to cover than both, and it doesn't care which assistant the customer happens to use. Bring your own agent. Not every customer is ready for that, and not every business should go first, but the ones that do will find that an enormous amount of what they thought was their product was actually packaging.

For developers, the uncomfortable corollary is that the work moves to the edges. Somebody has to build the sources and the interfaces and the agents, and that's serious engineering with serious consequences when it goes wrong. But the middle, the vast territory of CRUD (create, read, update, delete) screens, login processes, settings pages and "just a simple dashboard" requests that kept a lot of us employed, is where ephemeral software lands first. It lands there because that's where the user's need was the most specific and our solutions were the most generic. Not because our ideas weren't good or necessary or sometimes even beautiful, but because most of the time, serving the greatest number of people with the least amount of friction was the job.

I don't have a tidy ending for this one, because the thing I'm describing is a year or two out and I'm writing from the front of it rather than the back. What I do have is a handful of little dashboards that shouldn't exist by any economics I grew up with, a growing suspicion that the product is the wrong unit of software, and the same advice I gave back in August. I'd be ready for it.