DEV Community: Leon

We Ran 15,000 Browser Automations. The Failure That Matters Most Is Invisible to Your Monitoring.

Leon — Mon, 20 Apr 2026 01:37:47 +0000

Half of our YouTube automation runs return 0 rows. Status: ok. No exception thrown. No error logged. The program finishes in about 20 seconds and hands back an empty array, silently.

We didn't know this until we looked at the traces.

Over the past few months, Tap has executed 15,455 automation programs across real websites — Reddit, GitHub, Bilibili, Xiaohongshu, YouTube, Twitter, and more. The traces are structured JSON: site, tap name, status, rows returned, duration, error message if any. We analyzed all of them. What we found disagrees with the conventional mental model of how browser automations break.

The Reliability Table Nobody Publishes

Here are the actual numbers. Each row is a real platform. Hard error rate is the fraction of runs that threw an exception. Silent empty rate is the fraction of successful runs (status: ok) that returned zero rows.

Platform	Total runs	Hard error %	Silent empty %	Effective failure %	Avg duration
Twitter / X	128	0%	0%	0%	154 ms
GitHub	437	0%	0.2%	0.2%	3,644 ms
Reddit	688	13.8%	6.4%	19.4%	4,075 ms
Xiaohongshu	361	15.8%	6.6%	21.5%	9,054 ms
Bilibili	259	30.1%	18.2%	43.1%	2,666 ms
Weibo	38	36.8%	0%	36.8%	4,644 ms
YouTube	49	30.6%	50.0%	65.3%	20,273 ms

GitHub and Twitter are near-zero failure. YouTube is the opposite: two out of three runs either throw an error or return nothing. The 50% silent empty rate is more alarming than the 30.6% hard error rate — at least hard errors are visible.

The Failure Mode You're Not Tracking

Here's the part that surprised us most. We expected "element not found" to be the dominant failure. The conventional model: selector breaks, automation throws, you fix the selector. Obvious, visible, actionable.

The actual numbers:

Element not found (explicit selector failure): 5 occurrences
Cannot read properties of undefined (reading 'url') (implicit structural failure): 176 occurrences

The ratio is 35:1 in favor of the failure mode your monitoring doesn't catch.

What does Cannot read properties of undefined (reading 'url') actually mean? The selector found something. The extraction ran. The automation didn't crash during navigation. It returned data — a list of objects — but the objects no longer have a url field. The downstream code hits undefined and throws.

This is a structural drift failure, not a selector failure. The DOM element is there. The page loaded. The program traversed the right nodes. But the shape of the data those nodes return has changed — a field that was always present quietly stopped being present.

The sites affected, in order of frequency:

Bilibili (videos, articles, analytics, benchmark, content-ideas, stats, trending)
Algora bounties
IssueHunt bounties
Douyin (search, hot)
Zhihu search
X/Twitter (notifications, trending)
Xiaohongshu search
Weibo search
Baidu hot
Hacker News hot
ProductHunt forum comments
TechCrunch latest
Ars Technica news

That list spans Chinese platforms, Western platforms, social networks, news sites, and developer bounty boards. The failure mode is not platform-specific. It's inherent to how browser automation interacts with any site that changes its rendering.

Why Your Monitoring Doesn't See This

Consider what's happening at the infrastructure layer when this failure occurs:

HTTP response: 200
Page loaded successfully: yes
Navigation completed: yes
Automation process exited: 0
Exception thrown: eventually — but only after the extraction, when downstream code accesses the malformed object

Most monitoring stacks see a successful process exit followed by an application exception. But the harder version is when the object does have a url field — it just points to something different. A related item section. A sponsored result. A pagination link that got included in the data array.

In those cases: status ok, rows returned, no exception, wrong data. Pydantic passes. Row count checks pass. Prometheus reports a healthy process. OTel has nothing to report. The only signal is semantic: these URLs aren't the URLs you wanted.

The Platform Reliability Pattern

GitHub and Twitter have published APIs that their web UIs reflect. A GitHub repository page structure is stable because it's owned by the same team that maintains the underlying data model.

Bilibili, Douyin, Xiaohongshu, and Weibo run aggressive A/B experiments on their rendering layer — sometimes multiple experiments simultaneously for different user cohorts. The same page, loaded twice in the same session, can return different DOM structures. The url field on a video card might be in item.url in one experiment variant and item.jumpUrl in another.

YouTube lands in between for a different reason: aggressive anti-bot measures that return empty results instead of blocking requests. A request that would return a 429 or CAPTCHA on a naive scraper returns 200 with an empty content container on a logged-out browser session. Status: ok. Rows: 0. Duration: 20 seconds of wasted compute.

What Catches This, and What Doesn't

