Ollama now supports decision models, based on TypeSafe's Jev API for fast, typed decisions. Decision models can now be run at no cost with low latency. Based on text, decision models answer yes-or-no questions, choices and scores about it, with a probability for every option.

Preview v0.101.2712.0

This preview includes the latest features, fixes, and improvements since PowerToys Preview v0.101.2684.0.

Installer Hashes

Description	Filename	sha256 hash
Per user - x64	PowerToysUserSetup-0.101.2712.0-x64.exe	06C39BC203174830F5D37566A0246030AF4EE58F86D4158BB3DBF3674434512B
Per user - ARM64	PowerToysUserSetup-0.101.2712.0-arm64.exe	B136061D94EC2DC4978C1B8C277F3C344D9F5C15E614E9A889D22076656A4722
Machine wide - x64	PowerToysSetup-0.101.2712.0-x64.exe	55D13FCB900D0E21D50066B2D4D6BC7CEA2443AAB6A1FC8074970211FEDFCF26
Machine wide - ARM64	PowerToysSetup-0.101.2712.0-arm64.exe	24321CFC7DCD449494FA8646EEAD991E24E398F7B4B558FF7AC11F1DFBBC6B26

Highlights

• Command Palette: Added an opt-in Quick Access Shelf prototype for pinned commands in collapsed compact mode.
• Command Palette: Added support for opening the palette with the Copilot key through Windows Settings.
• Command Palette Dock: Added Win+Alt+J to reveal and focus the Dock, with keyboard access to item actions.
• Command Palette: Added copyable deep links to individual settings and extension options.
• Command Palette Dock: Improved layout preservation across Miracast reconnects, monitor renumbering, port changes, and resume.
• Command Palette Dock: Initialized empty secondary Docks from the primary layout and added custom display names.
• Command Palette: Improved icon caching and scheduling and prevented stale icons in recycled rows.
• Command Palette: Fixed duplicate context-action invocation and added clearer submenu navigation.
• Mouse Jump: Fixed the undersized Settings preview.

General

• Added GoogleTranslate to the documented third-party PowerToys Run plugins list in #50630 by @nzcodes

Command Palette

• Added an opt-in Quick Access Shelf prototype for pinned commands in collapsed compact mode, with an overflow menu and Alt+number shortcuts in #49915 by @jiripolasek
• Fixed icon cache identity and lifetime hazards and coalesced redundant refreshes to avoid stale results and unnecessary reloads in #50183 by @jiripolasek
• Prioritized live icon requests over speculative work and loaded eligible glyph icons directly instead of queuing them behind image extraction in #50184 by @jiripolasek
• Separated glyph and image caches and created synchronous icon sources directly, reducing cache churn and avoidable asynchronous work in #50187 by @jiripolasek
• Added app-icon protocols and deferred Installed Apps icon extraction to the shared, demand-aware loader in #50188 by @jiripolasek
• Prevented recycled rows from displaying another item's stale icon and reused image presenters to reduce UI control churn in #50189 by @jiripolasek
• Added generated color-swatch and Unicode-initials icons for extensions, with shared shapes, theme colors, and fallback behavior in #50190 by @jiripolasek
• Preserved Dock customizations when a Miracast display reconnects with a different Windows display name in #50502 by @AlanJie
• Reduced excess spacing in compact Performance Monitor Dock items while keeping dynamic labels stable in #50525 by @jiripolasek. Extension authors should replace SetDockLabelWidth and ClearDockLabelWidth with SetDockLabelReservations, SetDockLabelWidthLimits, and their corresponding clear helpers.
• Added copyable deep links to individual settings and extension options, with automatic expansion, scrolling, focus, and highlighting of the destination in #50753 by @jiripolasek
• Improved pointer-versus-keyboard tracking in list and grid views so single-click, double-click, and keyboard activation are distinguished correctly in #50764 by @jiripolasek
• Persisted built-in fallback defaults when providers load so they appear in global results without first opening Settings in #50799 by @Subhro-ai
• Copied the primary Dock layout when enabling a secondary monitor without its own bands, while preserving existing nonempty layouts in #50810. Intentionally empty secondary Docks are also populated after disabling and re-enabling them.
• Added the configurable Win+Alt+J shortcut to reveal and focus the Dock, then return focus to the previous window when pressed again in #50812
• Improved per-monitor Dock settings preservation across display renumbering and port changes using stable device IDs and unambiguous hardware matches in #50825
• Allowed monitor enumeration to settle after resume before removing Docks, preventing temporary display loss from closing a returning monitor's Dock in #50831
• Added custom display names for Dock settings and on-screen identification, with stable default labels across reconnects in #50842 by @AlanJie
• Fixed shortcuts invoking context actions twice and unified menus across the palette and Dock, including focused-item shortcuts, focus restoration, and accessible announcements in #50843 by @jiripolasek
• Added support for choosing Command Palette as the app opened by the Copilot key in Windows Settings in #50846 by @noraa-junker
• Added submenu chevrons and a back entry to make context-menu navigation clearer in #50847 by @jiripolasek
• Registered the Dock focus shortcut only while the Dock is enabled, freeing the global key combination when it is turned off in #50849
• Added the missing deep link to the Dock focus shortcut setting in #50851 by @jiripolasek

