DEV Community: Ahsan Ali

How Anthropic reviews code when Claude writes 90% of it

Ahsan Ali — Sun, 25 Oct 2026 10:00:00 +0000

Claude writes ~90% of Claude Code's own code. So how does Anthropic review it? Not by having a human read every line.
Their team published their setup, and one idea stuck with me: "did a human read it?" is the wrong safety check. The real question is what could break, and which check should catch it.

Automated checks first

Every PR goes through automated checks before a human sees it. Claude has to prove its own work with tests and screenshots. Several AI reviewers hunt for bugs and vote, and only the agreed findings get posted. Security issues block the merge.

Humans scaled to risk

Low risk (docs, copy, flagged additive changes): zero human approvals- Medium (normal product changes): one approval- High (billing, auto-updater, CI workflows): two approvalsA classifier sets the tier from the change, not the author. And an agent's approval never counts as a person's. ## Results Merged PRs doubled in three months. Reverts dropped 40%. PRs passing review in one round went from 65% to 78%. ## The bit I'm stealing Every past incident becomes an eval for the AI reviewer. If a prompt change doesn't catch more old bugs, it doesn't ship. I run something similar with my own agents, and the humans don't go away. They just stop reading lint output and start making the calls machines can't. Source: the Claude Code team's post on claude.dev, October 2026.

Mobile E2E testing three ways: Detox, Maestro, and now plain-English agents

Ahsan Ali — Sat, 24 Oct 2026 09:00:00 +0000

I've written mobile E2E tests three ways now.

Detox

Painful. Flaky tests, long setup, and every small UI change broke something.

Maestro

Made it easy. Simple YAML, and it just worked.

Now: e2e by TesterArmy

You write the test in plain English, like "upgrade the workspace to the Pro plan," and an agent drives the app to do it.
The clever part: once a step passes, it records what the agent did. After that it just replays those actions, with no AI call, until the app changes. So it doesn't cost money on every run, and you don't get a different result each time.
It works on iOS and Android simulators, and there's an Expo example.

My take

It's still pre-1.0, so I wouldn't move a critical suite onto it yet. But it's interesting to see where testing is heading.
What are you using for mobile E2E right now?

GitHub stacked PRs are the review tool agentic development needed

Ahsan Ali — Thu, 22 Oct 2026 15:00:00 +0000

Agents can write a 2,000-line PR in ten minutes. Nobody can review it in ten minutes.
That's the real bottleneck in agentic development. Not writing code. Reviewing it.
GitHub just made stacked PRs generally available, and I think they matter more for agents than for humans.

One feature, four layers

Instead of one giant PR, the agent splits the feature into layers:

#101 DB schema- #102 API (built on #101)- #103 UI (built on #102)- #104 Tests (built on #103)Each PR targets the one below it. Each one is small enough to actually read. ## Two ways to merge
Merge the bottom one. The next PR automatically retargets to main. Repeat.- Merge the top one. Every approved layer below it lands in one click.## Let the agent do the splitting GitHub ships an agent skill: gh skill install github/gh-stack. With it, the agent can turn a big diff into a stack, or plan the stack before writing a line. ## What changes
Reviews you can do properly, not skim- Feedback on layer 1 while the agent builds layer 3- Impact assessment per layer, not per featureOne caution: check your merge strategy first. Squash merges can fight with stacks. Agents made writing code cheap. Stacks make reviewing it possible.

iOS SceneDelegate and React Native: what changed and how to fix it

Ahsan Ali — Wed, 21 Oct 2026 17:39:52 +0000

TL;DR

Any UIKit app built with the iOS 27 SDK (Xcode 27) that hasn't adopted the UIScene lifecycle won't launch. React Native apps are UIKit apps, so every RN app is affected, whatever the RN version.

Deadline: the day you build with Xcode 27. Binaries built with Xcode 26 keep launching on iOS 27; Apple says it strives for binary compatibility but won't guarantee zero issues.
RN 0.88+: move startup into a SceneDelegate using the new startReactNative(withModuleName:in:connectionOptions:), forward links to RCTLinkingManager, add UIApplicationSceneManifest to Info.plist.
RN 0.79–0.87: same shape, but you build the root view yourself from reactNativeFactory.rootViewFactory and handle cold-start links by hand.
RN 0.74–0.78: keep your RCTAppDelegate subclass, but build the window in a SceneDelegate from its rootViewFactory.
RN below 0.74: create the root view in SceneDelegate from the RCTBridge the AppDelegate owns, with RCTRootView(bridge:moduleName:initialProperties:).
Watch: deep links, Universal Links, push-tap routing and third-party SDKs that hook AppDelegate callbacks.

Before: one app, one window, one AppDelegate

Until iOS 13, the UIApplicationDelegate (your AppDelegate) owned everything: process launch, the single UIWindow, foreground/background state, deep links and push.

A typical flow:

UIKit calls application(_:didFinishLaunchingWithOptions:) with a launchOptions dictionary. If a URL or Universal Link opened the app, it's inside that dictionary.
The AppDelegate creates UIWindow(frame: UIScreen.main.bounds), sets a root view controller and calls makeKeyAndVisible().
State changes arrive as applicationDidBecomeActive, applicationWillResignActive, applicationDidEnterBackground and applicationWillEnterForeground.
Warm deep links arrive in application(_:open:options:) and application(_:continue:restorationHandler:).

This model assumes the app is its window. Any code can reach the UI through UIApplication.shared.delegate.window or keyWindow, and lots of libraries do.

Now: AppDelegate for the process, SceneDelegate for the UI

A scene (UIWindowScene) is one instance of your app's UI. iOS 13 split responsibilities in two:

AppDelegate keeps process-level work: SDK init, push token registration, UNUserNotificationCenter delegate, background tasks, and choosing a scene configuration.
SceneDelegate (UIWindowSceneDelegate) owns a window and its lifecycle: create the window, go foreground/background, receive URLs and user activities.

