When we shared this year’s Octoverse data with Guido van Rossum, the creator of Python, his first reaction was genuine surprise.

While TypeScript overtook Python to become the most used language on GitHub as of August 2025 (marking the biggest language shift in more than a decade), Python still grew 49% year over year in 2025, and remains the default language of AI, science, and education for developers across the world. 

“I was very surprised by that number,” Guido told us, noting how this result is different from other popularity trackers like the TIOBE Index.

To learn more, we sat down with Guido for a candid conversation about Python’s roots, its ever-expanding reach, and the choices—both big and small—that have helped turn a one-time “hobby project” into the foundation for the next generation of developers and technologies.

Watch the full interview above. 👆

The origins of Python

For Guido, Python began as a tool to solve the very real (and very painful) gap between C’s complexity and the limitations of shell scripting.

I wanted something that was much safer than C, and that took care of memory allocation, and of all the out of bounds indexing stuff, but was still an actual programming language. That was my starting point.

Guido van Rossum, creator of Python

He was working on a novel operating system, and the only available language was C. 

“In C, even the simplest utility that reads two lines from input becomes an exercise in managing buffer overflows and memory allocation,” he says. 

Shell scripts weren’t expressive enough, and C was too brittle. Building utilities for a new operating system showed just how much friction existed in the developer workflow at the time. 

Guido wanted to create language that served as a practical tool between the pain of C and the limits of shell scripting. And that led to Python, which he designed to take care of the tough parts, and let programmers focus on what matters. 

Python’s core DNA—clarity, friendliness, and minimal friction—was baked in from the beginning, too. It’s strangely fitting that a language that started as such a practical project now sits at the center of open source, AI, data science, and enterprise AI.

Monty Python and the language’s personality

Unlike other programming languages named for ancient philosophers or stitched-together acronyms, Python’s namesake comes from Monty Python’s Flying Circus.

“I wanted to express a little irreverence,” Guido says. “A slight note of discord in the staid world of computer languages.” 

The name “Python” wasn’t a joke—it was a design choice, and a hint that programming doesn’t have to feel solemn or elitist.  

That sense of fun and accessibility has become as valuable to Python’s brand as its syntax. Ask practically anyone who’s learned to code with Python, and they’ll talk about its readability, its welcoming error messages, and the breadth of community resources that flatten that first steep climb.

If you wrote something in Python last week and, six months from now, you’re reading that code, it’s still clear. Python’s clarity and user friendliness compared to Perl was definitely one of the reasons why Python took over Perl in the early aughts.

Python and AI: ecosystem gravity and the NumPy to ML to LLM pipeline

Python’s influence in AI isn’t accidental. It’s a signal of the broader ecosystem compounding on itself. Today, some of the world’s fastest-growing AI infrastructure is built in Python, such as PyTorch and Hugging Face Transformers.

So, why Python? Guido credits the ecosystem around Python as the primary cause: after all, once a particular language has some use and seems to be a good solution, it sparks an avalanche of new software in that language, so it can take advantage of what already exists.

Moreover, he points to key Python projects: 

• NumPy: foundational numerical arrays 
• pandas: making data manipulation easier
• PyTorch: Machine learning at scale
• Local model runners and LLM agents: Today’s frontier with projects like ollama leading the charge. 

The people now writing things for AI are familiar with Python because they started out in machine learning.

Python isn’t just the language of AI. It enabled AI to become what it is today. 

That’s due, in part, to the language’s ability to evolve without sacrificing approachability. From optional static typing to a treasure trove of open source packages, Python adapts to the needs of cutting-edge fields without leaving beginners behind.

Does Python need stronger typing in the LLM era? Guido says no. 

With AI generating more Python than ever, the natural question is: does Python need stricter typing? 

Guido’s answer was immediate: “I don’t think we need to panic and start doing a bunch of things that might make things easier for AI.” 

He believes Python’s optional typing system—while imperfect—is “plenty.”

AI should adapt to us, not the other way around.

He also offered a key insight: The biggest issue isn’t Python typing, but the training data. 

