As part of the mass layoffs hitting Xbox, Doom developer id Software has laid off around 50 percent of its staff, according to Game Developer. One source claimed to the publication that the cuts equate to more than 90 redundancies. Another source said that id's QA department was significantly impacted. The report was published the same day that id is releasing a major expansion for its latest Doom game.

A former id employee affected by the cuts, Michael Maynard, corroborated the figure in a LinkedIn post, saying that the layoffs affected "roughly" 50 percent of the company. "We created arguably THE BEST first person engine technology in the …

Read the full story at The Verge.

We’re announcing new capabilities in Managed Agents in Gemini API so developers can build reliable, production-ready agents.

Q1 2026 was a banner quarter for open source collaboration, as shown by the GitHub Innovation Graph’s economy collaborators metric, part of the latest data release. Outbound collaboration, defined as the sum of git pushes and pull requests sent from developers in one economy to public repositories in another economy, grew by 16% quarter-over-quarter from Q4 2025 to Q1 2026.

That’s the second highest quarter-over-quarter growth rate we’ve seen since 2020. The highest was in Q2 2020, with a 21% growth rate, when many of us suddenly and collectively decided to use our computers more.

In third place was Q1 2023, with a 9% growth rate. This was the first quarter after a research lab blogged about a new website they made, and they enticed users to sign up and file bug reports by offering a chance to win up to $500 in API credits. Evidently, sweepstakes are unreasonably effective motivators.

Metrics by economy

While it’s clear that collaboration is growing globally, plotting these and other metrics separately by economy highlights the different trajectories of the world’s developer communities:

Now, it’s your turn to analyze the underlying datasets yourself for interesting pursuits, such as improving how economic growth is measured or estimating the impact of a research lab’s new website. While we have no sweepstakes to offer (for now), we think there are fascinating data stories strewn throughout these CSVs just waiting to be told.

One example might be the impressive recent growth in Syria starting in Q4 2025, which coincides with changes we made to enable broader access to GitHub functionality following the relaxation of sanctions and export controls on the country:

We’re grateful to the developers who advocated for these changes and the communities that continue to help spread the word, such as GitSyria. Thanks to their efforts, we’re happy to share that we’ve been able to provide the GitHub Student Developer Pack to over 8,000 verified Syrian students in just the last six months.

Helping maintainers manage collaboration

While greater collaboration leads to many benefits, we recognize that the rapid increase in contribution volume has strained several communities. Ashley Wolf, our Director of Open Source Programs, wrote about the Eternal September of Open Source in February 2026, describing how maintainers are managing new contribution dynamics and what we’re doing to try to help. Features we’ve shipped include:

• Pull request limits: You can set a maximum number of open pull requests that users without write access may have open in your repository at one time, giving you a more proactive way to manage contribution volume.
• Repo-level pull request and issue controls: Gives maintainers the option to limit pull request and issue creation to collaborators or disable pull requests and issues entirely.
• Pinned comments on issues: You can now pin a comment to the top of an issue from the comment menu.
• Banners to reduce comment noise: Experience fewer unnecessary notifications with a banner that encourages people to react or subscribe instead of leaving noise like “+1” or “same here.”
• Pull request performance improvements: Pull request diffs have been optimized for greater responsiveness and large pull requests in the new files changed experience respond up to 67% faster.
• Faster issue navigation: Easier bug triage thanks to significantly improved speeds when browsing and navigating issues as a maintainer.
• Temporary interaction limits: You can temporarily enforce a period of limited activity for certain users on a public repository.

Do you have feedback on the directions we’re exploring? Share it in the community discussion.

Share what is working for your projects, where the gaps are, and what would meaningfully improve your experience maintaining open source.

The post Q1 2026 Innovation Graph update: Open source collaboration is accelerating worldwide appeared first on The GitHub Blog.

