Large refactors become workable when humans split them into small, verifiable tasks that agents can run in parallel.
2
Orchestration works best for repeatable maintenance, migrations, and modernization work where each change can fit in one commit or pull request.
3
The intended workflow is about 90% automated, with humans reviewing intermediate results and approving pull requests.
Summary
Robert Brennan argues that coding agents are moving from autocomplete and single-task coding toward fleets of agents that can handle large maintenance projects. A single agent struggles with long tasks because context runs out, domain knowledge is missing, and small early errors compound. Brennan's answer is to decompose work into independent batches, run agents in parallel, track dependencies, and keep a human reviewing intermediate results. The talk includes an OpenHands demonstration that divides a repository into dependency-aware batches, verifies code smells, dispatches fixers, and produces pull requests for review. It also describes a Redux-to-Zustand migration using temporary scaffolding so the application could keep working while components moved one at a time. The later workshop builds a CVE remediation workflow with the OpenHands SDK, using one scanning agent and separate agents for each vulnerability.
Coding agents have progressed from snippets to autonomous development loops
Brennan describes three stages in coding assistants. Early models generated isolated snippets such as bubble sort or SQL access without knowing the project. Context-aware tools such as GitHub Copilot could use local variable and database names inside an IDE. The larger change came with autonomous agents, which could write code, run it, search for error messages, read relevant material, add debugging statements, and run tests again. OpenHands is presented as part of this stage. The next stage is orchestration, where several agents work at once, communicate, or create additional agents. Brennan says these systems can address large amounts of technical debt that a single agent cannot finish in one pass.
Cloud sandboxes make parallel agents safer and easier to scale
Brennan places local agents, cloud agents, and orchestration on a progression. A local agent is useful for ad hoc work, but it can affect the developer's laptop, install unwanted software, or require constant approval. A cloud agent gets a separate containerized environment, so the worst damage is usually confined to that environment. This makes it possible to run agents more autonomously and in parallel. Brennan says most developers are still adopting local agents, while a small group of early adopters is experimenting with fleets of cloud agents that communicate and coordinate larger changes. OpenHands began with cloud agents and later added a local CLI to meet developers in a more familiar workflow.
Orchestration fits repeatable maintenance and migration work
The strongest candidates for orchestration are large tasks made from repeatable, automatable changes. Brennan names dependency updates, vulnerability remediation, documentation, release notes, Python type annotations, Java modernization, monolith-to-microservice work, and framework migrations. One client uses OpenHands to scan thousands of repositories for newly announced vulnerabilities, update dependencies, handle breaking API changes, and open pull requests. Brennan reports a 30x improvement in vulnerability resolution time for that client. He also describes migrating Spark 2 jobs to Spark 3 and moving OpenHands' frontend from Redux to Zustand. These projects still need human decisions about the plan, but much of the repetitive code change can be delegated.
Long-running refactors fail when context, errors, and human intent do not carry through
Brennan gives several reasons a large refactor is difficult to one-shot. The agent may not have enough context for a large repository, and compacting the context can make it lose track of the task. Agents can also stop early, as in his example of an agent migrating three of 100 services and asking for a team to finish the rest. They lack the team's domain intuition, and a small mistake early in a long trajectory can be repeated across later changes. Humans also struggle to express their mental model in one instruction, decompose the work correctly, or define what completion means. For these reasons, intermediate review is part of the process.
Small batches, dependency order, and verification turn a refactor into manageable work
In the OpenHands refactor demonstration, Calvin Brennan's example starts with a dependency graph in which files are nodes and imports are edges. The repository is divided into batches that a human can understand and an agent can handle. Directory structure can group semantically related files, while graph algorithms can provide stronger guarantees about the edges between batches. A second graph shows dependencies between batches. Agents begin with batches whose dependencies are already understood. A verifier checks each batch, either with commands such as tests and linters or with a language model using specified code-smell rules. Failed batches go to a fixer, which has tools to inspect code, run tests, and read documentation. The result is a focused pull request for human approval.
Temporary scaffolding lets components migrate one at a time
For the Redux-to-Zustand migration, the team first had an agent create scaffolding that allowed the application to use both state-management libraries. Brennan calls the arrangement ugly and temporary, but it gave each component a migration boundary. Parallel agents could update individual components, and the team could test the application after each component changed. Once every component used Zustand, the scaffolding and remaining Redux references could be removed. This approach avoided requiring the entire frontend to change in one operation. It also gave humans a way to check that the application and each migrated component still worked as the migration progressed.
Agents should exchange only the context that helps the next task
Brennan compares several ways to share discoveries between agents. Giving every agent every other agent's context quickly fills the context window and behaves much like one agent working serially. A human can paste specific facts into an agent or edit an agent instruction file, but that requires ongoing babysitting. Agents can update a shared file such as agent.md, although they may add trivial information, so human review helps. Another approach gives agents tools for broadcast or point-to-point messages. Brennan calls this an active area of SDK experimentation and warns that agent-to-agent communication increases non-determinism. He gives an example of two agents looping while wishing each other 'zen perfection.'
CVE remediation can use one scanner and one solver per vulnerability
The workshop builds a CVE remediation workflow with the OpenHands SDK. An initial agent receives a GitHub repository and decides how to scan it, such as using Trivy for a Docker image or npm audit for a package.json. The scan writes the vulnerabilities to JSON. The script then starts a separate agent for each vulnerability. Each solver researches whether the issue is solvable, updates the dependency, fixes breaking API changes, and opens a pull request. Independent pull requests can be merged as they become ready, and one stuck vulnerability does not block the others. Brennan says this can still provide value even when the workflow reaches only 90% or 95% completion.
"Having that scaffolding in place allowed us to validate, as each agent finished its work for just that one component, we could validate the application was still working."31:43
Who should watch
You have a large dependency, vulnerability, or modernization backlog made from many similar code changes.
You are designing an agent workflow and need practical rules for splitting tasks, ordering dependencies, and reviewing pull requests.
You want to migrate a codebase incrementally while keeping tests and application behavior checkable throughout the change.