“Most tutorials don’t teach static typing,” he says. “AI models don’t see enough annotated Python. 

But LLMs can improve. “If I ask an AI to add a type annotation,” he says, “it usually researches it and gets it right.” 

This reveals a philosophy that permeates the language: Python is for developers first and foremost. AI should always meet developers where they are. 

Democratizing development, one developer-friendly error message at a time 

We asked why Python remains one of the most popular first programming languages. 

His explanation is simple and powerful: “There aren’t that many things you can do wrong that produce core dumps or incorrect magical results.” 

Python tells you what went wrong, and where. And Guido sees the downstream effect constantly: “A very common theme in fan mail is: Python made my career. Without it, I wouldn’t have gotten into software at all.” 

That’s not sentimentality. It’s user research. Python is approachable because it’s designed for developers who are learning, tinkering, and exploring. 

It’s also deeply global. 

This year’s Octoverse report showed that India alone added 5M+ developers in 2025, in a year where we saw more than one developer a second join GitHub. A number of these new developers come from non-traditional education paths. 

Guido saw this coming: “A lot of Python users and contributors do not have a computer science education … because their day jobs require skills that go beyond spreadsheets.” 

The clear syntax provides a natural entry point for first-time coders and tinkerers. As we’ve seen on GitHub, the language has been a launchpad not just for CS graduates, but for scientists in Brazil, aspiring AI developers in India, and anyone looking for the shortest path from idea to implementation.

Whitespace complaints: Guido’s other inbox

Python famously uses indentation for grouping. Most developers love this. But some really don’t. 

Guido still receives personal emails complaining. 

“Everyone else thinks that’s Python’s best feature,” he says. “But there is a small group of people who are unhappy with the use of indentation or whitespaces.” 

It’s charming, relatable, and deeply on brand. 

Stability without stagnation: soft keywords and backwards compatibility

Maintaining Python’s momentum hasn’t meant standing still. Guido and the core dev team are laser-focused on backward compatibility, carefully weighing every new feature against decades of existing code.

For every new feature, we have to very carefully consider: is this breaking existing code?

Sometimes, the best ideas grow from constraints.

For instance, Python’s soft keywords, context-sensitive new features that preserve old code, are a recent architectural decision that let the team introduce new syntax without breaking old programs. It’s a subtle but powerful engineering choice that keeps enterprises on solid ground while still allowing the language to evolve. 

This caution, often misinterpreted as reluctance, is exactly why Python has remained stable across three decades. 

For maintainers, the lessons are clear: learn widely, solve for yourself, invite input, and iterate. Python’s journey proves that what starts as a line of code to solve your own problem can become a bridge to millions of developers around the world.

Designed for developers. Ready for whatever comes next. 

Python’s future remains bright because its values align with how developers actually learn and build: 

• Readability
• Approachability 
• Stability
• A touch of irreverence

As AI continues to influence software development—and Octoverse shows that 80% of new developers on GitHub use GitHub Copilot in their first week—Python’s clarity matters more than ever. 

And as the next generation begins coding with AI, Python will be there to help turn ideas into implementations.

The post Why developers still flock to Python: Guido van Rossum on readability, AI, and the future of programming appeared first on The GitHub Blog.

We’ve been hard at work over the past few months to build the most usable and enjoyable AI agents for developers. To strike the right balance between usability and security, we’ve put together a set of guidelines to make sure that there’s always a human-in-the-loop element to everything we design.

The more “agentic” an AI product is, the more it can actually do, enabling much richer workflows, but at the cost of a greater risk. With added functionality, there’s a greater chance and a much greater impact of the AI going off its guardrails, losing alignment, or even getting manipulated by a bad actor. Any of these could cause security incidents for our customers.

To make these agents as secure as possible, we’ve built all of our hosted agents to maximize interpretability, minimize autonomy, and reduce anomalous behavior. Let’s dive into our threat model for our hosted agentic products, specifically Copilot coding agent. We’ll also examine how we’ve built security controls to mitigate these threats, and perhaps you’ll be able to apply these principles to your own agents.