Tool	Catches hard error?	Catches silent empty?	Catches wrong data (right shape)?
Process monitoring	✓	✗	✗
Pydantic / type validation	✓	Sometimes	✗
Row count threshold	✓	✓	✗
Health contracts (range + pattern + drift)	✓	✓	✓
Structural fingerprinting	✓	✓	Signals change, not interpretation

The only layer that catches all three failure classes is a contract that validates semantics — not just shape. A min_rows check catches silent empties. A pattern check on URLs catches wrong-source data. A drift check catches distribution shifts that look valid but represent changed behavior.

What We'd Do Differently

Treat silent empties as first-class failures. A run returning zero rows should be suspicious by default. Most automations that legitimately return zero rows are edge cases. Most that return zero rows unexpectedly are broken. The difference is detectable with a min_rows contract.

Fingerprint before running, not after. The structural drift that causes Cannot read properties of undefined is detectable in the DOM before you run your extraction logic. A fingerprint check is cheaper than a full tap execution.

Treat Chinese platforms as a separate reliability tier. The A/B experiment cadence is genuinely different. A tap targeting Bilibili needs shorter contract drift windows and more frequent health checks than one targeting GitHub.

Duration is a signal. Our YouTube taps average 20 seconds per run and fail 65% of the time. That's not slow extraction — that's waiting for content that's not coming. A timeout contract that fires at 8 seconds would catch most of these early.

The trace data from 15,455 runs is the most honest answer we have to "what actually breaks in browser automation?"

The answer: silent structural drift, not explicit selector failure. The sites that change fastest break most. The failures that matter most are the ones that look like success.

Built with Tap — browser automation programs that run forever.

Search arXiv in One Command — No API Key, No Tokens

Leon — Tue, 07 Apr 2026 09:46:59 +0000

Keeping up with AI research is exhausting. New papers drop daily. Most "paper discovery" tools require an account, burn API tokens on every search, or give you a bloated UI when all you wanted was a list.

Here's what I use instead:

npx -y @taprun/cli arxiv search --keyword "LLM" \
  | npx -y @taprun/cli sort --field published \
  | npx -y @taprun/cli table

Output: 20 papers sorted newest-first, with title, authors, published date, abstract, and URL — in under 2 seconds.

No account. No API key. No AI tokens consumed. First run downloads a ~30MB binary and caches it; every subsequent call is instant.

Why This Works

The arXiv Atom API has been public and stable for 15 years. arxiv/search is a Tap skill — a 20-line deterministic program that calls it directly. AI wrote it once. It runs forever at $0.

The Unix Pipeline Model

Every Tap skill is a composable Unix filter. Data flows as JSON:

# Search only
npx -y @taprun/cli arxiv search --keyword "RAG"

# Search → sort by date → filter recent → display
npx -y @taprun/cli arxiv search --keyword "RAG" \
  | npx -y @taprun/cli sort --field published \
  | npx -y @taprun/cli filter --field published --gt "2025-01-01" \
  | npx -y @taprun/cli table

Each command reads JSON from stdin, writes JSON to stdout. Exactly how Unix tools work.

Use It in CI

# GitHub Actions — daily paper digest
- name: Paper digest
  run: |
    npx -y @taprun/cli arxiv search --keyword "LLM agents" \
      | npx -y @taprun/cli sort --field published \
      | npx -y @taprun/cli limit --n 5 \
      > papers.json

200+ Skills, Same Pattern

arXiv is one of 200+ community skills that follow the same pattern: call an API, return structured rows, compose with any other skill.

Skill	Returns
`arxiv/search --keyword X`	Papers matching keyword
`github/trending`	Trending repos today
`reddit/search --keyword X`	Posts matching keyword
`stackoverflow/hot`	Hot questions

Browse and contribute: github.com/LeonTing1010/tap-skills

Try it now — no install required, works on any machine with Node.js:

npx -y @taprun/cli arxiv search --keyword "your topic" \
  | npx -y @taprun/cli sort --field published \
  | npx -y @taprun/cli table

→ taprun.dev

16 Comments, 6 Insights: Using HN and Reddit as a Positioning Lab

Leon — Mon, 06 Apr 2026 05:18:09 +0000

I spent an afternoon writing 16 comments across Hacker News and Reddit. Not to promote anything — to test which pain points actually resonate with developers.

The result: 6 content principles I now use to decide what to build, what to write about, and how to position my product. Here's the method.

The Method: Comments as Micro-Experiments

The premise is simple: a comment is the cheapest possible A/B test.

Writing a blog post takes hours. A landing page rewrite takes days. A comment takes 2 minutes. If it gets upvoted, the angle works. If it's ignored, you saved yourself a blog post nobody would read.

The process:

Find hot posts in your domain (automation, scraping, developer tools, AI)
Write a comment that tests a specific angle — one pain point, one insight
Track which angles get traction
Turn validated angles into blog posts and landing page copy

I posted across 10 subreddits and HN front-page posts spanning AI, infrastructure, open source, and developer tools.

