Software Development Agents: What Works and What Doesn't

Which parts of software development can you hand off, and which still need your judgment? Coding agents make that question practical: some tasks work remarkably well, while others demand repeated intervention. Robert Brennan brings the perspective of more than a decade building open-source developer tools and his team's work on OpenHands, formerly OpenDevin.

In this 2025 talk, Brennan describes a profession already different from two years earlier and likely to change again over the next two. His prediction is that developers will spend much less time writing code, without software engineering disappearing. The shift is from leaning forward and squinting into an IDE to sitting back and asking what users want, what the organization needs and which architecture will support the future.

The write–run loop is a good target for automation; deciding what deserves to be built remains an engineering responsibility. An agent can repeatedly write code, execute it and respond to the result. That does not give it the same grasp of users or business objectives as the people responsible for the product. Fewer keystrokes should leave more room for thinking, imagination and creativity.

An agent has agency because it can act outside the model. For software development, that means access to familiar tools: an editor to navigate and modify files, a terminal to run code, and a browser to consult documentation or find examples on Stack Overflow. Together, these let the agent participate in the development loop rather than merely suggest its next line.

Brennan describes the last category as working independently for five, ten or fifteen minutes. That changes how work can be organized: dispatch several agents, then communicate with coworkers—or browse Reddit—while they work. The benefit comes from delegating a stretch of activity instead of supervising every keystroke.

Understanding the machinery helps explain both successful delegation and failure. At the center is a loop between a large language model and the external world:

1. Give the model its goal and the information accumulated so far.
2. Ask it to choose the next action that moves toward that goal.
3. Execute the action: read a file, make an edit, run a command or inspect a webpage.
4. Return the observed result to the model for its next decision.

The model supplies the next step; the surrounding system performs it and supplies feedback. File contents, command output and webpage contents become evidence for the next turn. An agent's effectiveness therefore depends on the tools and observations around the model as well as on the model itself.

The simplest editor interface would send the old file to the model and ask for a complete replacement. But changing one line in a file containing thousands of lines would require generating all the unchanged content again. That spends output tokens on material the agent did not need to modify.

Targeted edits keep the operation proportional to the change. Find-and-replace editors let the model identify existing text and supply its replacement. Diff-based editors express the lines to remove and add. Both avoid reproducing the entire file for a small modification.

Editing is only part of the problem. Agents also need to locate relevant code. An abstract syntax tree, or another structured navigation facility, can help them explore a codebase more effectively before choosing what to change.

A terminal appears to be a simple text-in, text-out interface until commands stop behaving like short function calls. A long-running command may produce no standard output: should the system kill it, or let the model wait? Other tasks require parallel commands or background processes. Starting a server and then running curl against it requires the server to remain alive while the next command executes. These are process-lifecycle decisions that the agent's terminal tool must support.

Browser tools introduce another problem: how much of a page should the model see? Returning raw HTML is straightforward, but it includes substantial markup and other material irrelevant to the task. Brennan describes several alternatives:

• Accessibility trees expose a structured representation of the page.
• Markdown conversion provides readable content with less markup.
• Scrolling lets the agent inspect a large page in portions.

Interaction adds another layer. The agent can write JavaScript against the page, or receive a screenshot with labeled nodes and identify the element it wants to click. The representation must support both understanding the page and choosing an action on it.

Brennan reports that a contribution roughly a month before the talk doubled OpenHands' web-browsing accuracy. He does not identify the benchmark, baseline, model or evaluation conditions, so the figure describes a reported project improvement without establishing a general browsing success rate.

Autonomous execution makes sandboxing essential. Brennan describes OpenHands agents running in Docker containers by default, separated from the developer's workstation. His example is preventing an agent from applying rm -rf to the host home directory. That protection depends on configuration: the maintained OpenHands v0 Docker documentation warns that agents can modify or delete host files mounted writable into their workspace. A container does not make those mounts untouchable.

External credentials create a separate boundary. A GitHub token or access to an AWS account lets an agent affect resources outside its container. Least privilege means tightly scoping those credentials to the operations the task requires. Workstation isolation and service permissions must both be considered when granting autonomy.

The best starting task fits in a single commit and has a clear definition of done. The agent needs a completion signal—tests passing or merge conflicts resolved—and the engineer needs an easy way to check that the work is complete and correct. A pull request with one failing test, lint errors or merge conflicts supplies exactly this kind of bounded chore.

Task size can grow as you learn how to communicate with the agent and recognize its strengths. Brennan estimates that 90% of his code goes through an agent, with a return to the IDE needed perhaps 10% of the time. This is his personal account of an established workflow, reached through practice rather than an expectation for someone's first task.

