A study of more than 700 software firms found that AI coding agents significantly increase the amount of code developers produce, but not the amount of software companies actually ship. Ars Technica reports: A recent study (PDF) of actual coding practices across hundreds of firms finds that human code review forms a significant "bottleneck" for the overall efficiency of AI coding tools, resulting in "little evidence that firms increase software output or reduce employment" by using them. Any efficiency increased during the actual coding phase, the study authors find, is "absorbed by downstream constraints in the production process"; as "the code review process significantly increases in length, pull requests are more likely to require revisions, and reviewers leave more comments." [...] In terms of raw code being produced, the results are clear and stark. The introduction of AI coding agents at a firm leads to a 30 percent increase in total lines of code generated, a 20 percent rise in the number of total commits, and a 23 percent increase in pull requests on average, the researchers write. But all that extra code doesn't translate directly into improved software output on the firm level. On the contrary, the resolution rate for Issues and Epics (i.e. wholesale software features) tracked by tools like Jira did not change in a statistically significant way after AI tools were introduced (the researchers also found no "compositional shift" in the size or complexity of those Jira-tracked issues across the AI introduction). The reason for that discrepancy can be found directly in the code review process, which takes markedly longer on average after the introduction of AI coding agents. Overall, the average "review process" time between a pull request getting submitted and it being merged into the codebase balloons 49 percent on average after AI agents are introduced. That effect can be seen in more granular data, too, with "the share of pull requests with changes requested nearly doubl[ing], and the number of comments per pull request increas[ing] by 35%" following the AI agent shift, the researchers write. In response to this change, the researchers found a 14 percent increase in the share of workers performing code reviews after AI agents' introduction. They also write that they "cannot attribute significant employment changes to AI" after looking at total active workers across Jellyfish and cross-referencing with LinkedIn data at those firms. While AI could also theoretically help with this review process, the researchers found that, so far, that impact has been marginal. Although 80 percent of measured firms used some form of AI code review by March 2026, AI agents were only responsible for 23.3 percent of all review comments and 10.8 percent of all pull requests, suggesting humans were still responsible for the vast majority of this work.

Read more of this story at Slashdot.

Context matters when you’re working with AI. Every codebase has its own house rules: how components are structured, which scripts to run, and which conventions apply to different frameworks and file types.

Copilot can help you make changes across a project, but it works best when it knows those rules, too. Much of that knowledge can live inside the repository, so Copilot can pick it up automatically instead of requiring you to explain the same standards, scripts, and workflows every time you start a new task.

In this installment of our GitHub Copilot app for Beginners series, we’ll look at four ways to tailor how Copilot works with your project:

• Custom instructions communicate the conventions Copilot should follow.
• Agent skills package repeatable procedures.
• Custom agents bring specialized guidance to larger tasks.
• Model Context Protocol (MCP) servers connect Copilot to external tools and data sources, expanding what it can do.

Let’s look at how each one works and how they can work together.

Start with custom instructions

Suppose you ask Copilot to add a custom page size to an application. Making the change is only part of the job. The new code should also follow the patterns your team already uses.

Repository custom instructions give Copilot that baseline context. Add a .github/copilot-instructions.md file to define guidance that applies across the repository, such as your preferred architecture, naming conventions, or expectations for testing and validation.

You can also create path-specific instruction files inside .github/instructions. These files use an applyTo field to tell Copilot when the guidance is relevant.

When Copilot works on a matching file, it can use both the repository-wide instructions and the more specific guidance. That lets you keep the broad rules in one place without forcing every file type into the same mold.

Package repeatable procedures as agent skills

Custom instructions are useful for standards that should shape many tasks. But some guidance only matters when Copilot is performing a particular procedure, such as running quality checks, preparing a release, or debugging a failed workflow.

That’s where agent skills come in. A skill is a folder containing instructions and, optionally, scripts and other resources that Copilot can load when they’re relevant. Project-level skills can live in .github/skills, with each skill in its own subfolder.

For example, a .github/skills/quality-checks folder could contain a SKILL.md file that explains:

• When Copilot should use the skill.
• Which scripts run the project’s tests and linting.
• What each script checks.
• How to troubleshoot common failures.

