It's the end of the road for the Apple Support Community. The dedicated discussion forum, which gave Apple users a place to exchange advice, troubleshoot, and generally chat about Apple products, has been placed into read-only mode, with a message from the company announcing that the Support Community will shut down for good on November 20th.

Here's the full banner notice that's currently displayed on the website:

"The Apple Support Community will permanently close on November 20, 2026. Starting today, the site will no longer accept new posts and is available in a read-only state. You can continue to find trusted guidance and support on t …

Read the full story at The Verge.

Most of today’s AI entrepreneurs and social media enthusiasts are young. AI is the first technology revolution they’ve lived through. They don’t remember how unbelievably exciting it was in the late 1970s to get your own computer, instead of struggling to get time on one of the vast machines chugging away in what used to be called “the glass house,” an air-conditioned room where from outside you could watch the nine-track tapes being accessed and the refrigerator-sized disk drives spinning. Input and output was on high-speed teletype printers (no screens) and magnetic tape (and before that on punch cards.) They also mostly don’t remember, as I do, writing assembly-language programs in which you moved data from one computer register to another, specified the arithmetic or logical operations to be performed on it, and then specified where to save the result.

They look at today’s AI and marvel at how virtually anyone can now generate code. They don’t realize that that’s also how it felt when you could use an interpreted programming language like BASIC to write your own applications instead of writing them in Assembler. They also don’t remember when Dan Bricklin used BASIC to write the first version of VisiCalc in 1979. He went into business with Bob Frankston, who rewrote it in 6502 Assembly Language for the Apple II. Dan was able to express the idea in Basic; Bob then wrote a tight, efficient version for widespread distribution. People rushed out to buy computers so they could use VisiCalc, and everyone predicted that the VisiCalc “spreadsheet” would put all the accountants out of work. It was the first program to be referred to as a “killer app.” It wasn’t the democratization of programming itself that was the killer app but what Dan and Bob did with it. In the entrepreneurial explosion that followed, databases, graphics, word processing, and other business applications came out of the glass house and, as Bill Gates put it, “onto every desk and into every home.”

We saw the same leap from astonishment to innovation to adoption with the World Wide Web. When O’Reilly demonstrated GNN, the first commercial website, to people at a trade show in 1993, attendees couldn’t believe that clicking on a link could pop up an image or a document from another computer thousands of miles away. They didn’t understand the difference between the software application (the web browser) from the network-connected documents with clickable hyperlinks that it acted as a frame for. They didn’t understand that web pages were a new kind of software written in a simple markup language anyone could understand. It didn’t make sense that the web page was a document that in many ways could look and act like a kind of program. And when people did understand, they thought that might be the end of programming.

In 1993, everyone thought that the web browser itself was the killer app, and that Marc Andreessen, the young creator of Mosaic, the most popular web browser, which became Netscape, was going to dethrone Bill Gates as the new king of computing. They didn’t realize that the true killer apps of the web were not the web browser and the web server but applications “up the stack” built using the new programming paradigm the web enabled. Those applications weren’t software as we’d known software before. They were database- and application-backed websites delivering services that were previously impossible. I remember thinking of Amazon as the 2005 equivalent to VisiCalc when a friend told me she had just bought her first computer so she could shop on Amazon. Once again, it wasn’t the new capability itself that was the killer app but what developers did with it.

What makes a killer app? I think that Tom Stoppard nailed it in his play Rosencrantz and Guildenstern Are Dead:

A man breaking his journey between one place and another at a third place of no name, character, population or significance, sees a unicorn cross his path and disappear. That in itself is startling, but there are precedents for mystical encounters of various kinds, or to be less extreme, a choice of persuasions to put it down to fancy; until—“My God,” says a second man, “I must be dreaming, I thought I saw a unicorn.” At which point, a dimension is added that makes the experience as alarming as it will ever be. A third witness, you understand, adds no further dimension but only spreads it thinner, and a fourth thinner still, and the more witnesses there are the thinner it gets and the more reasonable it becomes until it is as thin as reality, the name we give to the common experience.