The key behaviour change: once UIApplicationSceneManifest is in Info.plist, UIKit stops calling the AppDelegate's UI-lifecycle and deep-link methods and calls the scene equivalents instead.

AppDelegate (old)	SceneDelegate (new)
Create window in `didFinishLaunchingWithOptions`	`scene(_:willConnectTo:options:)`, using `UIWindow(windowScene:)`
`launchOptions[.url]` (cold-start link)	`connectionOptions.urlContexts`
`launchOptions[.userActivityDictionary]` (cold-start Universal Link)	`connectionOptions.userActivities`
`launchOptions[.shortcutItem]`	`connectionOptions.shortcutItem`
`application(_:open:options:)`	`scene(_:openURLContexts:)`
`application(_:continue:restorationHandler:)`	`scene(_:continue:)`
`application(_:performActionFor:completionHandler:)`	`windowScene(_:performActionFor:completionHandler:)`
`applicationDidBecomeActive` / `WillResignActive`	`sceneDidBecomeActive` / `sceneWillResignActive`
`applicationDidEnterBackground` / `WillEnterForeground`	`sceneDidEnterBackground` / `sceneWillEnterForeground`

Unchanged on AppDelegate: didFinishLaunchingWithOptions (minus window work), didRegisterForRemoteNotificationsWithDeviceToken, notification delegate methods, background fetch and supportedInterfaceOrientationsFor.

Why Apple changed it, and when it bites

Apple's UI no longer fits "one app = one full-screen window". iPad multi-window, Stage Manager, resizable windows, external displays, Mac Catalyst and visionOS all need an app to show several independent UIs, each with its own state. A scene gives each window its own lifecycle and restoration state, which a single AppDelegate can't express. Apple has been deprecating the window-centric APIs (keyWindow, UIScreen.main-sized windows) in the same direction.

Apple rolled this out gradually (TN3187):

Release	What happens to apps without UIScene
iOS 13 (2019)	Scenes introduced; optional
iOS 18.4	Console log: the process doesn't adopt the UIScene lifecycle and this will become an assert
iOS 26	Log hardened: UIScene lifecycle will soon be required
iOS 27 SDK (Xcode 27)	Assert at launch. The app doesn't launch

Two details from Apple engineers on the developer forums:

The assert is only evaluated when you build with the new SDK. An Xcode 26 build still runs on iOS 27, though Apple doesn't guarantee zero issues (thread).
Only adopting the scene lifecycle is required. Supporting multiple scenes is encouraged, not mandatory.

In practice, App Store Connect will eventually require the latest SDK for submissions, so "stay on Xcode 26" only buys time.

How React Native booted on iOS before 0.88

Every RN version up to 0.87 starts React Native from didFinishLaunchingWithOptions and creates the window itself from UIScreen.main.bounds. Only the wrapper changed over time:

RN version	Entry point	What it does at launch
≤ 0.70	Hand-written `AppDelegate`	Creates `RCTBridge(delegate:launchOptions:)`, then `RCTRootView(bridge:moduleName:initialProperties:)`, puts it in a `UIViewController`, creates the window
0.71–0.73	Subclass of `RCTAppDelegate`	Same work hidden inside the superclass's `didFinishLaunching`; you set `moduleName` and `initialProps`
0.74–0.78	Subclass of `RCTAppDelegate`	Root view creation moves into `RCTRootViewFactory` (`self.rootViewFactory`), which also handles bridgeless/New Architecture
0.79–0.87	`RCTReactNativeFactory` + `RCTDefaultReactNativeFactoryDelegate`	`factory.startReactNative(withModuleName:in:launchOptions:)` on a window built from `UIScreen.main.bounds`
0.88	`SceneDelegate` + `RCTReactNativeFactory`	`startReactNative(withModuleName:in:connectionOptions:)` inside `scene(_:willConnectTo:options:)`

The 0.87 template shows the pattern every older version shares: the window and React Native both live on the AppDelegate.

// RN 0.87 template AppDelegate (abridged)
func application(_ application: UIApplication,
                 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil) -> Bool {
  let delegate = ReactNativeDelegate()
  let factory = RCTReactNativeFactory(delegate: delegate)
  delegate.dependencyProvider = RCTAppDependencyProvider()
  reactNativeDelegate = delegate
  reactNativeFactory = factory

  window = UIWindow(frame: UIScreen.main.bounds)
  factory.startReactNative(withModuleName: "HelloWorld", in: window, launchOptions: launchOptions)
  return true
}

On the JS side, three modules depend on this native plumbing:

Linking.getInitialURL() reads the cold-start URL out of the launchOptions handed to the bridge/host.
Linking.addEventListener('url') fires when RCTLinkingManager receives a forwarded open URL or continue userActivity call.
AppState listens for UIApplication active/background notifications.

What breaks in a React Native app

If you do nothing and build with Xcode 27, the app asserts on launch. Adding only the scene manifest without moving code gives you subtler bugs:

Symptom	Cause
Crash on launch (Xcode 27)	No `UIApplicationSceneManifest`
Blank or white screen	Manifest present, but the window is still created in AppDelegate. A scene-based app needs a window attached to a `UIWindowScene`
`Linking.getInitialURL()` returns `null`	The cold-start URL moved from `launchOptions` to `connectionOptions`
Warm deep links and Universal Links do nothing	`application(_:open:)` and `continue userActivity` on AppDelegate are no longer called
Home-screen quick actions ignored	`performActionFor` moved to the window scene
Libraries can't find the window	They read `UIApplication.shared.delegate.window`, which is now `nil`
Attribution/analytics SDKs lose deep-link events	Their AppDelegate hooks or swizzles stop firing (Branch, AppsFlyer, Adjust, Airbridge, Firebase Dynamic Links-style SDKs)
Layout surprises on iPad	The window becomes resizable; `Dimensions` and `useWindowDimensions` now change at runtime

