In 2004 I published the first edition of The CSS Anthology with Sitepoint. The idea for the book was to take the entire CSS 2.1 specification, and come up with 101 examples to show people how to use all of the CSS that existed. I have a copy on my shelf, but recently discovered you can read it on archive.org.

Despite the personal horror of realising that book is old enough to buy alcohol in the USA, it’s fun to look at as a snapshot of a certain point in the history of the web. In 2004 many sites were still laid out with tables, several of the examples explain how to do a certain layout “without tables”. It’s also notable how I refer throughout to specific browser versions, because in 2004 a browser version would last for at least a year and usually much longer. Chrome is about to begin a two-week release cycle, we’ve come a long way.

It’s also interesting how long we had to wait for interoperable, robust ways to achieve some of the solutions. On page 328 I explain how to create coloured scrollbars, using the scrollbar-* that only worked in Internet Explorer. Over 20 years later the scrollbar-color property became Baseline Newly available.

I ultimately published four editions of The CSS Anthology. People still tell me how they learned CSS from that book, something which I find amazing and wonderful. I often wonder what a modern version of that book would look like, and how big it would need to be to attempt to cover all of CSS in 2026!

1179. This week, we talk to Valerie Fridland, a linguist and professor who grew up in Memphis surrounded by Southern accents and now researches the history and social power of speech. We look at her new book, "Why We Talk Funny: The Real Story Behind Our Accents," which explores the history of how American speech developed and how colonial settlement patterns shaped regional identities. Then we look at the decline of regional accents, the mechanics of speech sounds like "L" and "R," and the psychological impact of accent bias.

Get Valerie’s new book, "Why We Talk Funny: The Real Story Behind Our Accents."

More from Valerie at valeriefridland.com

🔗 Join the Grammar Girl Patreon.

🔗 Share your familect recording in Speakpipe or by leaving a voicemail at 833-214-GIRL (833-214-4475)

🔗 Watch my LinkedIn Learning writing courses.

🔗 Subscribe to the newsletter.

🔗 Take our advertising survey.

🔗 Get the edited transcript here.

🔗 Get Grammar Girl books.

| HOST: Mignon Fogarty

| Grammar Girl is part of the Quick and Dirty Tips podcast network.

• Audio Engineer: Dan Feierabend
• Director of Podcast: Holly Hutchings
• Advertising Operations Specialist: Morgan Christianson
• Marketing and Video: Nat Hoopes, Rebekah Sebastian
• Podcast Associate: Maram Elnagheeb

| Theme music by Catherine Rannus.

| Grammar Girl Social Media: YouTube. TikTok. Facebook. Threads. Instagram. LinkedIn. Mastodon. Bluesky.

Hosted on Acast. See acast.com/privacy for more information.

The AI landscape has shifted. The question is no longer “Can we build AI applications?” it’s “Can we build AI applications that actually work in production?” Demos are easy. Reliable, scalable, resilient AI systems that handle real-world complexity? That’s where most teams struggle.

If you’re an AI developer, software engineer, or solution architect who’s ready to move beyond prototypes and into production-grade AI, there’s a series built specifically for you.

What Is AI Apps & Agents Dev Days?

AI Apps & Agents Dev Days is a monthly technical series from Microsoft Reactor, delivered in partnership with Microsoft and NVIDIA. You can explore the full series at https://developer.microsoft.com/en-us/reactor/series/s-1590/

This isn’t a slide deck marathon. The series tagline says it best: “It’s not about slides, it’s about building.” Each session tackles real-world challenges, shares patterns that actually work, and digs into what’s next in AI-driven app and agent design. You bring your curiosity, your code, and your questions. You leave with something you can ship.

The sessions are led by experienced engineers and advocates from both Microsoft and NVIDIA, people like Pamela Fox, Bruno Capuano, Anthony Shaw, Gwyneth Peña-Siguenza, and solutions architects from NVIDIA’s Cloud AI team. These aren’t theorists; they’re practitioners who build and ship the tools you use every day.

What You’ll Learn

The series covers the full spectrum of building AI applications and agent-based systems. Here are the key themes:

Building AI Applications with Azure, GitHub, and Modern Tooling
Sessions walk through how to wire up AI capabilities using Azure services, GitHub workflows, and the latest SDKs. The focus is always on code-first learning, you’ll see real implementations, not abstract architecture diagrams.