That is, a killer app is at first a startling window onto an undreamed-of possibility, but one that so changes the paradigm that it rapidly gets taken for granted. In the meantime, everyone tries to make sense of the new world. Usually, their sensemaking is to try to reduce it to what they already know. The breakthrough entrepreneurs see more deeply and go farther.

In 1995 and 1996, almost everyone saw the future as a showdown between Microsoft and Netscape over who would own the web server and the web browser, and whether the web would supplant the desktop as the new platform. Microsoft won the browser wars, but it turned out to matter far less than anyone expected. The value went to the companies building on top of the browser, the ones that figured out what the network made possible.

The current narrative pitting AI model providers against each other sounds a lot like Microsoft versus Netscape to me. It is the platform war, the war for the layer that will become the common experience on which the revolutionary future will be built. ChatGPT, Claude, and Gemini are the browsers of this era. That is not a small thing. But the browser wasn’t actually the killer app of the web. Netscape made money for a little while. Amazon and Google and the explosion of other sites were what made the web into something people couldn’t live without.

Claude Code, Codex, Cursor, and the other coding agents may be the BASIC of this era, or like the tools and frameworks that made database-backed web applications possible. They are plumbing. Important plumbing, and plumbing that has to be in place before the future can truly happen. But still just plumbing. Inventors tend to spend decades maturing it, and O’Reilly tends to spend decades teaching people to build it. I suspect that will be just as true this time around.

In short, I’ve started asking myself whether we’ve actually seen the killer app for AI yet. The obvious assumption is that ChatGPT was. It certainly got a LOT of people excited and onboard very, very quickly. But maybe Claude Code was, enabling the breakthrough in agentic coding. Or maybe Hermes or Dots or Muse or some other personal agent will be. But we should take seriously the possibility that the killer app is not yet on the scene. These initial candidates for the killer app look too much like advances in a new enabling platform and not enough like a new generation of applications.

Personal agents may turn out to be a breakthrough category, but right now they look to me like early ecommerce before Amazon got it right.¹ For Amazon to work, the web had to become secure enough for people to use credit cards online. The apps were waiting on missing mechanisms. For Google’s economic model to kick into gear, pay-per-click advertising had to be invented. I suspect we are in a similar moment waiting for crucial pieces to be dumped on the table so developers can complete their part of the puzzle. For AI agents to act on our behalf in the world, they will need their own equivalents: ways to pay, to prove who they are acting for, to be held accountable, and for the counterparties to settle on the allocation of the value created by the transaction. Ilan Strauss and I have argued in “The Missing Mechanisms of the Agentic Economy” that many of those mechanisms don’t exist yet. Maybe the killer apps are waiting on the equivalent of https and pay per click.

In short, when you listen to the AI conversation and mostly hear about people’s programming pipelines and how much more productive their programmers are, and very little about what they are using that productivity to build, you can be pretty confident that the killer apps haven’t arrived yet.

Where are we in the cycle?

Let’s line up the calendars and see if that tells us something useful.

CP/M (Control Program for Microcomputers), the first widespread personal computer operating system, was developed in 1974, and the Altair 8800, the first mass-market personal computer, appeared on the cover of Popular Electronics in January 1975. Microsoft released a BASIC interpreter for it in June of that same year. A host of competing personal computer hardware platforms running CP/M were introduced soon thereafter. The Apple II was released in 1977, VisiCalc in October 1979, and dBase II in 1980. The IBM PC came out in August 1981 with Microsoft’s MS-DOS as its operating system. Lotus 1-2-3 (which included spreadsheet, graphing, and simple database features) was released in January 1983 and turned the PC into a business necessity.

In 1984, the revolutionary graphical user interface of the Macintosh was the next step function jump in the PC era. The GUI itself had been invented at Xerox PARC in the 1970s, but it wasn’t till Steve Jobs built his “insanely great” Mac that the world embraced it. Desktop publishing became the killer app of the GUI, with Aldus PageMaker and the Apple LaserWriter in 1985. The PC proper didn’t get the GUI till Windows 3.0 in 1990, but Microsoft’s embrace of it for applications such as Word (1983), Excel (1985), and PowerPoint (1987) as well as for the operating system and programming environment made it, for the time, master of the computing world.

