---
title: "How to use AI to instrument your mobile app for observability"
metaTitle: "How to use AI to instrument your mobile app for observability"
slug: "ai-to-instrument-app"
blurb: "A walkthrough for using an AI coding agent to install the bitdrift Capture SDK, add user journey instrumentation, and verify the telemetry is actually firing."
metaDescription: "Learn how an agent can read your app, decide on a best approach, add the right instrumentation, and wire up the SDK in a single pass with bitdrift."
cover:
  url: "/assets/posts/ai-to-instrument-app/feature-hero-desktop@1x.webp"
  alt: "AI interface over a mobile codebase showing automated instrumentation steps."
socialThumbnail:
  url: "/assets/posts/ai-to-instrument-app/feature-hero-desktop@1x.webp"
  alt: "AI interface over a mobile codebase showing automated instrumentation steps."
coverYoutube:
  title: "Demo: using AI to instrument your mobile app for observability"
  src: "https://www.youtube.com/embed/iL-OrZCtX88?si=z_4bUOlrU7Pt4a_S"
  overlayText: "Watch AI instrumentation in action"
  overlayImage: "/assets/posts/ai-to-instrument-app/feature-hero-desktop@1x.webp"
  aspectRatio: "1120 / 616"
  titleSize: 32
author:
  - "steve"
tags:
  - "mobile"
  - "android"
publishedDate: "2026-07-24T12:00:00.000Z"
modifiedDate: "2026-07-24T12:00:00.000Z"

---

We recently introduced bd-instrumentation, the agent skill that installs and instruments the bitdrift Capture SDK. That unlocks full-resolution observability with a modern, minimalistic approach to instrumentation that can be entirely performed by AI.

AI and bitdrift change mobile observability in a way that's easy to undersell. An agent can read your app, decide on a best approach, add the right instrumentation, and wire up the SDK in a single pass. This post walks through exactly how to do that with bitdrift, including the prompt, the commands, and the code an agent generates.

## The walkthrough: instrumenting an app in one prompt

Here's the setup. On the left is an Android app open in Android Studio. In the middle is the repo's README. On the right is a terminal running Claude Code. Any agent that supports skills works here — Cursor, Codex, and Copilot included — but we'll use Claude Code in this walkthrough.

Two things need to be in place before the agent can do anything useful: the bitdrift CLI and the bitdrift skills.

### 1. Install the bd CLI

The CLI is the main tool the agent uses to talk to bitdrift — creating workflows, querying charts, and tailing logs from real devices. Install it with Homebrew:

```bash
brew tap bitdriftlabs/bd
brew install bd
```

Confirm it's installed and current:

```bash
bd --version
```

For example:

```bash
bd --version
bd 0.2.10 (294420f)
```

### 2. Install the bitdrift skills

