# Maybe Software Stops Being the Default > Source: > Published: 2026-08-04 00:00:00+00:00 # Maybe Software Stops Being the Default *(a human wrote every word of this article, and made the silly little image too)* Every bank is shit, and every bank’s transaction export is shit, so for years I was writing little translators to get it into my accounting software. Predictably, the last few years, ChatGPT has been writing those little translators, based on copies of the exports I gave it. Most recently, the little translators stopped getting written: there’s no convertor at all. I give an agent the file directly and tell it to convert it. I want to talk about this progression from: *I write the software* to *AI writes the software* to *nobody writes the software*. Concretely: **as agents get better at following instructions and not making shit up, we need less software**. Most of the discourse is about the *AI writes the software* part. How much better (or worse) is Fable 5 at coding than Sol? What happens to my programming job? But these are stage two questions, and stage two feels like it might be just a transition phase. More interesting is stage three: the task gets automated and gets done, and no durable software is written. The agent might knock together a bash script along the way, but what we think of as “the software” is gone. The need to design, deploy, and maintain a persistent, task-specific artifact has disappeared. This is (perhaps) not the first time you’ve heard this, and certainly parts of this shift have names: [malleable software](https://www.geoffreylitt.com/2023/03/25/llm-end-user-programming.html), [ephemeral software](https://tomtunguz.com/ephemeral-software/), [just-in-time software](https://www.idc.com/resource-center/blog/the-dawn-of-just-in-time-software/). Obviously the general observation that AI can generate disposable, one-off code and interfaces isn’t new. But to me, that mostly sounds concerned with better ways to make and use tools; what about tasks where I don’t want to build or maintain a tool at all? Where I don’t want a better interface, I just don’t wanna do the work myself. That raises the question the disposable-software framing doesn’t quite answer: **what determines whether a task needs to become durable software in the first place?** Take my small-business accounting. Every VAT quarter, I kick off my agent in a folder with an API key for my accounting software, a folder of PDFs, and access to the notes it made last time. I ask it to attach the correct PDFs to the correct transactions, and fill out the VAT information. My accountant checks the work, just like she did when it was my wife doing the reconciliation step, and the number of mistakes seems to have gone down. My wife is definitely happier to get a weekend from every 12 weeks back. There’s no application representing this workflow. No bespoke UI, no matching logic trained on a corpus of previous PDFs. I never wrote an integration with the accounting software’s API. The agent’s the integration now: an improvised runtime bridge with access to curl. This used to need a consistent, software-defined bridge, rather than me saying “here’s a URL with the API docs” in a text window. The parsers, document pipeline, the whole workflow kerfuffle this would have become, have evaporated. My timesheets, the same story. I no longer click through ClickUp’s cursed interface. The agent pulls from GitHub and Slack, we have some markdown files where it stores what it’s learned about my projects and coworkers, and the agent runs through the timesheets with me before directly filling them in via the ClickUp API. ClickUp is incidental to this process: it’s just an interface through which my project manager’s agent will read the data. Nobody ever really needed me to “operate timesheet software”, they need me to *maintain a useful record of my work and make it available to the project manager*. The software was only ever one way of meeting that requirement, and it’s no longer the way I meet it. This feels strange as a developer: you see repetition, you write a program. But there’s always been another way of getting stuff off your plate, and we’ve always made heavy use of it: getting another human to do it. You delegate the task to a competent person with more or less documentation and context, instructions, access, some examples, and let them get on with it. That’s the interesting thing about agents; not that they’re writing code, but that we can delegate human-described processes to them. And that gets us a bit closer to what software was doing for us all along: **software is, among other things, a way of paying the cost of formalization in exchange for determinism.** You invest — per workflow — into translating enough of that workflow into something a machine could execute. In return, we got reliable and cheap repetition, and potentially scale. Once we’d correctly encoded a rule, the machine would do it the same way every time. That translation step was the cost of a new workflow, and so we paid it every time, whether or not we actually needed the determinism and cost efficiency. Agents bring us another deal to consider instead. It’s not “skip the spec” … quite. For my expenses, there are still accreted notes about how I handle certain things, still some examples, folder conventions, a standing instruction to escalate ambiguity. That’s all kind of a spec? It persists and it gets iterated on and improved over time, and it’s what we give to the agent next quarter when we wanna do the same thing again. But what’s missing is the exhaustive translation from a specification into executable code. **As models’ abilities to stay on track and not make shit up improve, much sparser specs become executable “enough” that nobody needs to translate them into code any more.** They just need to be clear enough that an agent will reliably do a good enough job with them, consistently. And obviously, agents today *do* [forget constraints and misread instructions](https://arxiv.org/abs/2505.16944). They do the right thing very often. And the other time they often do something subtly different. We get much better repeatability out of actual software where the relevant behaviour has been formalized; that’s almost *why* we formalize. However, we don’t always need that. We don’t *always* require agents to be perfect: human assistants / employees are rarely perfect, and yet we delegate to other humans all the time. The real question is “what’s the threshold for this task?”, or, more specifically: **when does an agent follow instructions well enough that asking it to do the task beats formalizing the task into software?** That threshold sits somewhere different for every task. How often does it run? How bad is a mistake? How cheaply can a human check the output? There are a huge number of tasks being run sufficiently frequently that paying an agent to reason it out each time will cost far more in time and treasure than having someone commit it to code. [Some agent-workflow products](https://www.usemalleable.com/) already work this way, scripting the steps that never change and reserving the model’s judgment for the ones that do. My financial reconciliation runs quarterly, mistakes are recoverable, and there’s already a paid professional who reviews the results. A payment pipeline running ten thousand times a day sits in a far different place. The axes are also shifting beneath us. Agents *are* getting better at the things that mess up the cost-benefit analysis here. Instruction adherence and a reduction in hallucinations are the hinge of what I’ve been writing about here, but it’s not the only factor. There are adjacent improvements in tool-use, context retention, and [long-horizon reliability](https://evals.alignment.org/time-horizons/). Part of better at “following instructions” is also “knowing when to stop”, and knowing when to “come back to me when you need my judgement”. My thesis here isn’t that software is going to completely disappear, and obviously much of the stack is currently made of software. Instead it’s that we’ll see a reduction in task-specific software to automate certain processes: especially those that required bespoke software or that we might previously have given to another human. When we need repeatability, determinism, testability, explicit behaviour, performance, etc, we’ll continue to formalize processes by writing software. But it may well stop being the *default* mechanism for automation, replaced instead by a folder full of rough instructions, an API key, a few URLs, and some data. It’ll be one of the tools we reach for, rather than the only way to automate a process. Large swathes of processes may not need the formalization an explicit write-out into software gives, or the benefits that come with that. Internal tooling, convertors and parsers, gluing together two APIs to get ad-hoc reports. Most small and ad-hoc processes, in practice. Bespoke UIs whose real job was letting a human feed structured data to a process, rather than meeting the human where that data already was. As instruction-adherence improves, and hallucinations decline, more of those tasks make more sense to just delegate to the agent, and that software stops being built. Not removed, not replaced, but just not written in the first place. Same way I didn’t bother adding a new convertor for my bank’s new God-awful data export format.