Last week in Hangzhou, AI dragged me back to old-school code again

At 10 p.m., I was staring at the popup code it had generated. The browser could already handle the overlay and focus, yet the code still packed in a long script. The page worked, but maintenance costs were back. I had fallen into this “if it runs, good enough” trap before, and eventually learned that rework often starts with choosing the wrong tool.

It isn’t a chat box that writes code for you—it’s a browser development knowledge pack

The Google Chrome team opened up more than 200 practical guides and worked with people from Firefox, Edge, and MDN to organize them. In plain terms, it tells AI to check what the browser already supports before falling back on patterns from more than a decade ago—for features such as popups and automatic text-field expansion. In the team’s own tests, the share of AI-generated pages that passed checks rose from 55% to 92%. That figure came from their test tasks, so nobody should assume everyone will see the same lift.

Replicating it today costs little more than time and one installation

Money: The guide is open source and costs ¥0. If I already have an AI coding tool, I usually don’t need another purchase. Time: I spend 20 minutes reading the project instructions, then test it with one real page, which takes about one hour. Technical barrier: Complex configuration isn’t required, but I need to understand web files. If I’m comfortable with code, I can do it myself; if not, I’d ask a developer or AI assistant for help. First step: Open the project’s GitHub page, follow the installation instructions in the README, select the AI coding tool I use, then run a comparison test with an old popup page.

Here’s how I’d stage it, depending on where I’m

If I’m just starting and have only a few pages, there’s no rush to try this. Getting client requirements working matters more for now. When I’m ready to revise the company website, I can have AI process one page under the guide and see whether it cuts the script. If I already have one or two clients, I can list the existing pages and trial the guide on just one component that keeps breaking, rather than changing everything at once. If I’m scaling, I’d standardize this check first, record code size and maintenance time before and after, then decide whether to add it to the team workflow. It isn’t essential for everyone: if the team has no frontend developers and nobody carries the burden of maintaining the site, the gains may not justify the learning cost. I might bookmark it and try it the next time I revise a page.