The pizza party of the future - teams, architecture, and product value in the age of coding agents

AI will have a huge impact on our software development teams and our software architecture - nobody is sure how exactly, and Simon and Katie don’t have the perfect prediction either!

This is not the first time the way we approach software teams has changed: we’ve gone from silos and super specialization to cross-functional Scrum teams and 2-pizza teams; T-shaped and M-shaped professionals to full-stack, DevSecFin…Ops, value streams, Team Topologies and more. We’ve added all kinds of coaches and then removed them again.

Now that these teams have AI coding agents doing the typing we are seeing “new” (or maybe not so new?) bottlenecks: value questions (domain/product/requirements) and trust questions (quality/testing/reliability/architecture/process). And we’re seeing suggestions from moving down to one-pizza-teams or even just a product owner and their AI wrangler.

So who is invited to the pizza party of the future? Who makes decisions, who takes responsibility, what new and old roles and skills will be needed? And who is no longer welcome?

We’ll take a look at what some of the friendlier agile critics from the past can tell us. We will see how their takes can help us move to a more value-oriented future with agents and humans collaborating on user needs.

Co-Speaking with Simon Rohrer

Transcript

1. KATIE CLARK PIZ the Y T R A P A Z SIMON ROHRER of the future SOFTWARE TEAMS & PRODUCT VALUE IN THE AGE OF CODING AGENTS
2. Some pizza orders we spotted online 2 3 4 5 7 8 9 10+ #people
5. PIZ the Y T R A P A Z of the future
6. Rabbit holes + sources https://futurepizzaparty.substack.com/
7. PARTY 2: POSSIBLE FUTURES TAKEAWAY PIZZA PIZ PARTY 1: PAST ERAS the Y T R A P A Z of the future
8. User guide Scope Breadth instead of depth Timelines Bear with us! Party 2 is coming soon! Quotes & people We like them! If you don’t, feel free to ignore “A therapy session for developers” Anonymous commenter #1, Oct 2026 “This could be 3 talks” Anonymous commenter #2, Oct 2026 Audrey Hobert – Bowling Alley
9. (2013/20) • From ITIL to agile • Distributed systems & cloud • Complex domains (supply chain etc.) Our eras 1950 1960 1970 1980 (1994) • Waterfall & V-model • XP white book • Highly regulated environments (banking) 1990 2000 2010 “There are a number of asterisks but imo coding agents basically didn’t work before December and basically work since.” Andrej Karpathy, Feb 2026 ! 2020 2030 (2025) • LLMs & agentic dev
10. AI looks like this massive wrecking ball, but it’s not the first one • Languages & Paradigms • Ways of Working • People & Team Management Miley Cyrus – Wrecking Ball
11. Rick Morris, LinkedIn post, April 2026
12. Look at the timeline of languages & paradigms through the lens of collaboration FORTRAN (1954) COBOL (1959) “It was… intended (and expected) that [COBOL] could be used by novice programmers and read by the management.” Jean Sammet, The Early History of COBOL, 1981 SQL (1970) 1950 OO 1960 Simula (’61) 1970 Smalltalk (’72) xDD No-code (2014) Visual Basic (1991) 1980 1990 C++ (’80) SUnit (’89) “Object technology lets developers work in users’ and executives’ vocabulary […]” Alistair Cockburn, Surviving OO Projects,1997 LLMs & agentic dev (2025) 2000 Java (’95) 2010 ! 2020 Evans (’03) JUnit (’97) BDD (’03) XP (’99) Snowbird (’01) Agile 2030 DDD
13. AI looks like this massive wrecking ball, but it’s not the first one • Languages & Paradigms • Ways of Working • People & Team Management Miley Cyrus – Wrecking Ball
14. We have tried all these different ways of… • dealing with uncertainty and complexity • coordinating a group of humans • specifying what we want a.k.a. playing “telephone”
15. Waterfall was a myth and agile became a way of managing Defense Science “all the elements of the Board W.W. Royce Managing SAGE the Development of Large development Systems (1970) process Herbert Benington (1956) reveals SAGE used Software Factory prototyping (1983) dream: NATO S/w Eng Conference (1968) 1950 1960 1970 1980 recommends waterfall mandate be dropped for iterative prototyping (1987) 1990 2000 SCRUM PLoP Agile roots Tom Gilb, Software New New Product Development Game (1986) paper (1995) Metrics (1977) “By definition, ‘agile’ existed before the Manifesto” Alistair Cockburn, LinkedIn comment, August 2026 Conversations & fast feedback standard [Waterfall] myth turn out to be false or at least substantially at odds with the historical record” Laurent Bossavit, Leprechauns of S/w Engineering, 2012 2010 ! 2020 Manifesto for Agile S/w Dev. (’01) Dark factory dream (2025) 2030 …the Curious Absence of Scrum: Orosz (2021) “Agile today… is used to manage developers instead of empowering them” Fadi Stephan, A Behind the Scenes Look at the Writing of the Agile Manifesto, 2021 From agility to capital ‘A’ Agile Processes & tools
16. And either way we often ended up building feature factories not value “2. Welcome changing requirements, even late in development […] “7. Working software is the primary measure of progress. This principle is ridiculous, except if writing code is the only purpose in life.” Tom Gilb, gilb.com, Jul 2019 If you mean a design, then yes. If you mean your success criteria, then that’s another story. These might change as you learn, but you actually don’t want constantly changing goals.” Charles Lambdin, Agile Light & Dark and Becoming ValueDriven, Jun 2021 “The questions that rarely gets asked in these organizations however, are: • Which features should we build? • Did we build the right ones? • Did we design them well? • Did we optimise them to achieve maximum value for our customers and our business?” Jeff Gothelf, Agile Doesn’t Have a Brain, Oct 2014
17. Others have long been warning that one size does not fit all and context is key “[components] move from an uncharted space (the novel, the chaotic, unpredictable, uncertain, potential differential) to the more industrialised (the common, appearance of linear order, the predictable, the certain, the cost of doing business)” Simon Wardley, blog post, Nov 2013
18. AI looks like this massive wrecking ball, but it’s not the first one • Languages & Paradigms • Ways of Working • People & Team Management Miley Cyrus – Wrecking Ball
19. Coding was once stereotyped as ‘women’s work’ “A good programmer was concise and elegant and never wasted a word. They were poets of bits […] In the United States, by 1960, according to government statistics, more than one in four programmers were women. […] It wasn’t high-status work — yet.” New York Times, February 2019 “It’s just like planning a dinner. […] Women are ‘naturals’ at computer programming […] For every computer girl, there are eight computer men. […] There’s no sex discrimination in hiring. The girl with a college degree in math, physics or engineering can start off her computing career […]” Cosmopolitan Magazine, April 1967
20. Then we started hiring some different stereotypes 1966 Does anyone work with this guy? “Figure 2: Programmers are crazy about puzzles, tend to like research applications and risk-taking and don’t like people.”
21. The 10x myth will not go away https://1x.engineer/, Cher Scarlett, 2019 Taylor Town, 2023 1950 1960 1970 1980 1990 2000 2010 ! 2020 2030 “the 10x claim is poorly supported by empirical evidence; that is, essentially anecdotal. It persists largely because we lack any well-articulated theory of what productivity consists of for a programmer.” Laurent Bossavit, Leprechauns of S/w Engineering, 2012 Boehm et al. Mills 1983 Card 1987 2000 Study: Sackman DeMarco and Boehm and Valett and Curtis 1981 Lister 1985 Curtis et al. 1986 et al. 1968 Papaccio 1988 McGarry 1989
22. Offshoring & outsourcing treated all coding as standardised, deskilled work “Activities offshored are those which: are standardised, can be precisely defined, and may even be considered tedious, repetitive, and undesirable. Hence, coding and maintenance, which can be well defined, are often offshored” Outsourcing / offshoring to an army of agents Dark factories “Circa 1995: The phenomenon of offshoring [software development] was starting to gain prominence” Carmel & Tjia, Offshoring Information Technology, 2005 1950 1960 1970 1980 1990 The Kodak wave starts in 1989 with Kodak/IBM outsourcing their data centres but not development 2000 2010 ! 2020 “Circa 2005: Offshoring of IT is now an irreversible trend and is regarded as a business necessity” 2030
23. We saw three ways developers were treated as people 3. A full-stack crossfunctional team of Tshaped people 2. “Lone genius” Rockstars / ninjas Full-stack developers 1. Dumb individuals “Clearly, this man must be, in some sense, a generalist rather than a specialist. The ideal systems engineer is a ‘T-shaped man,’ broad, but deep in one field.” Hyper-specialization Code monkey Robert E. Machol, System Engineering Handbook, 1965
25. We saw (and keep forgetting?) everything published about teams & psychology Egoless Programming Cognitive Load Psychology of Computer Programming, Weinberg (1969) 1950 1960 Cooperative Game Cognitive Load During Problem Solving: Effects on Learning, John Sweller (1988) 1970 1980 Agile Software Development: The Cooperative Game, Cockburn (1999) 1990 T-Shaped Man 2000 Brains-in-Jars Psychology of S/w Teams, Hicks (2026) 2010 ! 2020 Glue Work Machol, System Engineering Handbook, 1965 The Staff Engineer’s Path, Tanya Reilly (2022) Semi-autonomous Teams Jelled Teams Psychological Safety Longwall mining study, Trist & Bamforth (1951) Peopleware, DeMarco & Lister (1987) Psychological Safety and Learning Behavior in Work Teams, Amy Edmondson (1999) 2030
26. Cross-functional teams don’t need to be stable – they can be dynamic or fluid So instead of asking what’s the best structure of teams to deliver value / impact… Forming → storming → norming → performing (Tuckman) is not replicable …ask how do we get people into the same shape as the work that needs to be done Daniel Terhorst-North, Shaped By Demand: The Power of Fluid Teams, October 2024
27. “The notion of people as resources is deeply ingrained in business thinking, it's roots going back to the impact of […] Taylor’s Scientific Management approach. […] But for the highly creative and professional work, which I believe software development to be, this does not hold.” Martin Fowler, The New Methodology, July 2000
28. And we’re off on a tangent… Taylor vs. Drucker
29. And we’re off on a tangent… Taylor vs. Drucker 1911 1959
30. Taylor(ist) Drucker(ist) “Ox-like man” “Knowledge worker” Outsourcing, offshoring Self-managing teams Dark Scrum, SAFe Extreme Programming Desert Forest Optimise technical Co-optimise social & technical “Knowledge Workers have to manage themselves. They have to have autonomy.” Peter Drucker, KnowledgeWorker Productivity:The Biggest Challenge, 1999 “My mission: help geeks feel safe in the world. Everything I’ve done fits somehow” Kent Beck, medium.com, June 2022 Socio-Technical Systems design
31. Socio-Technical Systems design started in the coal mines & evolved way beyond Merrelyn & Fred Emery Eric Trist & Ken Bamforth (1951) The Causal Texture Organizational of Organizational Choice Environments (1965) (1963) 1950 1960 1970 Design Principle 1: Redundancy of parts Design Principle 2: Redundancy of function Deskilled people: interchangeable people given clear tasks with external control T-shaped people: each person holds multiple functions and the team holds the whole task The Next 30 Years: Concepts & Anticipations (1967) 1980 1990 Humane work design combining both how & who 2000 2010 2020 2030
32. Calvin Pava extended STS design into the “digital coal mines” of modern office work Pava distinguished non-linear work requiring distinct working patterns. …but “discretionary coalitions” of stakeholders organised around “deliberations” – prioritised conversations. Not just stable self-managing work groups like for linear, routine work… Conversations, not handoffs Managing New Office Technology (1983) 1950 1960 1970 1980 1990 2000 Recent echoes 2010 2020 2030
33. Taylor Drucker But the pull of Taylorism and scientific management remained strong
34. Party 1 bowling scorecard Wobbling Many attempts but we are still here Wobbling The anti-social Wobbling Offshoring and stereotype & Taylorism are outsourcing sometimes still here work
35. PARTY 2: POSSIBLE FUTURES TAKEAWAY PIZZA PIZ PARTY 1: PAST ERAS the Y T R A P A Z of the future
36. As we move forward into an AI native future Will that be based on teams and collaboration? Or people and AI agents as resources? Miley Cyrus – Wrecking Ball
37. The future is already here, it’s just unevenly distributed William Gibson, https://quoteinvestigator.com/2012/01/24/future-has-arrived/
38. First bowling attempt Two pins at once
39. “Coding is going away first, then all of software engineering.” Nikhil Kamath, Dario Amodei: The AI Tsunami is Here & Society Isn't Ready, Feb 2026
40. We don’t think the developer role will go away But it will change Like many other jobs in the past Taylor Swift – Change (Taylor’s Version)
41. The human role is shifting Mining Supervision
42. The human role is shifting Coding Verifying Syntax Knower Human-in-the-Loop? Code Review Monkey? Meat Proxy? …?
43. The human role is shifting Developers T- or π-shaped person! Domain + architecture 2 Emerging Paths Expert Generalist Builder Enabler Enables humans and agents!
44. Which seems closer to what you’re seeing right now? 1 Developer Verifying 2 Coding 2 Emerging Paths Expert Generalist Builder Syntax Knower Enabler
45. Not everyone is shifting Developer ??? Brett Codes, I’m done using AI, August 2026 Boycotting AI due to depression, apathy, brainrot, existential dread, …
47. ¼″ drill Syntax knower? ¼″ hole As a developer what is your “job to be done” System engineer? Hang picture Problem solver? Happier life Value optimiser?
48. AI is a threat or a superpower, depending on the role you’ve been allowed to play “If a developer has spent a decade only being allowed to type code — never designing, never talking to customers, never deploying — where would they get the confidence to suddenly do more? Taylor / deskilling Drucker Expert Generalist Builder What if the system they're working within that has narrowed their role also destroyed their ability to outgrow it?… The pinnacle of this madness: make the job codes in your organization hyper-rigid so that you can outsource the whole function, and switch between outsourcers every couple of years. In contrast, when developers know their job is to solve problems, they see AI as a superpower, not an existential threat. ” Gene Kim (w Annie Vella) – LinkedIn post, April 2026
49. But the three ways of 2. “Lone genius” treating developers are still Single-player mode Me and my 50 agents there, now with agents “…where we find ourselves in a lot of our environments, is making sense of things together… 1. Dumb individuals Meat Proxies Code review monkeys “Brains in jars” 3. A full-stack cross-functional team of Tshaped people in multi-player mode that learns together Even if you're dealing with a fairly straightforward, regular problem, it's good to get together as a team” John Cutler, Single Player to Multiplayer: AI, Context, and Collaboration, April 2026
50. Speaking of learning: What about juniors? Adele – When we were young
51. Juniors or agents “So, why are people saying an LLM is like a junior developer? […] I’ve got two theories and neither of them is very pleasant. Taylor Drucker 1) treat juniors like transactional robots 2) replace juniors with robots I urge you to treat the machine like a machine and the people like people.” Daniel Terhorst-North, The Junior Developer Crisis: How to Build a Team When AI Does the Entry-Level Work, April 2026
52. Juniors and agents “The hardest thing about quantifying the value of junior engineers 10x is a myth is we don't know how to quantify the value of any engineer. It's all vibes. […] I believe that the kids are going to be okay. We just have to hire them. We just have to give them a shot.” Charity Majors with Gergely Orosz, Stop being skeptical about AI for development, August 2026
53. The barrier to writing software has collapsed… …but the barrier to engineering has not
54. Everyone can code now, so roles are blurring Maintainers Taylor Sweepers Growers Builders Engineering Prototypers Design Product User Research Data Science “And so I’ve started to think that the roles are actually segmenting in kind of the opposite way. ” Boris Cherny (Anthropic), Bloomberg Odd Lots podcast, July 2026
55. In some ways this is not new Boris Cherny 2026 Maintainers Sweepers Growers Builders Prototypers Kent Beck 2016 Simon Wardley 2015 Town Planners Villagers Explorers But with added nontraditional developers!
56. Build strong teams of T- and π-shaped humans They don’t need to fit your current stereotype to code • juniors • non-techies • social beings Lorde – Team
57. Second bowling attempt How about a spec-driven software factory?
58. " Spec-as-source SPEC.md Specify a thing The dream: stop editing the code, then stop reading it # $$$$ Plan a thing Code a thing Validate / verify a thing Deploy a thing % Shiny software Use a thing Dark Factory (aka Lights-Out) Dan Shapiro, The Five Levels: From Autocomplete to the Dark Factory, January 2026
59. " But sometimes you need to turn the lights up Spec-as-source for now SPEC.md Specify a thing Dim factory (some lights) $ $ $ Plan a thing “We built a lights off software factory in July of 2025 and by November we had shut it down” Dex Horthy with Gergely Orosz, Context Engineering, July 2026 Code a thing Validate / verify a thing % $ Shiny software Deploy a thing Use a thing
60. Zoom in: “One damn ticket after another” " And sometimes you need to zoom out to the system intent… Spec for now SPEC.md Specify a thing Programming as theory building, Peter Naur, 1985 Zoom out: “Cosa nostra” – what is “this thing of ours”? Dim factory (some lights) $ $ $ Plan a thing Code a thing Validate / verify a thing $ Shiny software Deploy a thing Use a thing Users / stakeholders /context Long-lived system context & intent " " User needs / values Goals Domain “…you actually don’t want constantly changing goals”, Charles Lambdin, Agile Light & Dark and Becoming Value-Driven, Jun 2021
61. …and always watch what it does in production " Observability 2.0 Spec for now SPEC.md Specify a thing $ $ $ Plan a thing Code a thing /context Long-lived system context & intent " " Validate / verify a thing % $ Shiny software Deploy a thing Use a thing “Production is where the users live and the money gets made… The spec describes intent. Telemetry describes reality.” Charity Majors, Production Is Where the Rigor Goes, Mar 2026 • Did we build the right [features]? • Did we design them well? • Did we optimise them to achieve maximum value for our customers and our business? Jeff Gothelf, Agile Doesn’t Have A Brain, Oct 2014
62. The engineering moves from the prompt to the harness " Spec for now SPEC.md Specify a thing $ $ $ Plan a thing Code a thing /context Long-lived system context & intent " " Validate / verify a thing $ Shiny software Deploy a thing Use a thing “Stop fixing the code that the agent kind of produced, but improve the system” Patrick Debois, The DevOps Godfather on AI's “Dark Factory” Problem, July 2026 Birgitta Böckeler, Harness engineering for coding agent users, April 2026
63. We've been here before with offshoring – one size does not fit all Wardley map Cynefin “Distance demands specification. Complexity forbids it.” DDD Michael Plöd, Staffing and Procurement for Fast Flow, March 2026
64. Another brief tangent What are we actually doing here? Olivia Rodrigo – Deja Vu
65. What is software development? Managers Conception Taylor Analysts “thinking” Architects “thinking” Developers / Robots “supervising / typing” Workers Execution SPEC.md Code Linear or Partially non-linear “Programming is not about building software; programming is about designing software” Conception Conception Conception Execution Execution Conception Execution Xin Yao, Having Your Agile And Your Agility Too, Feb 2026
66. Spec-as-source & dark factories do work – just not everywhere Local change For spec-assource, the spec must become… → pseudocode Spec-as-source Dark Tests judge results Linear →code Spec for now Dim (review code / tests) People judge results Partially non-linear Evolution (Wardley) Spec for now Dim (review code / tests) People check boundaries Partially non-linear system Systemic change Spec for now Lit (understand code) People add the ‘why’ Non-linear ripples across the system Also sets the dimmer: • Risk / criticality • Verifiability • Code health Residuality (O’Reilly) contracts anyone competent would know how Modularisation (Parnas) Spec = module Conventional Spec = natural language stays in one module Novel or idiosyncratic nobody knows yet, or only a few people do.
67. The engineering moves from the prompt to the harness → pseudocode →code Evolution (Wardley) Systemic change Architecture as code Spec for now Lit (understand code) People add the ‘why’ Non-linear ripples across the system Stressor analysis Novel or idiosyncratic nobody knows yet, or only a few people do. Context & the ‘why’ Spec for now Dim (review code / tests) People check boundaries Partially non-linear Residuality (O’Reilly) Spec for now Dim (review code / tests) People judge results Partially non-linear Spec-as-source Dark Tests judge results Linear system Platforms & frameworks stays in one module Feedback from production Spec = natural language Modularisation (Parnas) anyone competent would know how contracts Conventional Rapid visual feedback Local change For spec-assource, the spec must become… Spec = module Skills & templates Tests & checks
68. Developers will stay for something The expert generalist: • building the right thing And the enabler: • building the thing that builds the thing CMAT – Stay for Something
69. Now, how many people do we need to order pizza for?
70. Yes! Patrick Debois, The DevOps Godfather on AI's “Dark Factory” Problem, July 2026
71. “Will two-pizza teams shrink to one-pizza teams because LLMs don’t eat pizza - or will we have the same size teams that do much more? I’m inclined to the latter,” Martin Fowler, martinfowler.com, February 2026 “I still have teams whose job it is to own a piece of software, iterate on it, own oncall, and so on. We still have two-pizza teams.” Katelyn Lesse with Gergely Orosz, How building software is changing at Anthropic, July 2026
72. Some pizza orders we’ve collected 2 3 4 5 6 7 8 9 10+ #people
73. “Today, despite their initial success, few people at Amazon still talk about two-pizza teams.” Working Backwards, Bryar & Carr, August 2022 “To promote his decentralized vision of the company, he created "two-pizza teams": highly autonomous task forces with five to seven people — no more than can be fed with two pizzas - who innovate and test new features” Fast Company magazine August 2004 Two pizzas were only ever meant to feed about 5–7 people But the question was never really about the number of pizzas
74. builders / growers / scalers One size does not fit all You need to experiment in your own contexts In diverse teams through conversations prototypers stable teams maintainers / janitors / perfecters business-critical or or fluid teams / discretionary coalitions internal tools
75. Hold on a minute
76. Party 2 bowling scorecard Down Down Wobbling It’s teams, the role shifts; juniors, and Often dim it doesn’t conversations factories not disappear dark ones
77. PARTY 2: POSSIBLE FUTURES TAKEAWAY PIZZA PIZ PARTY 1: PAST ERAS the Y T R A P A Z of the future
78. Taylorism of the linear work = automation AI is yet another tool to help Taylorism of the workers? No Be humane to the humans
79. We are not sure how the developer role will evolve – but it will AI can give teams superpowers, and immense pace Please remember: humans are still in charge of what’s valuable That’s messy and non-linear work And that won’t change, regardless of technology Maintainers Sweepers Growers Builders Prototypers Enabler Expert Generalist
80. THANK YOU!