DEV Community: Aditya Pandey

Build an AI Browser Agent Without Writing Playwright Code

Aditya Pandey — Fri, 10 Jul 2026 16:47:41 +0000

If you have ever tried to automate a modern web app, you know the pain. You spin up Playwright or Puppeteer, inspect network requests, write CSS selectors, wrangle cookies, and hope the layout does not shift next week. It always shifts. Then you are back in the DevTools panel, patching selectors at 11pm.

What if you never wrote the browser code at all?

That is the pitch behind Webcmd, an agent runtime that turns websites, logged-in dashboards, APIs, and browser sessions into deterministic CLIs. You hand an AI agent a goal. The agent crawls the target, works out the UI and browser state, finds the useful requests, and packages all of it into a repeatable command. You get a stable CLI instead of a pile of selectors.

Here is how to build one, start to finish, without touching Playwright.

TL;DR

Install Webcmd where your coding agent can run a shell (npm install -g @agentrhq/webcmd, Node.js 20+).
Instead of writing selectors, you write a plain-language prompt describing the command you want.
The agent explores the site, picks a strategy, and generates a verified adapter.
Logged-in sites use named profiles, so credentials never end up in code.
When a site changes, you ask the agent to heal the command instead of rewriting it yourself.

1. Install Webcmd

Webcmd runs wherever your coding agent has shell access. It needs Node.js 20 or newer.

npm install -g @agentrhq/webcmd

Before you ask an agent to build anything, check the local runtime, daemon, and browser bridge:

webcmd doctor

If doctor is green, your agent has everything it needs to explore a site and write a command.

2. The "coding" part: prompting the agent

Here is the mental shift. You do not write Playwright selectors. You write a plain-language prompt, and your AI coding assistant crawls, implements, and verifies an adapter (the code that turns a surface into one or more commands).

Example 1: a public scraper

Say you want to scrape job listings. You never open DevTools to find the DOM. You describe the command:

Create a Webcmd CLI for example.com job search. I want:
- command: webcmd example jobs
- input: search query and optional location
- output: title, company, location, salary_text, posted_at, url
- format: JSON-friendly rows
Keep it as a private adapter and verify it with a smoke test.

The agent explores the site, picks the best strategy (PUBLIC for open pages, UI when it has to drive the live page), and writes the adapter. You review a command, not a wall of selectors.

Example 2: logged-in workflows

Authentication is where traditional browser automation gets ugly. Webcmd handles it with profiles, which keep browser identities and login state separate from the adapter code.

To automate a dashboard behind a login, point the agent at a profile:

Build a Webcmd adapter for the logged-in Acme dashboard that lists invoices. Use my `work` browser profile. Return invoice_id, customer, due_date, amount, status, and detail_url. Do not store credentials in code. If I need to sign in, pause and ask me to.

The login lives in the profile, not the command. That one detail is the difference between a demo and something you would run against a real account.

3. Using your new command

Once the agent finishes the exploratory work, you have a stable, deterministic CLI. You (or other agents) call it directly, no browser required:

webcmd acme invoices --format json

Because the output is structured JSON, this command becomes a reliable building block. Pipe it into a cron job, a data pipeline, or another agent, and it behaves the same way every run.

4. Healing broken commands

The real payoff shows up in maintenance. A site updates its UI or renames an API field, and your automation stops working. With a hardcoded Playwright script, that means diffing the new DOM by hand.

With Webcmd, you ask the agent to fix it:

The command `webcmd acme invoices` used to work but now returns empty rows. Diagnose it, repair the adapter, run verification, and explain what changed. Keep the output schema unchanged.

The agent uses Webcmd tracing and browser tooling to find what moved (selectors, API fields, or auth behavior), patches the adapter, and gets the CLI green again. Your downstream scripts never see the change, because the output schema stays fixed.

The takeaway

Traditional browser automation makes you the maintenance crew for every site you touch. Webcmd moves that burden to an agent: it explores once, freezes the result into a command, and repairs the command when the site drifts. You stop babysitting selectors and start working with structured, reliable data.

If you want to try it, the Webcmd quickstart walks through install, webcmd doctor, and your first agent-authored command in a few minutes.

Have you moved any of your Playwright scripts over to an agent runtime yet? I would like to hear what broke and what stuck. Drop a comment.

Stop "Vibe Checking" Your AI. Use Snapshot Testing Instead.

Aditya Pandey — Fri, 16 Jan 2026 11:08:18 +0000

We have all been there.

