Abstract

We spent decades making it safer to change software. Then we gave an AI agent access to the repository.

That agent arrived with some extraordinary advantages. It could work on a branch, run tests, inspect a failure, and submit a change for review. Engineers had already built ways to describe the desired behavior, check the result, and keep an experiment from immediately becoming a production incident.

Those advantages are easy to overlook when we talk about what makes coding agents useful. They are also much harder to find when we ask an agent to do other work.

Consider onboarding a new employee. One request might involve an HR system, identity provider, payroll application, and several team workspaces. Each application has its own permissions and its own account of what happened. There may be no place to preview the complete change, no test that proves the person has everything they need, and no single operation that undoes a mistake. A human usually supplies the coordination between those systems.

This talk examines what coding agents inherited and what it would take to build equivalent support for agents working across the rest of an organization. We’ll explore how familiar practices such as code review, staging, and automated verification translate to work that crosses application boundaries. We’ll also examine where the analogy breaks: passing tests never proves everything, and reversing a database update cannot unsend an email.

Attendees will leave with a way to assess whether a workflow is ready for delegation, identify the infrastructure it lacks, and decide which lessons from software engineering actually apply.

Key Takeaways

• Recognize how repositories, automated checks, and review workflows support the capabilities of coding agents.
• Understand why a task spanning several applications creates coordination problems that individual integrations cannot resolve on their own.
• Apply software engineering practices to preview proposed actions, verify resulting state, and recover from partial completion.
• Identify where knowledge work requires different approaches to correctness and recovery than changing code.
• Assess readiness for delegation by examining the environment around an agent as well as the model’s capabilities.

Questions

• How much of a coding agent’s usefulness comes from infrastructure we built before the agent existed?
• What is the equivalent of a pull request for a change that spans several business applications?
• How can we verify that an employee is fully onboarded when each system only knows about its own part?
• Which actions can we preview or reverse, and which need stronger checks before execution?
• Where does the comparison with software engineering help us, and where does it lead us astray?