At QCon San Francisco 2025, Michelle Brush, engineering director of Site Reliability Engineering (SRE) at Google, delivered the closing keynote “Humans in the Loop: Engineering Leadership in a Chaotic Industry” on November 19, 2025. Speaking to a room of software leaders, she explored the broader changes underway in software engineering, systems thinking, and leadership through complexity.
She opened by acknowledging the uncertainty that many practitioners feel, affirming that this was a shared experience and an expected part of navigating today’s technological landscape. Brush, who contributed two chapters to “97 Things Every SRE Should Know”, argued that the nature of software engineering work is shifting, not disappearing. She noted that she had explored similar themes in an earlier keynote at the InfoQ Dev Summit in Boston, and stressed that as AI systems automate pieces of software development, engineers will face harder and more complex challenges.
“Large language models are, by their nature, unconsciously competent—they know a lot, but they can’t explain it. When they hallucinate, that’s just the model being unconsciously incompetent for a moment and filling in the blanks with something that sounds plausible.”
Citing Lisanne Bainbridge’s classic paper “Ironies of Automation”, she explained that “when you automate some piece of work, the job that you leave behind for humans to do is actually harder.” The result is a landscape where engineers must monitor, debug, and validate automated systems, even as their direct responsibilities evolve.
She illustrated this point with a simple analogy: “Dishwashers are great… but we didn’t get rid of all the work.” While machines may handle routine tasks, humans are left with responsibility for exception handling, quality assurance, and system maintenance. In software, this translates into higher-level abstraction work, deeper troubleshooting, and a reliance on engineering judgment. “Our brains are going to start working on higher and higher abstractions,” she said, emphasizing the cognitive shift required in modern development.
Brush explained that large language models (LLMs) today operate with a kind of “unconscious competence.” They can produce impressive results but lack explainability and awareness of their limitations. “They don’t know what they don’t know,” she said, framing hallucinations as a natural byproduct of this architecture. By contrast, humans sit in the space of “conscious competence”—we understand what we know and can explain it, which is essential for teaching, mentoring, and validating machine outputs.
A central concept in her talk was the importance of “chunking,” or cognitive encapsulation, as engineers deal with increasing complexity. She argued that the ability to move between abstraction layers—while still being able to drill into the underlying systems—is crucial. “All abstractions leak,” she reminded the audience, “especially our hardware abstractions.”
“Dishwashers are great; we love them. But we didn’t get rid of all the work—now we have to know when the dishwasher is done, check whether every dish is actually clean, debug why it isn’t, and sometimes become amateur dishwasher repair technicians.”
She connected these themes to the current economic and hardware landscape: the end of zero-interest rates, renewed cost pressure, and fierce competition for specialized AI hardware such as GPUs and TPUs. Referencing Jevons’ paradox, Brush argued that as AI makes software development faster and cheaper, organizations will not do less engineering work but dramatically more—and that leaders must use techniques like non-abstract system design and back-of-the-envelope modeling to understand the real compute, storage, and reliability costs of their architectures before they build them.
Brush went on to frame reliability and complexity management as core leadership responsibilities. Drawing on Richard Cook’s essay “How Complex Systems Fail”, she described outages as emerging from hidden interactions in systems that are “working as designed,” and advocated investing in generic mitigations—safe rollbacks, traffic shedding, moving workloads off bad hardware, and other fast levers that restore service even when the exact failure mode is unknown. She closed by emphasizing experimentation, hypothesis-driven change, and deliberate mentoring and delegation as essential ways to grow the next generation of engineers who will have to operate these increasingly autonomous, opaque systems.
Sharing a case study from Google, where the SRE organization has been evolving for more than two decades, Brush detailed a 2019 outage that brought down two data centers due to runaway automation. The assumption that geographic distribution was sufficient proved wrong when a third data center also failed under the load of recovery traffic. The takeaway? “We realized we needed to be in more than just three data centers,” she said. The response involved not just more capacity, but smarter design—using latency injection testing and intent-based rollout systems to surface risks before deployment and reflecting the lessons highlighted in resources like Google’s “20 Years of SRE” retrospectives.
Developers looking to learn more can follow InfoQ’s coverage of the event and watch for videos to appear in the coming weeks.