Designing and Orchestrating AI Agents
Agent development is one of the series’ strongest threads. Sessions cover how to build agents that orchestrate long-running workflows, persist state automatically, recover from failures, and pause for human-in-the-loop input, without losing progress. For example, the session “AI Agents That Don’t Break Under Pressure” demonstrates building durable, production-ready AI agents using the Microsoft Agent Framework, running on Azure Container Apps with NVIDIA serverless GPUs.

Scaling LLM Inference and Deploying to Production
Moving from a working prototype to a production deployment means grappling with inference performance, GPU infrastructure, and cost management. The series covers how to leverage NVIDIA GPU infrastructure alongside Azure services to scale inference effectively, including patterns for serverless GPU compute.

Real-World Architecture Patterns
Expect sessions on container-based deployments, distributed agent systems, and enterprise-grade architectures. You’ll learn how to use services like Azure Container Apps to host resilient AI workloads, how Foundry IQ fits into agent architectures as a trusted knowledge source, and how to make architectural decisions that balance performance, cost, and scalability.

Why This Matters for Your Day Job

There’s a critical gap between what most AI tutorials teach and what production systems actually require. This series bridges that gap:

• Production-ready patterns, not demos. Every session focuses on code and architecture you can take directly into your projects. You’ll learn patterns for state persistence, failure recovery, and durable execution — the things that break at 2 AM.
• Enterprise applicability. The scenarios covered — travel planning agents, multi-step workflows, GPU-accelerated inference — map directly to enterprise use cases. Whether you’re building internal tooling or customer-facing AI features, the patterns transfer.
• Honest trade-off discussions. The speakers don’t shy away from the hard questions: When do you need serverless GPUs versus dedicated compute? How do you handle agent failures gracefully? What does it actually cost to run these systems at scale?

Watch On-Demand, Build at Your Own Pace

Every session is available on-demand. You can watch, pause, and build along at your own pace, no need to rearrange your schedule. The full playlist is available at https://www.youtube.com/playlist?list=PLmsFUfdnGr3znh-5zg1xFTK5dmaSE44br

This is particularly valuable for technical content. Pause a session while you replicate the architecture in your own environment. Rewind when you need to catch a configuration detail. Build alongside the presenters rather than just watching passively.

What You’ll Walk Away With

After working through the series, you’ll have:

• Practical agent development skills — how to design, orchestrate, and deploy AI agents that handle real-world complexity, including state management, failure recovery, and human-in-the-loop patterns
• Production architecture patterns — battle-tested approaches for deploying AI workloads on Azure Container Apps, leveraging NVIDIA GPU infrastructure, and building resilient distributed systems
• Infrastructure decision-making confidence — a clearer understanding of when to use serverless GPUs, how to optimise inference costs, and how to choose the right compute strategy for your workload
• Working code and reference implementations — the sessions are built around live coding and sample applications (like the Travel Planner agent demo), giving you starting points you can adapt immediately
• A framework for continuous learning — with new sessions each month, you’ll stay current as the AI platform evolves and new capabilities emerge

Start Building

The AI applications that will matter most aren’t the ones with the flashiest demos — they’re the ones that work reliably, scale gracefully, and solve real problems. That’s exactly what this series helps you build.

Whether you’re designing your first AI agent system or hardening an existing one for production, the AI Apps & Agents Dev Days sessions give you the patterns, tools, and practical knowledge to move forward with confidence.

Explore the series at https://developer.microsoft.com/en-us/reactor/series/s-1590/ and start watching the on-demand sessions at https://www.youtube.com/playlist?list=PLmsFUfdnGr3znh-5zg1xFTK5dmaSE44br

The best time to level up your AI engineering skills was yesterday. The second-best time is right now and these sessions make it easy to start.

When the first OWASP Top 10 list was released in 2003, no one knew that subsequent editions of the top 10 security risks for web applications would become a de facto standard, used and referenced around the world. A Google Scholar search for references to the list yields tens of thousands of results, and helped establish standards such as PCI DSS (Payment Card Industry Data Security Standard), while several national security bodies reference it directly.

