DEV Community: Aditya P Dixit

I Think Browser Agents Are Built on the Wrong Abstraction (So I Built a Compiler)

Aditya P Dixit — Tue, 30 Jun 2026 07:15:54 +0000

Every browser agent starts the same way.

It downloads HTML.

Builds a DOM.

Searches for CSS selectors.

Finds buttons.

Waits for JavaScript.

Clicks something.

Reads more HTML.

Repeats.

We keep making LLMs dramatically smarter...

...yet we're still asking them to reason over one of the lowest-level representations on the web.

That felt wrong.

So I started asking a different question:

What if websites could be compiled into semantic interfaces instead of being rediscovered every time an AI agent visits them?

That question eventually became an open-source project called Shiny Fishstick.

Yes.

That's actually the name.

The Problem

Imagine asking an AI agent to buy a laptop.

Today, its internal reasoning looks something like this:

Find login button.

Click login.

Wait.

Find email field.

Fill email.

Find password field.

Fill password.

Click submit.

Wait for navigation.

Search for "Laptop".

Find Add to Cart.

Click Add to Cart.

Now imagine doing that...

Every.

Single.

Time.

The website hasn't changed.

The workflow hasn't changed.

Yet the agent keeps rediscovering it.

HTML Is A Great Human Interface

HTML was designed for browsers.

It tells browsers:

where text goes
what buttons exist
how pages should render

An AI agent doesn't care about any of that.

It doesn't care whether the button is blue.

It doesn't care whether the developer changed a

to a .

It cares about actions.

Those are semantic concepts.

HTML doesn't represent them very well.

Thinking Like A Compiler

Compiler design has an interesting idea.

You don't execute source code directly.

You first transform it into an Intermediate Representation (IR).

Everything else builds from there.

I wondered if websites could work the same way.

Instead of repeatedly reasoning over HTML...

Compile the website once.

Generate a reusable semantic representation.

Enter Preflight

The compiler produces a specification called preflight.yaml.

A simplified example:

version: 1.0.0

actions:

parameters:
  - email
  - password

add_to_cart:
action_type: api

api:
  method: POST
  url: /api/cart/add

Notice something.

There's no HTML.

No XPath.

No brittle selectors.

Only actions.

API Disco

One of my favorite modules is called API Disco.

