惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

D
DataBreaches.Net
IT之家
IT之家
The Cloudflare Blog
Apple Machine Learning Research
Apple Machine Learning Research
WordPress大学
WordPress大学
N
Netflix TechBlog - Medium
阮一峰的网络日志
阮一峰的网络日志
P
Proofpoint News Feed
L
LangChain Blog
博客园 - Franky
美团技术团队
J
Java Code Geeks
Microsoft Security Blog
Microsoft Security Blog
博客园 - 叶小钗
小众软件
小众软件
Y
Y Combinator Blog
B
Blog RSS Feed
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
D
Docker
Hugging Face - Blog
Hugging Face - Blog
Jina AI
Jina AI
罗磊的独立博客
大猫的无限游戏
大猫的无限游戏
Vercel News
Vercel News

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
AI-Native Mobile Testing: What It Actually Means in 2026
Sharmin Sira · 2026-05-04 · via DEV Community

Sharmin Sirajudeen

AI-Native Mobile Testing: What It Actually Means in 2026

The phrase "AI-native" has been thrown around in the testing space since 2019. Almost every tool calling itself that just bolts a language model on top of Appium and ships the same brittle XPath selectors with a new label.

That's not AI-native testing. That's Appium with a chatbot.

This post is about what AI-native actually has to mean to be worth anything — and what it changes about how mobile teams ship.

The pattern that broke testing for the last decade

Traditional mobile UI testing has a well-known failure mode. You write hundreds of tests with hardcoded element IDs or XPath selectors. Then half of them break each release for reasons that have nothing to do with bugs — a designer moved a button into a BottomSheet, a resource ID got renamed, an animation timing changed. Forty tests turn red overnight.

Engineering teams burn entire sprint days fixing tests for code that works fine. The economics are absurd: you spend more on test maintenance than the tests prevent in production bugs. (I covered the deeper history of why this happens in Evolution of Mobile Automation.)

The dominant fix from the last decade was "better selectors" — accessibility IDs, more stable resource paths, page-object patterns. None of it fixed the fundamental problem: a test that says "tap the element with id btn_login" couples the test to an implementation detail that has no business being part of the test contract.

What AI-native actually means

A real AI-native testing tool does one structural thing differently: the AI is the orchestrator, not a polish layer.

Concretely, that means the test framework hands the AI:

  • the current screen (screenshot + parsed UI tree, in plain text)
  • a description of what the test is trying to accomplish ("log in with these credentials")
  • the list of available actions (tap, type, swipe, etc.)

…and the AI decides what to do, step by step. No selectors. No hardcoded IDs. No XPath. The AI looks at the screen, notices a button labeled "Login" near a username field, taps it. If next release the button gets a new background and moves down 80 pixels, the AI doesn't care. It still sees a button labeled "Login," it still taps it. The test passes.

Drengr is one implementation of this pattern. It's a single Rust binary that exposes three tools to any MCP-aware AI client (Claude Desktop, Cursor, Windsurf today):

drengr_look      observe the current screen + UI tree
drengr_do        execute a tap / type / swipe / draw / key event
drengr_query     read structured data (devices, activity, crashes)

Enter fullscreen mode Exit fullscreen mode

That's the whole surface. Three verbs, no XPath, no Appium daemon to keep alive.

What it changes economically

Once the AI is the orchestrator, two things shift:

1. Test maintenance approaches zero. The test prompt ("log in with test@example.com / pw123 and verify you land on the dashboard") rarely changes between releases. The implementation underneath (button labels, layout, animations) can change freely without breaking the test. Maintenance cost was the entire reason mid-size companies stopped writing UI tests at all. Removing it puts UI testing back on the table for teams that wrote it off.

2. The audience widens. Indie developers and small teams who could never afford a dedicated QA engineer are now in scope. The cost of one full-time Espresso maintainer was what kept many small apps shipping untested. An AI-native testing layer effectively replaces that role for the cost of a Claude or Cursor subscription. (How drengr's architecture lines up with what academic researchers have found, in Field Notes.)

Beyond testing: the same primitives, different audience

The interesting thing once you have an AI controlling a real device is that the testing use case stops being the most important one.

The same drengr_look / drengr_do / drengr_query primitives let an AI agent on the user's machine:

  • Open Maps and start navigation when the user says "drive me home"
  • Scroll through Instagram and report sponsored posts
  • Pay a bill in a banking app on behalf of someone with a motor disability
  • Run any of the long-tail "things you'd ask a human assistant to do on your phone" tasks

Mobile QA was the first audience because the pain is most acute there. The AI-agent-builder audience is much larger. If you're building anything that wants an AI to control a real mobile device — testing, accessibility, personal assistance, something I haven't thought of — the control plane is the part you don't want to write from scratch. (That argument in full: AI Can Browse the Web. Why Can't It Tap a Phone?)

Get started

Drengr is free. Install through Claude Code with one command, verify with a second:

claude mcp add drengr -- npx -y drengr mcp
drengr doctor

Enter fullscreen mode Exit fullscreen mode

Then point your agent at any Android device or iOS simulator and watch what happens when the model has hands. No XPath. No selectors. No find_element(By.ID, "btn_login") to maintain across forty test files for the rest of your career.

That's what AI-native is supposed to mean.