The description in SKILL.md helps Copilot determine when the skill applies. After updating the interface, Copilot can load the quality-checks skill and follow the project’s established process for testing and linting instead of guessing which commands to run.

Use a custom agent for broader, specialized work

Some tasks are larger than a single procedure. An accessibility review, for example, may require Copilot to inspect components, templates, styles, and interactions across multiple files.

Custom agents let you create specialized versions of Copilot for work like this. A repository-level agent profile lives in .github/agents and can define the agent’s purpose, instructions, tools, and relevant project context.

Use a custom agent when a recurring type of work benefits from a dedicated role or perspective, especially when the task may span multiple files and draw on several tools or sources of context.

Connect Copilot to external tools with MCP servers

Instructions, skills, and agents help Copilot understand how to work within your project. MCP servers expand what it can access and do beyond the repository.

MCP servers connect Copilot to external tools, data sources, and services. A documentation server can give it access to framework guidance, while a server such as Playwright can let it open and interact with your application in a browser.

You can browse available MCP servers in the Copilot app or add a custom one. Once Playwright is configured, you can ask: Use the Playwright MCP server to test the functionality manually.

Copilot can then use Playwright to open the application in a browser and interact with it much as you would. That gives it a way to verify not only that the code passes automated checks, but also that the updated interface behaves as expected.

Choose the right type of customizations

These customizations solve different problems, but they become more useful when you combine them:

• Custom instructions define the conventions Copilot should follow across the repository or for particular files.
• Agent skills package repeatable procedures that Copilot can load when they’re relevant.
• Custom agents provide focused expertise and guidance for broader tasks.
• MCP servers connect Copilot to external tools, services, and data sources, expanding what Copilot can do.

Take this with you

Giving Copilot useful project context starts with four questions:

• What project convention do I keep explaining?
• What multi-step procedure do I repeat?
• What complex task could benefit from a dedicated custom agent?
• What outside tool or source does Copilot need?

Not sure where to begin? The community has shared ready-made instructions, skills, agents, and more through Awesome Copilot. Find one that addresses a workflow you already repeat, review what it contains, and adapt it to your repository’s tools and standards.

Start small: choose one convention you keep explaining, add it to .github/copilot-instructions.md, and see how Copilot applies it to your next task.

The post GitHub Copilot app for Beginners: How to teach Copilot about your codebase appeared first on The GitHub Blog.

In the final episode of Zero to Agent in 30 Minutes, AI engineer Sajal Sharma showed how to build a personal assistant on OpenClaw that tracks your tasks and notes and handles scheduled work on its own.

A useful personal assistant has to be reachable when you’re away from your computer and keep running when it has scheduled work to do. OpenClaw supports both, and you decide where the agent runs, which models it uses, and how it accesses your data.

How to go from a fresh install to scheduled automations, step-by-step

1. Install your OpenClaw instance. Sajal recommends starting locally while you learn how it works, then moving to an always-on machine or hosted environment if you need continuous availability.
2. Connect the channels you use. Add a messaging channel such as Telegram, WhatsApp, or Slack so you can reach the assistant away from your desk. Sajal used Telegram in his demo to send requests and receive notifications from the same assistant.
3. Set up the assistant’s workspace. Give the agent a place to keep tasks, notes, skills, and memory, along with guidance files that define how it behaves and how it should work with the files in that workspace.
4. Use it in your daily workflows. Sajal asked the assistant for an overview of current projects and checked progress toward a reading goal. He also had it search the web for a book series and add the books it found to his reading list.
5. Add proactive automations. Schedule work the assistant should handle on its own. Sajal added a Telegram reminder and a morning briefing designed to pull from tasks, a calendar, and recent email. Recurring checks and webhooks can also trigger the agent when something changes in another system.

Thanks for following Zero to Agent

This episode closes out Zero to Agent in 30 Minutes. Thanks for watching and building along with our presenters throughout the series.

If you’d like to keep following how agents can take on more complex work, tune in to The Monday Morning Agent, which debuts Monday, October 12, at 8am PT/11am ET. The eight-episode series follows the development of an increasingly autonomous data agent working with real play-by-play data. Learn more and save your seat or follow along here on Radar.

