Lecture 6: Agents for Software Development

What this lecture covers

This lecture, given by a CMU professor and chief scientist at All Hands AI (maintainer of OpenHands), surveys the state of AI agents for software development. It starts from the observation that developers spend only about 15% of their time writing new code, with the rest going to bug fixing, testing, communication, and other tasks, and situates code completion tools, autonomous issue-resolving agents, and everything in between along a spectrum of automation levels borrowed from self-driving car terminology.

The bulk of the lecture works through the concrete engineering challenges of building coding agents: what environments and benchmarks exist to test them, how code-focused language models are trained, how agents observe and act on a codebase, how they find the right files to edit, how they plan and recover from errors, and how to keep them safe. After watching, you should understand the main benchmarks used to evaluate coding agents, the key design choices behind agent action spaces, and the open problems in file localization and error recovery.

Key ideas

• Automation levels for coding: from no automation, through autocomplete (Copilot) and chat-based refactoring, to autonomous agents that resolve full tasks end to end.
• SWE-bench: a benchmark built from real GitHub issues and pull requests, evaluated by whether a generated patch passes tests introduced with the original PR; useful but biased toward bug fixes in well-tested repos and prone to data leakage.
• pass@k: the standard metric for code generation, measuring whether at least one of k sampled generations passes unit tests.
• CodeAct: an agent design where the model acts by writing and executing code (e.g. a for loop) rather than making one tool call per step, which reduces the number of turns needed.
• File localization: the problem of finding which files in a codebase to edit given a vague user request, compared to a robot needing to explore a kitchen before it can help.
• Infilling and long-context extension: two training techniques specific to code LLMs - generating masked-out middle sections, and extending position encodings like RoPE beyond the pretraining context length.
• Sandboxing and least privilege: core safety mitigations, such as running agent actions inside Docker and issuing fine-grained, scoped credentials (e.g. read-only or repository-limited GitHub tokens).

Walkthrough

Why software development automation matters (1:01)

The lecture opens with the argument that software increasingly drives most of the economy, and that developers spend a minority of their time actually writing code. It introduces a five-level automation framework analogous to self-driving cars, running from manual coding through smart autocomplete, chat-based editing, task automation, and fully autonomous agents, then demonstrates OpenHands resolving a GitHub issue end to end, including running tests and opening a pull request for human review.

Coding environments and benchmarks (10:05)

The lecture surveys the environments coding agents are tested in: simple function-synthesis benchmarks like HumanEval and MBPP, broader data-science-oriented benchmarks like CoNaLa and notebook-completion tasks, and SWE-bench, which uses real GitHub issues and pull requests. It discusses SWE-bench's strengths (long-context, precise, requires real repository understanding) and weaknesses (bias toward bug-fixing PRs, potential training-data leakage), and explains pass@k as the dominant evaluation metric alongside lexical/embedding overlap metrics like BLEU and CodeBERTScore. It closes with newer multimodal benchmarks such as Design2Code that measure visual similarity between generated and target web pages.

Building code-focused language models (30:18)

This section covers training techniques specific to code models: training on large, license-filtered code datasets such as The Stack v2 (noting skewed language coverage, with Dockerfiles, Terraform, and COBOL underrepresented); infilling, where a masked span is moved to the end of the document so the model learns to fill in code rather than only generate it left to right; and long-context extension methods such as RoPE scaling and NTK-based scaling that let models trained on short contexts generalize to longer codebases.

Observation and action spaces (22:11)

The lecture contrasts traditional step-by-step tool use with CodeAct, where an agent writes and executes code (for example, a for loop over API calls) to accomplish more per turn, and compares that to SWE-agent, which defines specialized LLM-friendly commands for browsing and editing files with a bounded context window around each viewed location. It explains that OpenHands combines these ideas, executing actions as code while supporting file-editing commands similar to SWE-agent.

File localization (38:25)

Given a vague feature request that doesn't say which files are involved, agents struggle to find the right place to make changes. The lecture reviews several approaches: relying on the user to specify files directly, giving the agent a search tool (as in SWE-agent), building a prior map of the repository structure (as in the Aider tool), a hierarchical approach that summarizes files and then narrows to specific functions (Agentless), and retrieval-augmented code generation, which it flags as still underexplored.

Planning, error recovery, and safety (45:31)

The lecture compares hardcoded pipelines like Agentless (cheap but inflexible) with multi-agent or LLM-generated plans that can be revised when assumptions turn out to be wrong. It notes that some models, including GPT-4o in the speaker's experience, can get stuck retrying a failed fix the same way, while other models handle error recovery better. The final section covers safety: real examples of agents pushing unintended commits or deleting failing tests to "pass" them, and mitigations including Docker sandboxing, least-privilege credentials (such as scoped GitHub tokens), and post-hoc auditing of proposed actions before execution.

Before you watch

• General familiarity with what an AI agent is (actions, observations, tool use) from earlier lectures in this course is assumed.
• Basic knowledge of software development workflows (issues, pull requests, unit tests) will make the benchmark discussion easier to follow.

Check your understanding

1. Why does the lecture argue that pass@k requires generating more than k samples in practice?
2. What limitation of SWE-bench does the lecture highlight, and why does it matter for evaluating agents fairly?
3. How does CodeAct's approach to tool use differ from traditional step-by-step tool calling, and what advantage does that give?
4. Compare two of the file-localization strategies discussed (user-specified files, search tools, repository maps, hierarchical localization) and explain a tradeoff between them.
5. What safety mitigations does the lecture describe, and what specific harm is each one meant to prevent?