You write a perfect prompt for your AI feature.
It works great on your machine.
Two weeks later, you tweak the system prompt slightly.
Suddenly, your bot starts replying with 5-paragraph essays instead of one-liners.

In traditional web development, we solved this years ago with Snapshot Testing. If a UI component changes by one pixel, the test fails until you approve it.

Why aren't we doing this for AI?

Most of us are still "Vibe Checking" manually running the prompt, reading the output, and saying, "Yeah, seems okay."

I built a tool to fix this.

Introducing SafeStar

SafeStar is a zero-dependency CLI tool that brings the "Snapshot & Diff" workflow to AI engineering.

It doesn't care if you use Python, Node, or curl. It treats your AI as a black box and answers one question: "Did the behavior change compared to last time?"

How it works

It follows a Git-like workflow:

Snapshot a baseline of "good" behavior.
Run your current code.
Diff the results to detect drift.

Quick Start

You can try it right now without changing your code.

1. Install it

npm install --save-dev safestar

2. Define a Scenario
Create a file scenarios/refund.yaml. Tell SafeStar how to run your script using the exec key.

name: refund_bot
prompt: "I want a refund immediately."

# Your actual code command
exec: "python3 my_agent.py"

# Run it 5 times to catch randomness/instability
runs: 5

# Simple guardrails
checks:
  max_length: 200
  must_not_contain:
    - "I am just an AI"

3. Create a Baseline
Run it until you get an output you like, then "freeze" it.

npx safestar baseline refund_bot

4. Check for Drift in CI
Now, whenever you change your prompt or model, run this:

npx safestar diff scenarios/refund.yaml

If your model drifts, SafeStar screams at you:

--- SAFESTAR REPORT ---
Status: FAIL

Metrics:
  Avg Length: 45 chars -> 120 chars
  Drift:      +166% vs baseline (WARNING)
  Variance:   0.2 -> 9.8 (High instability)

Why I built this

I was tired of complex evaluation dashboards that give me a "correctness score" of 87/100. I don't care about the score. I care about regressions.

If my bot was working yesterday, I just want to know if it is different today.

SafeStar is open source, local-first, and fits right into GitHub Actions.

I built a "Vibe-Based" Notepad with Tauri v2 (It weighs 4MB)

Aditya Pandey — Mon, 05 Jan 2026 18:03:04 +0000

Stop me if you've heard this one:
A developer gets tired of their tools, decides to build their own, accidentally creates a cult philosophy, and learns DevOps along the way.

Hi, I'm Aditya. Last weekend, I looked at my text editor and realized something: It has no soul.

VS Code is a cockpit. Notion is a project manager. Obsidian is a graph database.
Where is the app for just... bleeding onto the page?

So I built SummerPad.
It's an open-source, local-first "Mood Engine" for writers. And I built it using the Tauri v2 Super-Stack.
Here is how (and why) I did it.

🏗 The Stack (RIP Electron)

I wanted this app to launch instantly. If I have an idea at 3 AM, I can't wait for a 150MB Electron helper process to spin up.

Core: Tauri v2 (Rust backend).

UI: React + Vite.

Styling: Tailwind CSS.

Animations: Framer Motion (crucial for the "feel").

Build System: GitHub Actions (Cross-platform compilation).

The Result: A native Windows, Mac, and Linux app that weighs about 4MB.

🎨 The "Vibe Engine" Architecture

Most apps treat themes as "Light Mode" or "Dark Mode." Boring.
I wanted Realities.

In SummerPad, selecting a font doesn't just change the typeface; it changes the entire DOM state.

// The Vibe Configuration
const FONTS = [
  { 
    name: 'Playfair Display', 
    label: 'The Romantic', 
    colors: { bg: '#F2EBE3', text: '#4A4A4A' } // Warm Beige
  },
  { 
    name: 'JetBrains Mono', 
    label: 'The Hacker', 
    colors: { bg: '#09090b', text: '#22c55e' } // Terminal Green
  },
  { 
    name: 'Righteous', 
    label: 'The Cyberpunk', 
    colors: { bg: '#11001c', text: '#ff2a6d' }, 
    glow: true // <--- The Secret Sauce
  }
];

When a user selects "The Cyberpunk," we don't just switch CSS variables. We inject a dynamic text-shadow property directly into the input components to create a neon burn-in effect:

const glowStyle = selectedFont.glow 
  ? { textShadow: `0 0 10px ${colors.text}, 0 0 20px ${colors.text}` } 
  : {};

<textarea style={{ ...glowStyle, color: colors.text }} />