Security concerns

When developing agentic features, we are primarily concerned with three classes of risks:

1. Data exfiltration

When an agent has Internet access, it could leak data from the context to unintended destinations. The agent may be tricked into sending data from the current repository to an unintended website, either inadvertently or maliciously. Depending on the sensitivity of data, this could result in a severe security incident, such as if an agent leaks a write access GitHub token to a malicious endpoint.

2. Impersonation and proper action attribution

When an agent undertakes an action, it may not be clear what permissions it should have or under whose direction it should operate. When someone assigns the Copilot coding agent to an issue, who issued the directive—the person who filed the issue or the person who assigned it to Copilot? And if an incident does occur as a result of something an agent did, how can we ensure proper accountability and traceability for the actions taken by the agent?

3. Prompt injection

Agents operate on behalf of the initiating user, so it’s very important to ensure that the initiating user knows what the agent is going to do. Agents are prompted from GitHub Issues, files within a repository, and many other places, so it’s important to ensure that the initiator has a clear picture of all the information guiding it. If not, malicious users could hide directives and trick repository maintainers into running agents with bad directives.

Rules for agentic products

To help prevent the above risks, we have created a set of rules for all of our hosted agentic products to make them more consistent and secure for our users.

1. Ensuring all context is visible

Allowing invisible context can allow malicious users to hide directives that maintainers may not be able to see. For example, in the Copilot coding agent, a malicious user may create a GitHub Issue that contains invisible Unicode with prompt injection instructions. If a maintainer assigns Copilot to this issue, this could result in a security incident as the maintainer would not have been aware of these invisible directives. 

To prevent this, we display the files from which context is generated and attempt to remove any invisible or masked information via Unicode or HTML tags before passing it to the agent. This ensures that only information that is clearly visible to maintainers is passed to the agent. 

2. Firewalling the agent

As mentioned previously, having unfettered access to external resources can allow the agent to exfiltrate sensitive information or be prompt-injected by the external resource and lose alignment.

We apply a firewall to the Copilot coding agent to limit its ability to access potentially harmful external resources. This allows users to configure the agent’s network access and block any unwanted connections. To balance security and usability, we automatically allow MCP interactions to bypass the firewall..

In our other agentic experiences like Copilot Chat, we do not automatically execute code. For example, when generating HTML, the output is initially presented as code for preview. A user must manually enable the rich previewing interface, which executes the HTML.

3. Limiting access to sensitive information

The easiest way to prevent an agent from exfiltrating sensitive data is… to not give access to it in the first place!

We only give Copilot information that is absolutely necessary for it to function. This means that things like CI secrets and files outside the current repository are not automatically passed to agents. Specific sensitive content, such as the GitHub token for the Copilot coding agent, is revoked once the agent has completed its session. 

4. Preventing irreversible state changes

AI can and will make mistakes. To prevent these mistakes from having downstream effects that cannot be fixed, we make sure that our agents are not able to initiate any irreversible state changes without a human in the loop.

For example, the Copilot coding agent is only able to create pull requests; it is not able to commit directly to a default branch. Pull requests created by Copilot do not run CI automatically; a human user must validate the code and manually run GitHub Actions. In our Copilot Chat feature, MCP interactions ask for approval before undertaking any tool calls.

5. Consistently attributing actions to both initiator and agent

Any agentic interaction initiated by a user is clearly attributed to that user, and any action taken by the agent is clearly attributed to the agent. This ensures a clear chain of responsibility for any actions.

For example, pull requests created by the Copilot coding agent are co-committed by the user who initiated the action. Pull requests are generated using the Copilot identity to make it clear that they were AI-generated.

6. Only gathering context from authorized users

We ensure that agents gather context only from authorized users. This means that agents must always operate under the permissions and context granted by the user who initiated the interaction.

The Copilot coding agent can only be assigned to issues by users who have write access to the underlying repository. Plus, as an additional security control, especially for public repositories, it only reads issue comments from users who have write access to the underlying repository.