Specify how the work should be done as well as what should change. Name the framework, request test-driven development if that is the desired approach, and point to relevant files or functions. An exact file reference reduces the exploration required before editing. Better instructions can therefore improve the result while also reducing elapsed time, token use and inference cost.

Cheap code generation changes the economics of experimentation. Brennan describes giving OpenHands voice instructions on his walk to work and finding a pull request waiting when he arrives. In Brennan's walk-to-work prototyping anecdote, he discards 50% of the resulting pull requests and merges 50%. The point is the freedom to try an idea without committing to salvage every implementation.

A failed attempt leaves two useful choices:

• Close to correct: continue in the same conversation, where the agent already has relevant context.
• Far off target: discard the work and start a fresh conversation with a better prompt informed by what went wrong.

Throwing away tens of thousands of generated lines can feel wasteful to someone accustomed to code being expensive. But preserving a bad direction simply because it produced a large diff defeats the advantage of inexpensive experimentation.

Generated code still needs review. Brennan has seen organizations run into trouble by automatically merging AI output into production applications. Without scrutiny, the codebase accumulates duplicate implementations and technical debt. Pull the changes and run them locally or in an ephemeral environment; verify that they solve the requested problem. Experience can build confidence in an agent's recurring strengths, but confidence does not replace checking the result.

OpenHands' early pull-request workflow exposed a subtler failure. Generated PRs appeared under OpenHands, with the hands logo as their owner. The person who initiated the work could then approve the bot-owned PR, bypassing the team's requirement for another human reviewer. The separation between requester and nominal author weakened the intended review control.

Those PRs also lacked an obvious person responsible for moving them forward. A failing unit test could leave one languishing, and a merged change that broke something offered no clear human owner to approach. Brennan describes changing the workflow so that the initiating user's face appears on the PR. That person is responsible for getting it merged and for any later breakage. Delegating implementation does not delegate accountability.

Agents are generalists, but their broad capabilities become easier to use when work is broken into bite-sized steps. Merge conflicts are Brennan's favorite starting point. In the fast-moving OpenHands repository, his PRs frequently encounter conflicts. A comment such as @OpenHands, fix the merge conflicts on this PR delegates the comparison of earlier changes, the current PR's changes and the intent behind each.

Brennan says OpenHands resolves his merge-conflict chores 99% of the time. He supplies no evaluation denominator, task-selection criteria or measurement period. Reviewer feedback is another useful input because someone has already articulated the requested change: @OpenHands, do what that guy said points the agent at that specification. In his React example, a front-end engineer used terminology Brennan did not know well, but the agent understood the instructions and implemented the requested changes.

Small UI bugs can be delegated without the overhead of locating the file yourself. Brennan's example is an input rendered as text that should have been numeric. The essential change can be illustrated in JSX:

export function QuantityInput() {
  return (
    <label>
      Quantity
      <input name="quantity" type="number" />
    </label>
  );
}

Here, the relevant correction is changing type="text" to type="number"; the surrounding component provides a concrete example. Brennan recalls requesting his fix directly from Slack by referring OpenHands to the issue they had just discussed. He did not need to open his IDE or manually find the implementation.

Infrastructure changes often involve specialized syntax that is tedious to retrieve. For Terraform, the model may already know the syntax; otherwise, its browser can retrieve the documentation. Brennan describes an operational trigger as simple as an out-of-memory exception appearing in Slack, followed by a request for OpenHands to increase memory.

Database migrations are another task where conventions matter. Brennan admits that he sometimes neglects appropriate indexes or foreign keys and finds that LLMs tend to follow those migration practices well. The appeal is assistance with routine implementation details that are easy for a busy developer to overlook.

The first task finishes work already close to completion. The second improves a neglected part of the codebase without requiring a new product feature. Brennan describes passing coverage additions as generally safe to merge, making them an attractive early task within the review discipline established earlier.

Greenfield applications are appealing because the agent can produce an entire working surface quickly. Brennan repeats his warning against turning unreviewed generated code into a production application, then describes a different tradeoff for internal tools. His team built a web application for debugging OpenHands trajectories and sessions. Because it served internal needs rather than end users, they accepted lighter review instead of inspecting every line.

That internal debugging tool illustrates the business value of quickly building a small application for a specific need. The accompanying slide shows a separate, visible app result: an empty Todo List interface with an input, an Add button, All, Active and Completed filters, and a Clear completed control, alongside agent conversation screenshots. It is an example of the greenfield interface on screen, not a view of the trajectory debugger.

Brennan closes by inviting developers to build with the OpenHands community on GitHub, Slack and Discord. The practical opportunity is to turn well-bounded needs—including internal tools that might otherwise stay on a backlog—into reviewable working software.