It’s simple, but it feels magical.

📸 The "Clout" Export (Solving the Screenshot Problem)

Writers love sharing snippets on Twitter/X, but OS screenshots look messy (UI clutter, cursors, bad cropping).

I built a rendering engine directly into the editor using html2canvas.

User clicks the Camera Icon.

React freezes the state.

We invisibly clone the DOM, strip out the UI (buttons/scrollbars), inject a watermark, and render it at 3x scale for crisp text.

We dump the Blob directly to the user's clipboard.

const handleExport = async () => {
  const canvas = await html2canvas(editorRef.current, {
    scale: 3, // Retina quality
    backgroundColor: currentTheme.bg,
    onclone: (doc) => {
      // Hack: Force height to auto to capture full text without scrollbars
      doc.querySelector('.editor').style.height = 'auto';
    }
  });

  // Direct to clipboard (No "Save As" dialog friction)
  canvas.toBlob(blob => navigator.clipboard.write([new ClipboardItem({'image/png': blob})]));
};

🔮 What's Next?

SummerPad is 100% open source. I'm currently looking for contributors who want to help add:

Typewriter Sounds (Rust-based audio triggers on keypress).

Zen Mode (Fade out UI completely when typing).

📥 Try it out

You can download the binary for your OS here:
👉 Download SummerPad

Or check the code (and maybe give it a ⭐️?):
👉 GitHub Repository

How to Build a Billion-Dollar Company by Giving Everything Away for Free

Aditya Pandey — Sun, 04 Jan 2026 10:01:48 +0000

My friend called me crazy when I told him I was contributing to Cal.com, an open source scheduling platform. "Why would you work for free on something that's already free?" he asked. "How do they even make money?"

Six months later, Cal.com raised $25 million and is building a legitimate business around their free, open source calendar tool. My friend still thinks I'm crazy, but now he's asking how this whole "give everything away and somehow get rich" thing actually works.

Here's the thing that blows most people's minds: some of the most valuable tech companies in history built their entire business on open source software. Red Hat sold to IBM for $34 billion. MongoDB is worth over $20 billion. Elastic, GitLab, HashiCorp. All built on code that anyone can download, modify, and use for free.

The traditional business logic says this should be impossible. You can't build a profitable company by giving away your core product for free. Except you absolutely can, and the companies that figure out how to do it right often dominate their entire industry.

The secret isn't in the code. It's in understanding what customers actually pay for.

When I started contributing to open source projects, I thought the business models were straightforward. Make free software, charge for support, profit. That naive view lasted about five minutes into reading actual company strategies. The reality is way more sophisticated, and way more interesting.

Most people think open source companies fail because they can't monetize free software. The truth is the opposite. Open source companies fail when they don't understand the difference between their product and their business. The code is the product. The business is everything else customers need to actually use that code in production.

Let me break down how this actually works, because once you see the pattern, you'll understand why open source isn't just a viable business model. It's often the dominant one.

The Economics Nobody Talks About

Traditional software companies spend massive amounts on customer acquisition. They build sales teams, run ads, attend conferences, and pray someone will try their closed, proprietary solution. Open source companies flip this entire model.

Instead of convincing people to try your software, you make it so good and so accessible that developers naturally gravitate toward it. Every GitHub star, every Stack Overflow answer, every blog post about your project becomes free marketing. Developers become your unpaid sales force because they genuinely love using your tools.

Cal.com gets this. They built a scheduling tool that's genuinely better than Calendly for many use cases, made it completely open source, and let the developer community discover it organically. No massive ad spend, no aggressive sales tactics. Just good software that solves real problems.

This creates what economists call a "network effect." The more people use your open source project, the more valuable it becomes. More users mean more contributors, more features, better documentation, and stronger community support. This makes it even more attractive to new users, creating a virtuous cycle that's incredibly hard for closed source competitors to break.

But here's where it gets really interesting from a business perspective. All those free users aren't just costs you're absorbing. They're your R&D department, your QA team, and your product marketing all rolled into one. They find bugs you'd never catch, build features you'd never think of, and advocate for your solution in ways no paid marketing could achieve.

The companies that understand this don't see free users as a drain on resources. They see them as the foundation of a business model that scales better than any traditional software company ever could.

The Three Models That Actually Work

Most people think there's only one way to monetize open source: charge for support. That's like saying there's only one way to monetize a website: banner ads. The reality is much more nuanced, and the successful companies usually combine multiple approaches.