So you can see a rough timeline. Four or five years from the introduction of the first version of what was to become the new platform to the first killer app. (Or two, if you count from the introduction of the Apple II, the platform for which VisiCalc was first written.) Then 10 years of invention, competition, and refinement, followed by fairly rapid consolidation and accumulation of market power.

Let’s do the same timeline for the web. Email and online forums might well have been the first internet killer apps, but they were really holdovers from previous generations of research networks. They were apps that had been evolving since the 1970s, though CompuServe and AOL had begun to bring them to the general public in the ’80s. The world really changed, though, when Tim Berners-Lee first wrote his proposal for what became the World Wide Web in March 1989. It was released to the world in August 1991. This was the new platform and the start of what would become the new programming paradigm.

Not too much happened outside physics labs and a few universities until 1993. (There were only about 200 websites when we published The Whole Internet User’s Guide and Catalog in November 1992.) In 1993, NCSA, the National Center for Supercomputer Applications, released Mosaic and we launched GNN, the first commercial website. Netscape shipped its browser, a follow-on to Mosaic, at the end of 1994. Yahoo! was launched that year too, Amazon, eBay, and the Altavista search engine in 1995, MapQuest in 1996, Google in 1998, and Wikipedia in 2001.

So, again about four years from the release of the platform to the appearance of the first killer app, and another 10 till the consolidation phase. (I see Gmail 2004, Google Maps 2005, Google Docs 2006, and Chrome 2008 as the equivalent of Microsoft’s release of Office on top of Windows as the beginning of the consolidation phase of the web.)

The timeline for mobile is not dissimilar. The iPhone in 2007, Android in 2008. Killer social apps Facebook and Twitter had gotten their start on the web at about the same time, but really came into their own on mobile over the next few years. The “could only have happened on mobile” killer apps of Uber, Lyft, and the on-demand economy didn’t arrive till 2011/2012.

A lot of people seem to think AI is moving way faster than previous technology revolutions. But if you line up the calendars, AI is moving at about the same pace as previous eras. Treat the transformer paper, “Attention Is All You Need,” published in June 2017, as the AI equivalent of Tim Berners-Lee’s 1989 proposal, and ChatGPT’s first release on November 30, 2022, as the equivalent of Mosaic. The gap from invention to breakout is about the same, five years for the web and five and a half for AI. That’s just getting the platform in place. The AI-native “killer apps” haven’t yet arrived but are due soon. (And please, let’s avoid the jokes that the “killer apps” of AI first showed up in the Russia-Ukraine drone war. That’s true, but not on the direct line of my argument here.)

On what seems to be a fairly consistent timeline, where are we today, then? October 2026 corresponds to roughly the spring of 1997. Amazon was about to go public. Hotmail was a year old. Google was still a research project at Stanford called BackRub. SixDegrees had kicked off social networking, but Facebook was still seven years off. Napster was still two years away.

Think of all those amazing application categories that had been pioneered, though. Search, ecommerce, email, and social networking were all in their infancy, but they were out there, delivering real value. I’m not sure that I see the equivalent time to value in AI. AI didn’t even get to Claude Code, its Microsoft Basic equivalent, till 2025! By some measures, AI is moving more slowly rather than more quickly. There’s more change to digest, and developers are still struggling with the tooling and developing the new knowledge that is needed.

Why so slow, with so much money?

The four largest hyperscalers are on track to spend roughly $700 billion in capital expenditure this year, nearly double what they spent in 2025. That is orders of magnitude more capital than went into the web in the 1990s. If capital and capability were the limiting factors, you’d think we should be well ahead of the earlier calendar, not behind.

I suspect that at least part of the answer is that Silicon Valley’s quest for premature monopoly may be making it less efficient at finding breakthroughs rather than more. Starting with the era of Uber and Lyft, massive VCs have canonized the winners at the beginning of the race, crowding out alternate technologies and business models. That may be happening here. But it’s also just in the nature of bubbles, which depend on groupthink to flourish.

And part of that groupthink is about where the value is going to be captured, rather than where it is going to be created. That is almost always backward looking. During the railroad boom, capital was pouring into building the tracks, and the new business models (think Montgomery Ward and Sears) that railroad enabled didn’t come till later. The dot-com bubble was far less capital intensive than people think. The telecom buildout that ran alongside it was where the money got spent. US carriers spent about $97 billion on capital in 2000 alone.

