DEV Community: Valentine Tikhomirov

My harness taught the agent how to build. Now it needs to see.

Valentine Tikhomirov — Thu, 08 Oct 2026 20:55:51 +0000

At the end of my last post I said the next step was letting my pipeline iterate on its own review findings. I didn't get there. I ran into something more basic first: the part of the harness that lets the agent use the app.

That part, rn-app-driver, reads the React component tree and taps the simulator so the agent can check its own work. It did its job. But the more I used it, the more it felt like the wrong shape for the problem. So I pulled it out of the harness and started building a separate tool around it.

This post is about why, and about a few things an agent simply can't learn from reading your code.

Where the driver stopped fitting into a skill

Only the agent could see it. The driver ran inside the agent's session. While it was tapping through my app, I was looking at a terminal. I only found out what it actually did by reading the log afterwards.

It only worked in one agent. It was built as a Claude Code skill. I also use Codex, and I'd like the same capability to work with whatever agent comes next.

Safety by word list doesn't hold. After the last post, two readers pointed out the same weak spot: the driver decided whether an action was risky by its label. "Delete" and "Save" stopped for confirmation, but a button labelled "Done" could change data and sail right through. They were right. The real fix isn't a better word list. It's putting the decision in front of a human who can see the screen.

A component name isn't a location. The driver told the agent "this is HomeActions/log-attack". What the agent actually needs next is "this is HomeActions.tsx:42", so it can open the right file instead of searching for it.

Things an agent can't see from your code

While building this, I kept measuring what the running app tells you that the source doesn't. Three findings stood out. All measured on one Mac, iOS simulator, RN 0.87 with React 19.

1. JS errors leave no trace in the iOS system log. I recorded 90 seconds of normal app use: 3,498 native log events. Every single one came from Apple's frameworks. Zero from the app, React Native or Hermes, including during deliberate JS errors. If your agent "checks the device logs", it's checking the wrong place for anything that happens in JavaScript.

2. In React 19, component locations can be off by 20 lines. React 19 removed _debugSource, the old way to map an element back to its file and line. The replacement points elements rendered inside .map(...) at the start of the callback, not at the tag. In a real app that was 8 out of 22 points I tested, with the actual tag 14–24 lines further down. An agent trusting that line edits the wrong place.

3. "The screen changed after the tap" proves nothing. The simulator's video stream keeps sending around 53 frames per second even when nothing on screen moves. So "a new frame arrived" is not evidence that your tap landed. What did work: comparing frame size against the idle background. A real UI reaction produced frames of 4–29 KB, idle ones were well under 2 KB.

None of this is visible in a diff. All of it matters when an agent claims "I checked, it works".

What I'm building

A desktop app for React Native development where the agent and I look at the same running app:

For the agent: the component tree with real file:line locations, logs and errors from the app, the simulator screen, taps, gestures and typing. It connects over MCP, so it works with Claude Code and Codex today, and with any MCP-capable agent in principle.
For me: the live simulator, what the agent is doing on it, and an approval card for risky actions. The agent asks, I see the screen and the action, I decide.
One rule I won't bend: the tool never types into my terminal for me. It can paste text, but Enter is always mine. I learned this the hard way when a test typed a message plus Enter into a terminal running an agent in auto mode, and kicked off a model turn nobody asked for.

The first stage, the part the agent talks to, already works and has been tested with both Claude Code and Codex. The desktop app is in progress: live iOS simulator at around 48 fps, and clicking anywhere on the screen finds the component under that point in about 5 ms.

The harness isn't going anywhere. It stays the "how to build" part: skills, review agents, pipelines. The new tool becomes its eyes and hands.

An honest result

To check that the tool actually helps, I planted a bug in my gym app and asked both agents to find it. They found it in 6 out of 6 runs. Then I realised they found it by reading the code, without needing the tool at all.

That's the lesson I keep coming back to. If you want to show that runtime tooling helps an agent, you have to test it on bugs that aren't visible in the source: wrong state, timing, a layout that only breaks on device. Otherwise you're measuring how well the model reads code.

What's next

I'll write up the most surprising findings separately, with numbers:

streaming the iOS simulator into an Electron app at ~50 fps (screenshots topped out at 2.3 fps);
why an environment variable from your terminal never reaches your MCP server in Codex;
a trap for anyone writing MCP servers: what Claude Code actually shows the model when a tool returns both text and structured content.