Skills are what turn a general-purpose coding agent into one that knows bitdrift. They follow the open [agentskills.io](https://agentskills.io) standard and cover three areas: installing and configuring the SDK (`bd-instrumentation`), using the CLI (`bd-cli`), and searching the docs (`bd-docs`).

Install them with the skills CLI:

```bash
npx skills add bitdriftlabs/bd-skills
```

The installer will ask which skills to add and which agents to install them for. Select everything, add Claude Code alongside the defaults, and install globally with symlinks so every project on your machine can use them without duplicating files.

That's the entire setup. From here, the agent has the SDK knowledge and the platform access it needs.

### 3. Point your agent at the app

With the app open and Claude Code waiting, the instruction is one sentence:

```text
Instrument my app with the bitdrift SDK and include user journey instrumentation.
```

That second half matters. A user journey is a view of how people actually move through your app: the y-axis is 100% of your users, and each step shows what share of them reached a given screen. It's how you spot where people drop off — the screen that loses a third of users before checkout, the flow nobody finishes. Asking for it tells the agent not just to add the SDK, but to log the screens that make up the path you care about.

### 4. Sync and review the changes

The agent loads the instrumentation skill, reads through your app's files to understand its structure, and starts making changes. On Android, the moment it edits your Gradle files, Android Studio notices and asks to sync — that's it pulling in the SDK dependency.

You can watch each change as it lands. The dependency goes into your build file:

```kotlin
dependencies {
    implementation("io.bitdrift:capture:<latest-version>")
}
```

The logger gets started once, early in the app's lifecycle:

```kotlin
import io.bitdrift.capture.Capture.Logger
import io.bitdrift.capture.providers.session.SessionStrategy

Logger.start(
    apiKey = "<your-api-key>",
    sessionStrategy = SessionStrategy.ActivityBased(),
)
```

And screen-view calls get added at each step of the journey:

```kotlin
Logger.logScreenView("checkout")
```

That's the part worth pausing on. Starting the logger gives you bitdrift's out-of-the-box observability for free — crashes, ANRs, network requests, resource usage, and app launch timing — without you writing a single line for any of it. The `logScreenView` calls are the targeted layer on top: they're what assemble into the user journey, and they're the part the agent placed by reading your actual navigation, not a template.

When it finishes, you get a summary of everything it did: SDK added, logger initialized, and screens instrumented along the journey.

### 5. Confirm the data is real

This is the step people skip, and it's the most important one. A clean diff tells you the code looks right. It does not tell you the events are firing. Run the app, click through the flow you instrumented, and watch the logs come off the device:

```bash
bd tail android
```

If the screen views show up as you navigate, the instrumentation is real. If they don't, you've caught it in two minutes instead of two weeks. Either way, you now have a user journey building from live behavior.

## Where this saves you real time

The obvious win is setup: what used to be an afternoon of reading SDK docs, wiring up Gradle, and sprinkling log calls is now a single prompt. But the bigger wins show up after.

**Faster root cause.** When an issue lands, an agent that can query your telemetry goes straight to the relevant sessions instead of leaving you to grep dashboards. The instrumentation is already there, and so is something that can read it.

**Smarter alerting, less noise.** Because bitdrift controls capture remotely, you can start broad and tighten as you learn — without shipping. An agent can help you target the exact cohort and events that matter and drop the rest, so your signal doesn't drown in volume.

**More time shipping.** Less of your week goes to the mechanical parts of observability — the boilerplate, the redeploys to add one missing log — and more of it goes to the product.

## Where it can mislead you

AI-assisted instrumentation is genuinely good, but it is not a thing you turn on and stop thinking about.

**The agent doesn't know what matters to your product. You do.** It can find every screen in your app, but it can't tell you that the payment step is the one worth watching closely and the settings page mostly isn't. If you hand it a vague prompt, you'll get vague, evenly spread instrumentation — technically complete, strategically useless. Tell it which journey you care about.

**A correct-looking diff is not correct telemetry.** An agent can write a `logScreenView` call that compiles perfectly and never fires, because it's attached to a screen that's rarely reached or named something that doesn't match your funnel. The only way to know is to run the app and watch the events land. Trust the device, not the diff.

**Plausible is not the same as right.** Generated event names and fields can read as reasonable while quietly not matching the conventions the rest of your app uses, which makes them hard to query later. Skim the names. Keep them consistent.

The throughline is simple: let the agent do the mechanical work, and keep the judgment for yourself. It's very good at the SDK wiring and the boilerplate. You're still the one who decides what's worth knowing.

## A few habits that make it work

- **Say what you want measured.** "Instrument the onboarding-to-first-purchase journey" beats "add some logging" every time.
- **Verify on a device before you trust a chart.** `bd tail` is the fastest reality check you have.
- **Keep naming consistent.** Future you will query these events. Make them findable.
- **Start broad, then narrow.** Capture is remote, so you can tune what you collect without a release. Use that.
- **Re-run the agent as the app changes.** New flow, new journey — point it at the change rather than hand-editing.

## Try it

If you've been putting off instrumenting an app because the setup is tedious, this is the part that's actually easier than it used to be. Install the CLI, add the skills, and let your agent handle the wiring while you decide what's worth watching.

```bash
brew tap bitdriftlabs/bd && brew install bd
npx skills add bitdriftlabs/bd-skills
```

For the full picture on how bd-instrumentation works, see the [skill overview post](https://blog.bitdrift.io/post/skill-that-instruments-mobile-sdk).

To go further — querying telemetry, building workflows, and triaging issues from your agent or your own scripts — take a look at the [bitdrift Public API](https://blog.bitdrift.io/post/public-api) and what we've built at [bitdrift.ai](https://bitdrift.ai).

Interested in learning more? Check out [the sandbox](https://bitdrift.io/sandbox) or start a [free trial](https://bitdrift.io/signup) to see what working with Capture is like. You can also [get in touch](https://bitdrift.io/contact-us) for a demo or [join us in Slack](https://communityinviter.com/apps/bitdriftpublic/bitdrifters) to ask questions and share feedback.

---

## Frequently asked questions

### Which agents does this work with?

Any coding agent that supports the open skills standard — Claude Code, Cursor, Codex, and GitHub Copilot among them. The walkthrough above uses Claude Code.

### Do I have to use AI to instrument with bitdrift?

No. The SDK and CLI work the same whether you wire them up by hand or have an agent do it. The skills just make the agent route reliable.

### Does this change my app's architecture?

No. The agent adds the SDK and instrumentation calls to your existing code. What you ship behaves the same — you just get visibility into it.

### Does the agent need access to production data?

Not to instrument your app — that's local code work. To query telemetry and build workflows, the CLI authenticates against your bitdrift account, so the agent only sees what your account can see.

### Why do I need to verify the instrumentation if the agent wrote it?

Because compiling code and firing events are different things. An event can be syntactically perfect and still never trigger. Running the app and tailing logs or using the bitdrift real-time workflow debugger are strong ways to confirm the data is real.

### What platforms are supported?

The Capture SDK supports Android, iOS, and React Native, with more coming. The CLI is currently macOS-only.