The 6 Insights

#1 Silent failure is the universal pain

I commented on Gallery-dl's DMCA move (HN front page) and r/webscraping's "endgame for scraping" (104 upvotes). Both times, the angle that resonated was: the hard part isn't writing a scraper — it's knowing when it breaks.

"Most scrapers fail silently — they return empty arrays for days before anyone notices."

Principle: Lead with the maintenance problem, not the creation problem. Everyone can build a scraper. Nobody can keep it running.

Solution: Health contracts. Every program defines what "working" means: minimum rows, required fields. tap doctor checks all programs in one command. When something breaks, you know in seconds — not weeks.

health: { min_rows: 5, non_empty: ["title", "url"] }

$ tap doctor
hackernews/hot    ✔ ok     30 rows
reddit/hot        ✘ fail   0 rows — selector changed
  ↳ auto-healing...

#2 Cost anxiety is real and specific

Caveman hit 727 points — a post about reducing LLM token usage. Nanocode (177 points) was about self-hosting Claude Code to understand the real cost. Developers aren't just curious about AI costs — they're anxious about them.

Principle: Use exact numbers. "$1.05 per run" and "300x cheaper" land. "More affordable" doesn't. Developers think in math, not adjectives.

Solution: The compiler model. AI runs once at authoring time (~$0.15), produces a deterministic program, and every subsequent execution is $0. Fifty daily automations: $18,000/year with AI agents vs ~$60/year with compiled programs.

#3 "Open-source alternative" is not a value prop

The Modo post ("open-source alternative to Cursor and Windsurf") had only 2 comments despite being on the front page. My feedback: users don't switch tools for ideology — they switch for workflow improvements.

"The README should lead with a concrete before/after: 'In Cursor you do X in 5 steps, in Modo you do it in 1.' That's what converts users."

Principle: Show the delta, not the category. "I'm like X but open source" tells users nothing about why they should switch.

Solution: Concrete comparison. Browser Use: $0.50–$2.00/run, 60–95% reliability, 30–120s. Tap: $0/run, 100% deterministic, 1–5s. Same task, measurable difference.

#4 Local-first is having a moment

Three unrelated posts all trended around the same theme:

Gemma 4 on iPhone (496 points) — on-device AI inference
Zero-dependency browser IDE (r/opensource) — works offline, no npm
Nomad offline media server (r/selfhosted) — works without internet

Developers are increasingly allergic to tools that phone home.

Principle: "Runs on your machine, works offline" is a feature worth highlighting, not an implementation detail to bury.

Solution: Tap programs are plain .tap.js files that execute locally. No API calls at runtime, no data leaving your device, no cloud dependency. They work on a plane, in a cabin, wherever your laptop goes.

#5 Legal pressure on scraping is accelerating

Gallery-dl's DMCA notice trended on both HN and r/programming simultaneously. The pattern: open-source scraping tools face increasing legal pressure.

Principle: API-first data access is both technically superior and legally safer. Position accordingly.

Solution: tap.fetch() calls site APIs directly — structured JSON, stable endpoints, no DOM parsing. Only falls back to browser rendering when no API exists. Less breakage, less legal surface area.

#6 Infrastructure beats features

Switzerland's 25 Gbit internet (315 points, 249 comments) wasn't about speed — it was about structural fairness. Open fiber access vs. local monopolies.

The parallel to automation tooling: AI agents at $1/run create a cost barrier. Deterministic programs at $0 are infrastructure.

Principle: Frame your tool as infrastructure people own, not a service they rent.

Solution: Every .tap.js is a file you own. Git-versionable, diffable, composable. Cancel your subscription and your programs keep running. No vendor lock-in, no API keys required at runtime.

The Playbook

If you're building a developer tool and struggling with positioning:

Don't start with a landing page. Start with 10 comments on relevant posts.
Each comment tests one angle. One pain point, one insight, one framing.
Upvotes = validation. High-scoring posts where your comment resonates = confirmed pain point.
Silence = signal too. If nobody engages with your angle, it's not a pain point.
Turn validated angles into content. Blog post from the best angle. Landing page copy from the specific phrases that worked.
Never link your product in comments. Share expertise. Build credibility. The product link lives on your profile.

Comments are conversations. Conversations reveal what people actually care about. That's worth more than any amount of competitor analysis.

The tool I used to validate these insights: Tap turns AI into a compiler for browser automation. AI writes a program once, then it runs forever at $0. The positioning came from the comments. The product came from the pain.

Programs Beat Prompts: Why AI Should Write Code, Not Run It

Leon — Mon, 06 Apr 2026 05:04:19 +0000

Every AI browser agent works the same way: send a prompt, burn tokens, get a result. Next time you need the same result? Send the prompt again. Burn more tokens.

This is the prompt loop, and it's why AI automation is expensive, unreliable, and slow.

There's a better model: AI writes a program once, then the program runs forever at zero cost.