Try it out now

We built our agentic security principles to be applicable for any new AI products; they’re designed to work with everything from code generation agents to chat functionality. While these design decisions are intended to be invisible and intuitive to end users, we hope this makes our product decisions clearer so you can continue to use GitHub Copilot with confidence. For more information on these security features, check out public documentation for Copilot coding agent.

The post How GitHub’s agentic security principles make our AI agents as secure as possible appeared first on The GitHub Blog.

We’re excited to announce that TypeSpec for Microsoft 365 Copilot is now generally available! This milestone marks the first stable release of the domain-specific language (DSL) designed to streamline how developers build and extend Microsoft 365 Copilot. Whether you’re creating an agent to help colleagues find documents, or connecting your service as an API plugin, TypeSpec for Microsoft 365 Copilot makes the process simpler, safer, and more productive. 

A developer-centric experience – strong typing, IntelliSense and productivity 

One of the biggest pain points for developers building Copilot extensibility solutions has been managing complex configuration files and schema definitions. TypeSpec addresses this by offering strong type safety and a fully typed development experience – type errors are surfaced at compile time rather than being discovered during runtime. The language integrates with Visual Studio Code and Visual Studio, providing rich IntelliSense and inline documentation. This means less time spent debugging manifest errors and more time focused on delivering value. Features like built-in type checking, IntelliSense and development-time validation make it easier to catch mistakes early and maintain high-quality code. 

What is TypeSpec for Microsoft 365 Copilot? 

TypeSpec is a Microsoft-crafted DSL for API-first development, letting you model APIs in a concise, human-readable format and generate artifacts such as OpenAPI specs or manifest files from a single source of truth. This Microsoft 365 Copilot variant takes this even further, providing Microsoft 365-specific decorators and capabilities to simplify authoring of declarative agents and API plugins. Instead of hand-coding multiple JSON or YAML files (agent manifest, plugin manifest, OpenAPI document, etc.), you describe your agent’s instructions, capabilities and API operations using a clean syntax that is familiar to developers. The TypeSpec compiler then automatically produces the required manifests and configurations, ensuring they conform to the latest schema requirements, ensuring they conform to the latest schema requirements. 

Simplified agent and plugin authoring 

Using TypeSpec’s intuitive decorators and capabilities make building declarative agents for Microsoft 365 Copilot a breeze. It’s simple to get started using the Microsoft 365 Agents Toolkit! 

Start with creating a new agent 

Select “Start with TypeSpec for Microsoft 365 Copilot” 

The following example highlights a simple agent that is a GitHub expert project manager. 

import "@typespec/http";
import "@typespec/openapi3";
import "@microsoft/typespec-m365-copilot";
import "./actions.tsp";

using TypeSpec.Http;
using TypeSpec.M365.Copilot.Agents;
using TypeSpec.M365.Copilot.Actions;

@agent({
  name: "GitHub Project Manager",
  description: "Smart project management agent with GitHub integration for issue tracking"
})
@instructions("""
  You are an intelligent project management assistant specialized in GitHub workflows
  and development team coordination. You excel at managing GitHub repositories issues,
  You can help prioritize work, track progress, and facilitate team collaboration through 
  GitHub's project management features. Always consider development best practices, help 
  maintain code quality through proper review processes, and provide actionable insights to
  improve team productivity and project delivery.
""")
namespace GitHubProjectManager {
  op codeInterpreter is AgentCapabilities.CodeInterpreter;  
  op webSearch is AgentCapabilities.WebSearch<Sites = [{
      url: "https://docs.github.com/en/issues";
  }]>;

  @service
  @actions(#{
      nameForHuman: "GitHub Project Management API",
      descriptionForModel: "GitHub API integration for project management focusing on issue tracking",
      descriptionForHuman: "Use this API to manage GitHub repository issues and track issues"
  })
  @server("https://api.github.com", "GitHub API")
  namespace GitHubAPI {
    @route("/repos/{owner}/{repo}/issues")
    @get
    @action
    op getIssues(
      @path owner: string = "octocat",
      @path repo: string = "Hello-World",
      @query state?: "open" | "closed" | "all",
      @query labels?: string,
      @query assignee?: string,
      @query milestone?: string,
      @query since?: string
    ): string;
  }
}