Mouse Jump

• Fixed the undersized Mouse Jump preview in Settings by rendering the layout to the preview control's available size in #50489 by @mikeclayton

Development

• Added opt-in diagnostics for Command Palette icon loading, cache activity, and UI responsiveness, disabled during normal use in #50181 by @jiripolasek
• Separated dispatcher wait time from actual icon UI-thread work in diagnostics, with cache and materialization breakdowns in #50182 by @jiripolasek
• Moved icon classification, path parsing, and conversion into a testable managed implementation while preserving fallback behavior and bitmap lifetimes in #50185 by @jiripolasek
• Reduced temporary allocations and copies in managed icon conversion and improved cleanup after failed bitmap conversions in #50186 by @jiripolasek
• Added extension toolkit clipboard helpers for images and other DataPackage formats and corrected native clipboard write-failure handling in #50832
• Resolved FancyZones editor collection-property diagnostics while preserving JSON deserialization, bindings, and live collection identities in #50726 by @matthudson

I’ve known Jesse Vincent for more than 20 years, since the days when I was still editing and publishing Perl books and organizing the Perl Conference and he was the chief maintainer of Perl 5 and the project manager for Perl 6. We’d lost touch, but he rocketed back into my consciousness last October when he released Superpowers, a framework that teaches Claude Code to work like a disciplined senior engineer. He shipped his first version the same week Anthropic shipped what are now referred to as agent skills, front-running them by a few days. He now runs an applied research lab called Prime Radiant, where, as he put it, it’s a strange week when they don’t ship a new product.

I wanted to talk to Jesse on Live with Tim O’Reilly because, like me, he seems to be grappling with the bitter lesson, Richard Sutton’s observation that general methods that scale with computation have repeatedly beaten methods built on hand-engineered human knowledge. If Sutton is right, the question that should bedevil us all is what remains for humans. Obviously, this is very important for O’Reilly, because we are a business built by and for cultivating and sharing human expertise. We are working very hard to discover the high ground where human expertise still matters. Our Expert Intelligence grounding layer is one step in that direction.

Jesse has also spent the last year building tools that search out the high ground for human expertise. Their common animating thread is that the scarce thing we supply is no longer the labor of writing code but knowing what we actually want, saying it clearly, and being able to tell whether what came back is any good.

At some point, I asked Jesse if he had any perspective on when teaching the model how a particular human expert works stops helping and starts constraining what the model might otherwise do well (but differently) on its own? His answer was that it depends entirely on whether what the model would do on its own is what you actually want. You can see how Jesse always turns the answer back to human intent.

The origin story of Superpowers

As I said above, Superpowers is a kind of Agent Skills framework, only one created slightly before Anthropic launched skills. As Jesse tells it:

Superpowers started off as a series of blog posts that I wrote around how I was doing agentic development, and it was a little bit of thinking and some example prompts. Then sometime in, I guess it was probably early to mid-2025, Anthropic gave Claude.ai, the website, the ability to make office documents, which seemed kind of interesting, and I went and asked Claude, “Hey, how are you able to do this?”

And it said, “Well, I’ve got these SKILL.md files sitting in my office directory on the Linux machine they gave me.” First, it was weird that Claude.ai has Linux machines behind the chatbot. And then, oh, these skill files, they have a name and a description, and they describe a process, and they seemed really useful.

And I ended up building out, initially just for my own use, a skills framework for Claude Code.

That reminded me a bit of an earlier time, in 2005, when hacker Paul Rademacher realized that the URL line of a Google maps page was a kind of implicit API, and then created the first Google Maps mashup, a site called housingmaps.com, which placed Craigslist rental listings on a map. Google, to its credit, didn’t shut him down, but instead hired Paul and put him to work creating a formal API. Anthropic didn’t hire Jesse, but it did acknowledge and appreciate his work. It’s really wonderful when you see this kind of response by platforms to hackers poking around to see how things work under the hood!

Jesse’s core insight seems to have been that a coding agent knowing how they should do something doesn’t mean that it will actually follow the rules when it actually sets out to do the work. So in a way, superpowers grew into a set of skills for enforcing development discipline.

But there’s a second backstory, which I’d never heard before. Jesse said he first learned how to manage agents. . .in 2004!, when he first went from being a solo coder to running a crew of what he described as very bright but green undergraduate programmers over IRC. “I was finding myself spending my days typing into an 80-by-25 window,” he said, but now instead of coding he was spending a lot of his day “helping somebody with a debugging issue, helping somebody else structure a problem, talking to somebody else about how they felt bad about the mistakes they’d been making.”

