Grab builds layered defense against bugs in AI-generated code

The problem: more code, more chance of crashes

The adoption of AI coding assistants has accelerated code writing and increased the volume of changes per release. At Grab, a mobility and delivery super-app that operates across several Southeast Asian countries, this became a matter of formal attention: the company published an account of how it structured defenses against the rise in crashes, reported by InfoQ on November 7, 2026.

The scenario described by the engineering team itself is one of high scale and a continuous flow of changes, many of them shipped via feature flag independently of the release schedule.

At Grab's scale, crashes leaking into production are an ongoing risk. A high volume of merge requests lands every week across many product teams, many shipping features behind flags that are switched on independently of releases. Any one of those changes can introduce a crash.

Grab engineering team, in a post on the company's engineering blog

The cost of a crash goes beyond user experience. It lowers the app's crash-free session rate and, as a result, affects its ranking on Google Play. Since not every user has automatic updates enabled, a crash that reaches production stays on people's devices longer than would be ideal, and crashes without a clean stack trace force the team to manually cross-reference release timeline, flag rollout, and session metadata to find the cause.

Three phases of defense, from commit to production

Grab's strategy follows a shift-left logic: detect the problem as early as possible, rather than only reacting after it has already affected users. The company organizes its defenses across three moments in the cycle: pre-merge through pre-production, release control, and post-launch response.

In the first phase, the goal is prevention, described by the team as the "primary line of defense." This includes static code analysis with Android Lint and SwiftLint, using platform-specific rules, community rules, and custom rules; automated and manual testing, covering unit, UI, and QA; and Grab Early Access (GEA), a pre-production gate that distributes early builds to closely monitored internal users.

A crash that only a handful of internal users see in GEA would, at production scale, translate into a substantial spike in the crash rate, extra support load, and potentially a hotfix. Catching these crashes before they ever reach production users makes GEA one of our most important stability gates.

Grab engineering team, in a post on the company's engineering blog

Exposure control at release

In the release phase, Grab limits the reach of a change before trusting it:

• Staged rollout: the new app version reaches a small slice of users first; if the crash rate rises abnormally, the team can pause distribution before releasing it to everyone.
• Feature flags: each feature is enabled gradually while the team watches its impact on the crash rate; if it crosses a predefined threshold, it is switched off immediately, without needing a new release.

Fast response after launch

In the last layer, the focus is on reducing the time between a crash happening and the team acting: real-time crash monitoring with Firebase Crashlytics and BigQuery to detect anomalies as soon as a build goes live; automated triage and enriched diagnostics, which aggregate metadata and stack traces and help map the crash back to the specific pull request that caused it; and a feedback loop that feeds back into lint rules and test coverage after every post-mortem.

What this changes for teams dealing with high PR volume

Grab's scenario is not exclusive to an Asian mobility app: any team that has adopted code copilots and seen its weekly PR count grow faces the same trade-off between speed and stability. Mobility, delivery, and fintech apps operating in Brazil, with multiple squads activating feature flags in parallel, have the same risk surface described by the company.

The practical point for anyone reviewing code today is that no single layer solves the problem on its own. Lint catches what is statically detectable but doesn't cover behavior regressions; QA and automated tests catch part of the rest but don't simulate every flag combination in production; and only staged rollout, combined with real-time monitoring, limits the damage from something that passed through all of that and still broke.

For teams that still review AI-generated code the same way they reviewed hand-written code, Grab's account suggests a shift in priority: investing in a pre-production gate with real users (the role GEA plays there) and in feature flags with automatic shutdown by crash threshold, not just manual shutdown, tends to pay off more than simply increasing the number of human reviewers per PR.

What remains unclear

InfoQ does not detail which custom lint rules Grab uses, nor the numerical crash threshold that triggers the automatic shutdown of a flag or the pause of a rollout. The company's original publication, according to InfoQ itself, has more detail than the summary covers, but the direct link to that post is not available in the material consulted for this report.