DEV Community: Valentine Tikhomirov

Your iPhone in Parallax, and agent taps 6 to 20 times faster

Valentine Tikhomirov — Fri, 06 Nov 2026 10:47:25 +0000

A Galaxy S24 and an iPhone 13 in one Parallax window, running the same test app on one Metro. The agent taps on the S24; the iPhone is
watch only, and a pick on its picture opens src/CompatScreen.tsx:16.

Parallax is a desktop app and an MCP server that give you and your coding agent the same live view of a running React Native app: the
screen, the component tree, logs, network and state. Three releases went out this week. Here is what changed, how one of the changes
works, and what is still missing.

What shipped

beta.8: a real iPhone in the window, watch only. Plug the phone in with a data cable, and the window shows its live screen next to the app's component tree, logs, network requests and state. You can point at an element on the picture and see its component in the Inspector. The agent can take screenshots of the phone. It can't tap on it yet. Together with beta.7's Android phones, this means an Android phone and an iPhone can run side by side in one window, as in the clip above.
beta.7: agent taps 6 to 20 times faster. A tap went from 3.3 s to 0.5 s on the iOS simulator, and from 14 s to 0.6–0.8 s on a Galaxy S24. The same release added physical Android phones, and in strict approval mode a third button on input cards, "Always allow taps, swipes and typing". Reloads, launches and other commands still ask.
beta.6: faster taps with the window closed. When the app isn't open, the agent's iOS taps now go through the screen helper: 5.1 s to 3.3 s on the simulator.

Reading the screen from React instead of the system

Every agent tap reads the screen twice. Before the tap, the tool needs to find the element and check that the app is in front. After
the tap, it tells the agent what changed. Until beta.7 both reads were the platform's accessibility dump: AXe on iOS, uiautomator on
Android.

Those dumps are slow. On a still screen they took 0.6 to 3 s. On an Android screen with an animation, uiautomator waits for the screen
to go idle, and on our busy test screen it gave up after 11 s. One tap took 14 s.

A React Native app already knows what is on its screen. Parallax reads the app's React tree through Metro, and from it builds the same
list the dump gives: each view with a testID, a label, text, or a text input, with its frame measured by the app itself. That takes 5 to
100 ms. The testIDs are the same, and 33 of 34 frames we compared matched the dump's to within a point.

So when the app is connected and in front, both reads now come from React. A tap is 0.50 to 0.53 s on the iOS simulator and 0.60 to
0.84 s on the S24, measured over 5 taps by id and 5 by point on each. The first tap of a session still takes about 4.9 s, because it opens
the input session and reads the dump once.

The agent's taps on the iOS simulator: count+ three times, then the perf lab opened and closed. The "Last action" line under the picture
updates after each tap.

The dump stays for what React can't see: system alerts and permission prompts, the keyboard, another app in front, an app that isn't
connected. If the app loses its connection to Metro, every read falls back to the dump, and taps are as slow as before.

Why the iPhone is watch only, and what is next

Showing an iPhone and controlling one are different problems.

Showing it is the cheap half. macOS can treat a plugged-in iPhone as a video source. Our capture helper, a small piece of native code of
our own, streams that picture to the window. The app's data comes through Metro as on a simulator, so the Inspector, logs, network and
state work unchanged. Nothing is installed on the phone, and you need no Apple account. macOS asks once for camera access, because that
is how it classes the iPhone's picture.

Pointing works on the iPhone's picture as on a simulator's, because a pick reads React, not input:

On the simulator: Select element, a click on "fetch", and the Inspector opens src/CompatScreen.tsx:16. The pick on the iPhone in the
first clip works the same way.

Controlling it is the expensive half. Sending a tap to a real iPhone needs a signed test runner on the phone. That is the next plan, and
until it lands, the agent's tap, swipe and type tools on an iPhone answer that this needs a later version. You tap on the phone itself.

One setup note. With React Native 0.86 and the prebuilt React Core, an app on a device ignores RCT_METRO_PORT and connects to port 8081.
If your Metro runs on another port, start the app from Xcode with this launch argument:

-RCT_jsLocation <your Mac's IP>:<port>

Parallax doesn't install or launch your app for you.

The limits

macOS 26 or later, on Apple silicon only.
The iPhone is watch only: the agent gets screenshots, not taps. You need a data cable (over Wi-Fi there is no picture), the phone must trust the Mac, and Developer Mode must be on.
The faster taps need the React Native app connected through Metro and in front. Otherwise the system dump is used, as before.
Our numbers come from one test app, on one iPhone simulator and one Galaxy S24.
It's a beta and free while it lasts. Things will break.

