Andi Gutmans, a contributor to the creation of PHP 3 and head of the Agentic Data Cloud at Google, does not present agent-based software development as a complete break with the past. In a conversation with Eira May and Peter O'Connor on Stack Overflow's Leaders of Code program, he compared the current shift with the impact PHP had when it made building websites possible for more people, including those without a background in computer science.
But this new accessibility does not mean the disappearance of engineering expertise. According to Gutmans, the individual developer is gradually becoming something like a “leader of a team of agents”: defining what is needed, distributing the work, reviewing the results, and making decisions that cannot be delegated without limits.
Value Is Shifting from Writing Code to Engineering Judgment
Gutmans believes that some fundamental questions have not changed with the emergence of agents. Teams still need to ensure that the solution addresses the right problem, that the architecture is scalable, and that the system is secure, well governed, easy to use, and cost-effective. What is new is that an agent can carry out more work autonomously, so the way it is supervised must be designed rather than simply relying on reviewing the resulting code.
Gutmans gave an example of this when he used one agent to create about one thousand tests, then used another agent to criticize those tests. The review revealed that the output was not good enough, and he had to improve it himself. In this case, the need for human judgment did not disappear; its position shifted from detailed execution to design, coordination, and evaluation.
This change also extends to understanding an unfamiliar codebase. Agents can navigate a broader scope of a project and may uncover categories of errors that are difficult for a human reviewer to detect when examining a limited part of the system. Nevertheless, Gutmans said that Google uses human review and agent review together, especially when decisions or changes are sensitive.
Review Is Not a Matter of Absolute Trust but of Risk Management
The conversation proposes viewing oversight through three modes: the human in the loop, the agent in the loop, and the agent above the loop. This does not mean choosing one approach that is valid for every situation, but rather determining the appropriate level of review according to the likelihood of error and its impact.
For changes involving sensitive security components, such as security tokens, the participation of a human expert is more important. For CSS and HTML modifications or some Python scripts, with the agent assisting in a security check, it may be practical to rely on a different level of automation. The central idea is not that agents do not make mistakes, nor that humans review everything with equal efficiency, but that the review decision should reflect the scale of the risk and its consequences.
Gutmans used Waymo's experience as an illustrative example of the gap between perception and data. He said that the likelihood of a person being involved in a harmful accident is 80% lower with Waymo than when riding with an Uber driver, even though many people still feel more comfortable when a human is behind the wheel. Similarly, a team may reject agent autonomy because of its impression, even when the indicators suggest that using it for a specific task could reduce risks compared with the human alternative.
Hiring and Learning Are Moving Toward Testing the Ability to Direct
Gutmans believes that computer science education will not stop, but students will be able to complete more complex and broader projects with the help of agents. Therefore, knowledge of how to build, operate, and scale systems will remain essential, while the ability to frame the problem, evaluate solutions, and direct intelligent tools will also become important.
He said that Google is changing part of its engineering interview process. Instead of focusing on asking a candidate to write an algorithm such as quick sort manually, it will allow the candidate to use Gemini and the agent to solve a problem, then evaluate their thought process, their sequence of handling the problem, and how they direct the agent. This does not eliminate technical skills, but it changes what the interview seeks to measure: from the speed of producing an abstract solution to the quality of reasoning, design, and coordination.
The Biggest Obstacle May Be in the Data, Not the Models
According to Gutmans, models such as Gemini and Opus have become capable of automating a large proportion of enterprise tasks, so the models themselves are no longer the only main bottleneck. The more important challenge is making enterprise data understandable and usable by agents while preserving semantic relationships, permissions, and governance.
This includes structured and operational data, as well as images, PDF files, contracts, and other unstructured data located in cloud storage or elsewhere. Google believes that agents can help discover where data is located, understand its connections, and build semantic models that previously required large numbers of data stewards. Gutmans describes this direction within the concept of a “borderless lakehouse,” which aims to activate data regardless of whether it exists in GCP, AWS, Azure, or on-premises environments.
He also pointed to the importance of open data formats such as Iceberg and said that intercloud integrations could help access data without relying entirely on data-transfer fees charged per gigabyte. He also discussed a “knowledge catalog” and the shift of ontology construction from a process led entirely by humans to one led by agents, with humans remaining in the role of coordination and editing rather than performing heavy manual work.
What changes in practice? For technical teams, it is not enough to provide a software agent and then leave it to work. Effective use requires identifying the tasks that merit automation, establishing review levels appropriate to their risks, and ensuring the quality of the data and permissions to which the agent has access. As for the developer, their role does not disappear; instead, it becomes closer to that of an engineer directing a set of tools capable of execution and bearing responsibility for the final judgment about what they produce.