After the initial 2003 version, the next edition came one year later. Then the project first switched to a three-year cadence (2007, 2010, 2013) and later to a four-year cadence (2017, 2021). If you do the math, you may have already guessed that a new edition of the OWASP Top 10 was due for 2025, and the project team delivered! Just in time, you might say, since the final version was not released before Dec 24, 2025, but now we have the 2025 OWASP Top 10. Let's have a look at how the list has been assembled, its relevance today, and of course, what's in the list!

I’ve been spending a lot of time thinking about how agents actually work under the hood, and one of the key insights I keep coming back to is this: the right context, injected at the right time, is what makes an agent useful. Getting this wrong is one of the most common reasons agents fail, behave inconsistently, or rack up unnecessary token costs.

Defining an Agent

Let me start with how I define an agent:

Agent = Harness + LLM + Directive

• The LLM is the language model doing the reasoning.
• The Directive is the system prompt, instructions, or persona that shapes how the LLM behaves.
• The Harness is the code that orchestrates everything — it manages the conversation loop, calls tools on behalf of the LLM, injects context, and routes the final result back to the caller.

Most of the interesting complexity lives in the Harness.

The Harness-LLM Loop

In most agent implementations, the Harness drives a loop where it calls the LLM, handles any tool calls the LLM requests, and feeds the results back in. Here’s the high-level flow:

1. Harness calls the LLM with the user prompt (plus the list of available tools and any other context).
2. LLM returns a result — this may be a final answer, or it may include one or more tool calls embedded in the response.
3. Harness executes the tool calls and returns the results back to the LLM as a new call, along with the full conversational history up to that point.
4. LLM returns another result — again, this may include more tool calls or may be a final answer.
5. This repeats until the LLM produces a final answer with no more tool calls, or until the Harness hits a configured iteration limit.
6. Harness relays the final result back to the original caller.

Each iteration through this loop, from user prompt to final result, is often called a “turn.”

One critical detail at step 3: when tool calls fail, the Harness should return detailed failure information — not just an error code, but a human-readable explanation of why it failed. The LLM uses that information to decide whether to retry, try a different approach, or surface the problem to the user.

The Harness Must Provide Context at the Right Time

The Harness needs to inject the right context at each step, and the timing matters:

• At the start of a turn, the Harness must provide the LLM with the list of available tools plus the user prompt. Without the tool list, the LLM doesn’t know what capabilities it has. Without the user prompt, it doesn’t know what it’s trying to accomplish.
• At each subsequent call, the Harness must provide the tool list again, the results of the tools just called (successes and failures), plus the full conversational history leading up to that point. The LLM doesn’t retain memory between calls — all relevant history has to be in the prompt.

Miss either of these, and the LLM either makes things up or gets confused about what it was doing.

Context Optimization Is Hard

Here’s where things get genuinely difficult: the Harness can’t always predict what tools the LLM will want to call, yet it also needs to minimize the amount of context it passes on each call. Token limits are real, and bloated prompts slow things down and cost more.

The tension looks like this:

• Pass too little per-tool detail and the LLM will call the wrong tool — it’ll pick the closest-sounding one and hope for the best.
• Pass ambiguous or incomplete parameter schemas and the LLM will hallucinate details to fill in the gaps. This leads to calls that look syntactically correct but are semantically wrong, and these failures can be hard to diagnose.
• Pass too much and you hit token limits or slow everything down with unnecessary context.

The Harness needs to provide enough tool descriptions, parameter schemas, and example values that the LLM can confidently construct a valid call — but no more than that.

Sometimes this isn’t achievable in a single pass. The LLM may need to make preliminary tool calls just to discover what other tools exist or what valid parameter values look like. This means extra round-trips before it can structure the actual tool call it was trying to make. This is expected behavior, not a failure — but a well-designed Harness and tool set can minimize how often it’s necessary.

MCP Aggregators and the Context Trade-off

This is one of the reasons MCP gateways and aggregators (like my mcp-aggregator) are useful. Instead of the Harness maintaining direct connections to many MCP servers and loading all of their tool details into every prompt, an aggregator acts as a single endpoint. The Harness exposes a small number of meta-tools — things like “list available servers” and “get tools for this server” — and the LLM makes targeted discovery calls when it needs details about a specific capability.

The trade-off is more round-trips between the LLM and the Harness. But the payoff is significantly smaller context payloads on most calls, because you’re only loading the details of tools that are actually relevant to the current task.

