# Why LLMs Like ChatGPT, Gemini, and Claude Understand FinalRun Identifiers Better Than XPath

The software world is buzzing with the rise of Large Language Models (LLMs) like **ChatGPT**, **Gemini**, and **Claude**. These tools promise to generate code, automate complex workflows, and even write full-fledged test scripts, all from simple natural language instructions.

One of the most exciting frontiers for this technology is **mobile test automation**: telling an AI, *“Tap the login button,”* and letting it handle the rest.

But there's a problem, a very old one. It's called **XPath**.

While LLMs are capable of generating Appium test code, they often stumble when it comes to building reliable, accurate XPath locators. It’s not a flaw in the models, it's a mismatch between how humans communicate and how XPath works.

That’s where [**FinalRun**](https://www.finalrun.app) comes in. With a structured, human-readable format for identifying UI elements, FinalRun bridges the gap between intent and automation, unlocking a level of AI accuracy and resilience that XPath was never built to support.

---

## The Core Problem: Why LLMs Struggle With XPath

To understand why FinalRun changes the game, let’s first look at what’s broken with XPath.

### 1\. **Brittleness and Strict Hierarchies**

Even when LLMs are given screenshots, XPath still relies on rigid UI structure, not what’s visually rendered. A small layout change, like wrapping a button in a new container, can break the XPath even though nothing looks different on screen. LLMs can understand what the user wants, but XPath forces them to guess how the UI is built behind the scenes, which often leads to fragile and unreliable locators.

### 2\. **No Spatial or Relational Awareness**

Consider this instruction:

> *“Click the trash icon to the right of ‘My Document.’”*

XPath has no built-in way to understand *"right of"*. The best it can offer is something like `following-sibling::`, which only checks if one node follows another in code, not on the screen. In responsive or dynamic UIs, that’s a dangerous assumption.

### 3\. **Cryptic and Unintuitive Syntax**

XPath is a dense query language that even seasoned engineers struggle to write correctly. Now imagine asking an LLM to produce this:

```json
//android.widget.LinearLayout[.//android.widget.TextView[@text='Submit'] and .//android.widget.Button]
```

One syntax error, one wrong assumption about the UI, and the test fails. XPath is fragile, hard to maintain, and deeply unfriendly to generative AI.

---

## FinalRun Identifiers: Built for Humans and AI

FinalRun replaces XPath with **declarative, structured identifiers** written in JSON. Instead of guessing a path through the DOM, you describe the element by what it **is** and how it **relates** to other elements.

Here’s a simple example:

```json
{
  "text": "Submit",
  "insideOf": { "id": "footer" }
}
```

It’s readable. Logical. And perfectly aligned with how LLMs think.

But FinalRun goes even further—with support for **relational** and **spatial** logic.

### Supported properties:

* `text`, `id`, `type`, `accText` (accessibility label)
    

### Supported relationships:

* `insideOf`, `containsDescendants`
    

### Supported spatial logic:

* `rightOf`, `leftOf`, `topOf`, `bottomOf`
    

This vocabulary allows an LLM to translate natural instructions directly into automation-ready identifiers—with no guesswork, and no brittle hierarchy dependencies.

> [Checkout the documentation on element identifiers](https://finalrun.gitbook.io/finalrun/advanced/element-identifier)

---

> ***📅*** [***Book a Demo***  
> See how Fi](https://calendly.com/arnold-finalrun/30min)***nalRun fits into your existing workflow with a live Demo.***

## Real-World Scenarios: FinalRun vs XPath in LLM Generation

### 🔍 **Scenario 1: Spatial Relationship**

**Prompt**: *“Find the settings icon that is to the right of the ‘Profile’ label.”*

#### ❌ XPath:

```json
//android.widget.TextView[@text='Profile']/following-sibling::android.widget.ImageView
```

* Only works if both elements are siblings in the XML structure.
    
* Breaks easily if layout changes.
    
* Doesn’t guarantee *visual* “right of.”
    

#### ✅ FinalRun:

```json
{
  "type": "icon",
  "rightOf": { "text": "Profile" }
}
```

* Mirrors user intent exactly.
    
* Leverages actual screen coordinates, not code structure.
    
* Simple and reliable for both humans and LLMs.
    

---

### 📦 **Scenario 2: Containment Logic**

**Prompt**: *“Target the product card that contains both the text ‘Organic Bananas’ and a button with the text ‘Add to Cart.’”*

#### ❌ XPath:

```json
//android.view.ViewGroup[.//android.widget.TextView[@text='Organic Bananas'] and .//android.widget.Button[@text='Add to Cart']]
```

* Dense and unreadable.
    
* Highly fragile—small DOM changes can break it.
    
* Hard for LLMs to generate consistently.
    

#### ✅ FinalRun:

```json
{
  "containsDescendants": [
    { "text": "Organic Bananas" },
    { "text": "Add to Cart" }
  ]
}
```

* Clean, expressive, and self-documenting.
    
* Perfect 1:1 mapping with the user’s natural instruction.
    
* LLMs excel at generating structured data like this.
    

---

## Why FinalRun Works So Well with LLMs

### **Semantic and Not Structural**

LLMs work by understanding **meaning**, not memorizing code patterns. FinalRun identifiers describe *what* something is and *how* it relates to other things—not *where* it lives in a brittle hierarchy.

### **Uses JSON LLMs' Native Language**

LLMs are trained extensively on JSON, API specs, config files, and structured logs. JSON is predictable, easy to generate, and easy to validate.

### **Aligns With Human Thought**

Users think in terms of relationships and meaning:

> *“The red button in the header,”* not *“/html/body/div\[1\]/button\[3\]”*.

FinalRun gives LLMs a vocabulary to express this intent directly.

### **Enables Smart, Self-Healing Automation**

Because FinalRun identifiers are expressive and spatially aware, LLMs (or test engines) can use alternate paths when one fails—making automation more resilient and adaptive.

---

## Conclusion: A New Foundation for AI-Driven Testing

The reason LLMs perform better with FinalRun isn’t about better AI—it’s about better **design**.

FinalRun identifiers are structured, expressive, and resilient. They speak the same language LLMs were trained on. XPath, in contrast, is a relic of a time before AI—built for rigid DOM traversal, not natural understanding.

If you’re building the future of test automation—where tests are written in English and powered by AI—then **FinalRun identifiers are the bridge between intent and execution**.

## **Related Reading**

Read our story behind why we took this new approach to element identification:

[How We Set Out to Solve the XPath Problem in Mobile UI Test Automation](https://hashnode.com/post/cmd8m76mq000802ie8dh0g08d)

[The future of UI Element Targetting: Finalrun Identifiers beats Xpath](https://blogs.finalrun.app/the-future-of-ui-element-targeting-why-finalrun-beats-xpath)

> ***📅*** [***Book a Demo***  
> See how Fi](https://calendly.com/arnold-finalrun/30min)***nalRun fits into your existing workflow with a live Demo.***