I used to write software. Now I work in mass agent transit. Ten AI agents on the bus today. The plan is a fleet of ten thousand.
That sounds like a joke and it is about half of one. Here is the half that is not.
I am still responsible for getting from A to B. A feature goes from an idea to a URL with a version number on it, and if it does not arrive that is on me. What changed is that I no longer personally carry every passenger there. I pick the destination. I assign the routes. I deal with the breakdowns. And I check that everybody actually got off at the right stop, instead of taking their word for it.
The word I have landed on for the practice is fleetcoding. Building software by directing coordinated fleets of agents rather than writing every line yourself. The job title, if you need one for a form, is agent fleet engineer.
Why fleet and not something softer like team or assistant. Because the scale is the whole point.
At ten agents you are driving a bus. You can see every seat. You notice when one of them has been staring at the same test for twenty minutes. You walk back and sort it out yourself.
At ten thousand you are not driving anything. You are running a transit network. You need dispatch, so work goes to the right kind of agent. You need routes, because a docs job and a database migration should not share a lane. You need capacity limits, because the org spend cap is real and I have hit it inside the first week of a month more than once. You need breakdown recovery, and you need a way to confirm arrival that does not involve asking the agent whether it arrived.
That last one is where most of my actual engineering time goes now. The failures are never the ones you expect. Two sessions running in parallel ship the same feature on two branches because each one checked out a snapshot before the other opened a PR. Git stash turns out to be one stack per repository, shared across every worktree, so parallel jobs pop each other's changes and nobody notices until the diff looks haunted. An agent runs a filtered test command, the filter matches nothing, the command prints nothing, and the agent reports a pass. A green CodeQL check gets read as proof a vulnerability was fixed when it only ever meant no new ones.
None of those are coding problems. They are transit problems. The passengers are fine. The network let them down.
So the ambition is not more agents. More agents is easy, it is a loop. The ambition is more agents making useful progress without each one needing more of my attention. Attention per agent has to go down as the count goes up, or the count is a vanity number.
That is also why engineer stays in the title. I am not pressing go and going to lunch. I am building the thing that lets the fleet operate, which means memory that survives a killed job, rules the scheduler enforces instead of me, and a definition of done that a machine can check.
Software engineers are becoming fleet engineers. We do not write every line anymore. We get entire fleets of agents from idea to production. I am running ten today. The target is ten thousand.
I don't write the fucking code. I drive the bus.
Next stop: production.