Modern Web Guidance 1.0: Scan Legacy Frontend Code Before Your Agent Rewrites It

Modern Web Guidance 1.0 adds a legacy-code scanner to Google's coding-agent skills. It can identify frontend patterns worth replacing with modern browser features, then give an agent the relevant implementation guidance. Start with a small folder and a reviewable plan rather than asking it to modernize your entire application.

That distinction matters because old code often encodes a requirement nobody wrote down. A resize listener might support an older browser, or it might be unnecessary work copied from another component. A useful agent needs to tell those cases apart before deleting anything.

Install the guidance and set a browser target

The Chrome installation guide recommends the package's interactive installer. Run it from the project where you want the skills available:

npx modern-web-guidance@latest install

For an existing installation made through that CLI, the documented update command is:

npx modern-web-guidance@latest update

Choose your browser-support target before using the resulting recommendations. The guide says an unspecified target defaults to Baseline Widely available. You can state a specific Baseline year in the project's AGENTS.md or CLAUDE.md, but choose it from your actual support policy rather than copying a year from a tutorial.

For example, a customer portal with managed enterprise browsers may need a more conservative policy than an internal prototype. Write that constraint down alongside any required embedded webviews. A feature working in your own Chrome installation does not settle compatibility for either audience.

Run a scan before requesting edits

The modernization workflow requires version 1.0 or later. Its documented scan can return structured findings without automatically applying a fix:

npx modern-web-guidance@latest legacy-scan src/components --json

The scanner uses local parsers to find candidate patterns. The subsequent agent review checks the surrounding code against each rule's keep-or-discard guidance. Google explicitly does not provide a blanket fix flag, and automated CI/CD integrations are still described as in development.

I would keep the first request narrow:

Use Modern Web Guidance to inspect src/components/forms.
Scan for legacy patterns, then verify each match against nearby code
and our documented browser support policy. Do not edit files yet.
For each retained finding, show the current behavior, proposed replacement,
necessary fallback, and tests that would demonstrate equivalent behavior.
Keep uncertain cases as questions rather than guessing.

This is an example workflow, not a claim that I ran the tool against a production repository. It gives the agent a concrete deliverable you can reject before the task becomes a large diff.

Work through one textarea, not fifty files

Consider a support form that grows its textarea as a user types. Google's guide lists JavaScript scrollHeight-based auto-resizing as a candidate for CSS field-sizing. That makes it a useful first inspection, but a string match alone is insufficient: scrollHeight might also belong to a virtualized list.

For the textarea, record its minimum height, maximum height and overflow behavior before requesting a replacement. Then check whether the suggested native feature meets your browser target and whether a fallback already exists. If it does, removing that fallback merely to satisfy a scan would make the application worse.

A sensible review table for this single change looks like this:

Check	Evidence to collect
Empty field	Starting height and placeholder remain readable
Long pasted text	Maximum height and scrolling still work
Keyboard use	Focus, editing and submission behavior remain intact
Supported browsers	Native path and fallback both behave as intended
Layout	Nearby controls do not jump or become unreachable

These are acceptance criteria, not predicted test results. Once the edit passes them, inspect whether any dependency or listener is genuinely unused before removing it.

When the agent ignores the skill

Installing a skill does not prove that the agent invoked it. The troubleshooting documentation recommends explicitly naming Modern Web Guidance and checking the tool output for the expected search and retrieval calls.

If the agent produces an answer without fetching the relevant guide, ask it to show which guide it used. If the wrong feature appears, describe the behavior more precisely. “Keep a form field sized to its contents” is a more useful request than “make this modern.”

For a folder-wide audit, request a scan. For a named individual component, the documented workflow can instead perform a normal guide lookup. Those are different operations, so a missing scan is not automatically an installation failure.

Local scanning does not mean no telemetry

The repository's privacy section says Google collects usage information including guide IDs, calling-agent names and agent-generated CLI search queries, though not raw user prompts. It documents DISABLE_TELEMETRY=1 as the opt-out.

If you need that setting, apply it to the environment that launches the commands. Also remember that package installation or updates can use the network, and your coding agent has its own data-handling rules. The local scanner does not change those rules.

The useful outcome is a smaller, better-supported implementation with evidence that it still works. A long list of replaced APIs is a poor success metric if the refactor creates a browser regression that your original code had already solved.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain their engineering decisions through clear developer stories and useful product content.

Book a 30-minute call.