Vibathon AI: The Browser Automation Extension That Refuses to Break

It records actions, but it also fingerprints elements, resumes workflows across page loads, encrypts sensitive data locally, and turns messy event logs into something a human can edit.

9 min read • View on GitHub • More from LikhithBellamkonda

A browser window drawn like a machine workshop, with a selector compass aimed at a form field and several redundant identity clues converging on the same target. One path looks cracked, but backup signals still lead to the right element, explaining how the extension keeps working when the DOM shifts. — Vibathon’s core idea is resilience. It does not trust one brittle selector when several weaker clues can agree on the same element.

Key Takeaways

Vibathon’s most interesting idea is not recording, but re-identifying elements after the page changes.
Its selector engine treats one click as a bundle of clues, then ranks live candidates instead of trusting a single CSS path.
The extension pairs local encryption and resume logic with AI-generated workflow summaries, so it behaves more like a browser operator than a macro recorder.
The trade-off is clear: it is ambitious and clever, but still shows prototype-era edges that matter for real-world trust.

Browser automation usually breaks in the same boring way. A label changes. A page re-renders. A CSS selector that worked yesterday now points at the wrong thing, or nothing at all.

That is the failure mode Vibathon AI is trying to escape. The project treats each recorded interaction as a bundle of identity signals, then uses those signals to recover the right element when the live DOM drifts.

The brittle-selector problem, solved from the inside

Most record-and-play tools capture a single path and hope the page behaves. Vibathon does something smarter. Its selector engine builds a richer fingerprint from attributes like aria labels, roles, text variants, placeholder text, title, and a bounded CSS path.

At replay time, it does not ask, “Does this exact selector still exist?” It asks, “Which live element best matches the identity I recorded?” That shift is the whole product thesis.

The engine works like a weighted search, not a brittle lookup. It scores several clues at runtime and resolves the best candidate when the page has moved under it.

Approach	What it stores	What happens when the page changes
Single CSS selector	One path	Usually fails fast.
Multi-signal identity	Labels, text, role, attributes, and path depth	Can recover when one clue drifts.
Heuristic scoring	A ranked set of candidates	Chooses the best live match instead of a dead reference.

What Vibathon records is not just clicks

The recorder is trying to preserve context, not just motion. A click on a button is not only a coordinate or selector. It is also the nearby text, the accessible label, the semantic role, and whatever attribute hints the page exposes.

That matters because modern apps are noisy. React and Vue can redraw the tree, forms can duplicate markup, and the visible wording can stay stable while the underlying structure shifts. Vibathon’s capture layer seems designed for that imperfect reality.

// Conceptually, Vibathon records more than one path to the same element.
const selectorSignals = {
  id: el.id,
  ariaLabel: el.getAttribute('aria-label'),
  role: el.getAttribute('role'),
  text: el.textContent?.trim(),
  placeholder: el.getAttribute('placeholder'),
  title: el.getAttribute('title'),
  cssPath: buildCssPath(el, 5)
};

That is the difference between a macro and a model. A macro remembers a gesture. Vibathon remembers enough about the target to find it again.

A close-up of a glass vault inside a browser, with a password entering from the left, turning into an encrypted shard in the middle, and landing in local storage on the right. A small key chip sits above the vault, showing that the system keeps the key on device rather than sending it to a cloud service. — The privacy story is architectural. Sensitive data is encrypted before storage, and the key lives locally instead of being handed to a server.

The selector engine is the real product

Inside the repo, the interesting part is not that selectors exist. It is that they are scored. Functions like generateSelectors and scoreElement turn matching into a heuristic problem, which is exactly what web automation needs once the DOM stops being predictable.

The research points to weighted clues such as ID matches, aria label matches, and similarity checks. That is a practical choice, not a research-paper flex. You want something simple enough to run inside a content script, but flexible enough to survive minor markup drift.

A vibathon is a shorter, more intense version of a hackathon that prioritizes speed, creativity and the use of AI tools to accelerate innovation.

Forbes, Publication · Vibeathons Are Taking Over Hackathons

Signal	Why it helps	What breaks it
ID	Fast and precise when stable	Refactors and dynamic IDs.
ARIA label	Tracks accessible intent	Sites that ignore accessibility semantics.
Visible text	Human-readable and robust	Copy changes or localization.
CSS path depth	Useful as a fallback	Layout changes and inserted wrappers.

Sensitive data stays local

Vibathon does not treat passwords like ordinary text. The research describes an AES-256-GCM flow in which sensitive input is encrypted before it lands in storage, with a locally persisted raw key so the browser can decrypt it later.

That choice matters because it changes the trust boundary. The extension is not asking you to send secrets somewhere else so it can do its job. It is trying to keep the vault on the device.

The caveat is worth saying out loud. Local-first is a design posture, not a guarantee of maturity. A prototype can still make dangerous mistakes, especially if it ships with hardcoded secrets or rough key handling.

AI turns event noise into a workflow model

The AI layer is not there to replace the recorder. It is there to translate. According to the research, analyzeWithGemini takes event logs and turns them into a summary and a structured flowchart, which makes the output editable instead of just replayable.

That is a useful distinction. Raw logs are for machines. A flowchart is for humans who need to understand, edit, and trust the workflow.

This is where Vibathon starts to feel less like a macro tool and more like a coordination layer. The AI is not the product. It is the interface that makes the product legible.

It survives navigation, which is where automation usually dies

The other clever piece is continuity. Browser automation often breaks when a new page load interrupts the flow or when the service worker goes idle. Vibathon appears to address that with alarms, pending-step storage, and a resume path that picks up the workflow after navigation.

That sounds mundane until you have watched a recorder lose its place halfway through a multi-step task. Continuity is not a feature garnish. It is what makes automation feel dependable.

Problem	Typical recorder	Vibathon approach
Navigation break	Execution stops or loses state	Stores pending steps and resumes.
Service worker sleep	Workflow gets stranded	Uses alarms to keep the process alive.
Cross-page continuity	Manual restart	Automatic continuation when the page returns.

Where it sits in the automation landscape

Vibathon is trying to sit between two familiar poles. On one side are plain record-and-play tools that are easy to use but brittle. On the other are scripted stacks like Playwright and Puppeteer, which are powerful but ask for more skill and setup.

Its bet is that you can keep the surface accessible while making the underside much smarter. That is a compelling position if it holds up under real-world page churn.

System	Selector robustness	Workflow editing	Skill required	Best fit
Plain recorder	Low	Basic	Low	Simple repeatable tasks
Playwright or Puppeteer	High	Script-driven	Medium to high	Engineered test and automation flows
Vibathon	Medium to high	Human-editable with AI help	Low to medium	No-code automation that still survives change

That middle position is exactly why the project is interesting. It is not trying to beat scripting at scripting. It is trying to borrow just enough of scripting’s resilience to make no-code automation useful after the first page refresh.

What this project is really testing

The repo reads like a prototype of a local-first browser operator. It combines resilience, privacy, and AI interpretation in one extension, then asks whether those pieces can feel simple enough for non-technical users.

The honest answer is that the ambition is ahead of the polish. The research notes prototype-era rough edges, including a hardcoded API key. That does not weaken the idea, but it does set the maturity level correctly.

Using the GenAI tools available at delaware - such as Copilot, Lovable, Claude or GitHub licenses - the format turns out to be more than just a fun weekend activity: First, it changed how we collaborate.

delaware Belgium, Organization · Vibathon 2026 blog post

That is the cleanest way to think about Vibathon. Not as “a Chrome extension with AI,” but as an attempt to make browser automation less fragile, less opaque, and less disposable.