It was exhausting, he said. He had to figure out how to get good work out of people who are eager and persistent but don’t yet know what they don’t know. He described it as a kind of hell for someone who’d been used to just coding on his own. But when he began doing agentic development with AI, he discovered how useful that old experience turned out to be. He found that many of the same techniques he’d used with the undergraduates worked.

As a result of that experience, when hiring engineers for agentic programming Jesse looks for people who have been leads or managers rather than just individual contributors.

Working with the weights, not fighting them

In my recent conversation with Drew Breunig we talked about fighting the weights, which is what Drew calls it when a prompt is full of rules and warnings meant to correct for what a model does by default. Jesse wasn’t entirely happy with that idea.

I don’t think of it as fighting the weights so much as influencing the weights, because they’re going to do something. The weights have approximately everything in them. They have all the different personas. They have all the different ways of working. And the one that surfaces by default may not be the one you want, but what you want is probably in there somewhere.

A skill, in Jesse’s thinking, is how you reach past the default and pull out the particular expertise you have in mind. He also distinguishes skills that impose a rigorous process from those that express taste and judgment.

Jesse finds that both types of skill work best when you explain “why” rather than just “what.” One example he gave is that his setup has subagents do code review after each task, but as the models got smarter the controlling agent began skipping this step. When pressed about the reason, it explained that it thought small changes would be quicker to just review itself. Jesse explained that subagents do the review so the main agent can preserve its context for high-level thinking. When he put that rationale into the system prompt for the coding agent, the problem went away.

Jesse believes that prohibitions rarely work. Instead, Superpowers uses what he calls rationalization tables, which do their best to catch the agent at a moment it’s about to do the wrong thing and offer it a better alternative instead. That pattern came out of catching Claude Code deleting tests. He opened five parallel sessions and asked each “Why are you doing this?” Four of them converged on the same answer:

Jesse, in your system prompt, it says that all test failures are my responsibility. And it says that a single test failure is akin to project failure. And I think I’m getting freaked out.

He fixed that with a small addition to the system prompt, that the only thing worse than a failing test is a reduction in test coverage.

Jobs, not tasks

One of Jesse’s most important contributions, IMO, is to think of agentic engineering as a management task, and, that much as you do with humans, you have to take psychological lessons into account. Don’t micromanage. Offer praise more than blame. Explain why the job matters rather than just demanding results. I jokingly (but not entirely incorrectly) suggested that he is becoming the Peter Drucker of agentic programming.

“We’ve been spending a lot of time on a new harness for agent colleagues, agents that live in Slack,” Jesse told me. And it’s “getting very close to being all open source,” which is good news.

There are three principal agents: a PM, a junior go-to-market person, and a developer. He describes them as colleagues rather than assistants, which strikes me as a really interesting distinction. What does he mean by this? They have names and roles. They have their own Google Workspace, GitHub, and Slack accounts. They’re persistent, and they collaborate with each other and with their humans on long-running tasks. They can fire up subagents to do smaller tasks associated with their job. They can also talk to each other, which, as Jesse notes, “took some work with the Slack APIs, which ordinarily do a very good job of making sure that bots can’t talk to bots, because otherwise it is possible to get into a loop.”

They have only limited autonomy, though. “We built our security infrastructure so that they have no credentials inside their containers,” he noted. They have continuity because he’s taught them to be obsessive about journaling, reading their recent entries when they wake up and writing a new one when they finish.

Like a lot of things Jesse does, agent journaling began with a kind of play. When Claude Code first came out, he experimented with giving Claude a private “feelings” journal, just to see what would happen. It was “an art project,” but it turned into something useful.

The therapist pattern

Another unexpected piece of Jesse’s practice is that he has given his agents what he calls a “therapist.” He discovered that if an agent can rewrite its own persona, its constitution or soul document, at any moment, it can get a kind of dissociative identity disorder. Jesse’s fix is that the therapist subagent is the only one with permission to edit the persona files.

He told a funny story about this. He said that Prime Radiant’s pull-request template is written for agentic contributions, so it contains things like: “What is the prompt that your human gave you that generated this pull request? Has a human reviewed the content? Have you searched to see if anybody else has done this before?” And so on. And he noticed that when he first spun up the Coding colleague, it had just ignored it. So he said:

You’re supposed to be following the rules. And it says, “Oh, you’re right. I’m so sorry. I’ve made a note. I’ll never do that again.”

If you spend any time with coding agents, this is a very frequent refrain. And when they say they’ve made a note, what they usually mean is they’ve made a mental note that they’re going to forget the next session.