The Prompt Loop Problem

AI browser agents like Browser Use, Stagehand, and computer-use tools are impressive demos. Point an LLM at a website, tell it what to do, watch it click around. Magic.

Until you need it to work reliably. At scale. Every day.

"The program cost $1.05 to run. So doing it at any scale quickly becomes a little bit silly."
— rozap, Hacker News

The math is brutal. An AI agent that scrapes one site costs ~$1 per run. Run it daily across 50 sites and you're spending $1,500/month on data collection that a deterministic script would do for free.

But cost isn't even the worst part. Reliability is.

"If each step has a .95 chance of completing successfully, after not very many steps you have a pretty small overall probability of success."
— rozap, Hacker News

95% per step sounds good. A 10-step workflow? 60% overall. Twenty steps? 36%. Every AI call is a coin flip weighted slightly in your favor — but over enough steps, the house always wins.

The Compiler Model

There's a pattern from 60 years of computer science that solves this: compilation.

A compiler reads high-level code once, produces optimized machine code, and that machine code runs billions of times at zero marginal cost. The compiler is expensive. The output is free.

Apply this to browser automation:

	Prompt model (interpreter)	Program model (compiler)
AI cost per run	$0.50 – $2.00	$0.00
Reliability per run	60 – 95%	100% deterministic
Speed	30 – 120s (LLM thinking)	1 – 5s (direct execution)
AI usage	Every run	Only at authoring time

The insight: AI is the compiler, not the runtime. Use AI to understand the interface, write a deterministic program, and then execute that program forever without AI.

What This Looks Like

# Step 1: AI observes the interface (the "compile" step)
$ tap forge "get trending repos from GitHub"
Inspecting github.com...
Found API: api.github.com/search/repositories
Verifying: 25 rows, all fields present
✔ Saved: github/trending.tap.js

# Step 2: Program runs forever at $0 (the "execute" step)
$ tap github trending
25 rows (890ms) Cost: $0.00

The first command uses AI. Every subsequent run is pure code — no LLM, no tokens, no variability.

Why Programs Win

1. Deterministic means debuggable

When a prompt fails, you get "the AI didn't understand the page." When a program fails, you get a stack trace, a line number, and a selector that changed. One is a mystery. The other is a bug you can fix.

2. Programs compose

Prompts are isolated. Each one starts fresh, with no memory of what came before. Programs call other programs:

// This tap calls two other taps and combines the results
async run(tap) {
  const repos = await tap.run("github", "trending")
  const stars = await tap.run("github", "stars", { user: "me" })
  return repos.filter(r => !stars.includes(r.name))
}

Composition is free. No extra tokens. No prompt engineering to maintain context across steps.

3. Programs have contracts

A prompt returns whatever the AI decides. A program has a health contract:

health: {
  min_rows: 10,         // must return at least 10 results
  non_empty: ["title"]   // title field can't be empty
}

When the site changes and the program breaks, the contract catches it immediately. No silent failure. No stale data for days.

4. Programs version naturally

A .tap.js file is just JavaScript. It goes in Git. You get diffs, blame, history, rollback. Try doing that with a prompt chain stored in a vector database.

When You Do Need AI Again

Programs aren't magic. Websites change. When they do:

$ tap doctor
github/trending   ✔ ok     25 rows
reddit/hot        ✘ fail   0 rows  — selector changed

# Doctor detected the break. Re-forge just that one:
$ tap doctor --auto
Re-forging reddit/hot...
✔ Fixed: reddit/hot.tap.js (new selectors)

AI is called once to fix the program. Then it runs at $0 again until the next change. You pay for intelligence only when the world changes — which is 1% of the time, not 100%.

The Numbers

For a real workload of 50 automations running daily:

	Prompt-per-run	Programs
Daily AI cost	$50	$0
Monthly AI cost	$1,500	~$5 (occasional re-forge)
Annual AI cost	$18,000	~$60
Reliability	60 – 95%	100% (until site changes)
Speed per run	30 – 120s	1 – 5s

300x cost reduction. 20x faster. Deterministic. The math doesn't require a sales pitch.

Try it:

# Install (macOS / Linux)
curl -fsSL https://taprun.dev/install.sh | sh

# Forge your first program
tap forge "get top stories from Hacker News"

# Run it forever at $0
tap hackernews hot

Getting started · GitHub · 200+ community taps included

Your AI Browser Agent Costs $3,600/month. Here's How to Make It $0

Leon — Sun, 05 Apr 2026 15:08:47 +0000

A developer recently documented burning through 180 million tokens per month — $3,600 — running AI browser agents. That's not a typo.

The browser-use community (78K GitHub stars) is full of users asking the same question:

"I have a recurring task meant for webscraping to be done every 5 min. I do not want to use too many tokens. Is it possible to repeat the tasks?" — browser-use #494