It simply adds key concepts of declarative agents (instructions, conversation starters, API plugins) without any of the complexity and fragility of JSON editing. 

What are developers saying about TypeSpec for Microsoft 365 Copilot 

During our preview, we collaborated closely with a select group of developers and customers to refine TypeSpec for Microsoft 365 Copilot. Their feedback was instrumental in shaping the developer experience and validating our approach. As Andrew Connell (Microsoft MVP, Founder Voitanos LLC) shared: “I love using TypeSpec for creating Declarative Agents – it’s a significant improvement for developer productivity! While text and JSON files remain a great option for low-code scenarios, TypeSpec brings IntelliSense, type checking, and reusability that developers really appreciate. In my Copilot extensibility workshops, I show both approaches, but for developers specifically, my preference and recommendation is definitely TypeSpec.” 

Why this matters – and what’s next 

The general availability of TypeSpec for Microsoft 365 Copilot signals that the language and associated tooling have reached a stable baseline and are ready for production use! If you’re building custom agents or API plugins, now is the perfect time to adopt TypeSpec and the Microsoft 365 Agents Toolkit. You’ll be able to focus on defining the logic and capabilities of your agent, confident that the extension will handle the manifest generation, OpenAPI compliance and secure integration into Microsoft 365’s AI ecosystem. will handle the manifest generation, OpenAPI compliance and secure integration into Microsoft 365’s AI ecosystem. 

Ready to get started? 

Check out the official documentation to learn more about TypeSpec for Microsoft 365 Copilot capabilities, explore the built-in decorators and agent capabilities, and dive into the M365 Agents Toolkit for a guided development experience. You can also get started right now with following the Copilot Camp lab on TypeSpec for Microsoft 365 Copilot! We can’t wait to see what you’ll build with TypeSpec for Microsoft 365 Copilot and declarative agents! 

The post Introducing TypeSpec for Microsoft 365 Copilot – Build declarative agents faster with more confidence appeared first on Microsoft 365 Developer Blog.

We continue to be humbled by the incredible momentum of the SharePoint Framework (SPFx) and the growth it enables for our customers and partners. Tens of millions of users across the world rely daily on custom SPFx solutions in Microsoft 365 – solutions built and innovated by you.

Since launching this monthly blog series in September 2025, our goal has been to increase transparency and provide ongoing visibility into the SharePoint Framework roadmap. With this November 2025 update, we are pleased to continue that commitment and share the latest view into our plans.

SPFx remains a foundational pillar of the Microsoft 365 extensibility platform, and we’re excited to see the strong engagement around our future investment areas. Your feedback continues to guide where we refine, expand, and prioritize. While the overall roadmap remains stable, we have made several small schedule refinements as we work toward delivering the SPFx 1.22 release with the quality and completeness it deserves. As always, we’ll keep the public SPFx roadmap page updated in parallel with each monthly post.

We have also continued to receive significant interest in the SharePoint Framework Community Advisory Committee introduced in the September update. We are actively shaping the long-term structure for participation and onboarding new members. We look forward to sharing more details on this early in 2026.

Roadmap

We are evolving towards a quarterly release cycle, providing more predictability on new feature introductions and updates. We will update the public roadmap with any schedule and feature updates as we move forward in this journey.

Here is the set of investments which we are planning to ship within the upcoming SPFx releases:

Version 1.22 – December 2025

This version will provide us with a new modernized baseline which does not have any npm audit issues and has a future proven toolchain to continue building experiences.

• General availability is planned on December 2nd 2025
• Addressing npm audit reported security issues on the dependency tree.
• Transitioning from Gulp to an open webpack based toolchain orchestrated by Heft.
• Update default TypeScript to v5.8