By 2002, according to an FDIC analysis, only 2% to 5% of the fiber in the ground was actually lit. More than 60 telecom companies went bankrupt. Once the data centers and dark fiber of the telecom bubble could be bought for pennies on the dollar, they enabled a generation of new applications like streaming video. YouTube was founded in 2005, after the crash, on cheap bandwidth that someone else had paid for before they went out of business. There were some visionary companies (think Google, Amazon) that had been started before the abundance arrived, but many more were founded after the bubble burst.

Carlota Perez’s book Technological Revolutions and Financial Capital documented this pattern across every technological revolution since the canal era. Financial capital pours into the installation of the new infrastructure, a bubble forms and bursts, and the deployment period that follows, when the technology actually reshapes the economy, is built by different people on top of what the crash left behind. If that is where we are in the cycle, then the absence of killer apps is not a puzzle at all.

The current data center buildout and the massive investments in frontier AI may not be the future. They are the infrastructure on which the future will be built. We have to ask ourselves what will we build once competition and overshoot and the bursting of the data center bubble make intelligence infrastructure cheap.

Help me fill in the picture

I see several possibilities. Either we are still early and the killer apps simply haven’t shown up yet, the way Google hadn’t shown up in 1997. Or AI is going more slowly than its boosters claim, in spite of all the capital, because capital and model capability are not the limiting factors. But it’s also possible that the killer apps are here, and I’m not hearing about them because the AI conversation is so focused on AI capability and nobody is telling the story of what they are accomplishing with it beyond building better developer tools.

I would like to know which. We all recognize a killer app when we see one. Amazon was a bookstore with more books than any physical bookstore could hold. Wikipedia was an encyclopedia written entirely by volunteers and was updated in real time within hours and sometimes even minutes of major events. Google Maps meant you always knew where you were and how to get anywhere else. If you know of an AI application, beyond the chatbot or agentic coding environment itself, that changes what ordinary people can do on that scale, or a business that does something an order of magnitude cheaper or better than the one it replaces, I want to hear about it. Tell me what you’re building in the Google Form below, and describe what tools you’re using only in the context of what they let you produce for others. If you’re a software developer using AI, what are you producing that was unthinkable before AI?

---

Footnote

1. CommerceNet demonstrated the first encrypted credit card transaction online in 1994, and Netscape made the idea mainstream when it introduced HTTPS (HyperText Transfer Protocol Secure) and made it available in the Netscape browser in that same year. This made it safe to type a credit card number onto a web page. ︎

The following article was originally published on James Shore’s Successful Software blog and is being republished here with the author’s permission.

AI is great for making teams faster. But is it sustainable? What about maintainability, burnout, and lock-in?

This is part 3 of my series on assessing AI’s impact on software development. In part 1, we looked at why assessing impact is important, and what not to do. In part 2, we looked at how to measure AI’s impact on delivery speed. In this part, we’re looking at how to measure and model the unintended consequences of using AI. Then we’ll wrap up in part 4 with an examination of business outcomes. Finally, an epilogue puts it all together with notes you can share with your CFO.

Does maintainability even matter?

I can hear it now: “Who cares about namby-pamby issues like maintainability and burnout? It’s a job. If jobs were supposed to be fun, they wouldn’t be called ‘work!’ Suck it up!”

So let me be clear: We care about AI’s unintended consequences because they have real economic impact. If code isn’t maintainable, features take longer to write and bugs take longer to fix, taking time away from more valuable work. If people are burned out, they don’t put forth their full effort, and they eventually quit, taking institutional knowledge with them and leading to time-consuming hiring cycles. If you’re locked in, and AI token costs increase, you could be stuck with a choice between a big bill and cutting back on development.

Among the people I’ve talked to, there’s widespread agreement that heavy use of AI produces code that humans have trouble understanding. But there’s disagreement about how much that matters. If AI is doing the maintenance, do we care if a human can understand the code?

There are strong opinions on this topic on all sides, but not a lot of actual evidence. What’s clear is that the costs of maintenance and other unintended consequences do matter, but only if there are any costs. This is what we need to measure: Is there an impact? And if there is, is it enough to matter?

