DEV Community: Arun Kumar T

An AI agent can reverse-engineer your entire repo & app in 10 minutes :) Thanks to REA, so I built the REAshield

Arun Kumar T — Sun, 01 Nov 2026 03:19:19 +0000

Right now, while you're reading this, your shipped app is defenseless.

Not "theoretically." Not "if someone really tried." Today, anyone can point an AI
agent at your bundle, walk away, and come back to a clean, plain-English teardown
of exactly how your licensing works, where your pricing logic lives, and how to
tear it out — with the code to do it.

No cracking. No debugger. No late nights in devtools. The agent reads your files,
rebuilds your entire app in its head, and hands the attacker the map.

This isn't a warning about the future. The tools are live. So I built the thing
that fights back, and it's open source. Here's how the attack works, why it's so
devastating, and the exact moves that make it fall apart.

The attacker: a reverse-engineering machine that works for free

REA hands a coding agent a full
reverse-engineering toolbox over MCP. Aim it at your shipped app.asar or bundle
and — without ever running your app — it statically reconstructs everything:
every module, import, route, IPC channel, and string. On a real ~14 MB Electron
app that's a graph of roughly ten thousand nodes. Then the agent reads a
summary of that graph and answers, in English: "here's how feature X works, and
here's the code."

Minutes. For free. At scale. On every app you've ever shipped.

And REA isn't alone

REA is the sharpest example, but it's a category, and the category is growing:

REA — an MCP server that gives a coding agent a full reverse-engineering toolbox. Statically reconstructs an app's whole module/IPC/route graph and lets the agent explain any feature from it.
humanify — uses LLMs to un-minify JavaScript, handing readable, meaningful names back to your mangled code. Your obfuscation's worst nightmare.
webcrack / wakaru — unpack and unminify webpack/bundled JS back toward the original, module-by-module source.

Wire any of these into an agent and the loop runs itself: unpack → rename →
map → explain → clone. The barrier to reverse-engineering your app just dropped
from "a skilled human with a weekend" to "a prompt."

What it eats

Starve the attacker — but first, know the diet. It feeds on:

Your module graph — the literal shape of every import and require.
Your names — every identifier you shipped is a signpost.
Your strings — routes, errors, keys, and IPC channel names.
Your source maps — ship these and you didn't get reverse-engineered. You published your source with a bow on it.

Its fatal weakness — and your entire opening

Here's what they don't tell you: this attacker is terrifying but narrow, and
it confesses its limits out loud.

It is 100% static. It never runs your app. Anything that only exists at runtime is invisible to it.
It will not guess. A name assembled at runtime? It writes "unresolved" and moves on. On a real test app, 14 of ~22 IPC operations with computed names were left blank. Holes in the map.
It buckles at scale, dropping relationships when the graph gets big.

So forget "make it unreadable." Obfuscation is a speed bump a machine rolls over.
The real play: starve the static graph, and bury your crown jewels in the exact
blind spots this attacker admits it cannot see.

Obfuscation is paint, not armor

Minify, mangle, encrypt your strings — sure. Just know it's the weakest,
first-to-fall layer in the stack. LLM-assisted deobfuscation improves every
month, and even with garbage names, your entire structure is still sitting there
for the graph builder to walk. Scrambling names doesn't hide the map.

Real armor, ranked by how long it survives contact:

Don't ship the secret. Move it off the device, period.
Get it off the JS graph. WebAssembly. Bytecode.
Turn static into runtime. Computed imports, computed channels, dispatch tables — the blanks the agent can't fill.
Make every build different. Version-diffing: dead on arrival.
Then obfuscate and drown the rest in decoys.

The shield

REAShield is an open-source, drop-in npm
dev-dependency that turns every move above into one config and one command:

// shield.config.cjs
module.exports = {
  input: "src/index.js",
  output: "dist-shielded",
  preset: "balanced",
  protect: [
    { name: "licenseCheck", mode: "relocate" }, // rip the real body off-device
    { name: "sealedCalc",   mode: "seal" },      // ship it as ciphertext
    { name: "pricingLogic", mode: "wasm" },      // compile it to WebAssembly
    { name: "featureGate",  mode: "obfuscate" }, // harden it in place
  ],
};

npx reashield build     # hardened client + a server skeleton
npx reashield test      # measures what the attacker can STILL see

What each mode does to the agent:

Relocate — the function's real body is lifted out of your app and into a generated server handler. The client keeps one opaque remote-call stub. You cannot graph code that was never shipped. This move never stops working — it's the oldest rule in security, enforced automatically.
Seal — the module ships as ciphertext, decrypted at runtime with a server-fetched key. Static analysis gets a wall of bytes.
WASM — numeric hot-paths compile to a real WebAssembly module (binary, synchronous, behavior untouched). Erased from the JS graph entirely.
Starvation (always on) — one flat module, no source maps, encrypted strings, and literal IPC/route names rewritten into runtime-computed ones: the exact names the agent surrenders on.
Polymorphism + decoys — every build is restructured and renamed so releases can't be diffed, and the graph is flooded with inert fake "feature" clusters so the agent's summary trips over false leads first.