The Open Core Strategy is probably the most common approach. You open source the core functionality that gets people hooked, then charge for enterprise features that businesses actually need. MongoDB does this perfectly. Their core database is completely free and open source. But if you want advanced security, monitoring, or management tools, you pay for MongoDB Atlas or Enterprise Advanced.

The genius here is that developers fall in love with the free version, build applications on it, and then their companies naturally upgrade when they need enterprise capabilities. You're not selling to developers. You're selling to the businesses that employ developers who already chose your technology.

The Hosted/Cloud Strategy takes your open source software and sells it as a managed service. Customers get all the benefits of your software without the headache of running it themselves. They're not paying for the code. They're paying for convenience, reliability, and not having to hire DevOps teams.

GitLab exemplifies this approach. You can download and run GitLab on your own servers for free. But most companies would rather pay GitLab to host, maintain, and scale their Git repositories rather than deal with that complexity internally. Same software, completely different value proposition.

The Dual Licensing Model is the most aggressive approach. You offer your software under two licenses: a free open source license with restrictions (usually around commercial use), and a paid commercial license for businesses that need more flexibility. This works particularly well for developer tools and infrastructure software.

Cal.com uses elements of this strategy. The core scheduling functionality is open source, but they offer Cal.com Cloud as a hosted solution for teams that want the benefits without the setup complexity. They're also building premium features and integrations that make sense for businesses but aren't necessary for individual users.

The key insight across all these models is that you're not selling software. You're selling outcomes. Businesses don't want to run databases, manage Git repositories, or configure scheduling systems. They want their applications to work, their code to be safe, and their meetings to be organized. Open source gives them confidence in the underlying technology, while paid services deliver the business outcomes they actually care about.

Why This Strategy Dominates Tech

There's a reason why open source business models keep winning in competitive markets. It's not just about the economics. It's about trust, transparency, and long-term thinking that resonates incredibly well with technical buyers.

When a developer evaluates closed source software, they're making a leap of faith. They don't know how it works internally, they can't fix bugs themselves, and they're completely dependent on the vendor for updates and improvements. With open source software, they can read the code, understand the architecture, and have confidence that they're not locked into a black box solution.

This trust factor becomes crucial as companies scale. CTOs making infrastructure decisions aren't just buying software for today. They're making choices they'll live with for years. Open source gives them an escape hatch. Even if the company behind the software disappears or makes bad decisions, the code will still exist and can be maintained by the community or internally.

The transparency of open source also accelerates innovation in ways that closed source software can't match. When Netflix built their entire streaming infrastructure on open source tools, they didn't just use the software. They contributed improvements back to the community, making the tools better for everyone. This creates a positive feedback loop where the biggest users become the biggest contributors, constantly improving the product for everyone.

From a competitive perspective, this creates incredibly strong moats. Once an open source project gains momentum, it becomes very difficult for closed source competitors to catch up. Why would developers choose a proprietary alternative when there's a battle-tested, community-driven solution that's constantly improving?

Companies like Docker, Kubernetes, and React didn't just win their respective markets. They essentially ended the competition. Once these tools reached critical mass in the developer community, alternative approaches became irrelevant almost overnight.

The Mistakes That Kill Open Source Startups

Not every open source company succeeds, and the failures usually follow predictable patterns. The biggest mistake is treating open source as a marketing strategy instead of a core business strategy. Companies that slap an open source license on mediocre software and expect the community to do the hard work of building a business around it are usually disappointed.

The community can smell insincerity from miles away. If your open source project feels like a demo version of your real product, developers will find alternatives. If your documentation is poor, your contribution process is complicated, or your company doesn't engage authentically with users, the network effects work against you instead of for you.

Another common mistake is optimizing for the wrong metrics. Companies that focus obsessively on GitHub stars or download numbers without thinking about conversion to paid services often build impressive-looking projects that generate no revenue. The goal isn't to maximize free usage. It's to build a sustainable funnel from free users to paying customers.

Timing matters too. Open sourcing too early, before your software is genuinely useful, means you'll never build the community momentum you need. Open sourcing too late, after competitors have established themselves, means you're playing catch-up in a market that's already moving toward other solutions.

The companies that succeed treat open source as a long-term investment in building the best possible solution to a real problem. They engage authentically with their communities, build genuinely useful software, and create clear paths from free usage to paid value. It's not a get-rich-quick scheme. It's a patient, strategic approach to building technology businesses that can dominate their markets for decades.

The Bottom Line for Entrepreneurs