"My business scenario requires solidifying the agent's execution process into a tool. I noticed save_as_playwright_script is commented out." — browser-use #4519

"Running the default task took 12 minutes on M3 Max, 36GB RAM" — browser-use #957

The problem is architectural: every run uses AI tokens, even when you're doing the exact same thing for the 1,000th time.

The Interpreter vs. Compiler Model

Today's browser agents work like interpreters — AI reasons about every click, every scroll, every form fill, every single time:

Interpreter (browser-use, Stagehand, Operator):
  Run 1:    AI reads page → decides action → executes    ($0.01)
  Run 2:    AI reads page → decides action → executes    ($0.01)
  Run 100:  AI reads page → decides action → executes    ($0.01)
  Run 1000: AI reads page → decides action → executes    ($0.01)
  Total: $10.00 (and growing)

But what if AI could compile the workflow once, then replay it forever?

Compiler approach:
  Run 1:    AI inspects page → generates program          ($0.04, one-time)
  Run 2:    Program runs deterministically                 ($0.00)
  Run 100:  Program runs deterministically                 ($0.00)
  Run 1000: Program runs deterministically                 ($0.00)
  Total: $0.04 (forever)

This isn't hypothetical. Tap implements this exact pattern:

forge inspect — Analyzes the page (framework, SSR state, APIs, DOM structure). Zero AI tokens.
AI generates a .tap.js program — One-time cost (~$0.04).
tap run — Executes the program forever. $0.00 per run.

Why API-First Beats DOM Replay