Whether that trade-off is worth it depends on the number of tools in play and how many of them are actually needed for a typical request. For a Harness wired up to a small number of tightly scoped tools, direct connection and full context may be fine. For a Harness with access to dozens of MCP servers and hundreds of tools, aggregation usually wins.

Why This Matters

If you’re building agents — or trying to understand why an agent you’re using behaves a certain way — understanding the Harness-LLM loop is essential. A lot of what looks like “the AI being confused” is actually the Harness not providing the right context at the right time.

The key concepts to internalize:

• The Harness owns context management. The LLM is stateless; every call starts fresh. The Harness is responsible for building up and injecting the history, tool lists, and results that give the LLM the information it needs.
• Turns have structure. Each turn starts with user input, may involve multiple LLM-Harness round-trips, and ends when the LLM produces a final answer.
• Context injection timing determines quality. The same LLM with the same Directive can produce dramatically different results depending on what the Harness puts in the prompt and when.

Once these concepts click, you’ll have a much clearer picture of how to build agents that actually work — and how to debug them when they don’t.

Microsoft told Windows Latest that it’s rolling out a new feature that allows you to skip forced Windows 11 updates during device setup (out-of-box experience).

Right now, when you clean install or reinstall Windows 11, or buy a new device, you have to go through a long out-of-box experience, also called OOBE. During the OOBE setup, Windows nags you to set up a Microsoft account, buy Microsoft 365, try Xbox Game Pass, and more.

While it’s unclear when the calmer OOBE without upsells will begin rolling out, Microsoft is already curbing one of the more annoying aspects of the experience: forced updates.

As you might be aware, OOBE goes beyond just upsells and forces you to install newer updates before you can use the device. This can be frustrating, especially if you’re excited to try new hardware right after unboxing it.

I ran into this recently. Last week, I gifted myself an ASUS ROG Ally, and as someone who loved the PSP, I was excited to jump into games on my new handheld running Windows 11. But as soon as I booted it up, Windows forced me to install all pending updates, and I couldn’t play anything for nearly an hour. It completely killed the excitement.

Thankfully, Microsoft says it’s aware of the issue and has been testing a new “Update Later” toggle in OOBE.

The feature was first spotted earlier this year, and it’s now available for everyone in production. All Windows 11 ISOs and recent cumulative updates include the new “Update Later” toggle.

When you click “Update Later,” OOBE instructs Windows 11 to keep checking for updates in the background without disrupting the initial setup experience.

This allows you to go straight to the desktop. Of course, only after you’ve gone through the usual prompts and nudges to set up a Microsoft account.

After booting to the desktop, you can open Windows updates and manually pause updates or choose to finish applying all the pending updates.

Microsoft is also testing a calendar view that allows you to pause updates for as long as you want.

It’s worth noting that this change isn’t live yet, and calendar view is currently broken in the preview builds where we tested the feature, but it’ll begin rolling out to everyone in the coming weeks.

Microsoft could drop the Microsoft account requirement and reduce upsells in OOBE

In addition to greater control over Windows updates, Microsoft’s senior leadership has suggested that the company is mulling an update that would remove the Microsoft account requirement.

Right now, Windows 11 forces you to set up your PC with a Microsoft account, especially when you use Windows 11 Home. Of course, you can always use Command Prompt, and one of the scripts/commands can help you bypass the requirement and set up a local account, but it’s not the ideal experience, and it’s becoming increasingly difficult.

My Samsung phone also nags me to set up a Google and Samsung account during setup, but I always have the option to skip.

You don’t have this experience on Windows 11, but that could change soon, only if the rest of the executives in top leadership agree with the idea.

Moreover, Microsoft has admitted that Windows 11’s OOBE has upsells (ads to promote Microsoft products). In fact, Microsoft recently added web-based Copilot to the OOBE experience, so you could interact with AI while Windows finishes setting up.

Microsoft is looking into ways to improve the OOBE experience, which is why the Copilot integration won’t roll out widely. But it doesn’t mean the company will drop all upsells in the OS. Instead, it plans to reduce upsells and make the first setup experience calmer, at least better than what we have currently.

How do you think Microsoft should redesign the current OOBE experience of Windows 11? Let me know in the comments below.

The post Tested: Windows 11 setup screen now finally lets you skip forced updates, and go directly to the desktop appeared first on Windows Latest