Norway will largely prohibit generative AI use for elementary kids ages 6 to 13 beginning with the new school year, while allowing limited, teacher-supervised use for older students. The government says the restrictions are intended to prevent children from skipping foundational reading, writing, and mathematics skills amid declining test scores. Reuters reports: Facing a broad decline in education test scores, the government in 2024 banned smartphones from schools and has given teachers back more powers to enforce discipline in the classroom. Using AI increases the risk that young children skip important steps in their education, Prime Minister Jonas Gahr Stoere told a press conference on Friday. "The most important thing in school is that our children learn to read, write and do mathematics," Stoere said, adding that the new standards will be imposed from the new school year beginning in late August.
Pupils from first through seventh grade, aged 6 to 13, should as a general rule not be using AI, while those in lower secondary school, aged 14 to 16, can cautiously adopt tools under teachers' supervision, the government said. In upper secondary education, from ages 17 to 19, students should learn to use AI appropriately so that they are prepared for further education and work, it added. In a related statement, the Norwegian government also said it would propose legislation to fund the use of more books in classrooms, reversing the trend towards computer tablets.
Large data and analytics organizations often struggle to make access to data and insights truly self-serve. The industry tried to solve this problem, quite unsuccessfully, for decades, but now AI is giving us a credible way to do just that.
At GitHub scale, providing dedicated analytics support to dozens of product teams is challenging, and therefore many teams are left to solve this problem on their own. Though there is a lot of valuable product telemetry that product and engineering teams can use to make decisions, figuring out which data model, which grain, which filter, and then write the query and validate the result has always been difficult without the support of a data analyst.
Enter Qubot, our internal GitHub Copilot-powered analytics agent. Qubot allows any Hubber (that’s what we call GitHub employees) to ask questions about any data model in GitHub’s data warehouse in plain language and get an answer within seconds.
Qubot is not a reporting tool or a dashboard replacement. Instead, it’s intended for exploratory questions like “Which cohort of users has the highest retention on this feature?” or “What product contributed to move this metric the most last week?” Qubot has zero cost maintenance and helps teams ramp up quickly on datasets they may be unfamiliar with.
In this blog post, we’ll go over how we built Qubot, how it’s changed, and what we learned.
How Qubot works
The architecture has three main components: user interface, context layer, and query engine.
User interface
Qubot is accessible through Slack, VS Code, and the Copilot CLI. The Slack interface doesn’t require any configuration, and it is the preferred collaboration tool of Hubbers. When someone posts a question in the Qubot Slack channel, a Qubot instance is spawned as a Copilot Cloud Agent running on github.com. The answer is provided directly in Slack, allowing the user to share the result with others, but also iterate in the thread to evolve or refine the question. All the results are also stored as a markdown report in a pull request that the user can reference to fine tune the query or use it in a dashboard.
Qubot is also available in VS Code and the Copilot CLI, for users that want an experience more integrated with their workflows. Qubot can be installed with one command as a plugin, and it becomes available in any agent session in VS Code or Copilot CLI alongside any other custom agents, skills, and tools configured by the user.
Context layer
Our data warehouse contains data at different stages of curation: raw events (bronze), conformed facts and dimensions (silver), and curated datasets designed for specific business use cases (gold). The context layer is built in a federated way, with knowledge that is tailored to the type of data.
For bronze data, we have telemetry context contributed by product teams, with schema information and metadata.
For silver data, we have examples of queries, usage guidance, mandatory filters etc, maintained by the data and analytics team.
For gold data, we have business rules and metric definitions, contributed by teams owning those datasets.
We also leverage our ETL pipelines to systematically enrich the context layer with additional signals and derived metadata. The context is loaded at runtime via the GitHub MCP Server, fetching it from the context layer.
Context agent
The context layer is constantly enriched with new knowledge persisted across multiple repositories. At GitHub, we primarily use markdown for documentation, so we don’t need to interface with multiple different tools.
We’ve streamlined federated context contribution through a context agent. Teams can contribute via a standardized template or by referencing a repository containing relevant context. The agent then ingests, organizes, and normalizes this information into a structured format that has proven effective for Qubot based on our evaluations.
Evaluation framework
Every change to the context layer or agent configuration gets evaluated before it ships. When someone wants to enrich the context layer with new knowledge, they can open a pull request. The new context goes through an offline eval framework that measures accuracy of the response, latency in finding the right answer, and catches regressions before they reach users.
The benchmarking framework for evaluating Qubot across structured test cases has three components:
Test cases: A curated dataset of prompts with known correct answers, ground-truth SQL, and metadata (domain, difficulty).
Automated run orchestration: A script that automates launching each test case as an agent task with the GitHub CLI gh agent-task create, runs multiple parallel trials, polls for completion, and saves detailed JSON results.
Stats aggregation: A reporting script that reads the saved results and computes per-test-case metrics: completion rate, accuracy, and duration (avg/min/max).
The end-to-end flow is: define test cases → run Qubot N times per case → collect results → aggregate stats → compare configurations.
Query engine
Qubot connects to both Kusto and Trino, the two query engines that power most of GitHub’s analytics workloads, via a MCP server. We developed a custom implementation of the Trino MCP server, while for Kusto we deployed a local version of the Fabric RTI MCP Server. Kusto is fast and well-suited to exploratory questions over recent event data. Trino handles complex joins and deeper historical analysis.
Rather than forcing users to know which to use, Qubot defaults to Kusto and switches to Trino automatically when the question requires it.
What changed, and what we learned
Qubot has been widely adopted at GitHub, with hundreds of enthusiastic users running thousands of queries. The number of questions that Hubbers ask in the data and analytics Slack channels has reduced dramatically, because now they can explore the data with greater autonomy and reach out only for complicated questions. It also allows Hubbers that never dared to dip into the data warehouse to access the data they need to drive their decision making. That is one of the reasons for offering multiple interfaces like Slack, Copilot CLI, and VS Code; Hubbers are very technical, but we wanted to offer an option with no barrier to entry and zero configuration.
We quickly discovered that the context layer is key to enriching the reasoning capabilities of Copilot and to create an expert analytics agent. In our experiments we found that structured and well curated context not only makes Qubot more accurate, but also three times faster at returning the right answer. This has profound implications on the analytics engineering discipline, because it makes this type of artifact a first class citizen in how data is modeled, rather than an afterthought.
Qubot has been a rare example of successful hub-and-spoke execution. It removes strain from the data and analytics team, as product teams own the telemetry for their surfaces and business teams own the definition of their gold data. Qubot acted as a gravitational force to centralize all this distributed knowledge into a single tool that can benefit all GitHub, providing incentives to partner teams to contribute to Qubot, instead of creating multiple tools limited to their own domains.
We will begin this migration in the coming weeks. For most customers, the change will be automatic and require no action. However, some apps will need customer updates before they can move to the new hosting model. This exception is:
Logic Apps that use the current NuGet-based deployment model
If your app does not fall into one of these categories, it will be migrated automatically and no action is required. If it does, review the guidance in this article to prepare your app for migration.
Getting ready for this update
If your application is using NuGet-based deployment, you should update your deployment processes to preserve the following app setting until your app is ready to move to the new hosting model:
LOGICAPP_INPROC_REDIRECT
1
This app setting is used to prevent an app from being automatically migrated to the Azure Functions out-of-proc-hosting model. We will update this app setting for apps that fall into the exception categories and will notify customers to update their deployment pipelines so this value is not overwritten.
We will start rolling out a change that will automatically move any app that does not have the above app setting to the Azure Functions out-of-proc-hosting model the next time the app restarts.
As part of the rollout process, we will add this flag to any application that fits the exception criteria. This will be done only once, so subsequent configuration changes could override our setting. This is why you need to update your processes to preserve this value until the app is ready to move.
Manual steps needed for NuGet-based applications
If your application is using the NuGet-base deployment model, you will need to make the appropriate updates described below before removing the redirect app setting and allowing the app to move to the Azure Functions out-of-proc-hosting model.
Download the latest Azure Functions Core Tools.
Update your project configuration to the Azure Functions out-of-proc-hosting model.
Validate your application locally before updating your deployment process and removing the redirect app setting.
After you have validated your application locally and updated your deployment process, you can remove the redirect app setting and allow the deployed app to move to the Azure Functions out-of-proc-hosting model when appropriate guidance has been published for your scenario.
Frequently Asked Questions
Q: How do I prevent my app from being migrated to the Azure Functions out-of-proc-hosting model?
The LOGICAPP_INPROC_REDIRECT setting is used to determine whether an app should remain on the current in-proc hosting model. By default, apps that do not have this setting will be moved to the Azure Functions out-of-proc-hosting model. Set the value to 1 if you need to prevent automatic migration until your app is ready.
Q: What happens if my app uses the NuGet deployment model?
If your app uses the NuGet deployment model, you should keep the redirect app setting in place for now. We will publish a separate communication when the required Logic Apps runtime package guidance and supported migration steps are confirmed for this scenario.
Q: Q: What happens if I accidentally remove the LOGICAPP_INPROC_REDIRECT = 1 from my configuration?
The LOGICAPP_INPROC_REDIRECT setting is used to determine whether an app should remain on the current in-proc hosting model. If you remove it by accidenty, your application will be moved to the Azure Functions out-of-proc-hosting model. But you can reset that behavior by reapplying the setting and restarting the application.
Q: Will there be a separate communication about .NET 10 support?
Yes. We will send a separate communication once we have confirmed the Logic Apps runtime and workflow version guidance for .NET 10 support.
The next annual update for Windows 11 is coming soon and is already available to Windows Insiders! Windows 11, version 26H2 continues our focus on delivering a predictable, low-disruption update experience for organizations and IT professionals.
For devices already running recent versions of Windows 11, this release should be easy to adopt. It builds on the same platform and servicing approach introduced in prior releases, while continuing to improve how updates are delivered, tested, and deployed.
In this post, we'll walk through how to prepare for Windows 11, version 26H2.
A familiar update experience, refined
Windows 11, version 26H2 uses the same shared servicing model as recent releases available annually in the second half of the calendar year. Supported devices get this feature update as a small enablement package instead of a full OS replacement.
If your organization is already on Windows 11, version 24H2 or 25H2, the update to 26H2 is similar to a regular monthly update in most environments:
A small, quick installation
Minimized disruption to users
No need for full reimaging or complex deployment motions
Note: Devices running Windows 11, version 26H1 won't be able to update to version 26H2. Instead, they'll have a path to update to a future Windows release. This is because Windows 11, version 26H1 is based on a different Windows core than Windows 11, versions 24H2, 25H2, and 26H2. Here's What to know about Windows 11, version 26H1.
This is possible because multiple versions of Windows 11 share a common servicing branch, including:
The same source code base
The same security and quality updates
The same compatibility validation
The difference between versions is simply which features are enabled.
Shared servicing branch progression
Why this matters for IT organizations
The shared servicing model isn't just a technical detail. It directly impacts how you manage updates across your environment. Compared to full OS upgrades of the past, Windows 11, version 26H2 comes with reduced deployment complexity, improved compatibility confidence, and faster time to value.
Reduced deployment complexity
Because features are delivered continuously and enabled later, there's no large "upgrade event." This makes planning easier and reduces operational overhead.
Improved compatibility confidence
Devices moving between versions on the same servicing branch typically benefit from:
Existing application compatibility validation
Lower risk of regressions
Fewer surprises during rollout
Faster time to value
With smaller updates and faster installations, organizations can move more quickly to the most current release. New features reach you without lengthy deployment cycles.
Support lifecycle considerations
As with previous annual feature updates, moving to Windows 11, version 26H2 resets the Windows support lifecycle for your devices.
This provides:
24 months of support for Home, Pro, Pro EDU, and Pro for Workstations editions
36 months of support for Enterprise, Education, IoT Enterprise, and Enterprise Multi-session editions
What does it mean for your servicing strategy? The annual update becomes a key milestone for maintaining a supported and secure environment.
How to prepare for Windows 11, version 26H2
Already managing Windows 11 in your organization? Preparing for 26H2 should align with your existing update processes.
1. Validate today
Begin testing with devices running recent versions of Windows 11 to confirm compatibility with your apps, policies, and infrastructure.
If you'd like to get a peak of what's coming and begin previewing version 26H2 on devices now, the update is available through the Windows Insider Program in the Experimental channel. Otherwise, your organization might prefer to wait for the update to become available in Release Preview before doing more extensive testing. At that stage, the experience is closer to final shipping quality. We'll have more information to share when version 26H2 is in Release Preview.
2. Use your existing deployment tools
Windows 11, version 26H2 will be available through familiar channels, including:
Windows Autopatch
Microsoft Intune
Windows Server Update Services (WSUS)
3. Plan your rollout rings
Use your standard deployment rings to:
Pilot the update with a small group of devices.
Expand gradually based on validation results.
4. Stay current
Windows features are delivered continuously. Stay up to date with monthly updates to help ensure a smoother transition when the feature update becomes available.
Feature delivery over time with enablement moment
Looking ahead and staying informed
Windows 11, version 26H2 continues the move toward a more predictable and efficient servicing model. This model helps reduce disruption while helping your organization stay secure and up to date. By building on a shared platform and delivering innovation continuously, Windows enables you to focus less on large upgrade projects and more on delivering value to your users.
We'll continue to share updates and guidance as Windows 11, version 26H2 becomes available. In the meantime, test it in the Windows Insider Program's Experimental channel and use the updated plan-prepare-deploy learning path to get ready.
Robin and Mazen unpack the rise of AI-powered security threats, from the TanStack breach to compromised React Native packages and GitHub supply chain attacks. Learn practical ways to secure your React Native apps, manage dependencies safely, and reduce risk in modern mobile development.
Infinite Red is a premier mobile app consultancy, especially focused on Expo and React Native, located fully remote in the US. We’re a team of 30 with highly experienced mobile app developers and have been doing this for over a decade. We are also one of the first development teams to adopt agentic coding in a way that keeps high quality standards and aren’t afraid to do things the old school way if we need to. If you’re looking for mobile app or React Native or Expo expertise for your next project, hit us up at infinite.red/radio.
What’s it actually like for Microsoft to manage open source projects? Amanda Silver shares how collaboration, community input, and real-world usage shape the way these projects evolve.
Log in
