Can Chrome Stop Your AI Agent Writing 2015 Code?

What did Chrome just release for AI coding agents?

As of September 2026, the Google Chrome team ships web platform best practices straight into coding agents. The project is called Modern Web Guidance. Chrome's documentation describes it as "a set of skills that embed web platform expertise, best practices, and browser compatibility data directly into your coding agents."

The problem it targets is one we run into constantly. Ask an agent for a layout and you often get code that would have been sensible in 2015. Float hacks. Wrapper divs three deep. A JavaScript solution to something CSS now handles on its own.

This is Chrome's attempt to fix that at the source, by changing what the agent knows before it writes a line.

What is Modern Web Guidance in plain terms?

It is a bundle of written guidance that your coding agent reads as part of its instructions. Chrome's docs say it "includes best practices for over 100 web development use cases across several core disciplines." Those disciplines cover areas like accessibility, performance, CSS, forms, security and built in UI components.

The delivery method matters more than it sounds. This is not a linter that flags bad code after the fact. It is context handed to the model up front, so the first draft is closer to right.

Chrome maintains it in the open. The source lives on GitHub under GoogleChrome/modern-web-guidance-src, and the docs invite contributions. That is worth knowing, because it means you can read exactly what your agent is being told rather than guessing.

The coverage list tells you who it is for. Chrome's get started page lists areas including user experience, CSS, performance, forms, built in UI components, accessibility, built in AI and passkeys. That is the spread of an ordinary marketing site build, not a niche corner of the platform. Forms and accessibility alone account for a large share of the front end problems we find on sites we inherit.

Why do AI agents write outdated web code in the first place?

Because the web's written record is heavily weighted toward the past. A model trained on years of tutorials, forum answers and blog posts has seen the old way of doing something thousands of times and the new way a handful of times. Volume wins unless something corrects for it.

The platform also moves faster than the writing about it does. A CSS feature can ship across every browser and still have almost nothing written about it, while the workaround it replaced has a decade of Stack Overflow answers behind it.

So the agent is not being careless. It is repeating the most common pattern it has seen. Guidance like this works by putting a smaller, newer, more authoritative voice closer to the model's attention than the old bulk.

What is Baseline, and why does it sit at the centre of this?

Baseline is the shared answer to whether a web feature is safe to use. According to web.dev, Baseline "gives you clear information about which web platform features are ready to use in your projects today." A feature is newly available when it is "supported by all of the core browsers, and is therefore interoperable."

The second tier is the one to care about. web.dev defines widely available as when "30 months have passed since the newly interoperable date," at which point "The feature can be used by most sites without worrying about support." The core browsers are Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS.

Modern Web Guidance ties itself to that standard. Chrome's docs state that "If you install Modern Web Guidance but don't configure a Baseline target for your project, Modern Web Guidance will default to Baseline Widely available." So out of the box it aims for conservative, and you opt into newer features deliberately. We went deeper on this system in our explainer on how Baseline decides what is safe to ship.

How do you install it?

With one command. Chrome's get started page gives the install as "npx modern-web-guidance@latest install." It then writes the guidance into the config your agent already reads, which in practice means a file like AGENTS.md or CLAUDE.md in your project root.

The agent list is broad. Chrome's docs name Claude Code, Gemini CLI, Codex, Copilot CLI, JetBrains WebStorm, Goose, Grok, Kimi Code and Antigravity among the supported tools. If your team standardised on one of those, this is a five minute job.

Setting a Baseline target is the step people will skip. If you never set one, you get widely available, which is the safe default but may be stricter than you need. A team shipping to a modern B2B audience might reasonably target newly available instead and pick up features two and a half years sooner.

Does this actually change what an agent produces?

We do not know yet, and we want to be careful here. Chrome's own documentation does not publish a benchmark showing how much output improves. Several third party posts quote a large jump in best practice adherence from an internal Google test, but we could not find that figure in Chrome's docs, so we are treating it as unverified.

What we can say is that the mechanism is sound. Feeding an agent current, specific, authoritative instructions does change its output, and every team using agents seriously has learned this by building their own version of exactly this file.

That is really the honest pitch. Chrome has written, and will maintain, the guidance document your team was going to write badly and then forget to update. The value is less about a measured lift and more about who owns the maintenance.

Which teams should install this today?

Any team letting an agent touch front end code. That is the whole test. If someone on your team asks a model to build a component, a form or a layout and that output reaches production, the cost of installing this is minutes and the downside is close to zero.

It is most valuable where web platform depth is thinnest. A backend engineer shipping a marketing page, a designer prototyping in code, a product team without a front end specialist. Those are the situations where an agent's bad habits go unchallenged, because nobody in the room knows to challenge them.

It is least valuable to a senior front end developer who already reviews everything closely. They were catching these problems anyway. It just saves them a round of comments.

What does it not fix?

Judgement. Guidance can tell an agent that a native dialog element beats a div pretending to be a modal. It cannot tell the agent whether your page needed a modal at all. The decisions that actually make a site good are still yours.

It also does not fix trust. Stack Overflow's 2025 Developer Survey found that 84% of respondents are "using or planning to use AI tools in their development process" and 51% of professional developers use them daily, yet 46% distrust the accuracy of what those tools produce against 33% who trust it. Better guidance narrows the gap. It does not close it.

And it will not catch a confidently wrong answer about your own codebase. The guidance knows the web platform. It does not know your component library, your design tokens or the reason someone wrote that odd workaround two years ago. Our notes on reviewing AI written code cover where we still read every line.

How does this change how we review AI written code?

It moves our attention up a level. When the obvious platform mistakes stop appearing, review time shifts to the things that were always harder to check. Does this markup describe the content honestly. Does the interaction work by keyboard. Is this the simplest version of the idea.

We would still review everything. What changes is that we expect to spend less time saying "use a grid here" and more time asking whether the section earns its place on the page. That is a better use of a senior person's afternoon.

The practical move is to treat installed guidance as a floor, not a ceiling. Put your own project rules in the same file, because an agent that reads Chrome's guidance will read yours too. That is the same pattern we described in our piece on how web teams use agent skills.

Where is this heading?

Toward browsers documenting themselves for machines as carefully as they do for people. Modern Web Guidance is a browser vendor accepting that a large share of web code is now written by agents, and deciding to write for that reader directly. We expect more of this, and we expect other vendors to follow.

For teams, the takeaway is small and practical. Install it, set a Baseline target on purpose, and keep reviewing. The tooling is getting better at the parts that were never the hard part.

If you want a second pair of eyes on how your team uses agents on front end work, or on code that came out of one, we are happy to talk it through. You can find us at phoenix.studio.