And a question for you: how do you check what your agent did in the app right now? Do you open the simulator yourself after every run, or trust the summary?

My agent built a feature, then tapped through it on the simulator

Valentine Tikhomirov — Mon, 28 Sep 2026 16:48:08 +0000

In my previous post I tested a single skill from my React Native harness: a refactoring agent. This time I ran the whole thing end to end for the first time. One confirmation from me, then the agent planned a feature, built it, tested it, tapped through it on the iOS simulator, and ran a review pass on its own code.

Here's how it's wired and what actually happened.

One checkpoint, then hands-off

The skill is called feature-pipeline. Before touching code, it sends me a single message with the proposed scope, the design direction, and how data, state and errors will be handled. I approve once, and from then on it doesn't stop to ask:

Build the UI and logic.
Test it.
Verify on device: drive the running app on the simulator.
Review: call the harness's other agents as real subagents (refactoring, test coverage, architecture review, plus instrumentation agents if the feature needs them).
Report: one consolidated list of what was done and what's still open.

It never merges to main and never touches deployment or store submission. Those are hard boundaries, not settings.

The part I'm most excited about: how the agent sees the app

Step 3 uses another skill, rn-app-driver. Most tools that let an agent use a mobile app work from screenshots: take a picture, guess where the button is, tap coordinates. That's slow and expensive in context.

The driver reads the app's React component tree straight from Hermes instead. It takes around 10 ms and 1–3k characters, and looks like this (from my headache tracker):

screen: Home
@Home/scroll ScrollView [0,62,402,723]
  "Saturday" "September 26"
  HomeActions
    @HomeActions/log-attack Pressable "Log attack" icon:Plus [24,561,354,84]
TabBar
  @TabBar/history Pressable "History" icon:TabHistory [101,796,100,44]

Every @id is something the agent can act on, with stable ids across runs and a real frame in points. Taps are real touch events on the simulator (via AXe), aimed at those frames, so the agent never guesses coordinates. Screenshots are still there for visual checks, just not for navigation.

A few rules make it usable rather than scary:

One action per command. Each action waits for the UI to settle and prints the new screen, and the agent checks it before deciding the next step. No planning five taps ahead on screens it hasn't seen.
A safety policy. Anything whose label looks like it changes data (save, delete, log, edit, and so on) stops with an error until I explicitly confirm that specific action.
Everything is logged. Each session writes an action log, and a walked flow can be saved as a test case and replayed later. The replay exits with 0 or 1, so it can eventually become a regression gate in CI.

The run

The target was a new "Exercises list" screen in my gym rep counter app, another side project.

Build: about 5–7 minutes from approval to working code.
On-device check: a few more minutes, and it took several runs. Verifying a screen like this needs the app in exactly the right state with the right data, and getting there reliably is the hard part.
Review agents: found only code smells, nothing structural.
Result: a report with recommendations prioritized by importance. No PR.

That last one was my decision, not a failure. With this much access, a run can end in many ways, and for now I want the irreversible steps (committing, pushing, opening a PR) to stay with a human. A full cycle with builds and pushes is on the list to test later, deliberately and separately.

What surprised me

The speed and autonomy, honestly. Scoping was sensible, it picked the right agents, and it really did use the app on the simulator instead of just reading its own code back.

But it made mistakes, and the interesting part is that it pointed them out itself in the final report as things worth fixing. Which raises the obvious question: if the agent already knows what's wrong, why stop after one pass?

What I learned

Read the structure, not the pixels. For navigating an app, the component tree beats screenshots on speed, cost and reliability. Screenshots are for checking how things look.
State is the real problem of on-device testing. Tapping is easy. Reliably getting the app into the exact state a check needs is not.
An agent that lists its own mistakes deserves a second pass. Running the implement-and-review cycle several times, not once, is my next priority.
Keep the irreversible steps human, for now. Autonomy up to a tested, reviewed result is great. What happens with that result is still my call.

What's next

Let the pipeline iterate on its own recommendations for a few cycles and compare the result with a single pass.
Start saving walked flows as replayable test cases and keeping the logs, so the next posts can show real traces and numbers instead of summaries.
Test the full cycle, including commits and pushes, on a project where that's safe.

If you're letting agents drive your app on a simulator: how do you deal with test data and state? That's the part I'd most like to compare notes on.

I stopped prompting and started building a harness

Valentine Tikhomirov — Wed, 23 Sep 2026 11:37:27 +0000

