Grab monta defesa em camadas contra bugs de código gerado por IA

O problema: mais código, mais chance de crash

A adoção de assistentes de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → no desenvolvimento acelerou a escrita de código e aumentou o volume de mudanças por release. No Grab, super-app de mobilidade e entregas que opera em vários países do Sudeste Asiático, isso virou motivo de atenção formal: a empresa publicou um relato sobre como estruturou defesas contra o aumento de crashes, reportado pela InfoQ em 7 de novembro de 2026.

O cenário descrito pela própria equipe de engenharia é de escala alta e fluxo contínuo de mudanças, muitas delas liberadas via feature flag de forma independente do calendário de releases.

Na nossa escala, vazamento de crashes para produção é um risco constante. Um alto volume de merge requests chega toda semana vindo de muitas equipes de produto, muitas ativando funcionalidades via flags de forma independente dos releases. Qualquer uma dessas mudanças pode introduzir um crash.

Equipe de engenharia da Grab, em post no blog de engenharia da empresaAt 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.

O custo de um crash vai além da experiência do usuário↳UX33 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025UX, IA e Front-End: quando experiência, inteligência e código se encontram para criar o futuro digitalProduto & UX · jul 2025Novidades em UX/UI para 2025: O futuro do design de experiências digitaisProduto & UX · abr 2025Ver tudo em Produto & UX →. Ele reduz a taxa de sessões sem falha do app e, como consequência, afeta o ranqueamento na Google Play. Como nem todo usuário tem atualização automática ativada, um crash que chega a produção fica no aparelho das pessoas por mais tempo do que seria ideal, e crashes sem stack trace limpo obrigam o time a cruzar manualmente linha do tempo de release, rollout de flags e metadados de sessão para achar a causa.

Três fases de defesa, do commit à produção

A estratégia do Grab segue uma lógica de shift-left: detectar o problema o mais cedo possível, em vez de só reagir depois que ele já afetou usuários. A empresa organiza as defesas em três momentos do ciclo: pré-merge até pré-produção, controle de release e resposta pós-lançamento.

Na primeira fase, o objetivo é prevenção, descrita pela equipe como a "linha de defesa primária". Isso inclui análise estática de código com Android↳Android46 conteúdosAndroid push notifications com Quasar Framework, Firebase e integração com WordPressDev (Back & Front) · mai 2019O X do Xamarin Forms – O guia das funcionalidades nativas - Parte 02: AndroidDev (Back & Front) · abr 2019Modularização de AndroidDev (Back & Front) · ago 2019Ver tudo em Dev (Back & Front) → Lint e SwiftLint, usando regras específicas de plataforma, regras da comunidade e regras customizadas; testes automatizados e manuais, cobrindo unidade, UI e QA; e o Grab Early Access (GEA), um portão de pré-produção que distribui builds antecipadas a usuários internos monitorados de perto.

Um crash que apenas um punhado de usuários internos vê no GEA se traduziria, em escala de produção, em um salto substancial na taxa de crashes, carga extra de suporte e, potencialmente, um hotfix. Detectar esses crashes antes que cheguem aos usuários de produção faz do GEA um dos nossos mais importantes portões de estabilidade.

Equipe de engenharia da Grab, em post no blog de engenharia da empresaA 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.

Controle de exposição no release

Na fase de release, o Grab limita o alcance de uma mudança antes de confiar nela:

• Rollout em etapas: a nova versão do app chega primeiro a uma fatia pequena dos usuários; se a taxa de crash sobe de forma anormal, o time pode pausar a distribuição antes de liberar para todo mundo.
• Feature flags: cada funcionalidade é ativada de forma gradual enquanto o time observa o impacto na taxa de crash; se ultrapassar um limiar pré-definido, ela é desligada na hora, sem precisar de um novo release.

Resposta rápida depois do lançamento

Na última camada, o foco é reduzir o tempo entre o crash acontecer e o time agir: monitoramento de crash em tempo real com Firebase Crashlytics e BigQuery para detectar anomalias assim que um build vai ao ar; triagem automática e diagnóstico enriquecido, que agrega metadados e stack traces e ajuda a mapear o crash até o pull request específico que o causou; e um loop de feedback que alimenta de volta as regras de lint e a cobertura de testes depois de cada post-mortem.

O que isso muda para quem lida com volume alto de PRs

O cenário do Grab não é exclusivo de app de mobilidade asiático: qualquer equipe que adotou copilots de código e viu o número de PRs por semana crescer enfrenta o mesmo trade-off entre velocidade e estabilidade. Apps de mobilidade, delivery e fintech que operam no Brasil, com múltiplos squads ativando feature flags em paralelo, têm a mesma superfície de risco descrita pela empresa.

O ponto prático para quem revisa código hoje é que nenhuma camada isolada resolve o problema sozinha. Lint pega o que é detectável estaticamente, mas não cobre regressão de comportamento; QA e testes automatizados pegam parte do resto, mas não simulam todas as combinações de flags em produção; e só o rollout em etapas, combinado com monitoramento em tempo real, limita o dano de algo que passou por tudo isso e ainda assim quebrou.

Para times que ainda revisam IA-gerada do mesmo jeito que revisavam código escrito à mão, o relato do Grab sugere um ajuste de prioridade: investir em um gate de pré-produção com usuários reais (o papel que o GEA cumpre ali) e em feature flags com desligamento automático por limiar de crash, não só manual, tende a compensar mais do que apenas aumentar a quantidade de revisores humanos por PR.

O que ainda fica em aberto

A InfoQ não detalha quais regras de lint customizadas o Grab usa, nem o limiar numérico de crash que dispara o desligamento automático de uma flag ou a pausa de um rollout. A publicação original da empresa, segundo a própria InfoQ, tem mais detalhes do que o resumo cobre, mas o link direto para esse post não está disponível no material consultado para esta reportagem.

Fonte: InfoQ