The desktop app is in closed beta: ask for an invite at https://parallax-rn.dev/download. Corrections to anything above are welcome.

Giving an AI agent eyes on a running React Native app

Valentine Tikhomirov — Tue, 03 Nov 2026 20:02:35 +0000

Over the last few months I've posted small findings about AI agents, MCP and React Native internals. They were all side effects of building one tool. This post is about the tool: Parallax, and the problems that shaped it.

The problem

An AI agent working on a React Native app sees source files and a terminal. It doesn't see:

the screen. "Fix the padding on that button" means nothing without it.
which component is which. The rendered tree is mostly library wrappers.
runtime errors. In 90 seconds of an app running, the simulator's native log had 3,498 events, and 0 of them came from the app, React Native or Hermes. JS errors live in the JS runtime, not in os_log.

So the agent guesses, and you end up copying logs and describing screenshots for it.

What Parallax is

Two halves that share one live connection to the app:

An MCP server for the agent (Claude Code and Codex). Tools for the screen tree with file:line, console logs, errors, screenshots, taps, swipes, typing, reload.
A desktop window for the human. The live simulator screen with real input, Select element → an inspector with the component, props and source line → Send to agent, approval cards for the agent's device actions, two devices side by side.

Setup is one command per agent:

npx -y @parallax-rn/mcp@<version> setup claude
npx -y @parallax-rn/mcp@<version> setup codex

It shows a diff of what it will change and asks before writing anything. setup ... --undo removes it.

Things that turned out harder than expected

Element → source line. React 19 removed _debugSource. The location now lives in _debugStack, which you symbolicate through Metro. The catch: for elements inside .map(...), the line points to the start of the callback, not the JSX tag (8 of 22 points in my test, with the tag 14–24 lines lower). Parallax searches forward for <ComponentName up to 40 lines.

The tree is mostly noise. On a real screen: 209 rows, 126 of them wrappers (View_withRef 57, SVG parts 45, PressabilityDebugView 23). The window folds them unless a row has a testID, label, text or handler, leaving 83. The agent still gets the full tree: hiding things from the model is a different decision than hiding them from a human.

Unhandled rejections hide. In older RN they're a console.warn; in RN 0.87 a console.error via ExceptionsManager. In both cases the global ErrorUtils handler never sees them, so a tool that only hooks there misses all of them.

A tap is fast, checking it is slow. device_tap takes 1.3–2.3 s end to end, but the tap itself is 56 ms. The rest is reading the accessibility tree and waiting for the screen to settle. If you want a faster agent loop, speed up verification, not input.

One simctl list doubled click latency. Adding a second simulator put a full xcrun simctl list (~100 ms) on the pick path. Click → inspector went from 77 ms to 156 ms p50, and nobody noticed for a whole step because that check measured a different number. Now every number has one definition and a threshold in the script.

Why there are approvals

While testing, an agent crashed the simulator's backboardd three times on purpose "to confirm the diagnosis". It wasn't malicious, just thorough. Since then the agent's device actions can go through approval cards in the window, with a strict mode if you want every action confirmed. Secret-looking props (authToken, apiKey) are masked in the inspector, matched by camelCase/snake_case words so passenger and authorName stay readable.

Some numbers

What	Result
Click on screen → inspector ready	77 ms p50
Component pick at a point	~4–5 ms
Live stream	44–52 fps (screenshots: 2.3 fps)
MCP cold start via npx	4.3 s → ~1.5 s (one bundled file)
Tool descriptions in context	~2,500 tokens, guarded by a test

What it is and isn't (yet)

macOS; iOS simulator and Android emulator. No real devices yet.
Bare React Native first; Expo works.
Runs locally. No account, nothing about your app leaves your machine.
Free beta. The agent tools stay free.

Try it

The beta is out and free: https://parallax-rn.dev/ (install guide: https://parallax-rn.dev/docs/getting-started/install). The app is also a direct download from GitHub: https://github.com/parallax-rn/parallax-releases/releases/tag/v0.1.0-beta.2.

If you work on React Native with Claude Code or Codex, I want to know where it breaks for you, and the site has a short feedback form for that.

Input said OK, nothing happened: Xcode 27, Device Hub and a flag that eats your taps

Valentine Tikhomirov — Wed, 21 Oct 2026 17:35:34 +0000

If you drive the iOS simulator from scripts, test tools or AI agents, this one can cost you an afternoon: every tap is acknowledged, every command returns ok, and nothing happens on screen.

I hit it while building a tool that lets an agent and me work on the same running React Native app. Here's what's going on, how to tell you're in it, and how to get out.