Unfortunately, unlike the rigorous speed trial we discussed in part 2, unintended consequences are gradual and fuzzy. Your measurements are going to be noisy and lagging. You’ll have to create models and explore scenarios. Ultimately, your decisions will come down to judgment, informed by your measurements and models but not driven by them.

One ring to rule them all

There is one idea that, while not perfect, does a good job of capturing the majority of unintended consequences. It’s cost of change.

Put simply, cost of change is like a tax on the changes you make to your software. When cost of change is low, complicated changes still take time, but they’re achievable. When cost of change is high, even simple changes can take weeks, and complicated changes seem completely out of reach.

Cost of change isn’t easy to measure, but there are several indicators you can use to inform your judgment.

Value-add percentage

Value-add percentage is the percentage of your software development effort that’s spent on things that bring value to your business, such as new features, versus the percentage of effort that’s spent on non-value-add work, such as fixing bugs, resolving incidents, and manual test and release cycles.

Non-value-add work is called “muda.”¹ Some muda is necessary, even valuable, but that doesn’t make it value-add. Imagine a demanding and crotchety customer who always asks, “Why didn’t you just do it right the first time?” If that customer won’t pay for something, it’s muda.

That’s why bug fixes are muda: “I’m not paying you to fix a bug that shouldn’t be there in the first place!” And performing releases: “Why don’t you just ship it already! How hard can it be?” Sure, bug fixes can be valuable, and releases are necessary, but they’re still muda.

I find it useful to distinguish muda further into discretionary and nondiscretionary muda. Discretionary muda is work that you choose, such as investing in code changes that decrease development costs. Nondiscretionary muda is work that’s chosen for you, such as bug fixes, incidents, and dependency upgrades.

You’ll always have a baseline amount of nondiscretionary muda; it’s a constant tax that takes time away from other work. But if it’s rising, that means the time you spend on value-add work is going down. You have less time to work on things that matter. Your costs are increasing.

When I was VP of engineering, value-add percentage was one of my key metrics. I made decreasing muda a priority, and it paid off. We doubled our value-add percentage over the course of my three years there, which allowed me to free up people for substantial new initiatives without increasing headcount.

DORA metrics

Your organization is likely already tracking the DORA metrics of change lead time, deployment frequency, change fail rate, and so forth. If not, they’re worth considering. As with value-add percentage, changes in these numbers are something to keep an eye on.

Token usage

Tokens are a literal cost, and the more tokens it takes to make a change, the higher your costs. Unfortunately, token usage can fluctuate for many reasons, not just cost of change. Still, it’s worth watching. Anecdotally, better-constructed software is easier for AI to work with and costs fewer tokens.

One of the biggest variances in token usage is people’s level of adoption. Rather than just tracking overall usage, keep an eye on individual usage changes. In the charts I’ve seen, usage has formed a Pareto curve. Increases in usage by people on the low end of the curve may just represent increasing familiarity. Increases by people on the high end of the curve are worth investigating further.

Changes in models, harnesses, prompts, and more will all affect token usage. This metric is only advisory; it’s meant to trigger further investigation, not to be used on its own.

One ring to find them

Of these metrics, value-add percentage is the one I trust the most. It operates at the level we care about: Where is the time going?

Tracking value-add percentage doesn’t have to be a big burden. You don’t need time sheets or detailed task tracking. The trick is to not care overly much about precision. Tracking work within a day or two is good enough.

When I did this tracking, I piggybacked on our valuable increment (VI) tracking. Each one was several days to several weeks of work and could be cleanly categorized as either value-add or muda. But you don’t have to use VIs; any tracking approach will work.

Don’t get too fine-grained with your tracking. When I was VP, managers checked in with each team twice a week and recorded which VI the team had worked on and how many people had worked on it. Each VI was categorized as “muda” or “value-add,” and we had a bunch of subcategories that helped us understand where time was going, such as “bug,” “capacity investment,” “major initiative,” and so forth. It was lightweight and very useful.

Review your value-add percentage monthly. If it’s going down, you don’t necessarily have a problem, but it’s worth investigating further.

