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

Read here for the AGENT-WORKFLOW half of a post that is mostly famous for its framework decision (RB-E-CROSSPLATFORM owns that argument). Two mechanisms are transferable regardless of what you think about the framework call. (1) HELIX, their migration system, exists because pointing an LLM at a codebase and asking for the same features in another language produces unshippable volume even when you freeze specs and task files first; instead a developer points it at one screen, it proposes small ordered checkpoints reviewable in minutes, and each checkpoint must prove behavior with tests, match the running app in a visual review, survive two adversarial code reviewers and get a human's nod before the next one starts — with review feedback remembered so the loop needs less hand-holding over time. The generalizable rule is that the gate, not the prompt, is what makes agent output shippable. (2) AGENT-ADDRESSABLE ARCHITECTURE: they argue the real mobile bottleneck is the FEEDBACK loop, not code generation — agents change code in seconds but take minutes to verify through a simulator, because reading state via the accessibility tree or screenshots is slow and brittle. Their fix is architectural: keep business logic fully decoupled from UI and runnable headlessly on desktop, then expose it to agents through a CLI that inspects state, navigates and acts in milliseconds, with simulator control reserved for when UI truly matters. That principle is framework-independent — it is the same reason this entry rates tools that give an agent a closed verify loop.

The primary source for the gate mechanics the back-to-native reading above only summarizes, and its most transferable part is HOW they verify UI equivalence when nobody can specify it. The four gates run in order and a failed gate cannot be overridden by the agent. Gate 1 (behavior): a CLI exposes the same screen state and actions as the app, so tests run without a simulator and the agent can iterate dozens of times before taking a single screenshot; a subagent generates per-checkpoint integration tests from the reference code, and those tests define what 'proven' means. Gate 2 (UI review) is the one they credit for near-1:1 output: pixel diffing is rejected because two UI frameworks never produce identical bytes, so an orchestrator (GPT) captures matching-state screenshots of reference and new app and asks Gemini — chosen for its spatial awareness — to act as a perfectionist design reviewer that must list every difference with a severity and an on-screen location, judged proportionally to each screenshot's dimensions; fixable differences are blockers by default, the reviewer can return INVALID when the two screenshots show different states (the orchestrator then re-captures), and review scope grows with each checkpoint (a skeleton checkpoint is checked only for nav bar and title). Gate 3: two independent, context-isolated reviewer agents check the new code against the documented target architecture and every finding must be fixed. Vendor-side account of their own process: no acceptance rates or timings are given.

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.)

A factual survey (with advocacy framing) of the convergence the tools themselves shipped in 2026: Next.js bundles its docs in the package (node_modules/next/dist/docs/) plus AGENTS.md and an MCP server at /_next/mcp; Material UI ships @mui/mcp and per-skill AGENTS.md; Storybook ships @storybook/addon-mcp (verified vs npm — localhost:6006/mcp, three toolsets); Playwright generates planner/generator/healer agents via `npx playwright init-agents`; Vercel publishes a react-best-practices skill installable via `npx skills add`. The durable observation: four independent teams converged on machine-readable instructions shipped WITH the tool inside twelve months — check what a library already ships before writing your own agent context for it.