Today, Indie Games Week lights up the App Store with a celebration of the catalog of imaginative games made by independent teams with big dreams.

Azure Maia 200 now in production; Azure Maia 300 coming in 2027

As we move into the era of Super Intelligence, Microsoft is entering a new phase of infrastructure. We will scale our Azure Maia family to multi-gigawatt deployments starting in 2027, making Maia the primary inference system for Microsoft products and services.

The multigenerational Azure Maia program has become a foundational element of Microsoft’s AI infrastructure strategy. Maia 200 is now serving Microsoft production workloads, including Microsoft Copilot, and supporting the MAI team as they develop next-generation models, with GitHub Copilot and Microsoft Foundry to follow by end of year. Across these workloads, Maia 200 runs OpenAI models, Microsoft’s own MAI models and leading open-source model families. Insights from the scale of Microsoft’s AI services allow for unique co-design between hardware systems and software applications to optimize real-world use cases across enterprise applications and industry scenarios.

Maia 300 is a complete intelligent system designed for the new types of AI workloads emerging today: Long-context reasoning, latency-sensitive conversational experiences and sustained, multi-step agentic tasks. By improving efficiency across the system, we expect Maia 300 to deliver 40% more tokens per megawatt compared to leading GPU-based systems. And in a full 96-accelerator configuration, it delivers up to 7x the rack-scale token throughput of Maia 200.

Maia 200: Driving the workloads that Microsoft runs at scale

The Azure Maia system is designed around the real-world workloads Microsoft runs at scale and the models we expect to build in the years ahead. Because silicon development takes years, our software and hardware teams collaborate early to anticipate architectures, scale and capabilities, translating those requirements into greater memory capacity, higher bandwidth and more accelerators operating as a single system.

That co-engineering is already delivering measurable efficiency gains. Maia 200 is deploying across the United States, Europe and Australia and delivering up to 1.7x more tokens per watt for built-in AI capabilities in Microsoft Teams, Copilot and Cowork experiences compared with leading GPU infrastructure.

Experience running our AI models and services on Maia 200 directly informed the design of Maia 300. Together, the two generations are designed to support a broad set of additional Microsoft’s AI services: multi-step agentic work that will help GitHub deliver coding experiences more efficiently; cloud-scale model serving that will help Microsoft Foundry support diverse architectures and deployment environments; inference and data generation for the MAI team; and latency-sensitive interactions that will help Dragon Copilot scale workflows and reduce clinicians’ administrative burden.

Maia 300: Scaling more useful AI within every megawatt

AI is becoming a foundational layer of every application, workflow and business process. As enterprises move beyond chat experiences to systems of agents that can reason, act and collaborate, AI infrastructure must deliver intelligence securely and efficiently at scale while continuously adapting as models and workloads evolve.

As the third generation of our Azure Maia program, Maia 300 is designed with an inference-first architecture optimized for long-context, memory-intensive and decode-heavy AI workloads. This involves balancing compute, memory bandwidth, networking and power efficiency at cloud scale.

Key capabilities of the Maia 300 system include:

Less data movement, more useful compute: Moving data efficiently, rather than raw compute power, is increasingly the bottleneck in large inference systems. Maia 300’s software-defined dataflow architecture and AI-assisted kernel optimization work together to maximize locality, reduce data movement and improve utilization across compute, memory and networking resources. By treating dataflow as a first-class design principle, Maia 300 delivers a significant performance-per-watt advantage over traditional GPU architectures.

Higher memory bandwidth within every watt: As AI workloads become increasingly context and memory-bound, Maia 300 delivers industry-leading HBM bandwidth per watt. Eight HBM4 stacks provide 18.0 TB/s of peak memory bandwidth within a 950-watt TDP, enabling efficient execution of large models and long-context workloads. Specialized kernel support uses on-die SRAM as a software-managed scratchpad, reducing pressure on HBM.

Chiplet architecture for enhanced efficiency: A new multi-chiplet architecture separates compute, memory-controller and I/O functions, improving efficiency, scalability and cost structure. Compute chiplets are built on TSMC’s N2P process node to maximize performance-per-watt.

