Lighthouse stops handing you a list and starts handing you a diff

A post on dev.to from frontendfacile describes an agentic integration inside Chrome DevTools in which you can delegate both the running of Lighthouse checks and the start of the corrections to an AI agent, shortening the loop between diagnosis and patch ^[1]. That is a modest tooling change with an immediate process consequence: if the artifact leaving a quality run is a change set rather than a document, the place where a human says yes has to move.

The loop being replaced is familiar. Lighthouse produces a list of failed audits, you copy them out, open the code, fix, and repeat ^[2]. Other audit tools land in the same place: scan, generate roughly 47 problems, hand them back, and for anyone who is not a developer the report becomes a large TODO list ^[14]. The frontendfacile post is explicit that the agent is not a button that makes everything perfect, and that what it absorbs is the mechanical part - gathering the errors, locating the affected code, making the first repetitive edits ^[3].

The two worked examples show why the review question is not uniform. A missing or thin meta description recurs across pages and templates, and an agent can find where it is absent in layouts, templates or specific routes, propose or insert a sensible value, and help avoid duplicates ^[4]. Colour contrast is different in kind: the agent can identify the elements involved, propose more accessible colours, and apply the change to CSS variables or design tokens so the fix happens upstream rather than as a patch on individual rules ^[5]. Editing a token is a product decision wearing the costume of a lint fix. The post's own guidance points the same way - start with high-confidence audits such as metadata, contrast and missing attributes, converge fixes on components and tokens, and keep human review because accessibility and SEO need editorial consistency and product choices ^[6].

The same split appears in OptiQra, an open-source auditor whose author says it crawls, finds problems, explains them, fixes many of them and lets you verify the result ^[7]. Issues that do not need a model are handled deterministically: detect, generate the change, apply, verify ^[8]. Prose fixes require your own provider key, with OpenAI, Anthropic, Groq, OpenRouter, Mistral, DeepSeek and xAI listed ^[9]. The aggressive mode hands a model a whole file plus the detected problems and takes back a rewritten file, guarded by integrity checks that discard results violating structural invariants ^[10]. It can also audit an uploaded project archive, because a live crawl cannot see next.config.js, robots configuration, source files or build configuration ^[11]. Both tools, described independently, end in a verification step rather than an apply-and-forget ^[12].

Practically, that argues for two gates, not one. Deterministic attribute fixes can pass on a machine check. Token edits, generated copy and whole-file rewrites need a named reviewer on the diff, because the failure mode is no longer a missed audit but a plausible wrong answer committed at speed.

Watch where the patches actually land: the frontendfacile post does not say whether the DevTools agent writes to source files or only to the live page ^[13]. Watch the new agentic browsing audit category, which checks whether a site works when the navigation is done by agents rather than people [c14b]. And note OptiQra's author hedging his own GEO and AEO signals - blocked AI crawlers, content hidden behind client-side JavaScript, extractable answers - as still experimental ^[15].