CSS work with AI fails when the model can't see the runtime — and migrations fail when nothing gates the pixels. This module teaches runtime-context debugging with DevTools AI, codemod-plus-LLM hybrid migrations gated by visual regression, evidence-backed token sweeps, agent-driven responsive audits, and i18n pipelines with human gates.
Rohan inherits the styling backlog at a travel-booking product: a six-year-old Sass module system, a mandate to land on Tailwind v4, and a "while you're in there" list — token drift, broken tablet layouts, and a Hindi localization commitment for Q4.
He hands the LLM a Sass file: "convert to Tailwind v4." The output compiles. He merges four components on a Friday.
Support tickets: the fare-comparison table lost its zebra striping, and the booking card's hover elevation vanished. The LLM had silently dropped a nested &:hover and misread a Sass variable that shadowed a CSS custom property.
Nothing in the pipeline looked at the pixels. Type-checks passed, lint passed — and the UI regressed, because CSS correctness is visual, and no gate was visual.
New pipeline: the official upgrade tool does the mechanical conversion, the LLM handles only the ambiguous residue, and every step is gated by Playwright screenshot diffs. The same two regressions reappear in the diff report — as red rectangles, before merge, in seconds.
Rohan's Friday merge is the canonical styling-migration failure: delegating a visual transformation to a textual pipeline with no visual gate. Everything in this module is a variation on the fix — put the runtime, the pixels, or a human gate back into the loop. CSS debugging moves from paste-code-and-pray to AI that reads the live element. Migrations run as codemod-plus-LLM hybrids where deterministic tools do the bulk and screenshots adjudicate every step. Token sweeps and i18n externalization run repo-wide with per-change evidence. And localization — the most global-facing styling work there is — gets LLM speed with pseudo-localization and native-speaker gates, because "the model speaks Hindi" is not a QA strategy.
Pasting CSS into a chat window strips it of everything that determines its behavior: the cascade, computed values, the box tree, stacking contexts, container sizes. The model then debugs a fiction. Chrome DevTools AI assistance inverts this — you right-click the live element and the model receives its actual computed styles, box model, and ancestry, which transforms answer quality on exactly the bug classes that eat frontend afternoons:
transform created a context; invisible in pasted CSS, obvious in the live tree.min-width: auto strikes again), why a track collapses; the model sees actual computed sizes.When DevTools AI isn't available (region, policy, or you're in Firefox-only territory), approximate the same discipline manually: copy the element's computed styles and relevant ancestor chain out of the inspector and give your assistant that. The rule is the same either way — the model debugs the runtime, or it debugs a guess.
DevTools AI assistance answers are hypotheses with better grounding — not verdicts. Confirm the mechanism it names by toggling the property it blames before writing the fix. Runtime context removes the model's biggest handicap; it does not remove yours: the temptation to accept the first fluent explanation.
Every big styling migration — Sass to Tailwind v4, v3 to v4, CSS modules consolidation, and its JS sibling, classes-to-hooks — has the same anatomy: a large mechanical majority a deterministic tool converts perfectly, and an ambiguous residue requiring judgment. The pattern that survives production:
react-codemod — for everything it can do. Deterministic transforms don't hallucinate, don't tire, and produce reviewable, uniform diffs. Using an LLM for what a codemod can do is paying hallucination risk for nothing.Classes-to-hooks modernization follows the identical shape with one addition from M2: RTL characterization tests pinned before conversion, because lifecycle-to-effect translation changes timing semantics that screenshots can't see. Codemod the mechanical, LLM the ambiguous state semantics, and let tests plus pixels adjudicate together. Lab 04 runs the Tailwind version with two seeded visual regressions — the pixel gate must catch both.
Real-world migration write-ups (including the Preact/Tailwind case study in this track's research) converge on one finding: LLMs plan migrations impressively and then fail on configuration edge cases — plugin options, content paths, variable shadowing. The plan is a genuine accelerant; the per-step verification is non-negotiable. Trust the itinerary, check every landing.
Design-token consolidation — hunting hardcoded #6b7280s and 13pxs across a codebase and mapping them to tokens — is ideal AI work if structured as evidence-plus-approval rather than bulk rewrite. Have the agent inventory every off-token value with file, line, and rendered context; propose a mapping per instance (#6b7280 → --color-text-secondary) with its reasoning; then you approve per mapping — because the judgment call (is this actually text-secondary, or a coincidentally identical border color?) encodes design intent no model can read from hex values. Approved mappings apply mechanically; the visual-diff gate from the migration pattern catches the inevitable few where "identical value" wasn't "identical meaning."
Retrofitting responsiveness onto a desktop-first surface starts with knowing what's broken where — historically a tedious manual matrix of viewports times pages. An agent driving a real browser (chrome-devtools-mcp or Playwright) does the audit tirelessly: resize through 360/390/768/1024/1280, screenshot every page at every width, and catalog the breakage — overflowing tables, clipped controls, layout collapses — into a findings list with screenshots attached.
Every page × every breakpoint, screenshotted and cataloged in one run. The agent flags horizontal overflow, elements below minimum touch-target size, and text collisions. Output: a prioritized breakage inventory with visual evidence — the map you never had time to draw by hand.
Container queries where component context beats viewport context; clamp() for fluid type and spacing; grid auto-fit/minmax for collapsing layouts. AI drafts fixes per finding; you sequence them (shared layout components first) and the multi-viewport screenshot suite — now your permanent regression gate — verifies each.
Localization has two AI-accelerated halves with very different risk profiles.
Externalization is repo-scale mechanical work with conventions: find every hardcoded UI string, generate a key per your naming scheme (checkout.summary.fareTotal, not text_47), wrap it in the i18n API, and flag hazards — concatenated fragments that won't survive word-order changes, missing pluralization, interpolated variables without context. Agents sweep this well precisely because your conventions can be stated in the instruction file; the human pass reviews the hazard flags, which are where real i18n bugs live.
Translation is where teams get burned, because LLM fluency masks contextual failure. Research (Lingoport/RWS) is blunt: LLM UI-string translation works only with context — a bare string like "Book" is untranslatable without knowing it's a verb on a button in a travel app. The pipeline that works:
| Stage | What happens | Gate |
|---|---|---|
| Context assembly | Strings + screenshots + flow notes ("verb, button, booking flow") packaged per batch | String owner reviews context completeness |
| LLM draft | Model translates with context; flags uncertainty and untranslatable idioms | — |
| Pseudo-localization | Expanded pseudo-strings (~40% longer, accented) run through every screen | Layout: no truncation, overflow, or clipped RTL |
| Native review | Target-market speaker reviews drafts in the UI, not a spreadsheet | Ship gate per market |
Pseudo-localization deserves its underused reputation-rescue: it catches the layout half of i18n failure (German compounds, Tamil script height, RTL mirroring) before a single real translation exists, and an agent can run the pass across every screen mechanically.
The native-speaker gate is not bureaucracy — it is where "technically correct" meets "actually usable." LLM Hindi is grammatical; whether your users expect Hindi, Hinglish, or English UI labels for travel-domain terms is a product decision a model cannot make. Budget the reviewer; it is the cheapest line item in the entire pipeline.
This module's playbooks: pb-16 (CSS Debugging with Runtime Context), pb-17 (Tailwind v4 Migration: Codemod the 80%, LLM the 20%), pb-18 (Responsive Retrofit via Agent-Driven Multi-Viewport Audit), pb-19 (Legacy React Modernization with Test Pinning), pb-20 (i18n Externalization Sweep), and pb-21 (Context-Rich LLM Translation with a Human Gate). Lab 04 is the proving ground: a six-component Sass-to-Tailwind-v4 migration slice with two seeded visual regressions that your Playwright pixel gate must catch before the PR passes. The token-sweep discipline returns as pb-14 in the design-to-code stage.
Styling work with AI is safe exactly when the loop contains the thing being changed: the live element for debugging, pixel diffs for migrations, per-mapping evidence for token sweeps, screenshots for responsive audits, and native speakers for translation. Text-only pipelines for visual work are how zebra stripes vanish on a Friday.