Economists talk about the "last mile problem" — getting a package from a regional hub to a doorstep is expensive precisely because the autonomous scale vanishes at the boundary. Software automation has an analogous last mile. You can have agents enrich context, propose plans, write code, verify it, and merge to staging. But the last mile — the one where someone decides the factory should verify code this way, or that the staging gate needs a new threshold — is still driven by a human with a YAML file.
We solved every problem except configuration. It turned out configuration was the thing we were trying to escape.
For the past few years, the industry has been converging on something that now has a name: the software factory.
This is not a coding agent. A coding agent is a single thing: you give it a task, it generates a pull request, and maybe it passes tests. A software factory is an orchestrated pipeline of agents working in sequence, with human gates between them.
Here is a sketch of the factory as it already exists inside most companies that have tried to operationalize this:
This pipeline is real. I did not invent it. You can see versions of this at companies that have spent the last two years wiring agents into their CI/CD systems. It is impressive, legible, and in some ways already working.
But there is a problem.
Look at the pipeline again and ask a simple question: who configures the factory?
Not the code that the factory produces. The factory itself.
If you want to add a new verification gate — say, a check that all new database queries use an index — this is currently done by opening an editor, writing a new rule or agent prompt or test config, committing it, getting it reviewed, and merging. If you want to change the threshold for test coverage, you edit a hardcoded number. If you want the factory to start handling tickets from a different source, you update an integration. If you want it to run a different set of checks on Mondays because your traffic pattern changes, someone writes a cron expression.
In other words, the software factory, which automates everything, is itself configured by a process that resembles the old manual workflow. The factory has a heartbeat, but it does not have a nervous system.
This is the last mile problem.
It is surprising how long it took me to notice this, because I was building one of these factories. The agents were running. The pipeline was green. But every time I wanted to adapt the pipeline — really adapt it, not just tweak a parameter — I was back at a text editor, reasoning through PRs.
For a while I thought about what makes a project like OpenClaw work. The naive answer — the first answer most people give — is that it is for non-technical users. You run it on your computer, it connects to Telegram, and you can ask it things like "find me cheap flights to Berlin."
This is true, but it is not the important part.
The important part is what happens after the first technical setup.
After you install it once — which is, yes, technically complex — every subsequent interaction with the system happens through the same interface you use to talk to it. The interface is not split into "user chat" and "admin config." There is one channel. You tell it to find flights. It finds them. Then you say: "Do this every week." And it does.
I want to emphasize how strange this is, because we have been trained to treat these as completely different operations.
In a conventional software factory, if you wanted a weekly job to exist, you would:
In a prompt-based interface, you say: "Now do this every week." The agent has context. It remembers what you just wanted, what parameters worked, what the output looked like. It does not ask you to translate your intent into a different language — YAML, cron syntax, or Go — because the language you are already using is sufficient. It saves the behavior because the same conversation is the configuration.
This is the part that feels obvious in retrospect and invisible before you have seen it.
Here is a concrete example.
Suppose your factory has a rule that skips the security verification agent for PRs tagged docs-only. One day a hotfix touches auth utilities but keeps the docs-only label because the developer forgot to update it. The factory merges it, and staging breaks because the password-reset flow was refactored without the security agent ever seeing it.
In a traditional software factory, fixing this means a human opens the CI config, adds a clause: "for PRs touching auth, always run the security agent even if the labels say docs-only," commits, opens a PR, and waits for review.
In a prompt-based configuration interface, the interaction is:
"For PRs touching auth, always run the security agent even if the labels say docs-only."
The agent understands which pipeline definition to patch, proposes the exact diff, and after you approve, applies it. The config file is edited. But you did not open it. The agent understood the intent in the same language you used to report the incident, mapped it to the right part of the system, and asked for permission.
That is the distinction: the config file is still there. What changed is who diagnosed the gap and who authored the fix.
The software factory pipeline I described earlier is good at producing code. It is not good at changing what it itself does.
If you want the factory to start weighting security checks more heavily, or to skip the staging gate for hotfixes under a certain condition, or to route documentation-only changes through a lighter verification lane — these are configurations, and in current systems they require the same manual PR-review-merge cycle that the factory was supposed to eliminate.
What I keep returning to is this: a software factory should not need a separate configuration discipline. If a pipeline of agents can take a task, enrich its context, propose a plan, get approval, execute, verify, test, and merge — then that same pipeline should be able to reconfigure itself when told to, using the same approval gates.
The configuration should happen through the prompt box. The agent should be able to modify its own workflow definition, present the change as a plan, get human approval, and then apply it. Not as a special mode, but as the normal continuation of how you already talk to it.
I am not sure this is the right framing. Maybe in five years we will look back and laugh at the idea that "prompt-based configuration" was ever a category, the same way we laugh at "web 2.0." But I am fairly sure that the current state — where a pipeline of agents can merge your code but cannot change its own rules without a human editing a file — is a transitional state, and not a stable one. The last mile is what happens at the boundary between automation and intent. Right now that boundary is a config file. I think it is about to become a sentence.