All of this is on Xcode 27.0 with iOS 26.3 simulators, on one Mac. If you're on a different setup, your mileage may vary, and I'd love to hear if you see it too.

First, the change: no more Simulator.app

Xcode 27 doesn't ship a separate Simulator.app anymore. You look at simulators through Device Hub inside Xcode.

Two side effects worth knowing:

Closing the viewer can shut the device down. If you were relying on "the window is open, so the simulator is running", that's no longer a safe assumption.
You don't need a viewer at all. xcrun simctl boot <udid> brings the simulator up without any window, and anything that streams the screen or sends input to it keeps working. For automation this is actually nicer: nothing to keep open, nothing for a human to close by accident.

The bug: input that says yes and does nothing

One day input to one simulator simply stopped working. Not failing: stopped working while reporting success.

I measured it on a local test page that logs every pointer event:

5 taps and one typed word sent to the simulator;
every single one acknowledged by the input layer in 52–113 ms, no errors;
0 events reached the page.

Home and App Switcher commands also answered ok. The screen didn't move.

A second simulator on the same machine, same Xcode, same everything, worked fine.

The cause: a flag Device Hub leaves behind

The difference between the two simulators turned out to be one Darwin notification state inside the simulator:

com.apple.coredevice.dtuhidd.active

On the broken simulator it was 1, while no Device Hub process was running at all.
On the healthy one it was 0.

It's not a defaults key or a plist, it's a notify state held by the simulator's backboardd. As far as I can tell, it means "Device Hub attached to this simulator's input during this boot". While Device Hub is attached, input goes through its channel. When Device Hub goes away, the state stays at 1, and input from any other source is quietly ignored.

Just opening Device Hub and showing the simulator didn't set it in my tests; it stayed 0. Interacting with it from Device Hub seems to be what does. The name isn't documented anywhere I could find (I first saw it in the source of an open-source simulator tool), so treat the mechanism as my best reading of the evidence, not Apple's description.

The state survives closing Device Hub. It survives closing Xcode. It goes away only when the simulator reboots.

After a reboot: flag 0, input reaches the app again.

How to check yours

Two read-only commands. First, the state inside a booted simulator:

xcrun simctl spawn <udid> notifyutil -g com.apple.coredevice.dtuhidd.active

It prints com.apple.coredevice.dtuhidd.active 0 or ... 1.

Then, whether Device Hub is actually running:

pgrep -x DeviceHub >/dev/null && echo "Device Hub running" || echo "no Device Hub process"

How to read the pair:

State	Device Hub process	Meaning
0	any	Free, input from your tools works
1	running	Device Hub is attached right now, expected
1	not running	Stale: input will be silently dropped

Use notifyutil -g only. -s sets the state, which you don't want to do on a whim. The simulator has to be booted for simctl spawn to work.

The symptom is also easy to recognise once you know it:

Input commands succeed with no errors.
Nothing on screen reacts, including system gestures like Home.
Another simulator on the same machine works.
You (or a teammate, or a tool) used that simulator from Device Hub at some point since it was booted.

If you're in the stale state, reboot the simulator before you debug anything else:

xcrun simctl shutdown <udid>
xcrun simctl boot <udid>

Why this is worse for agents than for people

A person notices within seconds that taps don't do anything. An automated check often doesn't, for two reasons:

The acknowledgement is a lie. If your tool treats "input accepted" as "input delivered", every step passes.
"The screen changed" can lie too. The simulator's video stream keeps sending frames even when nothing moves, so "a frame arrived after the tap" proves nothing. My own heuristic that looks at frame sizes to decide whether a tap landed said "confirmed" once while in this state, because a page happened to load at the same moment.

So an agent can walk through a whole flow, report success, and never have touched the app.

What I ended up doing in my tool:

detect the stale flag (key set, no Device Hub process) and show the human a one-line note under the picture;
mark input as unverified instead of confirmed while the simulator is in that state;
add a warning to the agent's tool replies: input is likely blocked by a flag Device Hub left on this simulator; ask the user to reboot the simulator.

The last one matters most. The agent can't fix this itself, but it can stop pretending everything worked and ask the human for the one action that does.

Takeaways

On Xcode 27, a simulator doesn't need a window. simctl boot is enough for streaming and input.
Device Hub can leave a state that silently swallows input until the simulator reboots. One notifyutil -g plus one pgrep tells you if you're in it.
"Input accepted" is not "input delivered". If you automate the simulator, verify against what the app actually received.
When the tool can't fix something, it should say so. An honest warning to the agent beats a green check.

Have you run into this, or something like it, on Xcode 27? I'd like to know whether it's my setup or more common than it looks.

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.