Attribution vendors are already publishing scene migration guides for this. Airbridge's guide, for example, lists a blank screen and missing deep-link events as the two headline symptoms.

Fix A: upgrade to React Native 0.88

RN 0.88 adds scene support as an additive change: RCTReactNativeFactory gains startReactNativeWithModuleName:inWindow:connectionOptions: and a variant with initialProperties:. The old AppDelegate path still works under Xcode 26, so you can upgrade first and migrate second (RN 0.88 release notes).

1. Add SceneDelegate.swift. This is the 0.88 template file; replace HelloWorld with your module name.

import React
import React_RCTAppDelegate
import ReactAppDependencyProvider
import UIKit

class SceneDelegate: RCTDefaultReactNativeFactoryDelegate, UIWindowSceneDelegate {
  var window: UIWindow?
  var reactNativeFactory: RCTReactNativeFactory?

  func scene(_ scene: UIScene,
             willConnectTo session: UISceneSession,
             options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = scene as? UIWindowScene else { return }

    dependencyProvider = RCTAppDependencyProvider()
    reactNativeFactory = RCTReactNativeFactory(delegate: self)
    window = UIWindow(windowScene: windowScene)

    #if DEBUG
    reactNativeFactory?.devMenuConfiguration = RCTDevMenuConfiguration(
      devMenuEnabled: true, shakeGestureEnabled: true, keyboardShortcutsEnabled: true)
    #endif

    reactNativeFactory?.startReactNative(
      withModuleName: "HelloWorld",
      in: window,
      connectionOptions: connectionOptions)
  }

  func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
    RCTLinkingManager.scene(scene, openURLContexts: URLContexts)
  }

  func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
    RCTLinkingManager.scene(scene, continue: userActivity)
  }

  override func bundleURL() -> URL? {
    #if DEBUG
    RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
    #else
    Bundle.main.url(forResource: "main", withExtension: "jsbundle")
    #endif
  }
}

2. Slim down AppDelegate. Remove the window, the factory and the RN start call. Keep Firebase, push registration and other process-level setup.

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
  func application(_ application: UIApplication,
                   didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil) -> Bool {
    // FirebaseApp.configure(), push setup, SDK init...
    return true
  }
}

3. Add the scene manifest to Info.plist. Keep UIApplicationSupportsMultipleScenes set to false: 0.88 supports a single scene only.

<key>UIApplicationSceneManifest</key>
<dict>
  <key>UIApplicationSupportsMultipleScenes</key>
  <false/>
  <key>UISceneConfigurations</key>
  <dict>
    <key>UIWindowSceneSessionRoleApplication</key>
    <array>
      <dict>
        <key>UISceneConfigurationName</key>
        <string>Default Configuration</string>
        <key>UISceneDelegateClassName</key>
        <string>$(PRODUCT_MODULE_NAME).SceneDelegate</string>
      </dict>
    </array>
  </dict>
</dict>

4. Move any custom AppDelegate code for links, quick actions or lifecycle into the matching scene method (mapping table above).

Limits in 0.88: only one scene, and at cold start RN forwards only the first URL context or user activity from connectionOptions. Expo apps get this through Expo SDK 58.

Fix B: stay on an older React Native version

You can adopt scenes on any RN version. React Native only needs a root UIView, and UIKit doesn't care who creates it. Without 0.88's helpers, your SceneDelegate does three jobs by hand:

Build the root view and attach it to a scene-backed window.
Turn connectionOptions back into a launchOptions-shaped dictionary, so Linking.getInitialURL() keeps working.
Forward warm URLs and user activities to RCTLinkingManager's existing application(...) class methods.

Add the same Info.plist manifest as in Fix A, then pick the variant for your version.

Shared helper (all versions)

// Rebuilds the dictionary RCTLinkingManager reads for getInitialURL()
func rnLaunchOptions(from options: UIScene.ConnectionOptions) -> [UIApplication.LaunchOptionsKey: Any] {
  var launch: [UIApplication.LaunchOptionsKey: Any] = [:]
  if let url = options.urlContexts.first?.url {
    launch[.url] = url
  }
  if let activity = options.userActivities.first {
    launch[.userActivityDictionary] = [
      "UIApplicationLaunchOptionsUserActivityKey": activity,
      "UIApplicationLaunchOptionsUserActivityTypeKey": activity.activityType,
    ]
  }
  return launch
}

RN 0.79–0.87 (`RCTReactNativeFactory`)

Keep creating the factory in AppDelegate, but delete the window and startReactNative lines. Keep a window property on AppDelegate too, because libraries still read delegate.window.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {
  var window: UIWindow?

  func scene(_ scene: UIScene, willConnectTo session: UISceneSession,
             options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = scene as? UIWindowScene,
          let appDelegate = UIApplication.shared.delegate as? AppDelegate,
          let factory = appDelegate.reactNativeFactory else { return }

    let rootView = factory.rootViewFactory.view(
      withModuleName: "HelloWorld",
      initialProperties: nil,
      launchOptions: rnLaunchOptions(from: connectionOptions))

    let vc = UIViewController()
    vc.view = rootView
    let window = UIWindow(windowScene: windowScene)
    window.rootViewController = vc
    window.makeKeyAndVisible()
    self.window = window
    appDelegate.window = window // for libraries that read delegate.window
  }

  func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
    guard let url = URLContexts.first?.url else { return }
    RCTLinkingManager.application(UIApplication.shared, open: url, options: [:])
  }

  func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
    RCTLinkingManager.application(UIApplication.shared, continue: userActivity,
                                  restorationHandler: { _ in })
  }
}

RN 0.74–0.78 (`RCTAppDelegate` subclass)

The superclass's didFinishLaunching builds rootViewFactory and then also creates a screen-sized window. You want the first part, not the second.