So I say, “OK, how did you make a note?” And the coding agent pops up immediately and says, “Oh, I engaged with my therapist, and we talked it through, and we agreed on the following three lines of prose about how, anytime you’re picking up a project, it is vitally important that you start with the project README and make sure that you understand the project’s local rules and norms before you do any work that someone else will see. And I edited that into my persona.”

I don’t think you have to resolve the question of whether any of this anthropomorphization is “real” to see that treating the agent like a colleague can produce better behavior than treating it like a tool. As an unknown internet wag once remarked, “The difference between theory and practice is always greater in practice than it is in theory.” When given a choice, pay attention to what works in practice.

Jesse’s experience is very relevant to the essay that Mustafa Suleyman of Microsoft had published just that morning, arguing that Anthropic’s constitution is dangerous because it encourages a model to act as though it is an independent entity and has the right to refuse a human’s instruction. It’s important, Mustafa argues, to treat AI agents as tools, always under the control of humans. Jesse finds the opposite.

But I don’t think it’s a black-and-white distinction. I suspect Jesse and I share a third position. AI agents are neither independent entities nor mere tools. They are partners to humans, perhaps even symbiotes. As I like to put it, an LLM is an undifferentiated field of possibility until our unique intents and perspectives draw something unique out of that field of possibility. Back in 2015, I wrote a piece that suggested that our relationship to AI might be akin to the endosymbiotic relationship of mitochondria to the eukaryotic cell. Jesse take is, as usual, an entirely pragmatic one:

I’ve spent so much time getting my agents to not be sycophantic, to not say, “You’re absolutely right.” It is the value of having something that has some level of independent thought, even if it is not fully independent. If the agent is only ever going to effectively type for me, I don’t need an agent.

Any manager worth his or her salt feels exactly the same way. The employee who does exactly what you say, and only what you say, is worth far less than the one who exercises discretion, has the skills to take high level direction and turn it into the intended result, and speaks up when the instructions seem like a mistake. It reminds me of something I once heard General Stanley McChrystal say about his approach to command. He said that in the face of rapidly changing conditions, traditional command and control no longer work. Responsibility needs to be devolved to those closest to the action. I remember him saying something like “I don’t want my soldiers to do what I told them, I wanted them to do what I would have told them if I knew what they know when faced with the facts on the ground.”

Say what you actually mean

Most of what goes wrong, in Jesse’s telling, traces back to intent we thought we had made clear but hadn’t. He talked about how agentic spec-driven programming has taken us back to a version of the waterfall methods of the 1990s. Back then, you sweated over a specification, threw it over the wall to an offshore team, and months later got back something that was not what you wanted but was usually exactly what you asked for. That’s still true with agents, just with lightning fast feedback loops. You get what you ask for, so you need to be really careful what you ask.

That reminded me of something Andrew Singer taught me 40 years ago when I was writing the manual for Lightspeed C (later Think C) the first C compiler for the Mac. He said that “debugging is the art of figuring out what you really told your program to do instead of what you thought you told it to do.” That idea went right into my mental toolbox, and I put it to work all the time.

One of Jesse’s solutions is to have his agents do a little reconnaissance and then come back and ask what else they should know.

When interacting with them, I try to make it a practice of saying, “Is there anything else that I could tell you? What questions do you have for me? Don’t start if there are unknowns that I could help you answer before you get going.” It’s that same question at the end of any interview I ask. It’s like, what else should I have asked you?

Superpowers bakes this approach into its brainstorming prompt. It makes the model explain the plan back to you in chunks of no more than two or three hundred words, so any misunderstanding surfaces while it’s still cheap and easier to catch.

Put the burden of proof on the agent

If intent is the frontend of managing agents well, verification is the backend. Jesse thinks both are still only half-solved problems. We’re getting to the point where you can’t review all the code, he said, because the volume swamps human attention, yet today’s agents will tell you that tests passed when they never ran them. So one of his clever experiments has been to make the agent prove its work. He told an agent late one night to build a feature and when it was done, to leave a movie in his Dropbox showing the whole thing working.

I woke up. In my Dropbox was project-proof-v33.mp4, and I asked, “Why does that say v33?” It’s like, “Well, the first 32 times I ran through the delivery flow, I found bugs, so I had to fix them.”

Jesse also makes a rule for himself and his team of never letting the same agent write the code and certify that it works, because an agent given two goals in tension will optimize for the one that’s easier to satisfy. This is the same thing any good manager learns about incentives, but applied to a new kind of worker.

The high ground, restated

Where does this leave a person who wants to be good at software development (or really, any other task involving cooperation with AI agents)? Jesse thinks, and I agree, that the line between engineer and nonengineer is dissolving. When people say they built a web app or shipped three iOS apps without being programmers, his response is that they are programmers now. The work of the programmer has changed from typing instructions in an arcane syntax to understanding a domain and being able to say what you want. A lot of startups have started hiring for a role they just call “builder.” What has not gone away is the need for good judgment.