For the last few months I've been using AI agents in almost every part of my React Native work. At some point I noticed I was writing the same instructions over and over: how I want projects set up, what a good refactoring looks like, what to check before shipping. Every new session started from zero.

So I started turning those instructions into a harness: a set of skills and agents that encode how I actually work. It's still in alpha, I use it daily on my own projects, and here's how it's built and what I've learned so far.

Why a plugin and not a folder of prompts

My first version was just files copied into ~/.claude. Now the harness is a proper Claude Code plugin in its own git repo. Every skill and agent is called with an rnmh: prefix, so it's clear what comes from the harness and what doesn't.

The biggest change wasn't organizational, though. Once each task had its own dedicated skill, the agent's answers became noticeably more structured, and the results got better with them.

What's inside right now

Project bootstrap. Deliberately minimal: it fixes only strict TypeScript and the folder organization I choose, and asks about everything else per project. An opinionated template ages badly; a short interview doesn't.
Refactoring skill + agent. Built on the catalog from Martin Fowler's Refactoring (2nd edition), grouped by its chapters. The key decision: it applies refactorings instead of just listing code smells.
Cross-project consistency agent. I work on several RN projects in parallel. This agent compares them for duplicated code and naming drift, without assuming there's a shared library.
Design-to-code, architecture review, testing and test coverage round out the core set.
Diagnostics, release checklist, security review and RN upgrades are the newest additions. They're written, but I haven't battle-tested them on a real project yet, so they're next in line.

First real test

I ran the refactoring agent on my own side project, a headache tracker that's currently in alpha. The home screen had grown into a classic Long Function: one Home() component of ~330 lines with 5 useState, 5 useEffect, 3 async handlers and a three-way JSX branch, all inline.

Before:

function Home() {
  const [openAttack, setOpenAttack] = useState<Attack | null>(null);
  const [recent, setRecent] = useState<Attack[]>([]);
  const [now, setNow] = useState(() => systemClock.now());
  const [loadError, setLoadError] = useState(false);
  const [reduceMotion, setReduceMotion] = useState(false);

  useEffect(() => {
    AccessibilityInfo.isReduceMotionEnabled().then(setReduceMotion);
    const sub = AccessibilityInfo.addEventListener(
      'reduceMotionChanged',
      setReduceMotion,
    );
    return () => sub.remove();
  }, []);
  // ...4 more effects, 3 async handlers, ~150 lines of inline JSX
}

After:

function Home() {
  const reduceMotion = useReduceMotion();
  // ...same effects and handlers, unchanged

  return (
    <View style={styles.middle}>
      {openAttack ? (
        <OngoingAttackCard
          openAttack={openAttack}
          now={now}
          pulseStyle={pulseStyle}
          onSetIntensity={handleSetIntensity}
        />
      ) : recent.length > 0 ? (
        <RecentAttacksList recent={recent} now={now} />
      ) : (
        <Text style={styles.emptyText}>{t('home.noAttacksYet')}</Text>
      )}
    </View>
  );
}

Every change mapped to a named refactoring from the catalog:

Extract Component: IntensityPicker, OngoingAttackCard, RecentAttacksList, HomeActions
Extract Function into hooks: useReduceMotion, plus useDictation and a generic useKeyboardVisible on the log-input screen
Move Function: formatTime() went to the shared formatting module, so it wouldn't be duplicated in two new components
Remove Dead Code: an unused style and a dead import it found along the way

Home() went from ~330 to ~150 lines. The total line count actually grew a bit because of new files and imports, and that's fine: the point is that each piece now has one job. Behavior didn't change, since the agent kept refactoring strictly separate from feature work, and tsc and eslint came back clean.

One honest caveat: the agent only ran static checks, not the app, so checking the screens on a simulator was still on me.

What I've learned so far

Narrow skills beat one giant prompt. A skill that does one job with clear steps gives far more consistent output than a long general instruction.
Make it act, not just advise. A reviewer that only lists problems creates homework. One that makes the change and explains it saves time.
Understanding the project is still the weak spot. Agents struggle to read a codebase and actually use that knowledge later. They can miss existing features, so I often have to steer them. Tools like graphify, which gives the agent a map of the codebase, help a lot here, but it's not solved.

What's next

I'm planning to open the harness to other React Native developers. If you're building something similar, or would want a toolkit like this, I'd love to hear what you'd expect from it in the comments.