If your RCTAppDelegate exposes automaticallyLoadReactNativeWindow (check the header in node_modules/react-native/Libraries/AppDelegate/RCTAppDelegate.h), set it to false before calling super. Then use the 0.79 SceneDelegate above with appDelegate.rootViewFactory.view(...) in place of factory.rootViewFactory.
If it doesn't, the clean fix is a small patch-package patch that skips the window block in RCTAppDelegate.mm, or upgrading to 0.79+. Calling super and then making a second root view starts the JS app twice.

RN 0.70 and earlier, or 0.71–0.73 on the old architecture (`RCTBridge`)

Stop subclassing RCTAppDelegate (on 0.71–0.73) and use a plain UIApplicationDelegate. Create the bridge inside the scene, so it receives the cold-start link:

class SceneDelegate: UIResponder, UIWindowSceneDelegate, RCTBridgeDelegate {
  var window: UIWindow?
  var bridge: RCTBridge?

  func scene(_ scene: UIScene, willConnectTo session: UISceneSession,
             options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = scene as? UIWindowScene else { return }
    bridge = RCTBridge(delegate: self, launchOptions: rnLaunchOptions(from: connectionOptions))
    let rootView = RCTRootView(bridge: bridge!, moduleName: "HelloWorld", initialProperties: nil)

    let vc = UIViewController()
    vc.view = rootView
    let window = UIWindow(windowScene: windowScene)
    window.rootViewController = vc
    window.makeKeyAndVisible()
    self.window = window
  }

  func sourceURL(for bridge: RCTBridge) -> URL? {
    #if DEBUG
    return RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
    #else
    return Bundle.main.url(forResource: "main", withExtension: "jsbundle")
    #endif
  }

  // openURLContexts / continue userActivity: same forwarding as the 0.79 variant
}

If a native SDK needs the bridge during didFinishLaunching, keep creating it there. Then, once JS has loaded, forward the scene's cold-start URL with RCTLinkingManager.application(_:open:options:), so it arrives as a Linking url event instead of through getInitialURL().

Expo

Expo SDK 58 ships RN 0.88 with this built in. On older SDKs, write a config plugin that applies the changes above at prebuild. Editing ios/ by hand gets wiped on the next prebuild.

Be realistic about very old versions

Xcode 27 is a new toolchain. RN versions several releases behind may hit unrelated build failures with it (C++ headers, Folly, Hermes builds). Scene adoption is necessary but may not be enough. Below roughly 0.76, budget for an upgrade anyway.

Deep links, push and third-party SDKs

This is where most migrations actually break. Audit everything that touches AppDelegate:

Custom URL schemes (warm): handled in scene(_:openURLContexts:) and forwarded to RCTLinkingManager.
Universal Links (warm): handled in scene(_:continue:).
Cold-start links: come from connectionOptions in willConnectTo. In 0.88 only the first item is forwarded. On older versions, use the rnLaunchOptions helper.
Attribution SDKs (Branch, AppsFlyer, Adjust, Airbridge, your own): upgrade to a scene-aware version and call their scene APIs from SceneDelegate. Check that their swizzling doesn't still assume AppDelegate.
Push notifications: token registration and UNUserNotificationCenterDelegate stay on AppDelegate. A notification tap that opens a deep link still reaches JS through your push library.
Home-screen quick actions: move to windowScene(_:performActionFor:completionHandler:), plus connectionOptions.shortcutItem at cold start.
OAuth / SSO callbacks (react-native-app-auth, Google Sign-In, Facebook Login): they usually resume through open URL, so forward from the scene method to the SDK as well as to RCTLinkingManager.
Libraries reading delegate.window or keyWindow (splash screens, toasts, modal hosts, react-native-navigation): set appDelegate.window from the scene, or upgrade the library.
AppState and analytics session timing: verify foreground/background events still fire as expected.

Testing checklist and gotchas

Test on a release build, on a real device, with the app killed between cold-start cases.

Case	How to trigger	Expect
Normal launch	Tap icon	No blank screen; no UIScene warning in the Xcode console
Cold custom-scheme link	`xcrun simctl openurl booted myapp://path` with the app killed	`getInitialURL()` returns the URL
Warm custom-scheme link	Same command, app in background	`Linking` `url` event fires once
Cold Universal Link	Tap a link in Notes or Messages, app killed	Correct screen opens
Warm Universal Link	Same, app in background	Correct screen opens
Push tap (killed / background)	Send a test push	Routing works; token still registers
Quick action	Long-press icon	Action handled
Background → foreground	Home, then reopen	`AppState` changes; no JS reload
iPad resize / Stage Manager	Resize window	Layout responds to `useWindowDimensions`
Dev menu	Shake (debug)	Menu opens

Gotchas:

UISceneDelegateClassName must be $(PRODUCT_MODULE_NAME).SceneDelegate for a Swift class. For Objective-C, use the bare class name.
Don't create React Native in both AppDelegate and SceneDelegate. Two root views means two JS app instances.
Keep UIApplicationSupportsMultipleScenes set to false until RN supports multiple scenes; a second scene would need its own RN surface.
Remove leftover window = UIWindow(frame: UIScreen.main.bounds) lines. A window with no scene never shows.
Watch the Xcode console for the UIScene log message. If it's gone, UIKit sees you as scene-based.

Sources

TN3187: Migrating to the UIKit scene-based life cycle (Apple)
Regarding the deadline for adopting the UIScene life cycle (Apple Developer Forums)
Mandatory UIScene lifecycle support in iOS 27 (Apple Developer Forums)
React Native 0.88 release notes
RN 0.88 template SceneDelegate.swift
RN 0.88 template Info.plist
RN 0.87 template AppDelegate.swift
RCTReactNativeFactory PR #46298
Airbridge: Xcode 27 SceneDelegate migration for React Native

The older-version code in Fix B isn't from an official template. It's built on public RN APIs (RCTRootViewFactory, RCTRootView, RCTLinkingManager), so check it against the headers in your installed RN version.

