We’ve been bombarded with claims about how much generative AI improves software developer productivity: It turns regular programmers into 10x programmers, and 10x programmers into 100x. And even more recently, we’ve been (somewhat less, but still) bombarded with the other side of the story: METR reports that, despite software developers’ belief that their productivity has increased, total end-to-end throughput has declined with AI assistance. We also saw hints of that in last year’s DORA report, which showed that release cadence actually slowed slightly when AI came into the picture. This year’s report reverses that trend.

I want to get a couple of assumptions out of the way first:

• I don’t believe in 10x programmers. I’ve known people who thought they were 10x programmers, but their primary skill was convincing other team members that the rest of the team was responsible for their bugs. 2x, 3x? That’s real. We aren’t all the same, and our skills vary. But 10x? No.
• There are a lot of methodological problems with the METR report—they’ve been widely discussed. I don’t believe that means we can ignore their result; end-to-end throughput on a software product is very difficult to measure.

As I (and many others) have written, actually writing code is only about 20% of a software developer’s job. So if you optimize that away completely—perfect secure code, first time—you only achieve a 20% speedup. (Yeah, I know, it’s unclear whether or not “debugging” is included in that 20%. Omitting it is nonsense—but if you assume that debugging adds another 10%–20% and recognize that that generates plenty of its own bugs, you’re back in the same place.) That’s a consequence of Amdahl’s law, if you want a fancy name, but it’s really just simple arithmetic.

Amdahl’s law becomes a lot more interesting if you look at the other side of performance. I worked at a high-performance computing startup in the late 1980s that did exactly this: It tried to optimize the 80% of a program that wasn’t easily vectorizable. And while Multiflow Computer failed in 1990, our very-long-instruction-word (VLIW) architecture was the basis for many of the high-performance chips that came afterward: chips that could execute many instructions per cycle, with reordered execution flows and branch prediction (speculative execution) for commonly used paths.

I want to apply the same kind of thinking to software development in the age of AI. Code generation seems like low-hanging fruit, though the voices of AI skeptics are rising. But what about the other 80%? What can AI do to optimize the rest of the job? That’s where the opportunity really lies.

Angie Jones’s talk at AI Codecon: Coding for the Agentic World takes exactly this approach. Angie notes that code generation isn’t changing how quickly we ship because it only takes in one part of the software development lifecycle (SDLC), not the whole. That “other 80%” involves writing documentation, handling pull requests (PRs), and the continual integration pipeline (CI). In addition, she realizes that code generation is a one-person job (maybe two, if you’re pairing); coding is essentially solo work. Getting AI to assist the rest of the SDLC requires involving the rest of the team. In this context, she states the 1/9/90 rule: 1% are leaders who will experiment aggressively with AI and build new tools; 9% are early adopters; and 90% are “wait and see.” If AI is going to speed up releases, the 90% will need to adopt it; if it’s only the 1%, a PR here and there will be managed faster, but there won’t be substantial changes.

Angie takes the next step: She spends the rest of the talk going into some of the tools she and her team have built to take AI out of the IDE and into the rest of the process. I won’t spoil her talk, but she discusses three stages of readiness for the AI: 

• AI-curious: The agent is discoverable, can answer questions, but can’t modify anything.
• AI-ready: The AI is starting to make contributions, but they’re only suggestions. 
• AI-embedded: The AI is fully plugged into the system, another member of the team.

This progression lets team members check AI out and gradually build confidence—as the AI developers themselves build confidence in what they can allow the AI to do.

Do Angie’s ideas take us all the way? Is this what we need to see significant increases in shipping velocity? It’s a very good start, but there’s another issue that’s even bigger. A company isn’t just a set of software development teams. It includes sales, marketing, finance, manufacturing, the rest of IT, and a lot more. There’s an old saying that you can’t move faster than the company. Speed up one function, like software development, without speeding up the rest and you haven’t accomplished much. A product that marketing isn’t ready to sell or that the sales group doesn’t yet understand doesn’t help.

That’s the next question we have to answer. We haven’t yet sped up real end-to-end software development, but we can. Can we speed up the rest of the company? METR’s report claimed that 95% of AI products failed. They theorized that it was in part because most projects targeted customer service, but the backend office work was more amenable to AI in its current form. That’s true—but there’s still the issue of “the rest.” Does it make sense to use AI to generate business plans, manage supply change, and the like if all it will do is reveal the next bottleneck?

Of course it does. This may be the best way of finding out where the bottlenecks are: in practice, when they become bottlenecks. There’s a reason Donald Knuth said that premature optimization is the root of all evil—and that doesn’t apply only to software development. If we really want to see improvements in productivity through AI, we have to look company-wide.

To help people connect with the Internet Archive’s celebration of 1 trillion web pages preserved, we created “The Web We’ve Built,” a cinematic reflection on how humanity came together to build, shape, and now safeguard the web. From the crackle of a dial-up modem to the galaxy of pages preserved in the Wayback Machine, the film traces our shared journey online—the creativity, connection, challenges, and triumph of building the largest digital library in history, together.

Credits:
Written by Chris Freeland
Animated and Edited by Freya Morgan
Research support by Sterling Dudley

Alidad Hamidi: When a Billion-Dollar Team Becomes Invisible

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

"Most of the times, it's not teams that are self-destructive or anything... Simple analogy is when a flower is not blooming, you don't fix the flower, you fix the soil." - Alidad Hamidi