In the 1980s, Japan led the world in semiconductors, consumer electronics, and computer hardware, the industries everyone assumed would decide the next phase of economic power. Japan won them and still did not overtake the United States in the information revolution that followed. Jeff Ding, a political scientist at George Washington University, opens his book Technology and the Rise of Great Powers with the history of the first and second industrial revolutions and the third, the information revolution. The explanation he gives for who wins and who loses applies to companies as well as it does to nations, and very much to the current trajectory of AI.

Ding contrasts two theories of how technological revolutions reshape economic power. The conventional one he calls the leading sector model, or LS theory. It goes like this: New technologies create fast-growing new industries like steel and railroads and automobiles and semiconductors, and the country that dominates invention in those sectors captures the monopoly profits and the upstream and downstream economic linkages that come with them. As the story goes, if you win the leading sector, you win the era. Britain won in the first industrial revolution through its mastery of steam power, and then was surpassed by the US in the second through its leadership in electrification, the internal combustion engine, and mass manufacturing. The US kept its lead over Japan in the information systems revolution not by competing in the “leading sector” of electronic hardware but by diffusing “up the stack” via software that took the power of computing into every sector of the economy. (OK, that last bit is my explanation of what happened rather than Ding’s, but it’s consistent with his theory.)

Leading Sector theory is pretty clearly the working hypothesis of today’s AI industry and the national strategy that is forming around that industry. The company and the country with the biggest and best models wins. Everyone else is an also-ran.

Ding offers another explanation, which he calls diffusion theory. He points out that general-purpose technologies, foundational ones like the steam engine, electricity, and the computer, don’t just create massive profits and productivity gains in a single industry but instead spread across the whole economy. National economic leadership comes not from inventing the new sector but from diffusing the general-purpose technology more quickly and more broadly than your rivals. This happens over decades. The win goes to whoever most successfully embeds the technology into a wide range of ordinary productive work. This is how the US kept its lead over Japan rather than being surpassed by it.

This is obviously aligned with the thinking of Arvind Narayanan and Sayash Kapoor in “AI as Normal Technology,” which Ding cites in his book.

A big part of what enables diffusion is what Ding calls skill infrastructure, the education and training systems that widen the pool of people who can actually work with the technology. When the priority is widespread adoption rather than invention, he argues, the institutions that matter are the ones that build engineering skill at scale, standardize good practice, and tie research to industry. He writes:

GPT diffusion theory highlights the importance of GPT [General Purpose Technology] skill infrastructure. Education and training systems that widen the pool of engineering skills and knowledge linked to a GPT. When widespread adoption of GPTs is the priority, it is ordinary engineers, not heroic inventors, who matter.

Music to my ears, as it should be to yours: “It is ordinary engineers, not heroic inventors, who matter.”

That is not how the current AI narrative goes. Everyone is fixated on the labs, the frontier models, and the most famous researchers. And that fixation shapes enterprise strategy. Inside many companies AI strategy is a procurement decision: Which model and which vendor and which flagship tool should we choose? Or it’s a moonshot to stand up a lab and build an impressive demo and hire your own famous developer. Both approaches treat AI as a sector to be won. Ding’s argument is that the breakthrough sector itself is not where the long-term value for national power lives. And I believe that the same applies to corporate success. The value is in how widely and how well the technology gets embedded into the work of the people you already employ. The company that puts AI to work in finance and support and legal and sales and operations, across every unglamorous process, as well as in product and engineering, outperforms its competitors and drives its industry forward.

Diffusion is organizational, not technical

The reason diffusion takes a long time is that it is an organizational problem and not a technical one. In his oft-cited 1990 paper “The Dynamo and the Computer,” Paul David answered a quip from Robert Solow that you could “see computers everywhere except in the productivity statistics” by looking at the history of electrification, and more specifically, electric motors. When factories first electrified, they bolted a giant electric motor where the steam engine used to be and kept driving the same shafts and belts through the same Rube Goldberg system. Productivity barely moved.