The biggest problem with value-add percentage is that it’s noisy. My experience was that trends took three to six months to show up. It took a year before I was confident stating that my cost-of-change reduction efforts had led to lasting results.

That’s a long lag time, but it’s still worth tracking. My product partners and I found value-add percentage incredibly valuable as a tool for communicating what was happening in product development. And, sadly, improving cost of change is a lot harder than making it worse. If AI is causing serious problems, it’ll probably show up more quickly.

One ring to bring them all

Because your cost of change indicators will be noisy and uncertain, supplement them with models and scenario planning. Your models won’t tell you what the future holds, but they will tell you what it could hold, which will help you manage risks.

Here are some of the models I’ve found useful:

Maintainability

Model maintenance as a mandatory “tax” on development. For each month of value-add development, estimate a certain amount of maintenance in the following year, and then a lower amount of ongoing maintenance in every year after that. (Wisdom of the crowd estimation may help.) Then build a model that shows how many engineering days are available each month. Subtract the time spent on maintenance, and the rest is available for value-add.

To model AI’s impact, apply your measured development speed improvements. Estimate how AI will change maintenance costs and estimate effects on headcount. Then explore scenarios based on varying costs of AI maintenance.

If you only create one model, make it this one. I have a more detailed explanation here. It includes a spreadsheet you can use as a starting point for your model.

For example, using that model, if AI increases our speed by 50%, but token costs reduce headcount by 15% and maintenance costs are estimated to double, I can see that I’m only breaking even, despite the big performance improvement:

Excess lines of code

Lines of code aren’t a good productivity measure, but they are a reasonable cost measure. Generally speaking, more lines of code result in more maintenance costs.

This model works similarly to the previous one but uses lines of code instead of engineering days. Use traceability data to categorize commits as “value add” or “maintenance.” For each commit, measure gross code churn: the number of lines of code that were either changed, added, or deleted.

For each line of value-add change, estimate a certain amount of maintenance code churn in the following year, and then a lower amount in every year after that. Model how much maintenance code churn will be needed each month based on the value-add churn of previous months. (See the “tmux” tab of this spreadsheet for an example.)

To model AI’s impact, measure how AI affects code churn during your speed improvement trial. Then project value-add churn into the future and model how maintenance churn could change.

The advantage of this model is that you can use (part of) your actual commit data to refine your estimates. For example, the following graph uses real commit data from the open source tmux project.² Prior to running the model, I guessed one line of maintenance for every line of value-add in the first year, and 0.1 lines every year after that, which turned out to be surprisingly close to the actual data.

Lock-in

If token costs increase, how will you respond? Will you cut headcount? Reduce your use of AI? Switch to a less capable model?

To model these effects, update the “maintainability” model. Reduce your monthly engineering capacity according to headcount and estimate reductions to your speed improvements based on AI reductions. You may want to add a separate set of estimates and calculations for humans maintaining AI-written code.

Burnout

Productivity is likely to go down as mental exhaustion goes up, and turnover is likely to increase. I don’t think you can model these effects with any accuracy, but you can still keep an eye on them.

Include mental exhaustion as part of your development speed study to see if there’s a significant difference in mental exhaustion between the two approaches. Follow up with periodic one-question surveys about people’s mental energy levels. Pay attention to actual turnover relative to historical numbers, and look for complaints about AI in exit interviews.

And in the darkness bind them

There’s a dark side to value-add percentage. It’s incredibly easy to game. As soon as managers think their teams are being judged based on how they categorize their work, the temptation to tweak the categorization in their favor will be exquisite.

It doesn’t even have to be fraudulent. A leader with prioritization authority and something to prove can simply decide to defer maintenance in favor of value-add work. The pressure to do so is already immense, and it takes unusually strong character to resist.

(If you really hate your company, consider this: You can get away with deferring maintenance for a couple of years. Just enough time to line up a bigger title at a different company! Then your successor is left holding the bag, and your old company wonders why product development can’t get anything done.)

I don’t have an easy answer to these problems other than to remind you to use these metrics to evaluate your approach, not your people. There is no metric that can’t be gamed, and this one is more gameable than most. But it’s also critical for understanding AI’s possible downsides. Use it, but use it with caution.

