Three working apps, all of them on localhost
Coding agents can write the software. Getting it running somewhere other people can reach is still a human job, and that is the part worth automating next.
There is a genre of post you see every week now. Someone who has never written code says they built three working web apps in half an hour, and lists the links.
All three links point at localhost.
That is not a cheap shot. The apps probably do work. The person almost certainly did build them, and thirty minutes is probably honest. What the post captures without meaning to is exactly where the current generation of tools stops: the code exists, it runs on the machine it was written on, and there it stays.
The part that did not get easier
Writing software used to be the expensive step. It is not any more, or at least not in the same way. An agent will take a description and produce something that runs, and it will do it faster than you can specify it properly.
Everything after that has stayed exactly as hard as it was.
To put an application somewhere other people can reach it, you need a place to run it, a way to get it there, a domain, a certificate, somewhere to keep secrets, a database that survives a restart, backups, and some way of knowing whether it is still up. None of that is interesting. All of it is required. And it is the part that no agent can do for you, because it does not live in the repository.
So the work splits into a half that has collapsed to minutes and a half that still takes a competent engineer a day, or a beginner a weekend and three abandoned attempts.
Why agents stop at the edge of the repo
An agent is good at anything it can see and change: files, tests, a build. Its world ends at the filesystem.
Deployment is not a file. It is a sequence of privileged actions against systems that are not in the repository, each of which can fail in a way that is invisible from inside the code. The registry rejects the push. The certificate does not issue. The container starts and exits, and the reason is in a log on a machine the agent has never heard of.
You can hand an agent a shell and let it work all of that out. People do. But then you have given a process that cannot be fully predicted the credentials to your infrastructure, and the blast radius of a misunderstanding is your production environment. That trade is fine on a laptop and not fine anywhere else.
The alternative is to make deployment small enough to fit through a narrow opening. Not to give the agent more power, but to make the thing it needs to do simple enough that it takes one instruction.
The Google Doc comparison
I keep coming back to how a shared document behaves, because it is the closest thing to what deployment should feel like.
You open it. You change something. There is a new revision, automatically, and you can see what changed and go back. You share a link and the other person has it. Nobody thinks about where the file lives, what it runs on, or whether the save worked.
That is not because documents are simple. Some of them are enormous, with hundreds of contributors and years of history. The behaviour does not change with size. The complexity is real, it is just not yours.
Deployment could work like that, and mostly does not.
What this changes about business processes
There is a second reason this matters, and it is less obvious than the first.
If deployment is hard, then automating a business process pushes you toward tools built specifically to avoid it. Workflow platforms like n8n and Zapier are popular for a good reason: they take the deployment problem off the table entirely. You draw the process in a designer, and it runs. No servers, no pipeline, nothing to operate.
The cost shows up later. A process drawn in a designer is difficult to test properly, because there is no natural place to assert what should happen before it happens for real. It is difficult to review, because a diff between two versions of a canvas is not something you can read. And every company’s process turns out to have a shape that the available blocks do not quite make, so you end up with a node doing something it was not designed for and a comment explaining why.
If deployment were genuinely easy, none of that would be a trade you had to make. You would write the process as code, which means it gets tests that run before it goes live, a history you can read, and a review that shows what changed. Then you deploy it the same way you deploy anything else.
The reason people accept the limitations of a visual designer is almost never that they prefer drawing to writing. It is that the alternative involves a pipeline.
Small does not have to stay small
The obvious objection is that this only holds for trivial things, and that anything real needs the full apparatus anyway.
I do not think that follows. A process that starts as one service handling one job can grow into something substantial without ever changing how it is operated, in the same way a document can grow from a note to a specification without becoming a different kind of object. What has to stay constant is the interface: describe what should be running, and it runs.
The apparatus should be something you grow into if you need it, not the entry fee.
What I am building
I am working on this, which is the reason I have thought about it this much. Stackyl abstracts the deployment pipeline down to a single MCP server, so an agent can deploy what it has just written without being handed the keys to anything. You describe what should be running. It runs, in the EU, with a revision history.
Whether that specific attempt works is a separate question, and it is too early to claim it does. But the gap it is aimed at is real, and it is visible in every one of those posts. Three working apps in thirty minutes, and all three of them on localhost.
The building got fast. The shipping did not.
Hexxore builds software, connects systems, and runs the infrastructure underneath. Working on something where this question is live? Tell us about it.