DEV Community

Cover image for 🧩 Runtime Snapshots #10 — The Loop: E2LLM in Production
Alechko
Alechko

Posted on

🧩 Runtime Snapshots #10 — The Loop: E2LLM in Production

#e2llm #cicd #webdev #automation

Your CI is green. Your users can't checkout.

This is the story of every team that trusted tests more than reality.

The Problem With "Ship and Pray"

Traditional deployment flow:

Code → Tests → Deploy → Hope → (Bug report 3 days later)
Enter fullscreen mode Exit fullscreen mode

Tests check if code works. They don't check if users can use it.

A promo banner covering the checkout button? Tests pass.

Mobile layout pushing CTA below the fold? Tests pass.

Third-party widget blocking the form? Tests pass.

All green. Ship it. Break production.

The Loop

We built a different flow:

SHIP  -->  CAPTURE  -->  INTERPRET  -->  FIX  -->  REPEAT
  |           |              |            |           |
  v           v              v            v           v
Code hits   E2LLM        LLM analyzes  Actionable  Every deploy,
production  snapshots    with context  specific    every page
            real UI                    guidance
Enter fullscreen mode Exit fullscreen mode

No screenshots. No guessing. Real state → Real answers.

Step 1: Ship

You merge. CI runs. Tests pass. Deploy triggers.

Nothing new here. The difference is what happens next.

Step 2: Capture

Post-deploy, E2LLM captures what users actually see.

Not the source code.

Not the accessibility tree.

Not a screenshot.

The rendered DOM—with salience scoring.

{
  "page": "/checkout",
  "viewport": "375x667",
  "elements": [
    {
      "selector": "#pay-button",
      "salience": 95,
      "visible": true,
      "occluded_by": "#promo-banner",
      "occlusion_percent": 60
    },
    {
      "selector": "#promo-banner",
      "salience": 70,
      "position": "fixed",
      "z_index": 999
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

This is SiFR—Structured Interface Representation.

~400KB instead of megabytes. Zero schema overhead.

Step 3: Interpret

Feed the snapshot to any LLM. No special integration needed.

Prompt:

Analyze this checkout page snapshot.
Identify any UX blockers for completing purchase.
Enter fullscreen mode Exit fullscreen mode

Response:

CRITICAL: Pay button (#pay-button) is 60% occluded by
promo banner (#promo-banner) on mobile viewport.

Users cannot reliably tap the primary CTA.

Suggested fix: Add margin-bottom to promo banner
or reduce z-index below checkout form.
Enter fullscreen mode Exit fullscreen mode

The model doesn't guess. It sees what the user sees.

Step 4: Fix

You get:

  • What is broken (button occluded)
  • Why it's broken (z-index, fixed positioning)
  • How to fix it (specific CSS change)
  • Where it happens (mobile viewport only)

Not "button might be hard to click."

Not "consider checking mobile layout."

Actionable. Specific. Reproducible.

Step 5: Repeat

This isn't a one-time debug session. It's a loop:

// Post-deploy hook
async function checkDeployment(pages) {
  for (const page of pages) {
    const snapshot = await e2llm.capture(page);
    const analysis = await llm.analyze(snapshot);

    if (analysis.hasBlockers) {
      await alert.send({
        severity: 'critical',
        page: page,
        issues: analysis.blockers
      });
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Every deploy. Every critical page. Automated.

What This Catches 

                          E2E Tests    Visual Diff    The Loop
                          ---------    -----------    --------
Button covered by banner     Pass         Maybe        ALERT
CTA pushed off viewport      Pass         Pass         ALERT
Mobile-only layout break     Miss         Noise        ALERT
Third-party widget overlap   Pass         Pass         ALERT
Font size change            Ignore       500 alerts    Ignore
Enter fullscreen mode Exit fullscreen mode

The difference: we check meaning, not pixels.

Integration Points

The Loop fits into existing infrastructure:

CI/CD:

# .gitlab-ci.yml
post_deploy_check:
  stage: verify
  script:
    - e2llm capture --pages /checkout,/signup,/dashboard
    - e2llm analyze --alert-on critical
Enter fullscreen mode Exit fullscreen mode

Playwright:

await page.goto('/checkout');
const snapshot = await page.evaluate(() => 
  window.e2llm.capture({ selector: 'body' })
);
Enter fullscreen mode Exit fullscreen mode

Monitoring:

// Cron: every hour
const pages = ['/checkout', '/signup', '/pricing'];
await Promise.all(pages.map(p => e2llm.checkAndAlert(p)));
Enter fullscreen mode Exit fullscreen mode

The Mindset Shift

Old: "Tests pass, we're good."

New: "Tests pass, now let's check reality."

Tests verify intent.

The Loop verifies experience.

Both matter. But only one catches the banner blocking your checkout.

TL;DR

Ship → Capture → Interpret → Fix → Repeat

  • Capture real UI state with E2LLM (salience-scored, token-efficient)
  • Interpret with any LLM (Claude, GPT, Llama—your choice)
  • Fix with actionable, specific guidance
  • Repeat on every deploy, automatically

Your tests check if code works.

The Loop checks if users can use it.

👉 e2llm.dev — Free, open source, installs in seconds.

📖 Previous in series: Runtime Snapshots #9 — SiFR Deep Dive

Tags: #e2llm #qa #testing #devops #frontend #cicd #webdev

Top comments (0)