The gains came decades later, when a new generation of entrepreneurs, factory architects, and electrical engineers redesigned the plant around what electricity actually made possible, with many small motors each driving its own machine and the factory floor laid out for the flow of work.

David’s account has since become a paradigmatic example of how technology transformation actually works. This historical analogy suggests that the future might not be ever bigger and smarter centralized AI models but a decentralized network of AI rightsized for thousands or millions of specialized tasks. Yes, there will still be big centralized AI dynamos somewhere, but most of the action will be with smaller (perhaps open source) models distributed throughout the economy.

But there’s more to the story than right-sizing the technology so that it can fit into specialized tasks. The know-how to reorganize work around it had to be built up one person and one plant at a time. This gradual, bottom-up growth of knowledge about how to apply a new technology is also the point of one of my favorite books about the first industrial revolution, James Bessen’s Learning by Doing. It’s also one of the key messages from Arthur Herman’s Freedom’s Forge, which tells the story of the rapid military industrialization of the US in response to the challenges of World War II. (This story may be newly relevant today as AI and drones transform modern warfare.) Herman called out Bill Knudsen’s bottom-up knowledge of the industry as a critical element in his success transforming the auto industry into a defense powerhouse. (Knudsen was the CEO of General Motors, but he had risen up the ranks from the shop floor.)

That is also the whole story of enterprise AI right now. The latest and greatest model is widely available. Frontier models are getting better so fast that diffusion of the latest and greatest model is not the point. That will happen naturally, much as the availability of the fastest PCs did 40 years ago when the diffusion frontier that provided actual competitive advantage moved to software.

What takes time to develop is the organizational know-how to redesign work around it. Most of that know-how does not live in the labs that trained the model. It lives in ordinary practitioners, and it accumulates the way David and Bessen and Ding have described, person by person and team by team, as people work out what the technology is good for in the specific context of their own industry and their own jobs. The speed of model turnover makes organizational skill infrastructure even more valuable, since it’s the only asset that survives each model generation.

What skill infrastructure looks like inside a company

Ding’s national version of GPT skill infrastructure is engineering education, standardized best practice, and strong links between universities and industry. My firm-level version of his vision is the internal apparatus for spreading skill and compounding what people learn. The problem with most enterprise AI transformation programs is that they treat AI as a subject to be taught rather than a capability to be built. Training is part of it, but only part. The harder part is the set of mechanisms that apply AI to the actual problems of the business, then capture each new discovery and turn it into something the whole organization can use, so that learning compounds instead of hiding away in a thousand private workflows.

In “The End of Programming as We Know It,” I made the case that AI expands who can build rather than replacing the people who build today. This means that a company’s best source of applied R&D is the everyday experimentation of the people it already has. The job is to make that experimentation visible, shareable, and rewarded. It is also the framework we are building into O’Reilly’s enterprise AI transformation programs.

We base our ideas about effective AI transformation in part on ideas we’ve taken from Wharton business school professor and author Ethan Mollick and from Dan Guido, the CEO of AI security firm Trail of Bits.

Join Dan Guido and Tim online at the Live with Tim O’Reilly event taking place on July 9. You can register here.

Mollick suggests solving the enterprise transformation problem takes three things: leadership that not only sets the conditions and incentives but gives a good example by getting their own hands dirty with AI; a lab that turns individual discoveries into tools everyone can use; and the crowd, meaning everyone else, whose daily work is where most applied discoveries actually happen. This is a great way to think about applied corporate AI adoption.

Guido adds a number of other elements to AI transformation strategy as we conceive it at O’Reilly. As he put it in his essay “How We Made Trail of Bits AI Native (So Far)”: “AI works. Most companies are using it wrong. They give people tools without changing the system. That’s the gap between AI-assisted and AI-native. One is a tool, the other is an operating system.” To build that “operating system,” he suggests that a company must:

1. Standardize its toolchain. This step seems boring and perhaps even unnecessarily restrictive but according to Guido, without a shared standard across an enterprise, you get zero organizational leverage. While experimentation is encouraged and different departments may have different tools, it’s important to constrain the possibilities so that you don’t get a sprawling set of incompatible workflows. That does not mean that the toolchain becomes fixed, just that organizational discipline is important. New capabilities and tools appear at a furious pace. A key corporate capability thus becomes how to evaluate and select tools at enterprise scale as well as how to govern the toolchain over time as the ecosystem evolves.
2. Write down the rules. When large language models were new, enterprise AI handbooks were full of warnings: Watch out for hallucinations. Watch out for putting in PII or proprietary company data. Beware of copyright infringement. Check and compensate for bias. And so on and on and on. As Mollick noted, such handbooks often discouraged adoption. Guido simply argues for clarity: what tools are approved, especially for sensitive data. For example, among their rules at Trail of Bits:  “Cursor can’t be used on client code (except blockchain engagements; use Claude Code or Continue.dev instead). Meeting recorders are disallowed for client meetings conducted under legal privilege.” He notes, “The handbook doesn’t just list what’s approved. It explains the risk model behind each decision, so people understand why….Once you have policy, you can safely push harder on adoption.”
3. Build a capability ladder. Every company needs an “AI maturity matrix” to help employees understand where they are in their AI journey and measure their progress. This is not an exhaustive list of tools and techniques to master. The spine of the Trail of Bits maturity matrix is not specific technical skills but the pathway from resistance or lack of engagement (stage 0) to comfort with using a job-relevant set of AI tools (stage 1), to proactively seeking out and adopting new tools and techniques and sharing them with others (stage 2), to actually creating new tools and techniques that advance the AI capabilities of the firm (stage 3). As shown in the sample AI maturity matrix that Guido published in his blog post, you can see how the specific tasks and tools vary by department. His basic point, though, is that improvement across this matrix needs to be expected, measurable, and rewarded. At O’Reilly, as part of our AI transformation practice, we’ve built a similar capability matrix, integrated with our verifiable skills tooling and learning paths, which we plan to work with our customers to adapt to their unique situation.
4. Run adoption sprints so the org keeps pace with new tools and releases. Some of the best learning happens via organization-wide hackathons where people apply AI to their own problems rather than learning in the abstract. This is where Guido’s framework marries perfectly with Mollick’s: Management can use a regular hackathon to get “the crowd” engaged with the latest round of AI developments and apply it to their actual work. “The lab” then takes the best of that and explores how to productize it and make it reusable across the organization.
5. Package organizational learning into reusable artifacts (skills, repos, configs, sandboxes) so the system compounds. Compounding is absolutely critical to successful AI transformation, and I’m starting to understand what it means and how it works.
6. Make autonomy safe with sandboxing, guardrails, and hardened defaults. Give new employees one-click install of the AI environment they are expected to become proficient with.

Another thing that needs to be clarified is access to data. At O’Reilly, we’ve found that a major challenge in reuse of AI tools and skills created by our employees is fragmentation of data access. Workflows often cross departments, with users in one department having access to data and systems that are invisible or inaccessible to others. This needs to be fixed. Everyone doesn’t have to have access to the same data; there may be good reasons why they can’t. But every organization needs what DJ Patil, the first US Chief Data Scientist, calls “the tidy house.”

One of the biggest problems in enterprise AI, DJ notes, is the patchwork of systems of record without clear structure on who gets to access which data. As he put it to me, describing the data infrastructure he built that has enabled Devoted Health to move so quickly with AI, it is “fundamentally still data 101, unified data environments, data flows that are clean, that have a lot of organization. . . .Because we invested so heavily in that infrastructure, the dumb, boring, painful parts of making sure you’ve got a really great data warehouse, great data engineering pipes, all of the metadata that goes with it, when AI shows up, you get to use it right away.”

One constraint may be the incentives