Development speed and unintended consequences are two sides of the same coin. They help us understand how AI changes how much we deliver, both now and in the future. But just delivering more software isn’t enough. We need to produce the right software. We’ll look at business outcomes next, in part 4.

Footnotes

1. “Muda” is a Japanese word that comes to us from the Toyota Production System, the inspiration for the Lean Software Development movement. ︎
2. Many thanks to Christophe Stjernlöf for providing the raw data from the tmux project. He used an LLM to classify commits as “value-add” or “maintenance.” The stairsteps are an artifact of the way the data was collected. ︎

---

Scott and Wes sit down with GitHub’s Kyle Daigle to ask what the hell is going on with GitHub: the downtime, the agent traffic spike, and the infrastructure overhaul decoupling storage from compute. Plus Copilot Fusion’s cascade and critique modes, npm supply chain security, and whether pull requests are dead.

Show Notes

• 00:00 Welcome to Syntax!
• 00:07 What the Hell Is Going On with GitHub?
• 01:42 GitHub’s Growth by the Numbers: Billions of Commits a Month
• 03:36 Brought to you by Sentry!
• 04:00 GitHub’s Huge Infrastructure Update: Decoupling Storage from Compute
• 06:41 Moving to Azure and the Busy Monorepo Problem
• 09:00 Is CI the New Bottleneck? Rethinking Testing for Agents
• 11:01 Are Pull Requests Dead? Contributing Tokens Instead of Homework
• 13:16 GitHub Copilot App: Will We Ever Get Sign In with ChatGPT?
• 14:51 Is Copilot Fusion Just a Model Router? Cascade and Critique Modes
• 17:30 Can You Use Copilot Fusion in Other Harnesses?
• 18:31 What’s Going On with npm? Supply Chain Security
• 20:30 Do We Even Need Dependencies, or Should We Vibe Code Our Own?
• 22:13 Is npm Still a Focus for GitHub?
• 23:29 Audience Questions: Novel Code Storage Architectures and the Future of Git
• 26:05 Making Git Easier for Shipping with Agents
• 27:54 It’s About the People: Celebrating Open Source at Universe
• 29:52 Sick Picks + Shameless Plugs

Sick Picks

• Kyle: Studio Roem notebook

Hit us up on Socials!

Syntax: X Instagram Tiktok LinkedIn Threads

Wes: X Instagram Tiktok LinkedIn Threads

Scott: X Instagram Tiktok LinkedIn Threads

Randy: X Instagram YouTube Threads

Download audio: https://traffic.megaphone.fm/FSI3647670844.mp3

Rajveer Prasad: Using Scrum Master Working Agreements to Make AI Safer

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.

 

"AI can put garbage in a very good wrapping and give it to you, and you're none the wiser." - Rajveer Prasad

 

Rajveer brings a current challenge from his own work with AI: the false sense of achievement that comes from getting a polished output before the work is truly safe, scalable, or responsible. As a non-developer building AI-supported systems, he found that an agent can quickly produce something that appears to work, while missing security, architecture, testing, or cost implications. The coaching conversation turns toward something Scrum Masters know well: working agreements. Rajveer started defining roles, values, principles, and rules for the agent, treating it like a team member that needs clear expectations. He asks the AI to explain decisions in a way a Scrum Master can understand, captures lessons when something goes wrong, and plans more before building. The surprise is that AI work mirrors team coaching: set agreements, run small experiments, inspect the results, update the system, and avoid rushing into output just because the tool can move fast.

 

In this episode, we refer to working agreements, red-green-refactor, Ollama, and AI agents.

 

Self-reflection Question: What working agreements would make your AI experiments safer before you scale them?

 

[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 Rajveer Prasad

 

Our guest today is Rajveer Prasad, founder of OAKKTREEUNII. He's spent years helping aspiring and working project managers and Scrum Masters break into IT delivery — and grow once they're there — through real projects, real interview prep, and real accountability. He's mentored hundreds through career changes most people call impossible. Welcome, Rajveer

 

You can link with Rajveer Prasad on LinkedIn.

Download audio: https://traffic.libsyn.com/secure/scrummastertoolbox/20261111_Rajveer_Prasad_W.mp3?dest-id=246429