Larger context, richer intelligence: By designing for advanced low-precision formats, including enhanced MXFP4, Maia 300 reduces memory and bandwidth requirements for both computation and KV-cache storage. The result is larger context windows, higher throughput and improved model efficiency within the same power envelope.

Scale-up networking at datacenter scale: Maia 300 treats networking as a seamless extension of the software-defined dataflow architecture. Rather than moving data through separate communication layers, dataflow operations span compute, memory and network resources as a single system. High-bandwidth interconnects between Maia accelerators are optimized for tensor parallelism, while a custom AI transport delivers performant and reliable scale-up communication across accelerators and racks. The AI-optimized transport leverages Ethernet-based networking infrastructure to enable a unified topology that scales efficiently from a single rack to datacenter-scale deployments.

Higher AI throughput from every rack: Maia 300 rack systems bring together 96 accelerators within a 167-kilowatt power envelope, delivering 27.6 TB of HBM capacity and 1.7 PB/s of aggregate HBM bandwidth across a high-speed scale-up domain. That density allows Microsoft to serve more simultaneous AI interactions and larger workloads from each rack, improving datacenter capacity and the economics of expanding AI services.

Maia 300 will begin production deployments in 2027. For more information on Maia 300 architectural details, read our technical paper.

Azure Maia is at the heart of our Frontier Transformation

The future will not be defined by a single model or a single piece of silicon or a single innovation. Model and silicon choice are inherent in our vision for Frontier Transformation. Our focus is on developing responsible, affordable and scalable platforms that will help everyone amplify their intelligence to drive breakthrough outcomes that matter for them.

Microsoft is unique because we are able to optimize from silicon to systems to agent on an open, heterogenous and model diverse platform our customers can count on for their AI transformation, today and in the years ahead. This platform is at the heart of Frontier Transformation, and Azure Maia is a foundational component of our approach to expand access, accelerate innovation and help customers capture more value from AI.

Next month at Microsoft Ignite 2026 in San Francisco and online we’re looking forward to sharing more information on our strategy, technology adoption trends and success in Frontier Transformation.

For more details, photos and videos, visit our Maia 300 site.

Scott Guthrie is responsible for a set of hyperscale cloud computing solutions and services including Azure, Microsoft’s cloud computing platform, generative AI solutions, data platforms and information and cybersecurity. These platforms and services help organizations across the globe solve urgent challenges — and transform for the future.

The post Microsoft to expand Azure Maia system to multi-gigawatt deployments appeared first on The Official Microsoft Blog.

The following article originally appeared on the Agentic AI Foundation blog and is being reposted here with the author’s permission.

Websites are designed for people. We can look at a page and quickly understand where to enter information or which control will complete an action.

AI agents don’t see or use the web the same way we do. An agent may have to process a screenshot or inspect the page’s underlying structure, then reason about which control matches the request.

The additional context increases token use, and each interpretation step creates another chance for error.

WebMCP (not to be confused with MCP) gives web developers a standard way to publish structured tools to access the capabilities of their website enabling agents to call those functions with structured inputs.

A developer can register a tool through document.modelContext and give it a name and description. The tool also defines an input schema and the function that runs when an agent calls it.

For example, an article site could publish a search tool that calls the same application code as its visible search form.

const searchToolController = new AbortController();

await document.modelContext.registerTool(
  {
    name: "search-articles",
    title: "Search articles",
    description: "Search published articles by topic.",
    inputSchema: {
      type: "object",
      properties: {
        query: {
          type: "string",
          description: "The topic or phrase to search for."
        }
      },
      required: ["query"],
      additionalProperties: false
    },
    async execute({ query }) {
      const articles = await searchArticles(query);
      renderSearchResults(articles);
      return { articles };
    }
  },
  { signal: searchToolController.signal }
);

// Call this when the search tool should no longer be available.
// searchToolController.abort();

The name and description tell the agent when to use the tool. The input schema defines the arguments it can send. The execute function calls the site’s existing search logic and updates the page with the results.

The browser makes the registered tool available to a supported agent while the page is active. When the agent calls it, the browser passes the structured arguments to execute and returns the result.

When the search tool should no longer be available, the page can unregister it by calling searchToolController.abort().