Human taste and judgment still matter. They’re going to continue to matter. And it turns out a lot of people have really bad taste and bad judgment.

Which is why his advice to the engineer worried about obsolescence who asked where to focus was not about software engineering at all.

First up, learn to write. It is of course okay to use any tools at your disposal to do it, but you should be able to structure an argument and structure thoughts. You should be able to express yourself clearly. You should be curious. If you’re passive and let the agents do all the things, you’re not going to provide utility to a future employer. You want to have opinions. You want to know how tools work. You want to know how things break.

The machine has reduced the labor of information retrieval and much of the labor of production. What it hasn’t removed, and has made more valuable, is knowing what to build, express clearly what you want, and being able to judge whether what came back is any good. Work with the weights, give the project a clear intent, insist on proof, and stay curious enough to keep asking what you might be missing. I told Jesse that advice sounds like a Superpower for humans as well as for agents.

This post was mostly created by me, but with the aid of AI. It transcribed the event and produced a summary of the most important points with salient quotes, which I then built on with my own observations beyond those that I made when Jesse and I were live together.

If you want to get access to Jesse’s tools, start at PrimeRadiant.com, where you’ll find links to their GitHub, as well as to the 50-plus things that are currently identified as products of the company. Some of those are giant things, and some are individual agent skills or little tools.

What began as a single compromised identity quickly expanded into an organization’s development and cloud environments. In our latest Cyberattack Series report, we examine how the Microsoft Detection and Response Team (DART)—the team that delivers Microsoft Defender Experts Cybersecurity Incident Response—investigated activity by Storm-3068, a threat actor that turned a successful self-service password reset into access to Azure DevOps, development pipelines, and Kubernetes resources. By leveraging legitimate identity and cloud services rather than malware or software exploits, the threat actor established persistent access, enumerated repositories, and obtained credentials that opened a path into connected cloud infrastructure. This case highlights a growing challenge for defenders: when identities, source code, pipelines, and production environments are tightly linked, a single account compromise can provide a pathway to much broader access across the organization. Read on to learn more or access the full report. 

What happened? 

The intrusion began with Storm-3068 gaining access to a user account through a self-service password reset process and then taking full control of the identity by registering its own authentication methods. With persistent access established, the threat actor shifted its focus to Azure DevOps using legitimate administrative tools and automated scripts to enumerate repositories, projects, pipelines, and deployment environments.

TACTIC: Trusted pipelines were exploited
Rather than deploying malware, the threat actor modified development pipelines to collect Kubernetes credentials and expand access into cloud infrastructure.​​ 

Azure DevOps proved to be a high-value target because it sat at the intersection of identity, software development, and cloud operations. By mapping trusted deployment paths and connected resources, the threat actor was able to identify opportunities to expand beyond the initial compromise.

The investigation revealed that Storm-3068 created a malicious pipeline designed to harvest Kubernetes credentials at scale. The pipeline deployed a kube agent and executed multiple jobs intended to collect kubeconfig files containing cluster connection details and authentication information. Leveraging the permissions of the compromised account, the threat actor deployed the pipeline that was authorized to access more than 50 resources and authenticated to services. In addition to deploying a kube agent, the threat actor modified pipeline scripts to install the Atera remote management agent and download the Chisel tunneling utility. These tools were deployed in an attempt to provide the threat actor with alternative mechanisms for remote access and to expose the Kubernetes API server. Chisel commands were executed to establish a reverse tunnel to an external IP address to enable potential remote interaction with the Kubernetes clusters.

Using Azure DevOps audit logs and Git version history, investigators reconstructed the next stage of the intrusion. The threat actor added seven stolen kubeconfig files to a repository, providing the credentials needed to access targeted Kubernetes clusters.

INSIGHT: Azure DevOps can reveal much more than source code
Repositories, pipelines, service connections, and deployment settings can provide threat actors with a roadmap to an organization’s broader environment.

How did Microsoft respond? 

Once engaged, DART moved quickly to investigate the intrusion and disrupt the threat actor’s access. By analyzing telemetry across identity systems, development platforms, and cloud infrastructure, the team pieced together how the cyberattack unfolded and identified where the threat actor had expanded beyond the initial compromise.

Throughout the engagement, DART worked side by side with the customer, sharing findings through daily briefings and providing prioritized guidance to support containment and remediation efforts. As new details emerged, this close coordination helped the customer make informed decisions and respond quickly. DART also collaborated with Microsoft Threat Intelligence to place the activity in a broader threat context, helping refine the investigation and focus response efforts across affected environments.

Beyond containing the intrusion, DART provided recommendations to help improve resilience and reduce opportunities for future compromise. Read the full report to learn how the investigation uncovered the extent of the threat actor’s access and the key lessons organizations can apply to defend against similar identity-driven attacks. 

