Grab explains how its layered defense catches AI-written crashes

A mobile crash lands on a user's phone and stays there until the user updates. Grab's engineering team has published how it keeps that gap small. AI coding assistants now raise the volume of change in every release.

The Grab superapp runs on Android and iOS. It serves millions of users in Southeast Asia. Grab says it has over 100 million downloads on Google Play. Many engineers merge code every week, and features often sit behind flags. The post, by Nguyen Van Minh, names the three layers that keep a crash out of a user's hands.

Prevention: lint, tests, and an early-access build

Lint is the cheapest layer, Grab says. Android Lint and SwiftLint run on every merge request in CI. High-severity findings block the merge. Pre-existing issues sit in a baseline, so a merge only fails on findings it adds.

The rules come from three places. Platform rules cover known API misuse. Community rules cover patterns the platform rules miss. Custom rules turn post-mortems into checks. When a production crash traces to a code pattern, Grab writes a rule that blocks it from coming back. Grab says custom rules matter more as AI-assisted coding grows. An assistant can write code that looks right without knowing which patterns crashed the app before.

Tests run in four layers. Unit tests block logic errors. UI component tests catch rendering and state mismatches. End-to-end tests cover critical flows. Manual QA covers new features and a full regression pass on every release. Grab Early Access is a one-week internal gate. Builds are monitored, and every new crash creates a ticket for the owning team.

The release gate: staged rollout and kill switches

Every release rolls out over a week. It starts with a small share of users and expands in steps. A dedicated monitor tracks the new version's crash rate in isolation from older versions. If the rate rises past a threshold, an automated system pauses the rollout.

Grab says several Android rollouts were paused for on-call review in recent months. Most resumed after the signal turned out to be noise. A small number stayed halted at the first stage until a hotfix landed. All significant new features sit behind flags. A feature can be switched off without waiting for the next release.

Response: three steps, cheapest first

When a crash reaches production anyway, Grab's on-call framework runs three steps in order. Disable the responsible feature flag first. If no flag covers the path, apply a server-side fix: an API change, a config value, or a throttle on a backend dependency. Only if neither is available does the team cut a hotfix. The decision is tied to business criticality, severity, user impact, and time to the next release. Every hotfix ends in a post-mortem whose action items feed the lint layer or the test layer.

The post has detail the summary skips. It names the automated triage pipeline. It explains how Grab reads feature-flag rollout history when a crash appears with no new code. And it covers how iOS and Android share one release pipeline.

A buyer of AI coding tools can read this as the honest cost of adopting them. The assistant writes more code. The defense around it is where the cost shows up. Three parts are copyable. Custom lint rules from post-mortems. A staged rollout monitor that pauses itself. And a three-step response that leaves the hotfix for last.

Source

App stability at scale with a layered defense, Grab Engineering. Secondary coverage in InfoQ by Sergio De Simone.