AI-assisted development — agent skills, MCP tooling & device automation

Measures where the time actually goes when an agent drives a device, and the answer is: not on the device. A nine-action QA task on an Android emulator took the agent 3m18s; saved as a replayable script and re-run with `agent-device replay` it finished in 8.8 seconds INCLUDING app launch, with zero model calls. Taps and snapshots were thin slices of the original run — the ~190-second gap is model inference, API round trips, screen reading and deciding what to do next. Two numbers make it actionable: in the opening run 2 of 29 tool calls were help lookups or rejected commands, and across an audit of 108 spontaneous runs 375 of 2,668 calls (14.1%) never reached the device at all. So the design rule for agent-driven device work is to spend model turns on DISCOVERING a flow once, then replay it deterministically for every repeat — the same split that makes recorded E2E cheap. Stated caveats: simulators/emulators on a workstation (no physical devices), load-gated timings for one experiment only, small + mid-tier models of one provider.

An independent field test of the option row above, and the honest scoping this category usually lacks. Pointed at a real Vite + React questionnaire app (42 files) it correctly flagged a hardcoded light theme with no color-scheme/prefers-color-scheme, data-entry surfaces with zero <form> elements, validation predating :user-invalid, and min-height:100vh where 100dvh is the modern answer — each with Baseline-checked, copy-pasteable guidance, and it also explicitly endorsed what the app already had right (fieldset/legend, role=alert, :focus-visible). The limits are the useful part: THE SKILL DOES NOT READ YOUR CODE — a human or an agent must inventory the codebase, turn each suspicion into a search phrase and compare the answer back to the actual lines; semantic search has a recall ceiling (dark-mode hit 0.75, but the dvh answer never surfaced as its own result, only inside broad omnibus guides); guides are large (forms ~4,500 tokens, accessibility ~7,100, both reported up front so you can weigh the fetch); and it returns general rules that may not apply — most of the input-attribute advice was irrelevant to a radio-driven form, and noticing that is the human's job. The author's reframe is the durable one: it is less a tool you run than a standard you consult, best used the moment BEFORE writing a component, when the model in the loop (human or AI) is about to reach for the pattern it already knows.

The largest published agent-driven port to date, and the methodology reading for agent fleets: Bun v1.4 ships a Zig→Rust rewrite of 535,496 lines executed by ~64 parallel Claude agents across 4 worktrees in ~50 workflows over 11 days (2026-05), ~$165k in API cost vs an estimated blocked engineer-year — with the load-bearing discipline that each implementer agent was paired with TWO adversarial reviewers in separate context windows told to assume the code was wrong. Results: every instrumentable memory leak resolved (one bundler workload: 609MB stable vs 6.7GB before), ~20% smaller binaries, 2–5% faster. Not RN-specific, but the concrete data point for what adversarially-reviewed agent fleets can do to a production codebase — the review-pairing pattern transfers to any repo using the tools in this entry.

The first named production-adopter case study for agent-device: agents run Sentry-span measurement loops across branches and drive the React profiler mid-session via react-devtools integration, returning named components and render counts as bug evidence. What agent-in-the-debug-loop looks like at a real company, beyond vendor demos.

The layer ABOVE the device-drivers in this entry: not another profiler or benchmark, but a loop that decides what to keep. For a given performance goal it proposes one hypothesis, runs the experiment, measures it N times on a live app, keeps the change only if it beats the noise, commits it with the evidence, then picks the next hypothesis — one variable at a time. It ships no profiler and no device driver of its own; it orchestrates the tools already listed here (Agent Device for eyes and hands, Agent React DevTools, and the rest of Callstack's stack) and contributes the research loop plus memory. VENDOR POST — nearly every organ carries a Callstack logo, and the numbers are theirs. The durable, transferable part is the discipline: an optimization agent that can REJECT its own work against a noise floor is a different thing from one that reports a diff.

The clearest articulation of the closed loop this entry is about: the agent that writes the code also boots the simulator, drives the UI, attaches a debugger, and profiles React+iOS in the same session — with production numbers (~50% re-render reduction in a banking app) rather than demos.

First-party measured model comparison on real Expo apps: three models (Fable 5/Claude Code, GPT-5.6 Sol/Codex, GPT-5.5 control) each one-shot three apps end-to-end — ideation, per-feature on-simulator validation, debugging — under the same spec-driven prompt and template. Fable 5 won code + UI quality (code-health 88 vs 79/79) at ~3× the hourly cost ($74/h vs ~$30/h) and ~30% less wall-clock; the dominant token cost across all models was the simulator-validation loop, not generation. The model numbers are point-in-time (2026-08-05); the durable part is the harness — standing quality bars plus per-feature simulator validation is what made one-shot apps work at all. (Fetched via browser-UA curl; expo.dev/blog no longer blocks it.)