Ding’s theory needs one adjustment when it moves from countries to companies. For a nation, skill infrastructure is close to a public good. Educate more engineers and the whole economy benefits, more or less independent of who captures the immediate return. Inside a firm, diffusion may collide with incentives. The value comes from ordinary practitioners sharing what they have learned, but the practitioner who shares a workflow that automates half of her own job, in an organization that rewards looking indispensable and is quick to notice who looks replaceable, is being asked to act against her own interest. Mollick has pointed out that people hide their AI use for exactly this reason. And that’s why Guido’s methodology is so dependent on rewarding people for learning and sharing what they learn.

This is where corporate AI transformation strategy intersects with my interest in mechanism design, an often underappreciated branch of economics. (See my previous essay, “The Missing Mechanisms of the Agentic Economy.”) Mechanism design has been described as “reverse game theory”: start with the outcome you want, and design the rules of the game to produce it.

The constraint on enterprise AI adoption is not just the raw skill of the people. It is whether the organization has built incentives under which sharing what you learn raises your status rather than lowering it. Get that right and diffusion follows on its own. Get it wrong and you can have a small kernel of great people leveraging every frontier model on the market while adoption stalls out at a small fraction of your workforce.

Ding’s claim is that these transitions are won by the patient and the adaptive rather than the first and the flashiest. This fits right in with the messaging of Mollick and Guido. The companies that pull ahead over the next decade will be the ones that turned their ordinary engineers and their ordinary analysts and marketers and support reps into people who put AI to work in their own jobs, and that built the incentives to make them want to share what they learned.

Sovereignty, open source, and common protocols

Ding’s framework also helps clarify the geopolitics of AI. A foundational general purpose technology cannot remain the exclusive instrument of a single company or a single nation for very long. If it is that important, everybody has to have it.

That has implications for how we think about sovereign AI. The phrase is often used to refer to national competition for frontier capability. But sovereign AI is not just a matter of national power. It is a predictable consequence of diffusion. A technology that diffuses widely will be adapted by different societies, firms, and institutions to suit their own needs, values, and constraints. Sovereign AI is AI designed for diffusion, not just raw increases in capability.

This is one reason the arms-race framing is unhelpful. It encourages us to treat AI as if it were a weapons system or a scarce strategic asset. But if AI is closer to electrification, computing, or the written word, the important thing is how the technology is embedded into the ordinary life of economies and institutions, and whether that embedding happens in ways that increase agency broadly rather than concentrating it in a few hyperpowerful companies.

There are a few additional lessons we can take from the history of electrification. While motors became decentralized, factories stopped generating their own power and bought it from a centralized grid. The unit-drive revolution decentralized application, not generation. This limitation, which we are now working to overcome to some extent with decentralized solar generation, is perhaps ironically showing up most strongly in the strain that AI data centers are placing on the grid. Let’s learn from that misstep. You can diffuse AI into every workflow via API calls to a big centralized model, or it can be diffused by a network of smaller models that turbocharge every part of the economy.

We should design for a future of multiple AIs, not a single universal system. Different countries will want systems shaped by different legal regimes, languages, histories, and cultural assumptions. So will companies. So will professions and communities of practice. The instinct of some frontier labs is to imagine that the right answer is to homogenize the technology, purge it of bias, and offer a single sanitized intelligence layer for the world. But AI is a social and cultural technology. The differences are not a defect to be smoothed away.

We do need to think about standards and interoperability. The historical analogy that comes to mind is railroad gauge. When real world systems are built to incompatible standards, the result is not healthy diversity but decades of friction, kludges, and retrofitting. The same may prove true for AI. If we force the future into a choice between one universal model and a patchwork of disconnected sovereign systems, we will get the worst of both worlds. We need a layer between uniformity and fragmentation, which can come from standardized protocols that allow different models, tools, and institutions to interoperate without requiring them to become identical.

This is also why open source matters, but only if it is properly understood. Open source is not just about licenses. My earliest introduction to the shared development of software that now goes by that name came from the research community that grew up around Bell Labs’ Unix operating system despite AT&T’s proprietary (albeit permissive) licensing. Because of that experience, I became convinced that it was the modular, protocol-centric architecture of Unix that was a key driver of collaborative, internet-enabled software development.