The team sat on the sidelines, maintaining a large portfolio of systems while the organization buzzed with excitement about replatforming initiatives. Nobody seemed to care about them. Morale was low. Whenever technical challenges arose, everyone pointed to the same person for help. Alidad tried the standard playbook—team-building activities, bonding exercises—but the impact was minimal. Something deeper was broken, and it wasn't the team.

Then Alidad shifted his lens to systems thinking. Instead of fixing the flower, he examined the soil. Using the Viable Systems Model, he started with System 5—identity. Who were they? What value did they create? He worked with stakeholders to map the revenue impact of the systems this "forgotten" team maintained. The number shocked everyone: one billion dollars. These weren't legacy systems gathering dust—they were revenue-generating engines critical to the business. Alidad asked the team to run training series for each other, teaching colleagues about the ten different systems they managed. They created self-assessments of skill sets, making visible what had been invisible for too long. When Alidad made their value explicit to the organization, everything shifted. The team's perspective transformed. Later, when asked what made the difference, their answer was unanimous: "You made us visible. That's it." People have agency to change their environment, but sometimes they need someone to help the system see what it's been missing. Ninety percent of the time, when teams struggle, it's not the team that needs fixing—it's the soil they're planted in.

Self-reflection Question: What teams in your organization are maintaining critical systems but remain invisible to leadership, and what would happen if you made their value explicit?

Featured Book of the Week: More Time to Think by Nancy Kline

Alidad describes Nancy Kline's More Time to Think as transformative for his facilitation practice. While many Scrum Masters focus on filling space and driving conversations forward, this book teaches the opposite—how to create space and listen deeply. "It teaches you to create a space, not to fill it," Alidad explains. The book explores how to design containers—meetings, workshops, retrospectives—that allow deeper thinking to emerge naturally among team members.

For Alidad, the book answered a fundamental question: "How do you help people to find the solution among themselves?" It transformed his approach from facilitation to liberation, helping teams slow down so they can think more clearly. He first encountered the audiobook and was so impacted that he explored both "Time to Think" and this follow-up. While both are valuable, "More Time to Think" resonated more deeply with his coaching philosophy. The book pairs beautifully with systems thinking, helping Scrum Masters understand that creating the right conditions for thinking is often more powerful than providing the right answers.

In this segment, we also refer to the book Confronting our freedom, by Peter Block et al. 

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

Buy Now on Amazon

[The Scrum Master Toolbox Podcast Recommends]

About Alidad Hamidi

Alidad is a strategic advisor in human-centred transformation, focused on organisational design for autonomy, ownership, and impact. A recovering Agility Coach, he draws on years across delivery and coaching roles to help build organisations truly fit for humans—resilient, adaptive, and designed for people, not just processes.

You can link with Alidad Hamidi on LinkedIn. You can also visit his website at desirablefutures.group.

Introduction

I recently posted about my projects Isolator and ReferencesScanner, which allow us, respectively, to run .NET code in isolation and to list all of an assembly's references. Now, I'm going to present a change to Isolator that allows checking for a plugin's references with white and black lists. Any references on the white list will be allowed, and any on the black list will be denied.

Using Isolator with References Scanning

There is a new class, ScannedIsolationHost, which features four new properties:

public HashSet<Type> SafeTypes { get; }
public HashSet<Assembly> SafeAssemblies { get; }
public HashSet<Type> UnsafeTypes { get; }
public HashSet<Assembly> UnsafeAssemblies { get; }

So, we have new properties:

• SafeTypes: list of Type references that are safe to use
• SafeAssemblies: list of Assembly references that are safe to use
• UnsafeTypes: list of Type references that are unsafe to use
• UnsafeAssemblies: list of Assembly references that are unsafe to use

ScannedIsolationHost must be instantiated with an existing IIsolationHost, and, possibly, with some of these collection properties filled.

In a nutshell:

1. If either the SafeTypes or SafeAssemblies are specified, then every referenced method's type/assembly must be declared there
2. No referenced method's type/assembly can be present in the UnsafeTypes/UnsafeAssemblies collections, if any is specified

The Isolator has been updated, both GitHub and NuGet, so you can use this already.

Conclusion

As always, happy to hear your thoughts on this, and I hope you find this useful!

If you were confused about Apple releasing a crossbody iPhone strap, then you’re going to find its new iPhone Pocket even more perplexing. The Pocket is actually a knitted bag, though it might be more apt to describe it as a sock designed to snugly encase your iPhone, instead of just sticking it in your purse or pocket.

This limited edition collaboration with Japanese designer Issey Miyake can be yours for an eyewatering $229.95. That’s for the crossbody version available in blue, brown, or black. A shorter version is available in additional color options (including vivid orange, yellow, purple, pink, and turquoise) for $149.95, which can be hooked over your arm or tied to a bag.

Apple says the 3D-knitted design was inspired by “a piece of cloth” (yes, really), and was born from the idea “of creating an additional pocket” that accommodates “any iPhone” and small everyday items. That means it can carry more than Apple’s $59 crossbody iPhone strap.

“The design of iPhone Pocket speaks to the bond between iPhone and its user, while keeping in mind that an Apple product is designed to be universal in aesthetic and versatile in use,” according to Miyake Design Studio’s design director, Yoshiyuki Miyamae. “iPhone Pocket explores the concept of ‘the joy of wearing iPhone in your own way.’”

The iPhone Pocket will be available to purchase online starting November 14th, and from a handful of Apple Store locations in the US, France, Greater China, Italy, Japan, Singapore, South Korea, and the UK.