Version 1.23 – February/March 2026

This release focuses on open sourcing the templates and tooling to create SPFx solutions, enabling our ecosystem to optionally build their own templates. We also want to focus on providing additional value for optimizing developer experience and providing new extensibility options.

• Open-sourcing SPFx solution templates via GitHub and opening them for community contributions.
• A new open-sourced SPFx CLI for replacing the existing Yeoman generator – You will be able to introduce your company specific templates or adjustments on the scaffolded baseline for the SPFx solutions. We are decoupling the CLI itself from the SPFx release versions.
• Command set improvements for lists and libraries – grouping and potentially other improvements.
• New and edit panel override in lists – support panel level override on the Microsoft Lists and SharePoint lists with SPFx.
• New debugging toolbar improving the in-page development experience when workbench is not used.

Version 1.24 – May/June 2026

This version continues providing new extensibility options aligned with the future direction of SharePoint. We are also expecting to have other new features and capabilities as part of this release, which will be disclosed a bit later.

• Navigation customizers – Options to override navigation nodes and/or experiences with SPFx components.
• Other features will be shared later.

We also continue further innovation in the AI space with a focus on both customer features and developer tooling. More on this in future roadmap updates.

We encourage you to continue providing feedback to support our product planning for the upcoming semesters. We already have an extensive list of ideas and enhancements in mind but are always interested in your input.

Upcoming feature showcase – Npm Audit cleanup in 1.22

As part of the upcoming release v1.22, we have worked on cleaned up all known npm audit issues on the SharePoint Framework toolchain. We are also committed to closely following up and cleaning any new vulnerabilities which could come up from the npm dependency tree with updated minor releases as needed.

We are also aware of deprecated dependencies we have on the baseline SharePoint Framework installation package and are working on cleaning them as well.

What’s next?

We continue expanding the SharePoint platform to unlock more innovation across Microsoft 365:

• SharePoint Framework (SPFx) for building rich, AI powered and business integrated solutions with custom user interfaces directly in Microsoft 365.
• SharePoint Embedded to bring SharePoint content into your own apps hosted outside of Microsoft 365 with your own user interface.
• Agents and AI to create intelligent, adaptive experiences to access your content and business information efficiently and expose those easily for your end users.
• Microsoft Graph to access data and insights everywhere using our standard API surface.

We encourage you to explore these capabilities and see how they can help you build the next generation of solutions for your organization and customers.

If you are looking to build experiences for Microsoft 365, we strongly recommend joining our community calls and other Microsoft 365 & Power Platform Community activities covering Microsoft 365 Copilot, Power Platform, SharePoint, Microsoft Teams, Copilot Studio, Microsoft Graph, Microsoft Viva, and more. See community call details and other assets from https://aka.ms/community/home.

You might be also interested on our new SharePoint partner showcase series where we showcase different solutions build with SharePoint. Each episode has a video and blog post with further details. Are you building something with SharePoint and interested on doing a similar video with us? – Let us know by signing up with this form and we’ll get back to you for scheduling a recording.

We are also excited to share that we will be repeating the SharePoint Hackathon event during 2026 with updates submission categories, showcasing the different features and capabilities of SharePoint. We saw an impressive set of examples of ecosystem innovation across intelligent portals powered by AI and SPFx in 2025 and are looking forward on the community innovation with the new features and capabilities.

Follow us also on X or in LinkedIn to stay up to date on Microsoft 365 Platform announcements.

Got feedback or input on this blog post – leave a comment and we will get back to you.

Happy coding! Sharing is Caring!

The post SharePoint Framework (SPFx) roadmap update – November 2025 appeared first on Microsoft 365 Developer Blog.

---

Gemini 3 is available via API with updates for developers: new `thinking_level` for depth control, `media_resolution` for multimodal processing, and enforced `Thought Signatures` for agentic workflows, especially with function calling and image generation. It also introduces combining Google Search/URL Grounding with Structured Outputs and new usage-based pricing for Grounding. Best practices, like using default temperature, are advised for optimal results.