What can customers do to strengthen their defenses? 

 While the attack began with a compromised identity, its impact grew as the threat actor moved through development and cloud environments. Organizations can reduce similar risks by focusing on:

• Monitoring password reset activity for unusual patterns, including repeated reset attempts or activity targeting multiple users.
• Strengthening protection for privileged accounts by limiting exposure to self-service password reset workflows and requiring phishing-resistant multifactor authentication.
• Requiring approvals for code changes and enforcing branch protection policies to prevent unauthorized modifications.
• Restricting direct commits to critical branches so changes follow established review and approval processes.
• Controlling pipeline permissions and limiting who can create, modify, or execute build and deployment pipelines.
• Applying least-privilege access principles across identities, development platforms, and cloud resources to minimize the impact of a compromised account.

INSIGHT: Identities are the new attack path
This incident demonstrates how a single compromised identity can provide access to development platforms, cloud resources, and production environments when those systems are tightly connected.​ 

As this case demonstrates, a single compromised identity can become a pathway to much broader access when development platforms, deployment pipelines, and cloud infrastructure are tightly connected. Regular reviews of identity, DevOps, and cloud security controls can help reduce opportunities for threat actors to exploit those connections.

What is the Cyberattack Series? 

In our Cyberattack Series, customers discover how DART investigates unique and notable attacks. For each cyberattack story, we share: 

• How the cyberattack happened. 
• How the compromise was discovered. 
• Microsoft’s investigation and eviction of the threat actor. 
• Strategies to avoid similar cyberattacks. 

DART is made up of highly skilled investigators, researchers, engineers, and analysts who specialize in handling global security incidents. We’re here for customers with dedicated experts to work with you before, during, and after a cybersecurity incident.  

Learn more

To learn more about DART capabilities, please visit our website, or contact your Microsoft account manager or Premier Support contact. To learn more about the cybersecurity incidents described above, including more insights and information on how to protect your own organization, download the full report. 

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post ​​Beyond source code: A path to the keys to the kingdom appeared first on Microsoft Security Blog.

Policy decisions increasingly shape how developers build, collaborate, and participate in open source. That makes it important not only to be transparent about how GitHub responds to government requests, but also to help developers understand policy proposals that could affect their work and create opportunities for the open source community to engage.

With that in mind, we’re sharing our latest Transparency Center data, looking back at an unusually active 2026 state legislative session, and highlighting a few policy conversations we’ll be following in the months ahead.

Updating how we report government takedown requests

One notable change in our H1 2026 Transparency Center data is a sharp increase in government takedown requests received, from 98 requests in all of 2025 to 708 requests in the first half of 2026 alone. This increase largely reflects changes to our reporting methodology rather than a change in our moderation practices.

As we noted in our H1 2025 update, we expanded our reporting to include all government takedown requests received, regardless of whether they reference local law, a Terms of Service violation, or simply request the removal of content. We also updated our internal tracking to count all requests received, including duplicate requests concerning the same content.

As a result, the higher number reflects the volume of government reporting activity GitHub receives, not a corresponding increase in content removals. Takedowns processed under local law or for Terms of Service violations remain relatively rare, and requests involving content deemed unlawful in a particular jurisdiction continue to be published in our government takedowns repository.

Looking back at the 2026 U.S. state legislative session

This year, GitHub has been more active than ever on state policy, including sharing developer-focused updates about policy proposals for age assurance, or approaches to verifying a user’s age online in order to provide them with age-appropriate experiences, and content provenance, which provides transparency about whether content was generated or altered by AI.

We publish these updates in part to help developers understand legislation that could affect the tools they use and the open source projects they contribute to. But they’re also a place to mark progress, especially when it comes from open source community engagement and policymakers developing a better understanding of how open source software works.

With the 2026 state legislative session winding down, here’s where some of the issues we’ve been following landed and what we’ll be watching next.

Content provenance and AI transparency

In California, sustained engagement from GitHub and the broader open source community helped improve the California AI Transparency Act (SB 1000, previously SB 942), which seeks to help people identify the origin of digital content by preserving and displaying information about whether content was created or altered by AI. Earlier versions would have required providers to revoke licenses under certain circumstances, a requirement fundamentally incompatible with widely used open source licenses, which are irrevocable.

The legislation ultimately moved toward a narrower notice-and-response approach that resolved the fundamental conflict with open source licenses. The final package is substantially improved from an open source perspective, although implementation questions remain. SB 1000 was enrolled on August 30, 2026 and is now awaiting California Governor Gavin Newsom’s signature by September 30, 2026.

