Hannah Foxwell began her QCon London 2026 talk by noting that the long-sought velocity in development has arrived, but the industry is unsure how to use it. She set aside the technical details of agentic coding, focusing instead on its implications for the people working with these systems.
This is a talk about AI, but I'm not going to talk about the agents at all. I'm going to propose that they are coming, that they are here, and I'm going to talk about the humans and what we do as teams to adjust to this massive change that is happening in our industry
Foxwell, the founder of AI for the Rest of Us and BIMP.ai, opened by tracing her own career through successive waves of velocity, from shipping twice a year on a mainframe team to continuous delivery at scale. She suggested that the arrival of agentic coding is another step change, but one that creates novel organisational pressures rather than simply extending existing ones. She briefly described Steve Yegge's eight-stage developer evolution model, and suggested that Gas Town (Yegge's agent orchestration framework, which operates at stage 7 and 8 of the model) is "a little glimmer of what the future might look like for all of us".
Foxwell stated that there's already been an inflection point in LLM-supported coding, with agent requests now overtaking tab-completion coding as the dominant form of interaction, in tools such as Cursor, and this has happened very quickly as the capability and reliability of agents has increased so rapidly.
Having set the scene of the rise of agentic AI, with other QCon talks explaining the state of the art for reliable agentic engineering practices, Foxwell structured her talk around grounding this vision of the future in what these advances mean for the humans involved. She introduced three anchors she believes will remain true regardless of how capable agents become.
- We must build something worth building
- Speed requires safety
- People matter
The first anchor is that teams must build something worth building. Agentic coding introduces back pressure on product functions: developers are now producing features faster than product managers can supply well-qualified work to fill the pipeline, and Foxwell said she is now seeing development teams run out of backlog for the first time in her career. She advised not saying "yes" to everything.
"Enshittification is a thing," she noted, referring to the phenomenon of platforms becoming bloated with features that collectively serve nobody well. She explained that the cost to test ideas has collapsed, making a more experimental product culture much more viable with a new breed of "vibe-coding PMs" who prototype ideas with AI tools before committing them to a formal product backlog. Looking at team structure, she suggested that using forward-deployed engineers and product engineers helps shorten feedback loops with real users. She also challenged the two-pizza team norm: Norges Bank Investment Management (NBIM) is experimenting with much smaller team ratios, while others have proposed the opposite, placing two product managers alongside a single developer who orchestrates a fleet of agents.
Foxwell's second anchor is that speed requires safety. She drew on an AWS case study describing how the organisation achieved 10x throughput through agentic coding, only after completely rethinking its testing, deployment and coordination practices. "They couldn't just bolt on the speed of AI to what they were doing," she said. "They had to re-engineer that path to production." She also cited JPMorgan Chase's agentic testing framework that "never gets tired or bored," which catches edge cases that developers under time pressure might miss.
Foxwell also returned to SRE practices, specifically the error budget policy, which she described as a written commitment to users about what a team will do when reliability targets are missed. She suggested that the SRE function, which she had previously considered an anti-pattern when siloed from development teams, may be due for a comeback as an internal consultancy helping teams maintain reliability when delivery is so much faster.
Her third anchor was that people matter. Reviewing large volumes of AI-generated code, she said frankly, is not fun. She pointed to Joseph Ruscio's "write-only code" concept, which posits that much of the code produced by agents may never be read by humans. If that becomes the norm, she argued, the peer review process must shift left: rather than reviewing pull requests after the fact, engineers should review specifications, test strategies and architecture before any code is written.
On the question of skills, Foxwell returned to an idea introduced at QCon London 2025 by principal engineer Sophie Weston: the "broken comb." Where a T-shaped developer has one deep specialism, a broken-comb engineer cultivates a broad base of knowledge with several areas of depth. Foxwell argued this is the shape of an engineer best suited to working alongside agents, and she encouraged managers to use it as a framework for team development.
She closed with a personal case study. In a team of two, she built BIMP, a base image management platform, over two weeks using Cursor in agentic mode. The team repeatedly exhausted their daily goals before lunchtime and had to unlearn the habit of ruthless prioritisation. Documentation was generated in minutes and a codebase refactor took hours. "The experience of building a product at the speed of AI has been incredibly insightful," Foxwell said, "and it did make me way, way, way more ambitious about what I might build in the future."
Foxwell was careful to avoid being too prescriptive. Most organisations, she noted, are not yet ready for fleets of autonomous agents. But she encouraged engineers to start experimenting now, both with agentic tools and with the organisational changes those tools will eventually demand. "I want us all to feel confident about the roles we have in the future," she said. "I want us to feel like we have a place in this world of agents."