Merge Is the Bottleneck - Prasanna Sankar, Vorflux

Prasanna Sankar had ranked first in India as a competitive programmer at 18. A year at Microsoft taught him how much the pace of a large team could limit what he accomplished with that speed. He moved to Silicon Valley around 2009 to build companies. Years later, writing software for himself, he saw models winning the kinds of contests he had entered. What caught his attention was how those systems used the model once they had a problem to solve.

The shift he associated with Opus 4.5 was visible at the keyboard. IDE autocomplete could suggest the next piece of code. A terminal agent could take an assignment and work on it alone for a few minutes. Meanwhile, the systems winning programming contests devoted substantially more compute to each problem at inference time than a typical coding agent did. The harness, the software directing the model’s work, gave Sankar somewhere to make that trade himself.

Sankar started building Vorflux for his own use. He was willing to spend more tokens on a task if it saved him time, and he expected those few minutes of independent work to grow into hours. For a job that long, he wanted to be able to leave it running in the cloud. The first obstacle was everything his laptop already knew how to do.

A cloud agent might manage to start the service it was editing. Testing a change could still require other services, the expected ports, working authentication, and data to test against. Vorflux paid that setup cost during onboarding. Subagents started with a raw EC2 instance, brought up the development environment, connected the ports, and worked through machine secrets, authentication, and seed data. With those dependencies in place, a session could run the whole application.

Watching developers use the agents exposed a cost that a fast response could conceal. The planning agent usually came back in a minute or two. Then the developer spent several turns working through the plan with it. Vorflux spent more tokens before that first response. Several exploratory subagents worked in parallel on the design, producing a detailed plan that the harness condensed for the developer.

How could the developer read a short summary while the agents still knew which parts to build together? The underlying plan retained a dependency graph. A developer splitting up a large change would ordinarily have to identify the pieces and work out which could proceed independently. The graph gave the harness that information, so it could assign independent pieces to build subagents while respecting prerequisites elsewhere in the plan.

Testing still tied the developer to a laptop if every cloud session ended with a request to pull the branch and run the app locally. Vorflux ran browser and end-to-end tests on the cloud machine. The effort spent reproducing the environment now paid off twice. The agent could exercise the feature with its dependencies in place, and a person could inspect the result where it ran.

What did the test actually exercise? Sankar liked being able to watch a video of the interaction and see the new feature work. A feature-specific staging link answered a different question. What would happen if he tried something else? With the app already running on the remote machine, he could open the link and choose his own path through the feature.

Developers were already asking a second model to review the first model’s work. Vorflux made that division of labor configurable in the harness. One arrangement used Claude to build and GPT to review. A team could also assign several reviewer subagents to examine the same change from different angles, without the developer having to arrange each review by hand.

A reviewed pull request could still be waiting when another developer or agent landed a change. The base branch had moved. A branch that was ready to merge a moment ago might now need a rebase. With many pull requests open at once, keeping them mergeable became a job in its own right. Vorflux built a merge queue that repeatedly rebased pending changes against master and landed the pull requests. In Vorflux 1.0, a developer could start a multi-hour cloud session and have it carry the change through to merge.

Sankar put his experience at roughly three to five parallel tasks on the desktop and 20 to 30 with long-running cloud agents. His own ability to keep track started to give out around ten. He still had to remember which ideas needed starting, see which sessions needed attention, and decide whether the changes that landed were useful. More capacity to write code had given him a project management job.

The subagent design suggested a way to divide that job. A main agent could hold the plan, start sessions, and track progress. Each worker could do its detailed work in a fresh context window, leaving the main agent room to coordinate the assignments. Vorflux 2.0 applied that design to persistent agents called Autobots. Each had an ongoing goal and could decide when to start a session in pursuit of it.

Consider a customer call that ends with several to-dos. Someone has already expressed what they want. To feed each item to a coding agent, a person still has to notice the commitment, remember it after the call, and write up the task. The transcript can supply that intent directly. A production alert can likewise identify a problem to investigate. When several sessions start this way, the people who own different parts of the work need a shared place to see what is happening and help it land.

This gave Sankar a criterion for choosing assignments. Incremental work suits an Autobot when the conversation, alert, or codebase already contains enough information to identify the next change. Zero-to-one product work demands a different judgment. A customer can describe a bug they encountered. Imagining a product they could never have asked for is a job Sankar wanted to keep.

Tell an agent to fix every incoming error and it can open more pull requests than anyone has time to merge. Each comes with another interruption. Worse, a change can silence the alert while leaving its cause in place. If the agent spends hours on an issue nobody wanted it to pursue, the team pays for both the tokens and the review. Recognizing an error is considerably easier than deciding how much attention it deserves.

Sankar’s comparison was a new hire. Give the bot an important, specific responsibility and expect frequent check-ins early. Set a budget and make its work visible. Expand its responsibility when the results hold up and narrow it when they fall short. An Autobot gets a goal, an owner, and a home channel. Webhooks supply the events it can act on. Vorflux also built a directory of bots that teams could adapt, starting with assignments that had worked inside the company.

• On call. Triage incoming alerts and investigate before bringing in an engineer. The engineer can begin with what the bot has already learned about the incident.
• Continuous integration. Keep working on build speed. A slowdown gives the bot a concrete problem to investigate, and a tested fix gives the team something to review.
• Project management. Keep a project in one channel, report progress and blockers each day, and tag a reviewer when a particular change needs attention.

During a beta rollout with a friendly customer, a bot failed to reply in Slack. Sankar would usually have taken a screenshot and tagged Vorflux to investigate. This time an Autobot that watched customer calls picked up the task after the meeting. It found Sankar’s to-do in the transcript and used the timestamp to locate the corresponding moment in the recorded screen share. The words identified the unfinished work. The recording supplied the screen context he would otherwise have had to capture. 15:39

Who needed to approve what? The Autobot first asked Sankar whether to take on the fix. He agreed. It tagged the responsible engineer and came back with a pull request. The engineer approved the code, and the change merged and deployed. With the fix shipped, the bot closed the item and drafted a message telling the customer it was fixed. Sankar approved the wording, and the message went out.

Sankar could imagine routine work coming to feel like “approve, approve, approve.” In this case each approval had a purpose, and the bot saved the people involved from having to remember the next handoff. His expectation was that a bot with a track record could take on more of those decisions over time.

Sankar credited training focused on orchestration with making the manager role feasible. The main agent could plan and track sessions while subagents did the detailed work. On well-defined assignments, he found the outputs of frontier models increasingly hard to tell apart. Teams could bring existing coding subscriptions. For larger API users, he suggested sending well-specified work to open models to save money and reserving frontier models for judgment and communication. The manager still had to choose the next task within the team’s limits and show why it had chosen it.

Carried far enough, that division of labor suggested a company organized around recurring jobs. A customer call leads to a product fix. By the time an engineer picks up an alert, an investigation is under way. A slow build produces a tested change waiting for review. People spend more of their day designing the product and deciding which recurring job to automate next. Sankar described a zero-employee company as a direction to aim for. By his reckoning, ten people running a huge business would be close enough. Autobots still make mistakes, and some responsibilities still belong with people.

To choose the next engineering investment, Sankar borrowed an idea from studying driver interventions. Look for the situations in which a person still has to take over. Vorflux profiled where engineers spent their time. Repeated planning conversations pointed to a place to spend more compute before implementation. The beta call showed what an existing Autobot could pick up without Sankar taking a screenshot or starting a task. In a market where he saw companies growing unusually fast and facing intense competition, his bet was on small teams whose members own the work, exercise product judgment, and can enlist agents to carry their decisions through.