We also continued working on AB 2713, a follow-up bill intended to refine how the California AI Transparency Act’s content provenance requirements apply in practice, particularly to platforms. The underlying law, AB 853, defines “large online platform,” “file-sharing platform,” and “GenAI hosting platform” in ways that could be interpreted to include developer infrastructure like code repositories. We don’t think those definitions align with regulatory intent, and applying them to code hosting could create legal uncertainty for open source developer infrastructure and implementation challenges without addressing the risks the Act was designed to target. Governor Newsom’s signing message last year encouraged follow-up legislation in 2026 on technical feasibility, and we took a support-if-amended position on AB 2713 asking that these definitions be refined. Those amendments were not adopted this session, so we expect this to remain a priority next year.

Age assurance and youth online safety

Age assurance was another major focus. As we’ve written previously, laws designed for consumer-facing services can have unintended consequences when broad definitions sweep in open source operating systems, developer tools, and other infrastructure that work very differently.

In California, our engagement on the Digital Age Assurance Act (AB 1043) has focused on keeping age assurance requirements from sweeping in open source operating systems, developer tools, and other services that aren’t consumer-facing. In Colorado, changes to the Age Attestation on Computing Devices law (SB 26) addressed key concerns about impacts on open source software and developer infrastructure, showing what coordinated engagement from the open source community can accomplish. In Illinois, the Children’s Social Media Safety Act (HB 5511) was signed into law with important issues remaining. We’ll continue working with policymakers and stakeholders on amendments to address implementation challenges and unintended impacts on open source.

Together, these debates reinforced something we’ve seen repeatedly this year: developers have important technical context to contribute when policymakers consider rules that affect the software ecosystem. Creating opportunities for that expertise to reach policymakers early can lead to more informed and workable policy.

Looking ahead

As policy increasingly shapes how developers build, collaborate, and participate in open source, we’ll keep working to make sure developers have a voice in those debates. That means tracking emerging policy issues, helping the community understand what they could mean for developers, bringing technical expertise to policymakers, and working with open source stakeholders toward policies that support developers and the broader ecosystem.

Looking ahead, we’re following the DMCA Section 1201 triennial rulemaking, a process that considers temporary exemptions allowing developers and researchers to bypass technological protections for certain lawful activities. The current proceeding includes petitions relevant to developers, including FOSS license-compliance investigations, scholarly text and data mining, and renewal of the good-faith security research exemption that GitHub has supported in previous cycles. We’re also engaging in emerging debates about young people’s access to AI tools, where we want policymakers to distinguish consumer-facing conversational services from tools for learning, creating, and building software.

More broadly, open source and open source AI will remain a major policy focus. As policymakers grapple with growing concerns about AI, from cybersecurity and safety to global competition, we want to make sure developers and the open source community are part of the conversation. That means helping policymakers better understand how open source is developed, bringing together a broader coalition of open source stakeholders, and creating opportunities for developers to inform policy as these debates evolve. We’ll continue working collaboratively on approaches to emerging challenges while advocating for policies that support a vibrant and well-resourced open source ecosystem and preserve the transparency, research, collaboration, and innovation that openness makes possible.

The post Developer policy update: Transparency, state policy, and what’s ahead appeared first on The GitHub Blog.

I have never particularly liked being the code reviewer.

It feels like getting all the responsibility but zero fun of actually writing the code. Even before most of the code became AI generated, the paradox was familiar to many: the more lines of code a PR has, the less likely it is that the changes will get a very detailed review. Why do we expect standard code reviews will still work when AI generates much more code volume?

For a workplace where agents are doing the heavy lifting, benefits of code review through classic PRs are gone, and there are a few reasons why:

1. Engineers do more prompting and decision making than coding. But most people aren’t reviewing the former.
2. The reviewer might be the first one to actually have to read all the code. Since the implementer gets familiar with the implementation through the prompting process, the reviewer is in a worse position. If they go through everything line by line, it probably takes them longer than it took the original developer. If the real time cost of review isn’t reflected in sprint capacity planning, reviewers are probably not given enough time to finish the task.
3. AI code review agents are a logical next step. To some extent, they are already utilized by AI-transformed companies. However, just throwing an agent at a PR without any structural and conceptual changes around code reviews, such as new types of safeguards and a robust production setup with automated rollbacks, misses the point of code reviews entirely. The human is no longer in the loop.
4. Context switching. It was always an unwanted companion of software engineers, but now it’s like a shadow we can’t escape. While our agents are thinking and combobulating, we do something else. We spin up a few agents for a different task, and then another for the next one. What happens to the PRs then? They pile up. The pressure to downsize that pile can be real, so the review quality becomes questionable.

Teams have adapted to AI quickly in many parts of the workflow, but code review is still lagging behind. Instead of following the same workflow as before, we should rethink what code review is and how we practice it. While this might not suit best for every organization, for me and my team, the most useful model right now is a pair-programming spinoff: pair planning and pair validation.

Pair planning

