Software engineering is shifting away from typing code and toward deciding what to build, how to structure it, and whether the result solves the right problem.
2
Coding agents work best on small tasks with a clear definition of done, such as resolving merge conflicts, fixing tests, and addressing pull request feedback.
3
A human must review agent-generated code, run it, and remain responsible for merging it and dealing with any breakage.
Summary
Robert Brennan explains how to use software development agents without creating noise or technical debt. He distinguishes autonomous agents such as OpenHands from autocomplete tools because agents can edit files, run commands, browse the web, and work for several minutes without constant input. Their strength is the repeated cycle of making an edit, running code, reading the result, and trying again. Their weakness is deciding what users and businesses actually need. Brennan recommends starting with small chores that have a clear definition of done and are easy to verify. Agents are especially useful for merge conflicts, pull request feedback, small bugs, infrastructure changes, migrations, failing tests, and test coverage. They can also build internal applications, where the cost of imperfect code is lower. Brennan is direct about review: the person who starts the task must own the pull request, inspect the output, and verify that it works.
Software engineering is moving toward decisions rather than typing
Brennan expects people to spend much less time writing code, while software engineering continues to require critical thinking. He describes the human work as asking what the user wants, what problem the organization is solving, and how the system should be structured for the future. AI is good at the repeated development loop of writing code, running it, reading the result, and editing again. It is weaker at business objectives and empathy for end users. The practical result is that engineers can spend less time leaning into an IDE and more time deciding what should be built.
A coding agent acts through the tools engineers already use
Brennan defines an agent around agency, meaning the ability to take actions in the external world. A software development agent gets a code editor, a terminal, and a web browser. It can modify and inspect the codebase, run commands, look up documentation, and use web pages. This differs from Copilot autocomplete, which fills in a few lines at the cursor. Tools such as Devin and OpenHands can receive one or two sentences, work for 5, 10, or 15 minutes, and return with a solution. Multiple agents can work at once while the engineer handles other work.
The agent loop depends on feedback from the outside world
Under the hood, an agent repeatedly connects a large language model to the external world. The model chooses the next action, such as reading a file, editing code, running a command, or opening a web page. The system performs that action and sends the output back to the model for the next turn. Brennan explains that each tool creates engineering problems. Editors need efficient find-and-replace or diff-based changes instead of printing whole files. Terminals must handle long-running commands, background processes, and parallel work. Browsers may need accessibility trees, Markdown, scrolling, JavaScript, or screenshots with labeled nodes.
Autonomous agents need isolation and tightly scoped credentials
Because an agent may run for several minutes without someone watching every action, Brennan treats sandboxing as a basic safety requirement. OpenHands agents run in a Docker container by default, separated from the user's workstation. He gives the example that this prevents an agent from running rm -rf on a home directory. Agents increasingly receive access to services such as GitHub or AWS, which changes the risk. Brennan says those credentials must be tightly scoped and granted according to the principle of least privilege.
Small tasks with a clear finish line are the best starting point
Brennan advises new users to begin with work that can be completed quickly, often in a single commit. The agent should have a clear way to check whether it succeeded, such as passing tests or resolved merge conflicts. Small chores are especially suitable because they are repetitive and easy for an engineer to verify. Examples include a failing test, lint errors, and merge conflicts. As users gain intuition and learn how to communicate with the agent, they can assign larger tasks. Brennan says that about 90% of his own code now goes through an agent, while he returns to his IDE for roughly 10% of the time.
Specific instructions reduce errors, time, and inference cost
An agent needs to know both the desired result and the requested method. Brennan recommends naming the framework, asking for a test-driven development approach when appropriate, and identifying particular files or functions. These details reduce the amount of time the agent spends exploring the repository. They also make the requested output clearer and reduce token and inference costs. He treats generated code as cheap enough to discard. After trying an idea from his walk to work, he may find a pull request waiting when he arrives, then either merge it or throw it away. If an attempt is far off, he recommends starting a fresh conversation with a better prompt.
Brennan calls code review the most important practice in agent-assisted development. Organizations that automatically merge generated code can accumulate duplicated code and technical debt. Engineers should inspect the output and run it on a workstation or in an ephemeral environment. OpenHands learned this through its pull request workflow. When the agent owned a pull request, the triggering human could approve it and bypass the second-human review requirement. Nobody clearly owned stalled pull requests or later breakage. Now the person's face appears on the pull request, and that person is responsible for getting it merged and for problems caused later.
Agents are strongest on defined chores and internal applications
Brennan lists several practical uses. OpenHands resolves merge conflicts on OpenHands pull requests 99% of the time, in his estimate, because the intended changes are usually clear. It can apply written pull request feedback, fix small bugs, change infrastructure configuration, handle database migrations, repair failing tests, and expand test coverage. Building an application from scratch is also useful when the result is an internal tool and does not face end users. Brennan's team used this approach for a web application that helps debug OpenHands trajectories and sessions. He still warns against using the same approach for production software without review.
"We're paid not to type on our keyboard, but to actually think critically about the problems that are in front of us."00:51
Who should watch
You are considering autonomous coding agents and need practical guidance on where to start.
Your team is already generating code with agents and wants to avoid unattended merges and growing technical debt.
You maintain internal tools or repetitive repository chores that have clear tests or other ways to verify completion.