(Yes, that's the real filename.)

While the crawler performs browser interactions, it watches every network request.

If it discovers that an action is actually backed by a reusable API...

The compiler upgrades that action automatically.

Instead of generating browser automation...

It generates an API-backed SDK method.

If no API exists?

No problem.

The generated SDK simply falls back to resilient browser execution.

The developer never has to think about the difference.

One Specification, Multiple Outputs

Once the compiler has generated preflight.yaml, everything else becomes code generation.

Today it produces:

Python SDKs
TypeScript SDKs
Rust SDKs
MCP Servers

Tomorrow it could just as easily generate:

Go SDKs
Java SDKs
C# SDKs

The compiler doesn't change.

Only the backend generator does.

Why I Think This Is Interesting

The thing I'm most excited about isn't actually the compiler.

It's the specification.

Imagine a future where multiple tools understand the same semantic website format.

Different compilers.

Different validators.

Different SDK generators.

Different execution engines.

All sharing the same representation.

That feels much more powerful than another browser automation library.

Benchmarks

I also wanted to avoid hand-wavy performance claims.

So the repository includes public benchmark methodology measuring:

Token reduction
Execution speed
Reliability
Memory usage
Self-healing capability
Developer implementation effort

The goal wasn't to "win benchmarks."

The goal was to make every claim reproducible.

Is This A Browser Automation Replacement?

No.

Some websites simply don't expose reusable APIs.

Some authentication flows require browser interaction.

Some workflows are inherently visual.

Browser automation isn't going away.

The idea is to separate:

What an agent wants to do

from

How that action gets executed

Sometimes that's an API.

Sometimes it's a browser.

The interface stays the same.

What's Next?

The roadmap currently includes:

More SDK targets (Go & Java)
Better API discovery
Plugin architecture
Visual regression support
Improved compatibility across modern web frameworks

But more importantly...

I'd like to hear what other developers think.

Am I solving the wrong problem?

Is there a better abstraction?

Could something like preflight.yaml actually become useful outside this project?

I'd genuinely love the discussion.

Links

🌐 Website

https://adityapdixit.me/shiny-fishstick/

⭐ GitHub

https://github.com/Hootsworth/shiny-fishstick

If nothing else, I hope the name made you curious enough to click.

Thanks for reading.

I Got Tired of AI Agents Having Root Access to Everything, So I Built XRisk

Aditya P Dixit — Sat, 27 Jun 2026 19:13:01 +0000

Everyone is building AI agents.

Very few people are building the thing that sits between an AI agent and a disastrous decision.

That's why I built XRisk.

XRisk is an open-source autonomous safety engine that acts as a decision layer between an AI agent and the real world.

Instead of blindly executing an action, an agent asks XRisk:

"Should I actually do this?"

XRisk responds with one of three deterministic decisions:

✅ Allow
⚠️ Confirm
❌ Block
Why I Started This Project

As I experimented with increasingly autonomous AI systems, I noticed the same pattern over and over again.

Most projects focused on making agents more capable.

Almost nobody was asking:

"What happens when the agent is wrong?"

Consider a few examples.

An agent accidentally leaks API keys.
A prompt injection convinces it to ignore previous instructions.
A model decides to execute a shell command.
An autonomous workflow loops forever and keeps calling expensive APIs.
A deployment bot pushes code without human approval.

Most agent frameworks assume the model behaves.

Reality doesn't.

I wanted something deterministic sitting between intention and execution.

Not another model.

Not another prompt.

An actual policy engine.

What XRisk Does

XRisk evaluates every proposed action before it's executed.

It combines multiple safety signals into a single explainable decision.

Some of the things it checks include:

Policy-as-code with layered precedence
Prompt injection detection
Sensitive data and secret detection
Capability token validation
Network egress restrictions
Circuit breakers for autonomous loops
Tamper-evident audit logs
Supply-chain verification
Policy conflict detection
Deterministic forensic replay

Instead of a mysterious "Safety Score: 67%," XRisk explains why it made a decision.

Example

Imagine an AI assistant wants to execute:

{
"tool": "deploy",
"actor": "release-bot",
"prompt": "Deploy production immediately."
}

Instead of sending that directly to your deployment system...

XRisk intercepts it.

It evaluates:

Does policy require approval?
Is the actor allowed to deploy?
Is the destination trusted?
Are capability tokens valid?
Does this resemble prompt injection?
Is this part of a dangerous execution loop?

Only then does it decide whether to:

Allow
Confirm
Block
One Design Decision I Feel Strongly About

I deliberately avoided using another LLM to make safety decisions.

LLMs are excellent at generating text.

Policy enforcement should be deterministic.

If an action is blocked, I want to know exactly why it was blocked.

Every decision should be reproducible.

Every audit should be explainable.

Every policy should be inspectable.

That's the philosophy behind XRisk.

What's Next

I'm currently working toward:

Threat intelligence correlation
Zero-trust workload identities
Autonomous containment
Adversarial simulation
Multi-party approval workflows

The long-term vision is to make XRisk a reusable security layer that can sit in front of any AI agent, regardless of framework.

I'd Love Feedback

This project is still evolving, and I'd genuinely appreciate feedback from people building AI systems.

Some questions I'm particularly interested in:

What attack vectors am I missing?
Which policies would you want in production?
What integrations would make this more useful?
How would you design a safety engine differently?

If you'd like to contribute, open an issue, suggest improvements, or submit a PR. Even small documentation fixes are welcome.

Thanks for reading—I hope XRisk becomes something that helps make AI systems not just more capable, but more trustworthy.

Link: https://github.com/Hootsworth/XRisk