If you're thinking about building an open source business, here's what actually matters: start with a problem that developers face regularly, build something genuinely better than existing solutions, and make it ridiculously easy for people to get started with your software.

Focus on creating value for your free users first. A thriving community of happy free users is the foundation everything else builds on. But always have a clear vision for how businesses will pay you for additional value. Whether that's hosting, support, premium features, or professional services, you need a path from free to paid that makes sense for your specific market.

Don't underestimate the complexity of building and maintaining a community. It's not just about writing code. It's about documentation, communication, user support, and creating an environment where other developers want to contribute. This is often harder than building the initial software.

But if you get it right, you're not just building a business. You're building a movement. And movements, especially in technology, tend to be more durable and more valuable than traditional companies. The developers who contribute to your project become invested in its success. The companies that build on your software become stakeholders in your ecosystem.

That's not just a business model. It's a competitive advantage that's almost impossible to replicate through traditional means. And in a world where software is eating everything, that advantage might be the most valuable thing you can build.

Why Android is Not Really Open Source

Aditya Pandey — Tue, 30 Dec 2025 13:30:20 +0000

I used to believe Android was the poster child of open source. "It's Linux-based, it's free, it's open, right?" That's what I told myself when I first tried building a custom ROM in college. I pulled down the Android Open Source Project (AOSP) expecting the full Android experience.

What I got instead was a half-baked shell. No Play Store. No Gmail. No Maps. Just a plain OS that felt more like a demo than the "world's most popular open source project."

That moment taught me something important: Android might be open source on paper, but in practice? It's a tightly controlled Google product.

Android's Open Source Theater

Sure, AOSP looks impressive on the surface. You can clone the repo, build it, flash it, and boom you've got Android. That's leagues better than iOS, which is locked down from top to bottom.

But here's what nobody tells you: the Android you download from AOSP isn't the Android anyone actually uses.

The version running on your phone comes loaded with Google Mobile Services (GMS). That means the Play Store, Google Maps, YouTube, Chrome, Gmail, and all those APIs that third party apps depend on. None of that stuff is in AOSP. It's all closed, proprietary, and locked behind Google's licensing agreements.

This is where most developers hit the wall. You think Android is yours to hack and remix, but the second you need real features like push notifications, location services, app distribution you slam into Google's paywall.

Google's Real Power Play

Here's how the game actually works: if Samsung, Xiaomi, OnePlus, or any phone maker wants to ship devices with the Play Store, they have to sign Google's licensing deal. And that deal isn't just "here, use our store." It comes with requirements: preload Google apps, make Google Search the default, bundle Chrome. That's how Google keeps its ecosystem dominant while keeping the base code "open."

Companies that don't play ball get crushed. Look at Huawei. Google banned them from using Google services in 2019, and their phones became basically unsellable outside China overnight. They scrambled to build HarmonyOS and their own app store, but let's be real, it's not the same experience.

Amazon tried the same thing with FireOS. It's built on AOSP, but without Google services it feels like you're using a completely different operating system. Amazon spent years building their own Appstore, maps, and notification systems, and it still doesn't compare.

Even enthusiasts feel the pain. Custom ROMs like LineageOS are incredible community projects, but ask anyone running them: life without Google Play Services sucks. Apps crash, APIs break, the whole experience falls apart. As a developer, you can see how much of "Android" actually runs on Google's proprietary code.

You can fork Android, technically. But unless you've got billions to rebuild Google's entire ecosystem, you're shipping broken software.

The Bigger Game Here

For me, this whole "Android is open source" thing isn't really about phones. It's about how companies weaponize openness. Open source doesn't equal freedom it equals adoption. Google open-sourced AOSP so hardware makers everywhere could build cheap devices and flood the market. That's why Android dominates globally. But the real lock-in happens in that closed layer of services on top.

This pattern shows up everywhere. Chromium is open source, but Google Chrome with sync, DRM, and integrations is what people actually use. Elasticsearch was open until AWS built a competing service, forcing Elastic to change their license. MongoDB did the same thing. Open source gets the party started, but the money and control live in the proprietary add-ons.

When I flashed AOSP on my old phone and stared at that barebones homescreen, it finally clicked. Android without Google isn't Android. It's a skeleton. AOSP still has value (it powers forks, research projects, IoT devices), but it shows how "open" can be more marketing than reality.

If you care about open source, here's the real lesson: don't confuse open code with open ecosystems. The code might be free, but power belongs to whoever controls the services, distribution, and defaults. In Android's case, that's Google, and they've played this game better than almost anyone.