Assignments in Microsoft Teams and through the Microsoft 365 LTI app has shipped a set of updates that connect interactive learning content directly into the assignment workflow, improve content quality across English-speaking regions, and give educators more control over AI-generated output.
All of these features are available now for every Microsoft Education license (A1, A3, A5) at no extra cost.
Educators using a Copilot+ PC can turn any teaching idea into an interactive lesson — with slides, quizzes, and activities — using the Learning Zone app. Those lessons now connect directly into the assignment workflow.
When creating an assignment, educators see a new Learning Zone resource option. Pick a lesson, and it's attached to the assignment. Students complete the interactive lesson right inside their assignment in Teams or through the LMS, without leaving. When they finish, scores sync automatically — the student's completion percentage becomes their assignment grade.
A few things to know:
You need a Copilot+ PC to create lessons. Students can complete them on any device.
If you don't have any lessons yet, the picker will link you to download the Learning Zone app.
Students can also open the lesson in the Learning Zone app on Windows if they prefer.
We've updated how students see feedback on returned assignments. The view now reorganizes to put what matters most front and center:
Feedback, feedback resources, rubric, and grades take the main space.
Instructions and resources collapse into side sections — still accessible, just not competing for attention.
Before this change, students saw everything at once — feedback mixed in with instructions, attachments, and rubrics. Many students struggled to find the feedback you spent time writing. Now it's the first thing they see when they open a returned assignment.
This is already active for everyone. Nothing to turn on.
Standards alignment across Instructions and Rubrics
Educators can now add educational standards directly to their assignment. When you use AI to enhance your instructions, it takes those standards into account. And when you generate a Rubric for the same assignment, it pulls in those same standards as input — so your instructions and rubric stay aligned without extra work.
We've also made a few other improvements to AI Instructions:
Describe changes to tweak the output. After the AI generates a suggestion, you can describe what you want changed in a text field and re-generate. Want it shorter? More scaffolded? Focused on a specific concept? Type what you'd like changed and get an updated version — no need to start over.
Shorter, more focused suggestions. When you use Add Detail, Add Sparkle, Add Hints, or other enhancements, the output stays closer to what you actually need rather than over-expanding your instructions.
English locale support across Assignments and the Teach module in Microsoft 365 Copilot
AI features across both Assignments and the Teach module in Microsoft 365 Copilot now support English (UK), English (Canada), and English (Australia) in addition to English (US).
Language is automatically selected based on your browser language settings. If your browser is set to en-GB, the AI generates content using British English. If you've used Teach before, it defaults to your previously used language. You can switch anytime from the Language dropdown when creating content.
We've also updated the age/year selection to match what's appropriate for each locale — so you'll see "Year 9" instead of "Grade 9" when using English (UK), for example.
As AI-powered development scales, more of what organizations pay for on GitHub is shifting from fixed per-seat pricing to usage-based billing. GitHub Copilot, Actions, Codespaces, AI Credits: spend now reflects what teams actually build, and that can vary month to month.
For most engineering and finance leaders, that raises a familiar question: how do you set a confident annual budget when consumption is variable? How do you capture the savings that come with committing upfront?
That is what GitHub Pre-Purchase Plans are for. Commit to an amount upfront, use it across eligible GitHub services over a 12-month term, and receive built-in savings based on the size of the commitment. Variable usage becomes a plan. Builders keep building, and finance teams get a number they can count on.
Microsoft is introducing two GitHub Pre-Purchase Plans (P3) for commercial customers, both available through Azure Reservations:
How the plans work
The model is the same for both plans:
Commit upfront. Choose a pre-purchase tier that fits your expected GitHub usage.
Receive built-in savings. Larger commitments unlock higher discount tiers, up to 15%.
Draw down as you go. Eligible usage consumes from the prepaid balance over the 12-month term.
Replenish or shift to pay-as-you-go. If usage exceeds the prepaid amount, purchase another plan or continue with pay-as-you-go billing where available.
Commit units are available for the plan term and do not carry over after the term ends.
Why choose a Pre-Purchase Plan?
Pre-Purchase Plans are not replacing how you buy GitHub today. They provide another option for customers who have a reasonable view of expected usage and want to plan ahead.
The value is straightforward:
More predictable planning for usage that can vary from month to month, especially as agentic development grows.
Simpler purchasing with one prepaid commitment instead of managing multiple separate charges across GitHub services.
Built-in savings compared with pay-as-you-go pricing. The more you commit, the greater the discount.
Alignment with Azure billing. GitHub usage is billed through the Azure subscription linked to your GitHub organization, so Pre-Purchase Plans fit into the same planning motions you already use for Azure commitments and reservations
Pricing*:
Both plans use the same published tier structure:
*Pricing as of June 2026 and is subject to change. Customers should review the latest documentation before purchasing.
**Example if GitHub Enterprise generates a retail cost of $100, then 100 GitHub Commit Units (GCUs) are consumed
Two examples
Planning across the GitHub platform
Suppose an organization expects about $500,000 in eligible GitHub usage over the next year across GitHub Copilot, GitHub Enterprise, GitHub Advanced Security, Actions, and GitHub AI Credits. With the GitHub Pre-Purchase Plan, the organization chooses the 500,000 commit unit tier, pays $425,000 upfront, and applies that commitment across eligible services over the 12-month term. That gives the team one platform-wide commitment with 15% built-in savings.
Planning for AI credit consumption
Another organization's biggest source of variability is GitHub AI Credits as Copilot and agentic development expand. Instead of using a broader platform commitment, that team chooses the GitHub AI Credits Pre-Purchase Plan so AI Credit usage draws down from a dedicated prepaid balance. This is a better fit when the main goal is to plan specifically around AI credit consumption.
How Pre-Purchase Plans relate to Microsoft Agent Pre-Purchase Plan
If you are also evaluating the Microsoft Agent Pre-Purchase Plan, here is the distinction: that plan is broader than GitHub and covers eligible usage across Microsoft Foundry, Copilot Studio, Fabric, and GitHub.
Choose a GitHub Pre-Purchase Plan when GitHub is the platform you are planning around. Choose Microsoft Agent Pre-Purchase Plan when the goal is agent development spanning the wider Microsoft platform
Getting started
Both plans are available through Azure Reservations today.
Sign in to the Azure portal
Go to Reservations
Select Add
Choose GitHub Pre-Purchase Planor GitHub AI Credits Pre-Purchase Plan.
Select your subscription and scope.
Choose your tier and complete payment
For detailed purchasing steps, scope guidance, prerequisites, and examples, see the Microsoft Learn documentation:
So, you adopted event-driven architecture because your system was a rat’s nest of coupling, and events were the answer to decouple it.
But now debugging is a nightmare.
You have events coming in out of order. You have retries causing duplicates and multiple different side effects. Local development is a pain. It’s frustrating, right?
But we use events for a reason.
YouTube
Check out my YouTube channel, where I post all kinds of content on Software Architecture & Design, including this video showing everything in this post.
Events can help us reduce temporal coupling within our system. We can have a publisher publish events for downstream services or other parts of our system that consume those events, process them how they need to, when they need to.
The producer doesn’t care who’s consuming them.
There’s real value there around workflows, integrations, and scaling, when you need it. There’s real value there when you have the right problems.
But here’s where things start going wrong. You think everything needs to be independently deployable. Or that everything has to be asynchronous. Or you start publishing events that aren’t really business facts.
And when you really start to feel the pain of this, that’s when you start blaming event driven architecture.
But events aren’t really the problem. Misunderstanding is.
As I was reading it, I thought, okay, this is somewhat relatable.
But then, as I continued, I realized that no, this was really poor design. Things related to debugging, local developer experience, retries, ordering, and a lot of the problems they were having, they really didn’t need to be having.
I’m not here to tell you event driven architecture is a silver bullet, because it is not.
It has complexities. There are trade offs.
But the pain they were experiencing came from the wrong conclusions.
This Is Not Eventual Consistency Hell
The first pain point they brought up was what they called eventual consistency.
Their example was sales and orders being placed in their system, and they had different parts of the system that needed to do different things.
Shipping needed to create a shipping label.
Inventory needed to reduce the quantity on hand.
Payments needed to charge the customer’s credit card.
The issue they mentioned was, what happens if there’s a failure?
Before, in a monolith, they said they could just roll back the transaction. But now they needed all these compensating actions. For example, they had to publish a different event so inventory could undo what it did, or shipping could undo the label creation.
And if it was in a monolith, they said, you would just roll back the transaction.
I’m not so sure it’s actually that easy.
They called this eventual consistency hell.
This isn’t eventual consistency hell. This is workflow modeling hell.
When they mention rolling back a transaction, in this exact use case, it doesn’t really work that way.
If you’re interacting with some shipping system to create a label, typically that’s going to a carrier. That is not something you just roll back in your database.
Same thing if you have some type of payment issue or timeout. Did it actually go through? You might need to reconcile that.
There aren’t just multiple systems where you can roll everything back together and magically have some distributed transaction. That’s not likely going to happen.
This is more of a modeling problem.
You should be modeling actual business workflows using events that the business actually cares about.
Events Should Represent Business Facts
Events represent business facts. Things the business actually cares about and refers to in a particular way.
Not CRUD.
One example from the post was that a customer places an order, so they publish an OrderCreated event.
But was that really what happened? Was the order submitted? Was inventory reserved? Was a payment authorized?
Those are actual business events. Those are things that are really happening within a boundary.
Naming matters.
Don’t get too caught up in the exact domain here, but I want to illustrate the point. There isn’t just some massive rollback of all of this because you probably wouldn’t want that anyway.
If a payment failed, you’d probably be contacting the customer.
You don’t have to roll back inventory because maybe you didn’t actually reduce it to begin with. That’s not when it happens. You might be reserving inventory instead.
There are completely different business cases related to inventory, payments, shipping, and ordering. The example was framed as, “We had all these compensating actions and we were better off with one giant rollback.”
But you probably wouldn’t have had one giant rollback to begin with.
Asynchronous Does Not Mean Everything Is Eventually Consistent
Another pain point they mentioned was performance. Their API response times went from 150 milliseconds to 2.5 seconds. Why? Network hops.
They mentioned a customer saying, “I updated my profile, but the change doesn’t show up for 30 seconds.”
And the response was basically, “That’s eventual consistency for you. Eventually.”
Hang on. What?
The conclusion they landed on was that asynchronous isn’t fast. It can be fast, but it doesn’t have to be. The better question is, why is a user updating their profile and having to wait for anything?
Not everything has to be asynchronous.
If a user is trying to change their profile information, that should be synchronous. It should be immediately consistent, and it should be something the user immediately sees.
You want to be able to read your own write.
Does that mean you can’t have events involved? No. You absolutely can.
You can have different boundaries that care about when a profile has its phone number updated. Maybe CRM cares because you have some external CRM that you keep updated. Maybe analytics cares. Maybe some other part of the system cares.
Whatever handles the profile update can publish an event.
It doesn’t really care what other parts of the system care about that event. Those parts can be asynchronous.
That’s a good use case for asynchronous processing.
But updating the information so the user sees it immediately? Why would that be asynchronous?
It should be synchronous, just like you’d expect it to be in any other type of system.
Kafka Being Down Is an Infrastructure Problem
Another issue they had, and I’ve heard this before, was the single point of failure.
They mentioned a Kafka cluster incident where everything depending on events stopped working.
Which was everything.
They couldn’t create users. They couldn’t process orders. They couldn’t update inventory.
In the monolith days, they said, if the database went down, everything stopped, but at least they had one thing to fix.
Here was the glaring thing they mentioned: With Kafka down, they couldn’t even fall back to synchronous processing because they had removed all that code.
Well, first, we already established that not everything should be asynchronous.
Second, if you have vital infrastructure, you deal with it appropriately. Like anything else.
It’s no different than their database example. Do you want your database to be down? No. If it is down, everything is down.
If it cannot be down because not everything can be down, then what do you have?
You have monitoring. You have high availability. You have failover. You have backup processes.
This is no different than any other piece of infrastructure.
Same thing with a cache. If you have a cache and it goes down, there’s an outcome to that. Often, that outcome is hammering other parts of your system, like your database, because your cache is gone.
So you end up making the cache highly available too.
It’s no different than any other part of your infrastructure that you require high availability for.
Having said that, with messaging, depending on the libraries or infrastructure you’re using, it’s common to have some kind of local mailbox where messages are kept in case they can’t be published. The outbox pattern is one example.
Yes, there is complexity.
But you’re often using this to make the system more resilient.
Event Driven Architecture Does Not Require Microservices
There were two other pain points that were very related.
They mentioned the hidden costs nobody talks about, especially infrastructure costs.
Before, with their monolith, they had two application servers, one PostgreSQL database, and a cache.
With event driven architecture, now they had six microservices, a Kafka cluster, six different databases, a service mesh, and all these different costs.
They also mentioned the developer experience.
With the monolith, you clone one repo, run Docker Compose, and everything is good.
With their event driven architecture, they had all these different repos. You had to install Kafka, Zookeeper, all these databases locally. It became a nightmare to deal with.
These are really the same issue.
The issue is assuming event driven architecture has something to do with physical deployments, different repos, and separate infrastructure.
It doesn’t.
You can use event driven architecture within a monolith.
You can have a monolith with different boundaries like customers, orders, billing, inventory, and notifications. That can all be deployed in a single instance. Or multiple instances if you are scaling out. It can use a single PostgreSQL database or whatever database you’re using.
But each boundary owns its particular schema.
Physical boundaries are not logical boundaries.
I will keep saying this every possible chance I get until people figure it out.
Event driven architecture does not require six different repos, six different database servers, six different deployments, and Kafka all over the place.
You do not need that.
You can be using event driven architecture within a monolith.
You do not need microservices.
You do not need Kafka.
It’s about publishers and consumers. It’s about decoupling in time.
That’s the point of event driven architecture.
Not all the infrastructure.
Messaging Can’t Fix Bad Boundaries
The pain they felt was real. That’s why they said event driven architecture caused more problems than it solved.
But the reality is that misunderstanding and misapplying event driven architecture is why they felt that pain.
The better lesson is this:
Messaging can’t fix bad boundaries.
I think this is why people experience all this pain and then blame event driven architecture.
My solution is to start with logical boundaries.
Start by defining what your boundaries are.
From there, choose how those boundaries communicate.
Is the communication synchronous?
Is it asynchronous?
Then choose how you’re going to deploy.
Are you deploying one particular boundary by itself?
Are you deploying everything together?
That’s the order.
Define logical boundaries.
Choose communication patterns.
Choose deployment model.
I think most people do this in reverse, and that’s how they get into trouble.
They start by thinking, “We need to deploy this independently for scale.”
Then because of that, they decide they have to always communicate through events or always communicate asynchronously somehow. Or they introduce HTTP APIs everywhere and now they have more network hops.
Then, after all that, they try to decide what should go where.
That’s backwards.
Start with logical boundaries.
Then choose how they communicate.
Then choose how they deploy.
In that order.
Events Are Not the Problem
Event-driven architecture is not the problem.
Events have complexity. Messaging has complexity. Asynchronous workflows have complexity.
But a lot of the pain people attribute to event-driven architecture comes from misunderstanding what it’s actually for.
Not everything needs to be asynchronous.
Not every event is a business event.
Not every boundary needs to be independently deployed.
Not every event-driven system needs Kafka, microservices, six databases, and a service mesh.
Use events when they solve the right problem.
Use synchronous communication when that is what the workflow or user experience requires.
Model the business process correctly.
Define your logical boundaries first.
Because events can help reduce coupling, but they cannot fix bad modeling.
Join CodeOpinon! Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.
Every developer has tools they rely on daily. The workflows they’ve built around them, the ways they’ve learned to move faster, debug smarter, and write better code – that kind of hands-on experience can be hard to put into words.
We’re collaborating with LinkedIn to make it easier for you to showcase your expertise with JetBrains IDEs on the world’s largest professional network. You can now connect your IDE to LinkedIn and let your real tool usage speak for itself.
IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, Rider, GoLand, CLion, RustRover, and RubyMine are already supported via a free plugin, while support for DataGrip is coming soon.
In this blog post, we’ll explain what LinkedIn connected apps are, what they mean for your profile, and how to get started.
What this is about
Building on early collaboration with Descript, Duolingo, Lovable, Relay.app, and Replit, LinkedIn is expanding the range of apps you can feature on your LinkedIn profile, turning real-world product usage into a credible, visible signal of practical tool experience. We’re glad to join forces with them to bring this to JetBrains IDE users.
“We’re building new ways for members to show real, credible proof of what they’re capable of, right on their LinkedIn profile. And for the brands behind these tools, there’s no better endorsement than a customer who’s actively using and loving your product.” – Dan Shapero, CEO of LinkedIn
Connected apps let you link the tools you use in your daily work directly to your LinkedIn profile, where they appear prominently, helping you stand out to your professional network. Once connected, each app generates a simple statement based on how you actually use it. Unlike manually added skills, this is based on real usage and updates automatically as your experience evolves.
How to get started
Open your JetBrains IDE, go to Settings | Plugins, search for the LinkedIn Connected Apps plugin under the Marketplace tab, and install it.
Once installed, the plugin starts collecting data locally about how you use your IDE. Depending on your usage history, you may receive an initial statement right away, which will then be updated once the plugin has collected enough data to better reflect your real IDE expertise.
Your IDE usage data stays on your machine. When you are ready, you can connect your LinkedIn account and share your IDE expertise badge there. If you keep the plugin installed, your badge will update automatically as your IDE usage evolves.
The plugin is free for all JetBrains IDE users.
What’s included in this release
This is the first version of the integration, delivered as a standalone plugin rather than being built directly into the IDE. It covers IntelliJ IDEA, PyCharm, WebStorm, GoLand, PhpStorm, Rider, CLion, RustRover, and RubyMine; DataGrip is not yet supported.
Usage is detected within the IDE itself, so if you use AI features via an external tool or terminal, those won’t be reflected yet.
How your IDE expertise is determined
The model is intentionally simple for now. It is designed to represent your practical use of JetBrains tools, not to rank developers or certify skill levels. Our goal was to provide a solid starting point, but we know there’s more to capture about how developers work with their IDEs.
Statements map to different levels of experience and are generated based on how you interact with your IDE – from writing and editing code using basic features to working with debugging tools, version control, and AI-assisted workflows. For more information, see our documentation.
What’s coming next
We’re already working on the next version, planned for later this year. We’ll focus on improving how IDE usage, including AI feature usage, is represented, expanding support to DataGrip, and making the overall experience feel more integrated.
FAQ
Which JetBrains IDEs are supported?
IntelliJ IDEA, PyCharm, WebStorm, GoLand, PhpStorm, Rider, CLion, RustRover, and RubyMine. Support for DataGrip is coming soon.
Why isn’t DataGrip supported yet?
DataGrip is designed for working with databases and includes workflows that differ from our other IDEs. We plan to support it soon.
Can I connect multiple IDEs?
Yes, if you use multiple supported JetBrains IDEs, you can connect each of them. You’ll get a badge for all connected IDEs.
Note: If you use multiple JetBrains accounts across different IDE instances but link them all to the same LinkedIn profile, IDE usage statements from each account will be displayed on that LinkedIn profile.
Do I need to keep the plugin installed after connecting?
You can share your IDE usage statement once and then remove the plugin, but note that it must remain installed if you want to track your ongoing progress and have any changes reflected on LinkedIn.
Is this feature free?
Yes, it’s available to all JetBrains IDE users at no cost.
Is this a certification?
Connected apps reflect real IDE usage and are designed to showcase applied experience, not to act as a formal certification or skill ranking. Certifications, degrees, and licenses remain important markers of professional achievement. Connected apps on LinkedIn add a different kind of signal: partner-validated tool usage that reflects practical work and can update over time.
What data is shared with LinkedIn and JetBrains?
Only the information required to represent your connected account and IDE usage statement.
Will this help me get hired?
Having connected apps on your LinkedIn profile is extra proof of your practical experience with leading tools. While connected apps make your expertise visible, they are just one part of your profile. Think of it as a way to let your tooling speak for itself.
Give it a try and let us know what you think in the comments below. We’re continuing to develop this integration, and your feedback will help shape what comes next.
Welcome to Day 3 of Launch Week #12, a.k.a. Community Day. This is the one where we step out of the way and let the Waspeteers do the talking. 🐝
We get one question more than any other: "okay, but what do people actually build with Wasp?" Today's the answer.
Four apps, four verticals that have basically nothing to do with each other (video tooling, UK property tech, e-commerce, and early-childhood education), all paid, all in production, all built by people from the Wasp community. It's been a minute since Vol. 1 back in 2023, and the bar has moved. Let's get into it.
CutCue - the AI editing intern for streamers (Wasp + Python workers)
Imagine you just streamed for six hours on Twitch and now you have to pull the three best clips for YouTube. Normally that's an evening of scrubbing the VOD with a coffee. Drop the recording into CutCue and you get back a timeline already marked up with highlights, chapter breaks, brand mentions, moments that could lose you ad revenue (e.g. swearing), and chat peaks, automatically.
CutCue interpreting a VOD in real time.
The cool bit: the markers don't sit in some web dashboard you have to copy-paste from. CutCue exports straight into Premiere Pro, DaVinci Resolve, Vegas, Audacity, and Reaper, so they show up exactly where your timeline expects them. You open your editor, and the AI's homework is already on the canvas.
Under the hood: a Wasp app orchestrating four to five Dockerized Python workers (audio extraction, chapter detection, fingerprinting, queue management), self-hosted on Hetzner, built stateless from day one so it can scale horizontally when it needs to. The kicker: shipped by a backend-heavy engineer who'd never written React before this project.
"I described it usually as a baseline or a toolkit, the foundation for my project, which takes over the important stuff like session management, user payment, all the things which usually take a long time to build yourself and make stable and secure."
- the CutCue founder
Brick - a website builder for UK property operators
Picture this: you're a UK landlord with three properties, and a prospective tenant just asked for your website. You... don't have one. Brick is the fastest way out of that conversation.
You tell it your business name and what kind of property you run (rent-to-rent, serviced accommodation, HMO, deal sourcing, development), and it spins up a full website in about five minutes: AI-generated copy tuned to your niche, a chatbot that captures leads while you're at a viewing, GDPR pages, SSL, daily backups, the lot. Each property niche gets its own template, so the sites don't all look the same.
Brick features a full-fledged no-code website editor! Really cool.
ChatBuster - the AI chat that closes the sale, live on Shopify and WordPress
Try it out:chatbuster.com · Pricing: from $40/mo · Where: Shopify App Store + WordPress.org
If you've ever shopped on a Shopify store and pinged the chat widget at midnight to ask "do you ship to Canada?", ChatBuster is the thing on the other end. Except now it's AI, trained on the merchant's actual catalog, theme, and policies, so it answers with the right number, the right policy, and the right SKU.
Under the hood: live catalog sync (SKUs, prices, stock update as the merchant updates), proactive prompts you can trigger on scroll or schedule, and order tracking through the store's API. A merchant installs it from the Shopify App Store or WordPress.org (the WP plugin went live in May 2026), flips one toggle, and it's working five minutes later. No developer required.
And it's not theoretical. Real merchants are already leaving five-star reviews:
Five-star reviews from Shopify merchants.
PlanRelief - AI lesson plans for daycare and early-years educators
Try it out:planrelief.io · Pricing: free to try · For: educators of ages 0 to 12
Imagine you're a daycare teacher and you spent the afternoon watching kids in the play corner. You jot down "Mia experimented with mixing colours." PlanRelief takes that one-line observation, plus a theme you pick ("rainbows and seasons"), and generates a full lesson plan: learning objectives, materials list, assessment strategies, the activity flow, ready to hand to a supervisor.
I typed 'learn building web apps' as the topic. The AI took it seriously and came back with toddler-grade activities involving big buttons and Velcro icon boards. Respect.
The pitch line is exactly what you'd want it to be: "paperwork done in minutes, not hours." Free to try, no credit card.
Build anything with Wasp, ship it, and get paying customers
Four apps, zero overlap. Creator tools, property tech, e-commerce, classroom. All paid SaaS. All running in production. All built on the same framework you can install with one command.
That's the whole point of Community Day, really: when we say Wasp is a real fullstack framework, we mean real. Apps in real verticals, with real customers paying real money. The lineup looks very different from Vol. 1, and it'll look very different again the next time we do this.
If you've built something on Wasp that should be in Vol. 3, come say hi on Discord or X/Twitter. We'd love to feature you next time.
And if you haven't started yet, you're one command away:
Log in