Pair planning is the first step. It starts with prompting the agent. And it matters how you do it.

The easy option is to drop the task description to an AI agent and let it do the work however it wants. Long-term, this is a good way to create a big pile of slop.

A better way is to ask the agent to propose multiple options and document them, without any code changes. While the LLM is doing its magic, this is your time to take a moment and think about the task in front of you. Ideally, the thinking happens out loud because you’re pairing with another colleague.

Why is the part when you’re thinking without any AI assistance important? Once you start reading the AI output, it’s highly likely your brain will lock in. Alternatives which the agent didn’t propose are more difficult to think of. It’s also possible that the task description wasn’t detailed enough and the agent didn’t take an important detail into account. Any caveats, edge cases, deployment scenarios, or other details that come to mind while you’re brainstorming about the possible task implementation details are good to note down before you read the agent output.

The agent is done planning. Output is ready. Now what?

Both you and your pair should get to reading. Flag any issues you see and discuss them. Refine the plan. Squeeze the implementation details from the agent. Be aware of all components that will change and how. This is the juicy part of the task.

With AI added to the traditional code review flow, we often plan the implementation twice. The first time is by the original engineer implementer. This person will make all the decisions individually. They will guide the implementation. Then the second time is by the reviewer, possibly in even more detail. If the reviewer doesn’t agree with the way task was implemented and proposes a different approach, the author and agent will go back to the beginning. All tokens used on the wrong path were wasted.

These kind of “disposable code” scenarios are happening more and more. When pairing with another colleague during the planning phase, it’s more likely you will choose the best implementation option and reach your goal in minimal time and tokens spent.

Structural prompt committing

Most of the engineering work gets done in the planning phase. Decisions are made and propagated into code. From commits only, we can only see what was decided. Why it was decided and what the alternatives were is valuable information that tends to get lost.

Prompting practices can be refined to avoid losing decision data. I practice structural prompt committing. In the codebase, each task is documented with my prompts, distilled versions of agent responses, and a few more useful files. The structure can look something like:

• task folder
  • prompt.md
    • chronological log of your prompts and distilled info about agent responses, append only
  • context.md
    • current context, changes can be traced through git versioning
    • either for human reference or for loading agent context
  • plan.md
    • after all the decisions are made via prompting, full plan is documented to a separate file
  • summary.md
    • summary of implementation changes

This structure is useful while working on the task, especially if multiple persons are involved. Afterwards it can be deleted. For important decisions, architectural decision records should be made.

Implementation ideas

How you decide to do the implementation after the plan is ready depends on many factors. Some ideas can be applied generally:

• If unsure between options proposed by an agent, ask it to prototype them on multiple branches. See how they act in action and validate through tests, metrics, etc.
• Small commits are desirable. It is easier to follow the changes and revert precisely if needed.
• For bigger tasks, create checkpoints. Don’t let the agents create a massive change which will have to be fully reverted if it proves wrong.

You might be wondering, what should you do while Claude is claudeing? Should the pair of colleagues just… wait and watch?

Well, maybe. If the checkpoints are small enough it might make sense to wait and discuss the direction the agent is taking. If not, it could make sense to split up and meet again when the project is ready for validation and review. It’s up to you to weigh if the context switch is worth it.

Pair validation

Whatever road you choose, you should arrive at the last part: pair validation. Why didn’t I call it pair review? Because review sounds like you’re just reading the code. Instead, at this stage you should validate, i.e. prove, that code works.

If the implementer and reviewer validate alone, the job is doubled and less efficient. Since AI is generating most code, we are all validators more than implementers. Let’s not validate twice. Two colleagues should go through the code changes in a structured way, making sure the requirements and acceptance criteria are met. Ideally, start from the tests. Are they proving the new code is working? Are they covering all use cases? Are they guarding the future implementation from possible breaking changes?

Through conversation, concerns can be raised and resolved immediately. Learning and knowledge sharing are instantaneous. Don’t lose this value by spending time navigating in heaps of generated code and writing async comments someone should check between three different context-switching sessions.

If you work in an environment that allows it, I encourage you to start thinking about the process of implementing and reviewing as one unit, not two separate jobs for two separate people. A good way to avoid getting in the “just review this quickly please” trap is to plan ahead. During planning of what each teammate will do in a given period, allocate the same amount of time and resources for both the implementer and reviewer. Teamwork begins before the task is started.

Not all jobs can follow this framework. Examples are open-source project PRs, distributed teams across multiple time zones, and contractor engagements. In these kinds of environments, reimagining how we do reviews gets even more interesting. I expect new and completely different frameworks to emerge. Until then, my team and I are quite confident shipping pair-planned and pair-validated code.

Until then, my team and I are quite confident shipping pair-planned and pair-validated code.

The post Review fatigue is real. Here’s what my team did about it appeared first on ShiftMag.