The pizza party of the future 🍕 software teams and product value in the age of coding agents

AI is having a huge impact on our software development teams - nobody is sure how the role of a developer will evolve, and Simon and Katie don’t have the perfect prediction either!
Now that our teams have ever more capable coding assistants working around the clock, we are seeing “new” bottlenecks appear around value and trust questions. In response to this, we’re seeing organizations create new flavors of engineering roles, move down to one-pizza-teams, move to product owners and their AI wrangler (a one-pizza-slice team?), or even build factory lines.
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; from T-shaped and M-shaped professionals to full-stack, full-lifecycle, DevSecFin…Ops, value streams, Team Topologies, and more. We’ve added all kinds of coaches and then removed them again.
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 warn us about. 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. Rabbit holes + sources https://futurepizzaparty.substack.com/
6. PARTY 1: PAST ERAS PIZ the Y T R A P A Z of the future
7. PARTY 1: PAST ERAS
8. PARTY 1: PAST ERAS PIZ the Y T R A P A Z of the future
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. All of the staffing and procurement options have a place Wardley map Cynefin Michael Plöd, Staffing and Procurement for Fast Flow, March 2026 DDD
24. 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. Have we as an industry talked about teams & psychology enough? Egoless Programming Cognitive Load Cognitive Load During Problem Solving: Effects on Learning, John Sweller (1988) Psychology of Computer Programming, Weinberg (1969) 1950 1960 Cooperative Game 1970 1980 Agile Software Development: The Cooperative Game, Cockburn (1999) 1990 2000 Brains-in-Jars Psychology of S/w Teams, Hicks (2026) 2010 ! 2020 Glue Work 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. 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
35. PARTY 2: POSSIBLE FUTURES PIZ the Y T R A P A Z of the future
36. The future is already here, it’s just unevenly distributed William Gibson, https://quoteinvestigator.com/2012/01/24/future-has-arrived/
37. First bowling attempt Two pins at once
38. “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
39. 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)
40. The human role is shifting Mining Supervision
41. The human role is shifting Coding Verifying Syntax Knower Human-in-the-Loop? Code Review Monkey? Meat Proxy? Slop Grenade Thrower? …?
42. The human role is shifting Developers T- or π-shaped person! Domain + architecture 2 Emerging Paths Expert Generalist Builder Enabler Enables humans and agents!
43. Which seems closer to what you’re seeing right now? 1 Developer Verifying 2 Coding 2 Emerging Paths Expert Generalist Builder Syntax Knower Enabler
44. Not everyone is shifting Developer ??? Brett Codes, I’m done using AI, August 2026 Boycotting AI due to depression, apathy, brainrot, existential dread, …
45. ¼″ drill Typescript syntax knower? ¼″ hole As a developer what is your “job to be done” System engineer? Hang picture Problem solver? Happier life Value optimiser? “…the point of this… is not to climb to the top of the ladder, it's to find your rung… There aren't easy answers to these questions – the question itself and the ladder help to ask more questions that in turn help us navigate the situation.” Simon Rohrer, LinkedIn post, Sep 2026
46. 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
47. 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
48. Speaking of learning: What about juniors? Adele – When we were young
49. “The hardest thing about quantifying the value of junior engineers is we don't know how to quantify the value of any engineer. 10x is a myth It's all vibes. […] They don't know what the software development life cycle is but […] they are doing so much cool shit. 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
50. “So, why are people saying an LLM is like a junior developer? […] I’ve got to say I've got two theories and neither of them is very pleasant. Taylor Drucker So the first is the people saying this genuinely treat junior developers like transactional robots. […] And I'm not sure I want to hang out with those people. And the other theory I have is that the people saying this want you to believe you can replace your junior developers with robots. And again, I don't think that's a thing. I think the the future of of generative AI, LLMs, especially Agentic AI is going to be augmenting how people do work and helping us do work better. […] So 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
51. The barrier to writing software has collapsed… …but the barrier to engineering has not
52. Taylor Everyone can code now, so roles are blurring Engineering Design Product User Research Data Science Maintainers Sweepers “My feeling now is because everyone can write code the roles shift a little bit. 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 Growers Builders Prototypers
53. 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!
54. 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
55. Second bowling attempt How about a spec-driven software factory?
56. " 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
57. " 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
58. 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
59. …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
60. 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
61. We've been here before with offshoring “It was easy for onshore developers to say their Indian colleagues failed to collaborate because ‘they were expected to be spoonfed specifications’ and for the Indian participants to blame failure on poorly specified requirements from onshore ‘higherups.’” “Distance demands specification. Complexity forbids it.” Michael Plöd, Staffing and Procurement for Fast Flow, March 2026 Levina N. and E. Vaast, “Innovating or Doing as Told? Status Differences and Overlapping Boundaries in Offshore Collaboration,” MIS Quarterly (32:2), June, 2008, pp. 307-332
62. Another brief tangent What are we actually doing here? Olivia Rodrigo – Deja Vu
63. 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
64. 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.
65. 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
66. Developers will stay for something The expert generalist or product engineer: specifying, engineering and experimenting with value And the enabler: building the thing that builds the thing CMAT – Stay for Something
67. Now, how many people do we need to order pizza for?
68. Yes! Patrick Debois, The DevOps Godfather on AI's “Dark Factory” Problem, July 2026
69. “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. While each of these humans are supercharged by AI, the size and shape of the team is still similar. We still have two-pizza teams.” Katelyn Lesse with Gergely Orosz, How building software is changing at Anthropic, July 2026
70. Some pizza orders we’ve collected 2 3 4 5 6 7 8 9 10+ #people
71. “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
72. builders / growers / scalers prototypers stable teams maintainers / janitors / perfecters business-critical or or fluid teams / discretionary coalitions internal tools One size does not fit all You need to experiment in your own contexts In diverse teams through conversations Not in single player mode
73. PIZ BOWLING SCORES & TAKE-AWAY PIZZA the Y T R A P A Z of the future
74. Hold on a minute
75. Bowling scorecard Pin Result Down Woohoo! We the role shifts; no longer it doesn’t need devs! disappear Woohoo! We Down don’t need It’s teams, you to talk or juniors, and think conversations Woohoo! We just need to get the spec 100% right Wobbling Often dim factories not dark ones Audrey Hobert – Bowling Alley
76. Taylorism of the linear work = automation AI is yet another tool to help Taylorism of the workers? No Be humane to the humans
77. 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
78. THANK YOU!