The Man Who Invented Selenium Also Built Its Replacement

There's a specific kind of credibility that comes from someone destroying their own creation.

Jason Huggins built Selenium in 2004. It became the foundation of an entire industry; the WebDriver protocol he helped establish is still a W3C standard, running underneath a huge share of the world's test automation two decades later. So when Huggins is the one leading the charge on Vibium AI, a framework built on the premise that we shouldn't be writing test scripts at all anymore, it's worth paying attention to — not because it's guaranteed to win, but because the person most qualified to know exactly what's wrong with Selenium is the one saying so.

That's the real story behind the current three-way argument in test automation: Selenium, Playwright, and Vibium AI aren't just three tools competing for the same job. They're three different eras of the same underlying question — how much of testing should be code, and how much should be intent.

Selenium: What Made It the Standard Is What's Breaking It

Selenium's architecture is simple in a way that was radical in 2004 and is starting to look dated in 2026: a script sends commands through the WebDriver API to a browser-specific driver, which executes them in the actual browser. That client-server model gave Selenium unmatched cross-browser reach and two decades of community-built tooling. If your problem is obscure — an old Internet Explorer build, a weird enterprise browser config — Selenium is often still the only real answer.

But that same architecture is the source of its two biggest modern liabilities. First, speed: every command round-trips through the WebDriver layer, and that overhead adds up fast at scale. Second, and more painfully, brittleness. Selenium tests rely on static locators — an XPath, a CSS selector, an element ID. Change submit-btn to btn-primary-submit during a routine UI refactor, and the test doesn't degrade gracefully; it just fails. The script has zero contextual understanding of what it's looking for; it's matching a string, not an intent. Add in the ritual of manually inserting explicit and implicit waits to handle async behavior, and you get a maintenance tax that eats a disproportionate share of QA engineers' time — not finding bugs, just keeping the tests alive.

Playwright: Faster, Smarter, Still Fundamentally Code

Playwright, Microsoft's answer to Selenium's architectural ceiling, fixes a lot of this by abandoning the WebDriver protocol entirely in favor of direct browser communication via the Chrome DevTools Protocol (and equivalent direct connections for Firefox and WebKit). That bidirectional channel is what makes Playwright's signature feature possible: auto-wait, which checks whether an element is attached, visible, stable, and interactive before acting on it — eliminating most of the manual sleep-and-hope waiting that plagues Selenium suites.

It's also fast in a way that changes how teams work, not just how fast a single test runs. Isolated browser contexts spin up in milliseconds, which means genuinely parallel execution at a scale Selenium's heavier instances can't match.

What Playwright doesn't solve is the fundamental premise: it's still a code-based tool, still built around selectors — smarter, text — and role-based selectors, but selectors nonetheless — and still vulnerable when a UI gets a real overhaul rather than a minor tweak. It makes testing better for people who already know how to write code. It doesn't change who gets to write tests in the first place.

Vibium AI: Testing By Describing, Not Scripting

This is where Huggins' project comes in, and where the premise shifts entirely. Vibium AI drops explicit locators altogether, using LLMs and computer vision to interpret a page the way a human would — visually, contextually, semantically. Instead of writing find element ID email-input, type [email protected], find XPath //button[text()='Login'], click, you write: "Log into the application using the standard test credentials and verify the dashboard loads."

The model reads the rendered page and the underlying structure together, infers what a login form looks like even if yesterday's deploy rewrote every class name, and adapts if a button moved sides or got renamed. This is "intent-based testing" — sometimes called vibe coding for QA — and its appeal is obvious: locator-based maintenance, the single biggest recurring cost in test automation, mostly disappears. It also collapses the skill barrier. Anyone who can describe a user flow in plain English can, in theory, write a test.

The catch is that Vibium AI is, as of today, closer to proof-of-concept than production infrastructure. Live LLM inference is slow relative to a scripted click — a Playwright action measured in milliseconds can become a twenty-second reasoning process for an AI agent, which is a serious problem at the scale of a five-thousand-test regression suite running in CI. And LLMs hallucinate. In an ambiguous UI, an agent can click the wrong thing entirely — which is disqualifying for a discipline where a passing test is supposed to mean the software works, not that the model made a good guess.

Watching All Three Handle the Same Messy Checkout Flow

The theory is clearer with a concrete case: an e-commerce checkout where a cart icon loads asynchronously and a promotional modal can interrupt the flow unpredictably.

Selenium needs an explicitly scripted wait for the cart icon, plus custom handling for the promo modal — check if it appeared, find the close button, click it, resume. Change that close button's ID in a routine deploy, and the whole checkout test blocks the pipeline.

Playwright handles the async loading natively via auto-wait, and can go a step further by intercepting the network request that triggers the modal so it never renders at all — a cleaner test environment, but still requires an engineer to write the interception logic and define the locators.

Vibium AI just gets the instruction: "Add the first available laptop to the cart, proceed to checkout, dismiss any promotional popups, and enter generic shipping details." It reads the screen, clicks the laptop, starts checkout, recognizes the modal as an obstruction when it appears, and dismisses it — zero lines of code written by a human.

So Which One Actually Wins?

It depends on what you're optimizing for, and the honest answer splits by category:

• Speed and reliability: Playwright, clearly — direct browser communication and isolated contexts beat both WebDriver overhead and LLM inference latency.
• Maintenance burden: Vibium AI, in theory — removing locators removes the root cause of most test breakage, though Playwright is a real improvement over Selenium here too.
• Enterprise readiness: Selenium and Playwright, tied — both have the CI/CD ecosystem, the security posture, and the deterministic reporting that large orgs need. Vibium AI, being experimental, doesn't yet.
• Accessibility: Vibium AI, decisively — plain-English prompting needs no dedicated SDET, while Selenium and Playwright both do.

No single tool wins outright, because the industry is really asking for two things that don't currently live in the same product: Playwright's execution reliability and Vibium AI's near-zero maintenance overhead. Open-source frameworks — either one — only ever hand you the execution engine. The reporting, the parallel cloud infrastructure, the test data management, the CI integrations: that's all separately built and maintained cost, and it's the real reason "free" tooling has a total cost of ownership that rarely feels free by year two.

Where This Actually Goes Next

The interesting part isn't which of these three wins outright — it's that the gap between them is exactly the gap the next generation of tooling is being built to close: deterministic, enterprise-grade execution combined with intent-based, no-code authoring, rather than a tradeoff between the two.

Huggins spent two decades making the world write better scripts, then spent the last chapter of that arc arguing scripts were the wrong unit of work all along. Whether Vibium AI itself is the tool that ends up mattering, or just the provocation that pushes the rest of the industry to catch up to the idea, the argument it's making is hard to unmake once you've seen the checkout-flow example above. Test automation spent twenty years teaching humans to think like machines. The next stretch is about whether tooling can finally handle it the other way around.