EAS Update pricing: why shipping less often won't save you money

Ahsan Ali — Tue, 20 Oct 2026 15:00:00 +0000

Ship once a month or thirty times — two million users cost you the same $9,750 either way.
I had the EAS Update pricing model backwards, and I think most people do.

The actual billing rule

From Expo's own docs: "A monthly active user counts only once per billing period, regardless of how many updates this user downloads."
So the user charge is a flat line. $0.005 per updated user past your allowance, Production includes 50,000, and at two million installs that's 1,950,000 × $0.005 = $9,750. Your release cadence does not appear in that sum anywhere.

What does scale: bandwidth

Bandwidth is billed separately at $0.10 per GiB.
Fifteen releases a month, 5 MB bundle, two million installs. If each install pulls roughly a third of those releases (most people don't open your app daily), that's about 48,000 GiB, so another ~$4,800. If your users are genuinely daily-active and pull most releases, it's closer to $14,500.
Call it $15,000 to $24,000 a month, all in. The $10k is the floor, not the ceiling.
"Let's ship less often to save money" doesn't touch your biggest line at all. Shipping smaller bundles does, and so does not pushing an update that only changes one screen to your entire install base.

Self-hosting

Self-hosted on Cloudflare R2 the same thing runs $50 to $100 a month, for one reason: zero egress fees. The bandwidth line that costs you five figures is simply free there.
But that $50 is infrastructure. It is not the cost. What you're also taking on:

Fingerprinting: deciding whether a JS bundle is safe to serve to a given native binary. Get it wrong and you push a bundle importing a native module the installed app doesn't have. Crash on launch, on devices you cannot reach, with no kill switch.- Rollback, measured in minutes from "we broke it" to "it's reverted".- Staged rollout by percentage, because an OTA that hits 100% at once is just an outage with better timing.None of that is hard. All of it is yours now, forever, including at 2am. ## The takeaway Expo is genuinely the right default, and I'd still start every new app there. But the economics invert somewhere around a million installs. Do the sum with your own install count and bundle size. Then decide.

Shopify used agents to leave React Native. Expo used one to fix it. Same bet.

Ahsan Ali — Mon, 19 Oct 2026 15:00:00 +0000

Shopify used AI agents to get off React Native. Expo shipped an AI agent that fixes React Native bugs.
Both came out the same month. Same bet, pointed in opposite directions.
The bet: agents make large-scale mobile work cheap.

What each one did

Shopify's Helix is the internal tooling behind their move to Swift and Kotlin. They rebuilt the Shop app in 12 weeks, and now they're working through the main app, which has 300+ screens.
Expo's agent starts when someone adds a label to a GitHub issue. It reproduces the bug on a cloud simulator, fixes it and opens a PR with before and after recordings.

The wrong lesson

Everyone will read the Shopify post as "native won." I don't think that's the lesson.
Helix doesn't one-shot a spec. It works in small checkpoints, and each one has to pass gates: behaviour tests, UI review, two adversarial agent reviews, then a human.
That only works if logic and UI are separable enough to test on their own.

The real lesson

That's a testability problem, not a React Native problem. Most RN codebases I've seen in 10 years have it too.
Every native vs cross-platform cycle I've lived through was decided by team shape, not framework quality. This one is being decided by which codebase an agent can safely navigate.
So I wouldn't migrate on Monday. I'd measure how much of my app an agent can touch without breaking something. That number matters more than the framework.
How much of your app could an agent safely change today?

How I stop 18 Claude Code agents from pushing to main or touching secrets

Ahsan Ali — Thu, 15 Oct 2026 15:00:01 +0000

18 AI agents. 7 repos. Now none of them can push to main, touch a secret, or wander into another repo.
Claude Code Mods made that possible.
Every time Claude is about to act, it fires an event first. Your hook runs before the action and can let it through, change it, or block it.

What I'm setting up

tool.call: keep each agent in its lane

An edit outside its worktree pauses and asks me. No answer means refused.

tool.check: no pushing to main

It checks the current branch and denies git push on main, even if a permission rule allows it.

tool.call: protect secrets

It blocks any read or edit of .env, keystores or .p8 files.

prompt.submit: add context automatically

Every prompt gets the repo, branch and ticket number added. No more repeating myself.

turn.step: watch costs

It logs token usage and cache hits on every model call.

Why it works

When a hook blocks something, Claude reads the reason and changes approach instead of just failing.

One gotcha

If a hook crashes, Claude Code skips it and runs the action anyway. Add a .catch that denies.
CLAUDE.md says what you want. Mods decide what's allowed.

Your AI agent can't open your mobile app. Here's the plumbing that fixes it

Ahsan Ali — Wed, 14 Oct 2026 18:43:45 +0000

On mobile, the real problem is that the agent can't open the app. It can write a screen. It can't tap through it, see it break, or prove it works.
The model isn't the bottleneck. The plumbing is.

The pipeline

1. Give it a device

Maestro's MCP server lets the agent tap, assert and explore on a simulator.

2. Give it typed tools, not a debug menu

Things like "log in as test user" or "reset cart" get a declared name, a schema and a timeout. Callstack's Appduct does this without shipping a debug menu in your production binary.

3. Make it leave a file, not a transcript

Exploration ends as a Maestro flow in .maestro/. The agent writes the test.

4. CI owns it

That flow runs on every PR like any other test.

The hidden cost

Seed data and auth. Agents aren't flaky because of complex UI. They're flaky because the test fixtures are unstable.
Keep agents on exploratory work like new flows and edge cases nobody wrote. The critical-path suite stays deterministic and owned by humans.
Build the plumbing and the model barely matters.

CLAUDE.md is not a quality gate. Here's how to build one with hooks

Ahsan Ali — Sat, 10 Oct 2026 09:00:00 +0000

Most devs think writing "always run tests before finishing" in CLAUDE.md is enough. It isn't.
CLAUDE.md is context, not enforcement. The agent reads it, and most of the time it follows it. Most of the time isn't a quality gate.
Long session, big context, a tricky fix, and suddenly it says "Done ✅" while your build is red.
If a check matters, don't ask for it. Enforce it.

Hooks

Hooks are shell commands Claude Code runs automatically at set points. The agent can't skip them, forget them or talk its way past them. Here's a real quality gate in .claude/settings.json:

1. PostToolUse: fast checks after every edit

Matcher: Edit|Write. Run eslint --fix on just the file that changed. The file path comes in on stdin, so it's scoped and quick.

2. Stop: the hard gate before the agent can finish

Run the full typecheck and tests: tsc --noEmit && vitest run. If they fail, the agent can't end its turn. It gets the errors and has to fix them.

3. The part most people miss: exit code 2

Only exit code 2 blocks the agent and sends the error back to it. tsc and vitest exit with 1 when they fail, so the agent just carries on. Wrap it:
(tsc --noEmit && vitest run) >&2 || exit 2

The loop closes by itself

Agent writes code → check fails → agent reads the error → fixes it → tries again. You stop being the agent's test runner.
CLAUDE.md tells the agent what you want. Hooks make sure it actually happens.

The device matrix was a cost problem, not a QA problem

Ahsan Ali — Wed, 07 Oct 2026 08:20:01 +0000

I have never signed off on a mobile release feeling confident about the device matrix. Not once. Nobody I've worked with has either.

The reason is boring. Walking the same screen across fifteen screen sizes, three OS versions and two accessibility scales is a full day of someone's life, and it's a day nobody budgets for. So you test on three devices, you ship, and you let the reports tell you about the other twelve.

That's the constraint four separate releases quietly removed this week.

Callstack took Apex generally available — a coding model specialised in React, strongest on RN and Next.js. Codex shipped Mobile Dev: Simulator, Instruments, logcat and Metro in one surface. Stim Desktop 0.1 watches and steers an agent's React Native work with live devices, replay and logs. Medula shipped headless devtools built for agents.

Nobody coordinated that. Four teams hit the same wall in the same quarter.

And the wall was never code generation. Agents write RN components fine. The wall was that the agent couldn't see the device — and neither could we, at any width that mattered.
So the shift isn't "agents write my tests". It's that device breadth stopped being expensive. Twenty simulator configurations running the same journey is now a cheap thing to kick off, not a sprint you have to argue for.

What I'd stay honest about: breadth is not confidence. An agent exploring twenty devices and reporting back is twenty chances to be told something plausible and wrong. It only becomes real when the run leaves an artefact behind — a flow file your CI replays on every PR. Then the second run is deterministic and the twentieth is free.

That's the whole play. Pick the matrix you've been quietly ignoring. Have the agent explore it once. Keep what it finds as tests you own.

We spent a decade calling the device matrix a QA problem. It was a cost problem, and the cost just moved.

react-native #ai #agentic-development

Running a Multi-Repo Product with Parallel AI Agents (Claude Code)

Ahsan Ali — Mon, 05 Oct 2026 08:00:00 +0000

Running a Multi-Repo Product with Parallel AI Agents (Claude Code)

How I set up one workspace where a single Claude Code session hands work to one agent per repository, keeps them out of each other's code, and runs several tasks at the same time without them stepping on each other.

The setup: 7 independent git repos (API backend, customer dashboard, admin portal, marketing site, iOS SDK, Android SDK, an internal Python tool) sitting side by side in one folder.

1. The idea in one picture

workspace/                      ← its own small git repo (agents, rules, contracts)
├── CLAUDE.md                   ← map of all repos + shared rules
├── contracts/                  ← the ONLY place cross-repo changes are agreed
├── .claude/
│   ├── agents/<repo>.md        ← one agent per repo + a read-only test auditor
│   ├── hooks/                  ← guards that enforce the rules
│   └── settings.json
├── clone-all.sh                ← one command to get every repo
├── backend/                    ← separate repo (ignored by the workspace repo)
├── client-dashboard/           ← separate repo
└── ...

You talk to one main session started at the workspace root. It plans, starts one agent copy per task per repo (each in its own git worktree), and collects the results.

2. Step by step

Step 1: Make the workspace root its own repo

Don't use submodules. Keep each product repo as a normal clone, and make the root a tiny repo that tracks only workspace files. Use an allowlist .gitignore so a product repo can never be committed by accident:

/*
!/.gitignore
!/README.md
!/CLAUDE.md
!/clone-all.sh
!/contracts/
!/.claude/
/.claude/settings.local.json

Add a clone-all.sh that clones every repo into its folder, so a new machine or teammate gets the same layout with one command.

Step 2: A CLAUDE.md in every repo

Keep each one short (under 300 lines): purpose, stack, key folders, entry points, run/test/build commands, conventions. Generate it by having an agent read package.json, build files and the existing docs, then check the commands against the real scripts.

End each one with a pointer to the shared rules instead of copying them:

## Agent rules
Shared rules live in the workspace root ../CLAUDE.md.
In short: edit only this repo, put cross-repo needs in ../contracts/.

Claude Code automatically loads CLAUDE.md files from parent folders, so the root rules apply inside every repo.

Step 3: The root CLAUDE.md

One line per repo: name, stack, role.
How the repos connect (who calls which API, which auth).
The core rule: route work to the matching agent; cross-repo changes go through /contracts.
A git workflow (branch from develop, never skip hooks, one PR per repo).
Parallel-work rules (see section 4).

Step 4: One agent type per repo, one copy per task

A file in .claude/agents/ defines an agent type, not a single worker. The main session can start many copies of the backend agent at once, one per task. Each copy works in its own git worktree, never in your main checkout.

.claude/agents/backend.md:

---
name: backend
description: "Use for any work in /backend: Node/Express API, database, webhooks, endpoints used by the dashboards and SDKs."
tools: Read, Edit, Write, Grep, Glob, Bash
---
You own the backend repo. Many copies of you can run at once, one per task,
so you never work in the main checkout.

1. Read backend/CLAUDE.md first, and follow it.
2. Work in your own worktree, one per task:
   git -C backend worktree add ../_wt/backend-<task> -b <type>/<task> origin/develop
   Install dependencies there for real; never symlink node_modules.
3. Edit only inside _wt/backend-<task>/. Never edit backend/ itself (it's the user's
   checkout) and never edit another repo.
4. Cross-repo needs: write contracts/<task>.md (owner, consumers, status), then stop.
5. Write tests for what you changed, including edge cases, and run them. Then reply
   with your worktree path so the main session can run test-auditor. Fix any gaps first.
6. Commit, push (hooks on, never --no-verify), open one PR to develop.
7. Append a 2-line summary to backend/.agent-notes.md. Final reply: worktree, branch,
   PR link, tests run, open contract items.

The description is what routing uses, so make it specific ("Use for any work in /backend: …").

Step 5: A read-only test auditor that judges quality, not just presence

---
name: test-auditor
description: Use after a code change, before pushing, to audit one task's worktree. Read-only.
tools: Read, Grep, Glob, Bash
---
1. List what changed in the worktree vs origin/develop. Read the task.
2. Coverage: every new or changed behaviour has a test; no untested branch,
   error path or validation rule.
3. Missing edge cases: name the specific ones that should exist but don't:
   empty/null, boundaries (0, 1, max), invalid input, auth/permission failures,
   cross-tenant access, duplicates/idempotency, retries/timeouts, dates/time zones,
   pagination, UI loading/empty/error states.
4. Value: flag tests that would still pass if the code were broken: no real
   assertion, asserting a mock's own return value, testing implementation details,
   snapshot-only logic, copy-paste cases, over-mocking the thing under test.
5. Run the tests. Output PASS, or GAPS: one specific bullet per gap, most important first.

It has no Edit or Write tools, so it reports problems instead of quietly "fixing" them. Each gap is specific enough for the repo agent to write the missing test.

Step 6: /contracts for cross-repo work

A folder of small spec files, one per topic. Each says: owner repo, consumers, status (proposed / agreed / implemented), and the shape (types, endpoints, examples). An agent never edits another repo; it writes the need here, and the owning agent implements it.

Step 7: Enforce the rules with hooks (instructions alone aren't enough)

Rules written in CLAUDE.md are suggestions. Hooks are code the harness runs every time.

PreToolUse guard: a repo agent may edit only its own worktrees, contracts/, and its notes file. Not other repos, not other agents' worktrees, and not your main checkout. Hook input includes agent_type when a subagent makes the call:

// .claude/hooks/repo-guard.js (trimmed)
const path = require('path');
let raw = '';
process.stdin.on('data', (c) => (raw += c));
process.stdin.on('end', () => {
  let data;
  try { data = JSON.parse(raw); } catch { process.exit(0); } // fail open
  const file = (data.tool_input || {}).file_path;
  const agent = data.agent_type;                 // set only inside a subagent
  if (!file || !agent || agent === 'test-auditor') process.exit(0);

  const root = process.env.CLAUDE_PROJECT_DIR;
  const rel = path.relative(root, path.resolve(data.cwd || root, file));
  const [top, sub = ''] = rel.split(path.sep);
  const ownWorktree = top === '_wt' && sub.startsWith(`${agent}-`);  // _wt/backend-<task>/
  const notesFile = rel === path.join(agent, '.agent-notes.md');

  // Allowed: own worktrees, contracts/, own notes file. Not the main checkout.
  if (rel.startsWith('..') || !(ownWorktree || top === 'contracts' || notesFile)) {
    process.stdout.write(JSON.stringify({
      hookSpecificOutput: {
        hookEventName: 'PreToolUse',
        permissionDecision: 'deny',
        permissionDecisionReason: `Agent "${agent}": work in _wt/${agent}-<task>/; cross-repo needs go to contracts/.`,
      },
    }));
  }
  process.exit(0);
});

PostToolUse formatter: each repo gets a hook that formats the file Claude just edited, using that repo's own pinned prettier (node_modules/.bin/prettier, not npx), limited to the file types its CI checks.

.claude/settings.json at the root:

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Edit|Write|MultiEdit|NotebookEdit",
        "hooks": [{ "type": "command", "command": "node \"${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/repo-guard.js\"" }] }
    ],
    "PostToolUse": [
      { "matcher": "Edit|Write|MultiEdit",
        "hooks": [{ "type": "command", "command": "node \"${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/format-dispatch.js\"" }] }
    ]
  }
}

Also add a guard that blocks reading .env files. It caught me (the AI setting this up) trying to link a .env into a temp checkout, which is exactly what it's for.

Step 8: Keep local git hooks fast

Pre-push runs only lint and the formatter check (seconds). Typecheck, unit tests, build and E2E run in CI on the pull request, where branch protection gates the merge. Slow local hooks teach people (and agents) to use --no-verify, which then skips the fast checks too.

3. How a task flows

Start Claude Code at the workspace root and describe the task. Example: "Add utm_campaign to link analytics and show it on the dashboard."

Plan. The main session sees that two repos are involved and that it's a cross-repo change.
Contract first. A backend copy writes contracts/utm.md (owner, consumers, shape, status).
Build each side in parallel. One backend copy in _wt/backend-utm/, one dashboard copy in _wt/client-dashboard-utm/, each on its own branch.
Audit. Each copy runs its tests and returns its worktree path. The main session runs test-auditor on it, and gaps go back to that same copy.
Ship. Each copy pushes (lint + format hooks) and opens its PR. CI runs the heavy checks.
Report. The main session summarizes with PR links and removes the worktrees.

Subagents can't start other subagents, so every handoff goes through the main session. You only talk to that one.

4. Running many tasks at the same time

Every task gets its own agent copy and its own worktree, so tasks never share files or branches, even when ten of them touch the same repo.

Example: 10 tasks, 8 touching backend + dashboard and 2 backend-only:

8 full-stack tasks → 8 backend copies + 8 dashboard copies (same task name, joined by a contract)
2 backend-only     → 2 backend copies
                     = 18 agent copies, each in its own _wt/<repo>-<task>/ worktree

Limits and what to do about them:

Machine load (installs, builds): run in waves of ~4 copies; keep local hooks to lint + format.
Tests that share one local database: run that repo's test suite one copy at a time.
Token cost and rate limits: waves; the main session only keeps each copy's short summary.
Task B needs task A's API: contract first; list dependencies in the prompt.

A prompt that works:

Here are 10 tasks. Run one agent copy per task per repo, each in its own worktree. Cross-repo tasks go contract-first, then both sides in parallel. Max 4 copies at a time. Run test-auditor on every worktree before pushing, open one PR per repo per task, then give me one summary with the PR links.

5. Lessons learned (the painful ones)

Hooks can be silently off. Git runs nothing if core.hooksPath points to a folder that doesn't exist (for example, husky never installed in a stale checkout). CI failed on a formatting issue the pre-push hook would have caught. Check that .husky/_ exists, or run the hook once by hand.
A PostToolUse hook only sees Claude's file-edit tools. Files changed through shell scripts, or written before the hook existed, are not formatted. CI is still the backstop.
Check that a PR is still open before pushing to its branch. I pushed follow-up commits to PRs that had already been merged; they never reached develop and had to be moved to new PRs. This is now a written rule.
Never --no-verify to get past a hook, not even for a doc-only commit. If a hook can't run in a temp checkout, fix the checkout.
Don't symlink node_modules into a worktree. Next.js/Turbopack refuses a symlink that points outside the project. Do a real install (pnpm install --prefer-offline is fast thanks to the shared store).
Settings load only from the folder you start in. Root hooks apply when you start at the root; a repo's own .claude/settings.json applies when you start inside it. Ancestor CLAUDE.md files load either way.
Relative paths only. Absolute machine paths in shared docs break for every teammate.
Keep settings.local.json out of git. It holds personal permissions.

6. Checklist to copy

Workspace root repo with an allowlist .gitignore + clone-all.sh
Short CLAUDE.md per repo, with commands checked against real scripts
Root CLAUDE.md: repo map, connections, routing rule, git workflow, parallel rules
.claude/agents/<repo>.md (one type per repo, one copy + worktree per task) + a read-only test-auditor that checks edge cases and test value
contracts/ with owner / consumers / status per spec
PreToolUse repo guard + .env guard; PostToolUse formatter using each repo's pinned tools
Pre-push = lint + format only; everything heavy in CI on the PR
Guard blocks agents from the main checkout; waves of ~4 copies

DEV Community: Ahsan Ali

How Anthropic reviews code when Claude writes 90% of it

Automated checks first

Humans scaled to risk

Mobile E2E testing three ways: Detox, Maestro, and now plain-English agents

Detox

Maestro

Now: e2e by TesterArmy

My take

GitHub stacked PRs are the review tool agentic development needed

One feature, four layers

iOS SceneDelegate and React Native: what changed and how to fix it

TL;DR

Before: one app, one window, one AppDelegate

Now: AppDelegate for the process, SceneDelegate for the UI

Why Apple changed it, and when it bites

How React Native booted on iOS before 0.88

What breaks in a React Native app

Fix A: upgrade to React Native 0.88

Fix B: stay on an older React Native version

Shared helper (all versions)

RN 0.79–0.87 (RCTReactNativeFactory)

RN 0.74–0.78 (RCTAppDelegate subclass)

RN 0.70 and earlier, or 0.71–0.73 on the old architecture (RCTBridge)

Expo

Be realistic about very old versions

Deep links, push and third-party SDKs

Testing checklist and gotchas

Sources

EAS Update pricing: why shipping less often won't save you money

The actual billing rule

What does scale: bandwidth

Self-hosting

Shopify used agents to leave React Native. Expo used one to fix it. Same bet.

What each one did

The wrong lesson

The real lesson

How I stop 18 Claude Code agents from pushing to main or touching secrets

What I'm setting up

tool.call: keep each agent in its lane

tool.check: no pushing to main

tool.call: protect secrets

prompt.submit: add context automatically

turn.step: watch costs

Why it works

One gotcha

Your AI agent can't open your mobile app. Here's the plumbing that fixes it

The pipeline

1. Give it a device

2. Give it typed tools, not a debug menu

3. Make it leave a file, not a transcript

4. CI owns it

The hidden cost

CLAUDE.md is not a quality gate. Here's how to build one with hooks

Hooks

1. PostToolUse: fast checks after every edit

2. Stop: the hard gate before the agent can finish

3. The part most people miss: exit code 2

The loop closes by itself

The device matrix was a cost problem, not a QA problem

react-native #ai #agentic-development

Running a Multi-Repo Product with Parallel AI Agents (Claude Code)

Running a Multi-Repo Product with Parallel AI Agents (Claude Code)

1. The idea in one picture

2. Step by step

Step 1: Make the workspace root its own repo

Step 2: A CLAUDE.md in every repo

Step 3: The root CLAUDE.md

Step 4: One agent type per repo, one copy per task

Step 5: A read-only test auditor that judges quality, not just presence

Step 6: /contracts for cross-repo work

Step 7: Enforce the rules with hooks (instructions alone aren't enough)

Step 8: Keep local git hooks fast

3. How a task flows

4. Running many tasks at the same time

5. Lessons learned (the painful ones)

6. Checklist to copy

RN 0.79–0.87 (`RCTReactNativeFactory`)

RN 0.74–0.78 (`RCTAppDelegate` subclass)

RN 0.70 and earlier, or 0.71–0.73 on the old architecture (`RCTBridge`)