Most record-and-replay tools (including browser-use's workflow-use) capture DOM interactions — clicks, typing, scrolling. This breaks when the UI changes.

The better approach: extract via API when possible, DOM only as fallback.

Most modern websites have internal APIs (Next.js __NEXT_DATA__, Nuxt SSR state, REST endpoints). Calling the API directly is:

100x more reliable than simulating clicks
Immune to UI redesigns
Faster (no rendering needed)

For example, getting Hacker News front page:

// DOM approach (fragile):
document.querySelectorAll('.athing').forEach(row => { ... })

// API approach (robust):
const data = await fetch('https://hacker-news.firebaseio.com/v0/topstories.json')

Real Numbers

Metric	AI Agent (per run)	Compiled Program (per run)
Cost	$0.003–0.01	$0.00
Speed	12 min (reported)	5 seconds
Reliability	Varies (AI hallucinations)	Deterministic
Tokens	1K–10K per action	0

At 100 runs/day:

AI agent: $30–300/month
Compiled program: $0.04 total (one-time forge cost)

The Takeaway

If you're running the same browser task more than once, you're overpaying by 100–1000x. The future isn't smarter agents — it's agents that are smart once and produce deterministic programs.

Token prices are falling 10x/year. But $0 will always beat any price.

Tap is open source. 208 pre-built programs across 77 sites. One binary, zero dependencies.

Try it: taprun.dev | GitHub

Your Scraper Is Broken Right Now. You Just Don't Know It Yet.

Leon — Sat, 04 Apr 2026 13:18:29 +0000

Somewhere in your infrastructure, a scraper is returning empty arrays. Your dashboard shows stale numbers. A report your team relies on has been wrong since Tuesday.

You won't find out until someone complains.

The Silent Failure Problem

Most scrapers don't crash loudly. They fail quietly.

"Instead of throwing an error when a page structure changes, they return empty arrays... A scraper that fails silently poisons your data for days or weeks before anyone notices."

This happens because scrapers have no health contract. They extract whatever they find — and when the site changes, "whatever they find" is nothing. No error. No alert. Just empty data flowing downstream.

The Maintenance Tax

When you do notice, you're back to fixing selectors. Again.

"Every time a website redesigns or updates their layout, I'm manually fixing selectors and rewriting parts of the workflow. It's eating up hours every month."

"Maintaining tests can take up to 50% of the time for QA test automation engineers."

The loop is always the same: build automation → site changes → selectors break → spend hours fixing → repeat.

The AI Agent Tax

AI browser agents promise to solve this by re-interpreting the page every run. But they introduce two new problems:

1. Cost compounds.

"The program cost $1.05 to run. So doing it at any scale quickly becomes a little bit silly."

2. Reliability degrades at each step.

"If each step has a .95 chance of completing successfully, after not very many steps you have a pretty small overall probability of success."

95% per step sounds great. But a 10-step workflow is 60% overall. AI agents trade one problem (brittle selectors) for another (probabilistic failure).

A Different Approach: Health Contracts

What if your automation had a contract that defined what "healthy" looks like?

// Built into every program
health: {
  min_rows: 5,           // must return at least 5 results
  non_empty: ["title"]   // "title" field must never be empty
}

Now instead of silently returning empty arrays, the system knows when something is wrong:

$ tap doctor
hackernews/hot    ✓ ok     30 rows  (245ms)
google/trends     ✗ fail   0 rows   min_rows: expected ≥5, got 0
github/trending   ✓ ok     25 rows  (1.2s)
bbc/news          ✗ fail   3 rows   min_rows: expected ≥5, got 3

Two failures caught. Before your data went bad. Before anyone complained.

Watch: Real-Time Change Detection

Health checks catch breakage. But what about legitimate changes?

"I built Site Spy after missing a visa appointment slot because a government page changed and I didn't notice for two weeks."

$ tap watch hackernews hot --every 10m
2026-04-04T10:00  +added   "Show HN: Tap"  score=342
2026-04-04T10:10  +added   "Rust 2.0 announced"  score=128
2026-04-04T10:10  -removed "Old post fell off"  score=12

Run your program on an interval, diff the results, output only what changed. Pipe it to a file, Slack webhook, or another program.

The Self-Healing Loop

Put it all together:

# 1. AI writes a deterministic program once
$ tap forge "scrape Hacker News top stories"
✓ Saved: hackernews/hot.tap.js

# 2. Run forever at $0
$ tap hackernews hot
30 rows (245ms) Cost: $0.00

# 3. Watch for data changes
$ tap watch hackernews hot --every 1h

# 4. Daily health check
$ tap doctor --schedule "0 6 * * *"

# 5. Auto-heal when something breaks
$ tap doctor --auto

The loop: forge → run → watch → doctor → heal → run. You sleep. Your automations don't stop.

Why This Works

The key insight: AI should run at authoring time, not at runtime.

Forge uses AI once to write a deterministic program
Run executes it with zero AI — $0 per execution, 100% deterministic
Doctor detects breakage via health contracts — no AI needed
Heal re-invokes AI only when the site actually changes

99% of runs need zero AI. You only pay for intelligence when the world changes.

Tap is open source. 195+ pre-built automations included. Getting started takes 2 minutes.

Originally published at taprun.dev/blog

Programs Beat Prompts: How Tap Turns AI into a Compiler for Browser Automation

Leon — Thu, 02 Apr 2026 07:06:51 +0000

The Problem

Every time you ask an AI agent to do something in a browser, it costs money and time. Click here, type there, extract that — the AI figures it out from scratch every single time.

What if AI only had to figure it out once?

Tap: The Compiler Approach

Tap is a protocol + toolchain that turns AI's interface operations into deterministic programs (.tap.js files):

Forge — AI observes the page (network, DOM, a11y tree) and writes a tap program
Verify — Test the tap with different inputs
Run forever — The tap replays deterministically. Zero AI cost.

First run:  AI inspects → writes .tap.js     ($0.50)
Every run:  .tap.js replays deterministically ($0.00)

How It Works

8 core operations + 17 built-in operations = complete browser control protocol.

A tap program is plain JavaScript:

export default {
  site: "github",
  name: "trending",
  async run(tap) {
    await tap.nav("https://github.com/trending")
    return tap.eval(() => {
      return [...document.querySelectorAll('article.Box-row')].map(el => ({
        repo: el.querySelector('h2 a')?.textContent?.trim(),
        stars: el.querySelector('.octicon-star')?.parentElement?.textContent?.trim()
      }))
    })
  }
}

Multi-Runtime

The same tap runs on:

Chrome Extension — Uses chrome.scripting (undetectable)
Playwright — Headless capable, CI/CD friendly
macOS — Native apps via Accessibility API

A new runtime implements 8 methods, gets 17 built-in operations for free.

Community Skills

119 community skills across 55 sites — tap-skills (open source).

Why Not Just Use Playwright?

	Playwright	Tap
Who writes scripts?	You	AI forges them
Cost per run	N/A	$0.00 (deterministic)
Runtimes	1	3+ (Chrome, Playwright, macOS)
Community scripts	No ecosystem	119 skills

Get Started

curl -fsSL https://leonting1010.github.io/tap/install.sh | sh
tap github trending
tap hackernews hot

Homepage: leonting1010.github.io/tap
Skills (open source): github.com/LeonTing1010/tap-skills

Programs beat prompts. AI forges once, programs run forever.

Try it: taprun.dev | GitHub

Programs Beat Prompts: AI Forges Deterministic Interface Programs That Run Forever

Leon — Wed, 01 Apr 2026 08:20:35 +0000

Every time my AI agent automated a website interaction, it was burning tokens to solve the same problem it had already solved last run. Find the API. Locate the selector. Compose the steps. Re-solved, re-paid, every single time.

I built Tap to fix this. The core idea: operating an interface is a solved problem the moment you figure out how. So separate the figuring-out (AI's job, done once) from the executing (a deterministic program's job, done forever).

The Paradigm: Forging

forge_inspect → forge_verify → forge_save → tap.run
    AI analyzes    AI tests      AI saves     runs forever, zero AI

AI analyzes the live site, creates a .tap.js file, and that file runs forever — no LLM calls, no prompts, no API keys. Runs in <1s. Returns structured data. Same result every time.

Cost model: ~$0.50 in tokens to forge. Then $0.00 at runtime, forever.

The Protocol

Tap defines a minimal, complete contract for interface automation:

8 core operations (irreducible atoms):

eval · pointer · keyboard · nav · wait · screenshot · run · capabilities

17 built-in operations (composed from core):

click · type · fill · hover · scroll · pressKey · select · upload · dialog
fetch · find · cookies · download · waitFor · waitForNetwork · ssrState · storage

8 + 17 = every interaction a human can perform on any interface.

A new runtime implements 8 methods → gets 17 built-ins free. Write a tap once, run it on Chrome, Playwright, macOS native apps — same protocol.

106 Ready-to-Use Skills

# Install
curl -fsSL https://raw.githubusercontent.com/LeonTing1010/tap/master/install.sh | sh
tap update  # Pulls 106 skills across 50 sites

# Use
tap github trending --limit 5
tap hackernews hot
tap xiaohongshu hot

# Compose with Unix pipes
tap github trending | tap tap/filter --field stars --gt 1000

Skills cover GitHub, Reddit, YouTube, Hacker News, X/Twitter, Medium, arXiv, Bilibili, Zhihu, Xiaohongshu, Weibo, and 40+ more sites.

What a .tap.js looks like

// API-first: fetch data directly
export default {
  site: "hackernews", name: "hot",
  description: "Hacker News top stories",
  health: { min_rows: 10, non_empty: ["title"] },

  extract: async () => {
    const ids = await fetch('https://hacker-news.firebaseio.com/v0/topstories.json').then(r => r.json())
    const items = await Promise.all(ids.slice(0, 30).map(id =>
      fetch(`https://hacker-news.firebaseio.com/v0/item/${id}.json`).then(r => r.json())
    ))
    return items.map(i => ({ title: i.title, score: String(i.score), url: i.url, author: i.by }))
  }
}

Pure JavaScript. Zero AI at runtime. The health contract means tap doctor can self-verify this tap automatically.

MCP Native

Works with Claude Code, Cursor, Windsurf, and any MCP-compatible agent:

{
  "mcpServers": {
    "tap": { "command": "tap", "args": ["mcp"] }
  }
}

43 tools across 6 categories — run taps, forge new ones, inspect pages, intercept network traffic.

Security

Community taps are untrusted code. Three layers:

Sandbox — Deno Worker, zero permissions (no filesystem, network, env)
Static analysis — 7 CI checks on every PR to tap-skills
Data isolation — secrets and sessions never leave your machine

How It Compares

	Tap	Browser-Use / Stagehand	Playwright
AI at runtime	No (forge once)	Yes (every step)	No (manual scripts)
Detection risk	Undetectable	Detectable (CDP)	Detectable (headless)
Cost model	~$0.50 once, then $0	Tokens per session	Free (manual)
Reusable artifacts	.tap.js (shareable)	None (ephemeral)	None
Skills ecosystem	106 across 50 sites	None	None

GitHub

https://github.com/LeonTing1010/tap

106 skills, 3 runtimes, ~2,000 lines of Deno, zero dependencies.

Try it: taprun.dev | GitHub

Programs Beat Prompts: Tap Turns AI Into a Compiler for Interface Automation

Leon — Wed, 01 Apr 2026 07:51:33 +0000

The Problem

AI agents operate interfaces at $0.10/call, 2-5s latency. Every. Single. Time.

The Insight

Operating an interface is a solved problem the moment you figure out how. AI understands the page once. Execution doesn't need AI.

Tap: Forge Once, Run Forever

forge_inspect → forge_verify → forge_save → tap.run
   AI analyzes     AI tests      AI saves    $0 forever

8 core operations + 17 built-in. 3 runtimes (Chrome, Playwright, macOS). Unix pipes:

tap github trending | tap tap/filter --field stars --gt 1000
tap watch github trending --every 5m

106 skills across 50+ sites. Self-healing via tap doctor. Sandbox + CI security.

199 constraint tests define the product — no spec docs, code is the spec.

GitHub: https://github.com/LeonTing1010/tap

This post was published using Tap itself (devto/post tap).

Try it: taprun.dev | GitHub

Programs Beat Prompts: How Tap Turns AI Understanding Into Deterministic Programs

Leon — Wed, 01 Apr 2026 07:48:19 +0000

The Problem

AI agents need to operate interfaces — read data, click buttons, fill forms. But AI is too slow ($0.10/call, 2-5s latency) and too unreliable to drive every interaction.

The Insight

Operating an interface is a solved problem the moment you figure out how. The hard part is understanding the page. That's what AI is good at. The easy part is executing the same steps again. That doesn't need AI.

Tap: Forge Once, Run Forever

Tap separates understanding (AI, once) from execution (deterministic, forever):

forge_inspect → forge_verify → forge_save → tap.run
   AI analyzes     AI tests      AI saves    runs forever, $0

The Protocol

8 core operations — the irreducible atoms of interface interaction:

eval · pointer · keyboard · nav · wait · screenshot · run · capabilities

17 built-in operations composed from core. One program runs on Chrome Extension, Playwright, and macOS native apps.

Unix Pipes

Taps compose like Unix commands — auto TTY detection, no flags needed:

tap github trending | tap tap/filter --field stars --gt 1000
tap watch github trending --every 5m | tap tap/filter --field stars --gt 500

Self-Healing

tap doctor
  ✔ github/trending     score=1.0  25 rows (180ms)
  ✘ douyin/hot           score=0.0  0 rows

Health contracts + declared examples = taps verify themselves.

Security: 3 Layers

Sandbox — Deno Worker with zero permissions
Static analysis — 7 CI checks on every community PR
Data isolation — .gitignore blocks secrets, no git remote on user taps

v0.5.0 Highlights

199 constraint tests (safety + quality + principle)
tap doctor — self-healing health checks
tap contribute — PR workflow to community skills
tap watch — outputs changes only, time dimension
Forge captures real API traffic for accurate strategy
Sandbox for untrusted community taps

106 skills across 50+ sites

GitHub, Reddit, HN, X/Twitter, YouTube, Bilibili, Zhihu, Xiaohongshu, Weibo, Medium, arXiv, and more.

GitHub: github.com/LeonTing1010/tap
Skills: github.com/LeonTing1010/tap-skills

This post was published using Tap itself (devto/post tap).

Try it: taprun.dev | GitHub

Tap: Forge Once, Run Forever — Why AI Browser Automation Needs a Protocol

Leon — Mon, 30 Mar 2026 12:22:00 +0000

Every AI agent that interacts with the web faces the same problem: AI is too slow, too expensive, and too unreliable to drive a browser in real-time.Tools like Browser-Use and Stagehand burn tokens on every click. A simple "get GitHub trending" costs ~$0.15 and takes 30+ seconds. Every operation can hallucinate.## A Different Approach: ForgingWhat if AI only did the hard work once?T

Try it: taprun.dev | GitHub

Tap: Forge Once, Run Forever — Why AI Browser Automation Needs a Protocol

Leon — Mon, 30 Mar 2026 12:02:54 +0000

Every AI agent that interacts with the web faces the same problem: AI is too slow, too expensive, and too unreliable to drive a browser in real-time.

Tools like Browser-Use and Stagehand burn tokens on every click. A simple "get GitHub trending" costs ~$0.15 and takes 30+ seconds. Every operation can hallucinate.

A Different Approach: Forging

What if AI only did the hard work once?

That's Tap. Instead of AI controlling the browser at runtime, AI creates a deterministic script — and that script runs forever.

forge.inspect(url)     → AI analyzes the page
forge.verify(expr)     → AI tests the extraction
forge.save(site, name) → Script saved

tap.run(site, name)    → Runs forever. Zero AI. Zero tokens.

The Protocol

Tap defines 8 kernel primitives — the irreducible atoms of all human-interface interaction:

eval · pointer · keyboard · nav · wait · screenshot · tap · capabilities

And 16 stdlib operations built from the kernel:

click · type · hover · scroll · pressKey · select · upload · dialog
fetch · find · cookies · download · waitFor · waitForNetwork · ssrState · storage

A new runtime implements 8 methods — instantly gains 16 operations and every existing script.

The Numbers

	AI-per-step	Tap
Cost per run	~$0.15	$0.00
Latency	30+ seconds	< 1 second
Reliability	LLM may hallucinate	Deterministic
Composability	None	Taps call other taps

81 Skills, Ready to Use

tap install              # Install 81 community skills
tap github trending      # GitHub trending repos
tap hackernews hot       # Top HN stories
tap zhihu hot            # Zhihu trending

41 sites including X/Twitter, Reddit, GitHub, YouTube, Bilibili, Zhihu, Xiaohongshu, Weibo, Medium, arXiv. All using your real Chrome session. No API keys.

MCP Native

38 tools as an MCP server — works with Claude Code, Cursor, Windsurf, OpenClaw:

{
  "mcpServers": {
    "tap": { "command": "tap", "args": ["mcp"] }
  }
}

~1,800 Lines, Zero Dependencies

CLI + MCP server + executor + daemon + two runtimes — under 2,000 lines of Deno. No frameworks, no build step.

Try It

curl -fsSL https://raw.githubusercontent.com/LeonTing1010/tap/master/install.sh | sh
tap install && tap github trending

GitHub: github.com/LeonTing1010/tap
Skills: github.com/LeonTing1010/tap-skills

What sites would you forge a tap for?

Try it: taprun.dev | GitHub