Open source AI depends on far more than open models. It depends on the architecture of participation built into the systems above and around them: the protocols, servers, interfaces, and shared technical conventions that let many different actors build on common foundations. The Open Source AI Gap Map shows just how rich that open source AI ecosystem is becoming. But open source can also coexist with proprietary, de facto standards like the OpenAI and Anthropic APIs. Like the electric grid we are now beginning to rebuild, the AI future will be a mix of centralized and decentralized systems. Cooperation and competition can coexist. Different actors can build different systems, for different purposes, under different forms of governance, while still participating in a shared technical and economic order.

This is how the future can belong not just to the inventors of AI but to the people who make it usable, adaptable, interoperable, and worth adopting.

What an incredible week for the ecosystem. We are diving deep into what it truly means to build a community-first framework, exploring how AI agents are changing how we write code, and looking at next-level browser testing.

Get inspired and upgrade your workflow with this week’s resources:

The Dev Life Podcast: Community-First Engineering with Magda Kustosz
Brooke Avery @JediBravery and Matthew Christiansen sit down for a must-listen conversation with our very own Angular Community Manager, Magda Kustosz 🌟 Dive into the strategy, heart, and insights behind building a community-driven ecosystem. Plus, check out the full playlist intro to catch the rest of the season’s tech discussions.

Listen to the Community Episode: https://www.youtube.com/watch?v=YAT7vc1zYLg Check out the full playlist: https://www.youtube.com/watch?v=6nmeHYDjZk8|

Agentic Coding: AI Support for Angular
Johannes Hoppe @JohannesHoppe and Ferdinand Malcher @fmalcher01 explore the frontier of Agentic Coding. Discover how advanced AI agents are moving past simple autocomplete to provide deep, context-aware architectural support tailored specifically for Angular workspaces.

Read the blog post: https://angular.schule/blog/2026-02-agentic-coding

Test Components Like a Real User with Vitest “Full” Browser Mode
Younes Jaaidi @yjaaidi drops a game-changing tutorial on testing. Learn how to leverage Vitest’s Full Browser Mode to test your Angular components exactly how a real user interacts with them in an actual browser environment.

Watch the testing guide: https://youtu.be/Pu22JQG6jdg

Signal Forms & Extended Compiler Diagnostics (Spanish with English Subtitles) Alejandro Cuba Ruiz @zorphdark brings us two fantastic videos with English subtitles. First, a comprehensive deep dive into the practical power of Signal Forms. Second, an essential look at how to leverage the Extended Diagnostics of the Angular Compiler to catch tricky bugs before they hit production.

Watch the Signal Forms breakdown: https://youtu.be/3AD-vIqvCgs
Watch the Diagnostics guide: https://youtu.be/Dt5rw1UCh5Q

AI Image Generation with Firebase Server Prompt Templates
Connie Leung @connieleung404 shares an excellent code sample showing how to generate images using Angular and Firebase AI Logic, utilizing Server Prompt Templates for secure, scalable AI operations.

Explore the GitHub repository: https://github.com/railsstudent/ng-server-prompt-template-demo

Restoring Status CSS Classes in Signal Forms (French)
Modeste Assiongbon @rblmdst continues his expert French-language coverage of Angular v21, walking through how to seamlessly restore form status CSS classes when working with the new Signal Forms API.

Watch the French tutorial: https://youtu.be/sSgu2DVIgPI

What does “community-first engineering” mean to you? Whether you’re answering questions on forums, speaking at meetups, or writing open-source code, your voice builds this framework.

Let’s keep the knowledge moving. Use #AngularSparkles to share your favorite mid-year tutorials and insights 👇

---

Community Engineering, Agentic Coding, and Real-User Component Testing 🎙️🤖 was originally published in Angular Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.