Pular para o conteúdo

Case 01 · Mobilidade · 2026 – hoje

Tazz.

App de corridas no Brasil. Arquitetei e construí do zero o app novo em Expo e os Workers novos dele, com agentes de IA escrevendo o código em paralelo. Também levei o compute do backend para Cloudflare e coloquei no ar o agente de atendimento e o PIX.

Ficha técnica

Papel
Arquitetura, app, backend e IA
Período
2026 – hoje
Stack
TypeScript · Expo · Cloudflare Workers · Durable Objects · Queues · Postgres
IA
Em produção · Agente com supervisão humana
App novo
Pré-lançamento · Expo, para substituir o app Flutter nas lojas
  • App novo

    Expodo zero, com auth, hub e API próprios

  • Migração

    100+ → 8Cloud Functions → Cloudflare Workers em ~47,5 h

  • Pagamentos

    set/2026PIX em produção

01 / Problema

Um teto de cota e um app preso ao Firebase.

20vCPU · cota fixa · São Paulo

O backend rodava em ~158 Cloud Functions no GCP e bateu na cota fixa de 20 vCPU da região de São Paulo, com o app em operação.

Mover o backend não bastava para sair do GCP. O app em Flutter falava direto com Firestore, Realtime Database, Storage e Firebase Auth pelo SDK, até no código nativo.

02 / Contexto

Trocar o motor com o carro andando.

Primeiro troquei o compute HTTP: ele foi para Cloudflare Workers, e os dados ficaram no GCP. Em set/2026, comecei do zero, como prova de conceito, um app novo em Expo que não fala direto com Firestore, Realtime Database nem Firebase Auth. Em 8/set, ele virou o substituto planejado do app Flutter nas lojas. Enquanto isso, o app Flutter segue em produção.

03 / Meu papel

Engenharia ponta a ponta.

3.1

IA e backend.

  • Agente de atendimento com tools, guardrails, LLM-juiz e evals
  • Orquestração dos agentes de código que construíram o app e os Workers novos
  • Migração strangler‑fig para Cloudflare Workers
  • PIX com o Asaas, sobre o ledger de partida dobrada
3.2

App novo.

  • App em Expo do zero, para passageiro e motorista
  • Auth próprio, hub em tempo real e API em Workers sobre Postgres
  • Biblioteca de componentes do app novo, com tokens e 2 temas
  • Admin novo e painel de atendimento, com handoff para humano

04 / Arquitetura

Dois apps na mesma borda.

Fig. 01App novo
  1. AppExpo · passageiro e motorista
  2. Workers própriosauth · API · corridas /v1Hub em tempo realDurable Object por cidade · WebSocket
  3. PostgresPlanetScale · Hyperdrive

Feito para OTA desde a primeira build · Firebase Auth só confere a senha no 1º login

Fig. 02Migração
  1. AppFlutter
  2. GatewayWorkerRotas não migradasFunctions legadasGCP
  3. Workers de domínio
  4. Firestore e Realtime DatabaseGCP

Durante o porte

Fig. 03Atendimento
  1. CanaisWhatsApp, Instagram, app, site, e-mail
  2. AtendimentoQueues + DO por conversa
  3. AgenteLLM via AI Gateway · WhatsApp e app
  4. Toolsconsulta, nota e handoff · allowlist
  5. Operador humanorevisa e envia · handoff

05 / Onde a IA entra

No atendimento.

Modelo
OpenAI via AI Gateway, com fallback.
Tools
Consulta de dados e da base, nota interna e handoff, com allowlist e auditoria. Não existe tool de dinheiro, cadastro ou cancelamento. No máximo 3 rodadas de tools.
Guardrails
Checagem em camadas, LLM-juiz e mascaramento de dados pessoais.
Evals
Evals offline com datasets, gate e comparação de 4 modelos. Rollout em shadow e canary.
Status
Em produçãoCom supervisão humana: a IA escreve o rascunho, e o atendente envia, edita ou descarta.

06 / Como foi construído

Um time de agentes, com portões humanos.

Comecei o app do zero em 4/set/2026. Uma discovery com 12 agentes leu o app Flutter e a documentação do Expo SDK 57 e escreveu specs com fatos citados por arquivo e linha.

Depois, agentes coordenadores, um depois do outro, tocaram um backlog de ~200 frentes em sessões paralelas, cada uma na sua worktree, e integraram o resultado. A primeira integração entrou na main em 8/set/2026.

Fig. 04Construção com agentes
  1. Discoverylê o app Flutter
  2. Backlogfrentes em ondas
  3. Coordenadoragente · integra
  4. Frentesparalelas · 1 worktree cada
  5. Revisãooutro provedor por frente
  6. Portões humanosbanco, main e lojas
Arquitetura
Defini a arquitetura na spec do app: auth próprio, conta no Postgres, hub em tempo real e suporte a OTA desde a primeira build.
Evidência
Cada frente fecha com uma prova por critério de aceite. O coordenador roda os checks de novo antes de integrar.
Revisão
Cada frente passa por revisão de um modelo de outro provedor. Por cima disso, 4 rodadas consolidadas deram GO ou NO-GO, e a primeira pegou 2 regressões críticas antes da main.
Modelo por risco
Modelo mais forte em dinheiro, auth, código nativo e arquitetura. Mais leve em portes 1:1 e telas simples.
Portões
Migração de banco, merge na main, redeploy de worker em produção e build de loja ficaram fora do alcance dos agentes sozinhos: eles preparavam, e um humano autorizava, às vezes para uma leva inteira.

07 / Decisões e trade-offs

O que ficou de fora, de propósito.

  1. 7.1
    Não usado

    Sem RAG no MVP.

    A base tem 58 entradas curadas, cada uma aprovada antes de ir ao ar, e busca por palavra‑chave. A decisão define quando reavaliar: só se o corpus passar de 200 KB de texto útil, se os "não sei" por falta de contexto passarem de 10% por duas semanas seguidas e se houver um dono para curar o corpus.

  2. 7.2

    Nenhuma tool mexe em dinheiro.

    As tools consultam dados, criam nota interna e passam a conversa para um humano, com allowlist e auditoria. Tool de dinheiro, cadastro ou cancelamento não existe.

  3. 7.3

    App novo, não um remendo no Flutter.

    A discovery de saída do GCP mostrou que o maior acoplamento estava no cliente: o Flutter falava com o Firebase direto pelo SDK. Para buscar dados, o app novo fala só com Workers próprios, e o Flutter segue nas lojas até a troca.

  4. 7.4

    Conta no Postgres, Firebase Auth só no 1º login.

    No app novo, a conta é a linha no Postgres. No primeiro login, o Worker de auth confere a senha no Firebase uma vez e grava um hash próprio. Depois disso, ele não chama mais o Firebase para aquela conta e nunca escreve nele.

  5. 7.5

    Strangler‑fig, não big bang.

    Rotas migradas por service binding atrás do gateway, e o que não migrou seguiu nas functions. Só o compute saiu: Firestore e Realtime Database ficaram no GCP, porque a cota que travou era de vCPU.

  6. 7.6

    Dinheiro isolado.

    Serviço de pagamentos isolado, ledger de partida dobrada sem rota pública e webhooks com autenticidade verificada (HMAC quando o provedor assina).

08 / Resultado

Agente no ar. App novo a caminho.

As primeiras builds de produção do app novo saíram em out/2026, e ele foi preparado para substituir o app Flutter como atualização nas lojas. O admin novo já roda na web, com dados de produção.

  • IAEm produçãoAgente nas conversas reais, com um atendente revisando cada resposta.
  • AppPré-lançamentoApp em Expo construído com agentes de código.