Don't trust it — prove it

This is the part I refuse to hand-wave. REAShield runs the actual attacker
(REA) against your own before/after build and shows you what changed.

On the bundled example — a small library with a license check, pricing logic, and
a sealed scoring function:

Secret strings and protected identifiers left in the shipped client: 6 → 0. The real algorithm and its constants now live only on the server.
String literals surviving verbatim into the output: 100% → 0%.
The import graph: collapsed to a single module.

Run npx reashield test --rea against your own app for REA's own "modules
resolved / relationships resolved" counts, before vs after — and on a real
multi-thousand-node app, that drop is brutal.

Because REA ships constantly, the harness doubles as a CI gate pinned across
REA versions: a new REA that recovers more than your committed baseline fails
the build. Protection stops being a hope and becomes a test.

The honest part — the line that makes the rest credible

I'll say the thing straight, because overclaiming is how security tools die:

Nothing that runs on someone else's machine is truly unreversible. REAShield
doesn't claim to be — and neither should you.

What it actually delivers: it turns a 10-minute automated agent job into
days of specialist human grind, and kills most automated attacks at the
door. A determined human with time still gets through. Relocation and sealing need
a backend you secure, and the request/response boundary stays observable. It's
behavior-preserving, transparent (no phone-home), and strictly defensive — it
protects code you own and ship. Never a weapon against anyone else's.

One line to walk away with: the strongest defense isn't a tool, it's a
decision. Whatever must truly stay secret belongs on your server — where no
bundle, and no agent, can ever reach it.

Repo + docs: https://github.com/HMAKT99/reashield — npm i -D reashield

Do reverse engineering? Come break the relocation and decoy seams and tell me
where they're weakest. I want the teardown.

Your AI agent writes Playwright tests that pass while your API returns 500

Arun Kumar T — Sun, 01 Nov 2026 03:08:58 +0000

AI agents now write a lot of Playwright tests. You ask Claude Code or Copilot to "add a test for the checkout", or let an agent explore your app through Playwright MCP and turn what it did into a spec. Healer agents even fix failing tests for you.

Here is the kind of test they write:

import { test, expect } from "@playwright/test";

test("places an order", async ({ page }) => {
  await page.goto("/");
  await page.getByLabel("Name").fill("Ada");
  await page.getByRole("button", { name: "Place order" }).click();
  await expect(page.getByRole("status")).toContainText("Order placed");
});

It's a good test: role-based locators and a web-first assertion. It passes.

It also passes when the order API returns 500 and stores nothing, as long as the page still shows "Order placed". The agent checked what it could see. Nobody told it to check what the server did, and agents almost never add a network assertion on their own.

That matters more with agents than with people. A human who wrote the checkout code might remember the API can fail. An agent generating fifty tests from what's on screen won't, and a healer agent that "fixes" a red test by updating the expected text can make things worse. The suite goes green while the backend is broken.

The one-line fix

Change the import, in the tests the agent wrote or in the template it writes from:

import { test, expect } from "@vedhajs/playwright-test";

Nothing else changes. Same test, same broken app:

  ✓  1 1-playwright.spec.ts › places an order (import from @playwright/test)
  ✘  2 2-vedha.spec.ts › places an order (import from @vedhajs/playwright-test)

    Error: Vedha guard: the test's own checks passed, but the app reported a problem:
      - POST /api/orders returned 500

On a healthy app, both pass.

The failure message is also written for whoever reads it next, human or agent: what the app did, and how to accept it if it was expected. A healer agent gets a real reason instead of a green run.

What it checks

@vedhajs/playwright-test re-exports Playwright's test and expect with an automatic fixture ("guard mode") that watches the browser context while each test runs:

Fails the test: any 5xx from your app's own site, or a write request (POST/PUT/PATCH/DELETE) that failed outright, even when every expect passed.
Warns, without failing: a 4xx answer to a write, and uncaught page errors. Validation tests expect a 422 and third-party scripts throw, so these become annotations in the report instead of failures.
Ignores: requests to other sites (analytics, CDNs).
Attaches: the findings to the test result as vedha-guard.json.

When a finding is expected, opt out per test or per endpoint:

test.use({ vedhaGuard: "strict" }); // 4xx writes and page errors fail too
test.use({ vedhaGuard: { ignore: ["/api/flaky", /\/v2\//], hosts: ["api.other-domain.com"] } });
test.use({ vedhaGuard: false }); // off, for a test that expects a 500

It is still Playwright's runner, so retries, sharding, reporters and traces work as before.

Making agents use it

Put it where the agent will pick it up:

Your project instructions (CLAUDE.md, AGENTS.md, Copilot instructions): "Import test and expect from @vedhajs/playwright-test, not @playwright/test."
Existing specs: agents copy the patterns they find, so once your specs use the import, new ones tend to follow.
A lint rule that bans importing from @playwright/test in spec files, if you want to enforce it.

When the agent drives the browser itself

Guard mode is for the tests an agent writes. When the agent is the tester, driving the browser live and reporting pass or fail, Vedha also ships an MCP server that checks every step the same way. In a small pilot on held-out tasks (one model, 3 trials per task), the agent missed 9 seeded bugs with Vedha's MCP server against 26 with Playwright MCP. That's a separate setup from guard mode, covered in an earlier post.

Limits

A hand-written waitForResponse assertion catches this too. Guard mode is the safety net for the many tests, agent-written or not, that don't have one.
In Vedha's benchmark, tests with typical text and URL checks caught 0 of 140 seeded defects with plain Playwright, and 60 of 140 with Vedha's page-health check: every defect where the server rejected or failed the write. Guard mode applies the same rules to whole tests, but it hasn't been benchmarked separately yet.
It does not catch a write that returns 200 but stores nothing or stores the wrong value. Vedha's checked steps can read the data back, but that's opt-in and needs more than one line.

Try it

npm install -D @vedhajs/playwright-test

Change the import in one agent-written spec and run it. If a test that used to pass now fails, look at the request it names. Either the agent's test was hiding a bug, or it's an expected error to add to ignore.

Repo, demo and benchmark data: https://github.com/HMAKT99/VEDHA (Apache-2.0)

I'd like to hear what it finds in agent-written suites, and about any false alarm.

Is Playwright alone enough for agentic testing?

Arun Kumar T — Sat, 31 Oct 2026 13:01:00 +0000

More teams now let an AI agent test their web app: "test the checkout", "check the signup flow". The agent drives a browser through Playwright, clicks through the flow, and reports back: all tests passed.

The problem is how the agent decides that. It looks at the page. If the page shows the success message it expected, the test passes. But a page can show success while the app is broken underneath: the API returned a 500, the server rejected the request, or it stored nothing at all. The test passes, and the bug ships.

I wanted to measure how often that happens, and whether a testing layer could catch these bugs without the agent (or a human tester) writing extra assertions. The result is Vedha, an open-source testing framework and MCP server built on Playwright.

A broken feature that passes its test

Here is an order form with a seeded bug: the order API returns 500 and stores nothing, but the page still shows "Order placed". The same test, with the same check (wait for "Order placed"), is run twice:

Playwright  PASS   "Order placed" is on the page
Vedha       FAILED declared checks passed, but the page reported: POST /api/orders returned 500
Server      0 orders stored

You can run it yourself in about 3 seconds: npx tsx examples/demo/run.ts in the repo.

A careful tester would catch this in Playwright too, by asserting on the network response. Most tests don't, and agents almost never do.

What Vedha adds to Playwright

Vedha keeps what Playwright does best (auto-waiting, locators, the browser itself) and adds a verification layer to every test step:

Every step gets a result: verified, failed, outcome_unknown, unverified or blocked. Never a silent pass.
Actions that change data are checked. Mark a step as mutating and Vedha watches the requests it sent. A 5xx, a rejected request or a page error fails the step even when the on-screen check passed. Where the API follows REST conventions, it also reads the data back to confirm it was stored.
No duplicate side effects from retries. If a click times out mid-submit, Vedha won't click "Place order" again and create a second order. It reports outcome_unknown until a read-only check settles it.
Agent explorations become regression tests. A verified flow can be exported as a plain @playwright/test spec for CI.
Safe defaults for agents. The MCP server won't start without a domain allowlist, treats page text as untrusted data, and redacts secrets you pass to it.

The numbers, and their limits

Every number comes from raw trial files in the repo, and each held-out test set was written before any run on it.

AI agent testing (Playwright MCP vs Vedha MCP, same model, same held-out test tasks):

	Playwright MCP	Vedha MCP
Seeded bugs missed (sets 2-4)	26	9
Healthy flows passed (set 4)	18/18	17/18
Median tokens, healthy flows (set 4)	76,018	52,990 (-30%)
Median wall time, healthy flows (set 4)	169 s	176 s (+4%)

Scripted tests, no model:

With typical text/URL-only checks, Vedha caught 60 of 140 seeded bugs; every Playwright and Selenium baseline caught 0.
A 1,120-trial audit after the last change had 0 false passes and 0 false fails.
Median overhead: 1.05x hand-written Playwright.

The limits:

The AI-agent results come from one free model, at 3 trials per task. That's a pilot, not a verdict.
When an expert writes every check by hand, Vedha and Playwright tie. Vedha's lead is with typical checks and with agents.
Read-back needs a REST-style read endpoint: the same path, or its singular/plural sibling. GraphQL, separate read endpoints and filtered or per-user collections aren't covered.
Vedha passed one fewer healthy flow than Playwright MCP on set 4, and it uses more tool calls.

Try it

With Claude Code:

claude mcp add vedha -- npx -y @vedhajs/mcp --allow-domain localhost

Then ask: "test the checkout flow on localhost:3000".

Any MCP client takes the same command (npx -y @vedhajs/mcp --allow-domain localhost). There is also an agent skill (npx skills add HMAKT99/VEDHA), a CLI for scripted tests (npm i -D @vedhajs/cli), and an SDK that wraps an existing Playwright page.

Repo, benchmarks and raw data: https://github.com/HMAKT99/VEDHA (Apache-2.0)

I'd most like to hear about real apps where it gets things wrong: a false failure on a healthy flow, or a bug it should have caught.