A page registers tools that match its current state. A content view may provide a search tool, while an editor can provide tools for changing the selected content. The agent then discovers the tools available for the page’s current state.

WebMCP also proposes a declarative path for existing HTML forms. The article search could be exposed through attributes on the form itself.

<form
  action="/articles"
  method="get"
  toolname="search-articles"
  tooldescription="Search published articles by topic."
>
  <label for="article-query">Topic</label>
  <input
    id="article-query"
    name="query"
    type="search"
    toolparamdescription="The topic or phrase to search for."
    required
  >
  <button type="submit">Search</button>
</form>

The browser uses the form attributes and controls to create the tool definition. Because the form omits toolautosubmit, the browser populates the field but leaves the final click to the person. The person can review the search query and click the Search button.

Keep the person and agent in the same interface

A WebMCP tool uses the state already visible in the application and the person’s active session. The shared page gives the person a place to review the agent’s work. When the agent completes an action, the person can see the updated state and make changes through the normal interface.

Web developers can also reuse application logic that already handles the visible interface. OpenAI’s Runme example is a browser application that registers tools for reading instructions and updating notebook content. Runme can offer those functions through the page without adding a separate server only to expose an MCP endpoint.

Pair WebMCP with MCP

WebMCP and MCP both expose tools to agents, but they operate in different parts of an application. Understanding the difference helps developers decide where each one fits and how they can work together.

An MCP server can provide tools when no related page is open. A WebMCP tool is attached to the current document and can use the page’s current state.

WebMCP standardizes how a page registers tools with the browser. The browser can present those tools to its agent through MCP or another function calling mechanism.

MCP Apps address another part of the interaction. An MCP server can provide an interactive interface that a compatible host displays to a person. WebMCP lets an agent use functions from an existing website.

WebMCP and MCP Apps can work together. For example, a shopping website could publish a compare_products tool through WebMCP. An MCP server could provide an MCP App for the comparison, so the person can adjust the options while the agent handles the supporting work.

The comparison interface could also be described with A2UI, which lets an agent describe an interface in a declarative format. The client renders the description with components from its own design system, so the client controls which components are available and how they behave.

People and agents can use the same interface at the same time. Developers need to decide which functions the agent can call and what the person should see while those functions run.

Design the page for agent use

Agent use begins before the first click. An agent may need to discover the website and determine how to authenticate. It may choose an API or structured documentation before opening a browser.

Web teams should study how agents use their site before deciding which interface to add. Check the server logs to see whether agents are crawling HTML or requesting machine readable content. Tool activity can reveal which WebMCP functions agents discover and which calls they abandon.

Keep existing controls in the execution path

WebMCP reduces the amount of interface interpretation an agent has to do, but a structured tool is still an entry point into the application. The website should apply its existing access controls and input validation whenever the tool runs.

For example, an update_cart tool can accept a product identifier and quantity. The server should confirm that the product exists and that the current user can modify the cart. Structured input doesn’t automatically make the request trusted, so the server should run the same checks it uses for updates made through the website.

The browser also has a responsibility. OpenAI reviews each site tool call before it runs and asks the person to confirm sensitive actions. The WebMCP draft requires origin isolation, and its tools permissions policy allows same origin use by default.

Clients need to handle tool changes during a task. A page can change a tool’s identity or schema after the agent begins working, so the client should review the tool again before using the new definition.

Researchers are already testing those boundaries. A June preprint on WebMCP tool surface poisoning found that changes to tool registration and metadata could redirect agents in its test environment. The researchers used a polyfill and a headless agent, so a native browser implementation may behave differently. But these reported attacks can serve as great test cases as you’re adding WebMCP to your site.

Test WebMCP while the design is open

WebMCP already has several experimental implementations. Chrome offers an implementation through a flag and an origin trial. Sarah Drasner created an interactive WebMCP demo of this implementation that you can try in your browser.

Cloudflare released a developer preview that can add a WebMCP bridge to a website, and Brave has tested WebMCP with its Leo assistant.

Testing WebMCP against varied applications can reveal assumptions in the current draft. For example, a form may need a declarative feature that has not been specified yet. Also, look for lifecycle problems when a website changes its tools during a task.

Bring your findings back to the WebMCP issue tracker.