Crisla
Pott

Um projeto pessoal para provar um conceito: uma PM sozinha, usando ferramentas de IA e infraestrutura de nuvem, consegue entregar um produto geoespacial funcional num ciclo curto de iteração — sem um time de engenharia dedicado.

Um mapa interativo de previsão de demanda para Bogotá que mostra onde os pedidos de delivery se concentram na cidade, em janelas de 30 minutos, para os próximos 3 dias. Os entregadores veem para onde a demanda está indo antes do pico. A mesma arquitetura escala para qualquer cidade com histórico de pedidos.

Dados: 30 dias de histórico de pedidos (lat/lng, timestamp). Indexação espacial: grade hexagonal Uber H3 na resolução 9 (~0,1 km² por célula). Previsão: perfil estatístico de demanda por hexágono — totalmente explicável, sem caixa-preta. Score: ranking por percentil (1–5) por janela de tempo, a mesma abordagem usada por Uber e DoorDash. Exclusão: o corredor da rodovia AK30 é removido via geometria de buffer — uma barreira operacional real na logística de Bogotá. Stack: Python · pandas · h3 · shapely · Kepler.gl · AWS S3.

Este é o case que parece o mais simples de todos, mas foi o que mais deu trabalho — e quase nada disso aparece na tela. O grosso do esforço foi a base geoespacial: garimpar e juntar vários shapefiles de Bogotá e da Colômbia, recortar e limpar as geometrias, e definir na mão as zonas operacionais da cidade pra que a malha H3 caísse sobre um mapa real e coerente. O demo renderiza em segundos; acertar a geografia levou dias.

ChatGPT e Claude em todo o pipeline: design de arquitetura, debug de casos extremos geoespaciais, scripts em Python, validação da metodologia de score. Claude Code para refatoração. Do conceito à demo ao vivo em algumas semanas de trabalho part-time.

Todo rolê tem a mesma treta: quem pluga o celular manda na música, e o gosto de uma pessoa domina a noite inteira. Uma playlist compartilhada nunca parece ser de todo mundo.

Um app web onde todo mundo joga as músicas que curte — colando uma playlist pública do Spotify ou do YouTube, ou só buscando, sem login — e o app mistura tudo num set só, com duas regras: justiça (ninguém monopoliza; cada pessoa tem o mesmo espaço) e fluxo (uma curva de energia que começa calma e sobe até o pico da noite, igual DJ). Dá pra tocar dentro do próprio app — jogar na TV pelos clipes — ou exportar pro Spotify.

Blend: junta as músicas repetidas em "âncoras", dá a cada pessoa uma cota igual e ordena as faixas numa curva de energia exponencial rumo aos hinos do fim da festa. Vibe: lê o clima de cada faixa pelas tags do Last.fm (o Spotify aposentou os audio-features). Sem login em escala: resolve músicas e clipes lendo direto as páginas públicas do Spotify/YouTube, contornando os limites de conta e cota das plataformas — então qualquer um contribui e toca sem se cadastrar. Stack: React · Vite · Supabase Edge Functions · Last.fm · Vercel.

Feito de ponta a ponta com o Claude Code num fim de semana — o algoritmo do blend, cache, o player embutido, i18n PT/EN, PWA e deploy. Eu descrevia o problema e tomava as decisões de produto; a IA escrevia o código enquanto eu testava e direcionava. A parte mais difícil não foi o código — foi decidir o que cortar e desenhar a experiência em cima do que as plataformas realmente permitem.

As plataformas de delivery na América Latina enfrentam uma ameaça crescente no cadastro de entregadores: fraude de identidade sintética — fotos de perfil geradas por IA reutilizadas em vários cadastros fraudulentos sob documentos diferentes. A revisão manual de fraude é lenta, inconsistente e não escala. Não existia sistema automatizado para detectar quadrilhas de fraude entre os cadastros.

Um pipeline de detecção de fraude de ponta a ponta com três camadas de defesa: validação cruzada de OCR dos documentos para pegar inconsistências entre os documentos enviados; detecção de imagens geradas por IA para sinalizar fotos de perfil sintéticas; e deduplicação por embedding facial para expor quadrilhas — o mesmo rosto cadastrado sob várias identidades diferentes.

Primeiro traduzi um processo manual em regras automatizáveis — mapeei cada passo que o time de revisão de fraude fazia na mão, identifiquei quais decisões seguiam uma lógica consistente e as converti em regras de negócio e limiares de risk scoring antes de escrever uma única linha de código.

Arquitetura modular — cada camada de detecção (OCR, imagem, rosto) funciona de forma independente, então o sistema pode sinalizar um caso por um único sinal ou por uma combinação, e cada módulo evolui sem quebrar os outros.

Saída em score de risco, não decisão binária — o sistema entrega um score de risco e um resumo de evidências para revisão humana, em vez de rejeitar cadastros automaticamente, mantendo uma pessoa no circuito para os casos limítrofes.

Claude Code como parceiro principal de desenvolvimento: estruturando a arquitetura do pipeline, iterando na lógica de validação de OCR, depurando as comparações de embedding e revisando o modelo de risk scoring. Isso é coerente com a minha forma AI-first de construir — a IA como copiloto da arquitetura à implementação.

Todo dia, milhares de clientes abriam tickets de suporte dizendo que o pedido nunca chegou. O suporte não tinha como saber quem falava a verdade — o entregador dizia ter entregue, o cliente dizia o contrário. Sem um sistema de evidências, o padrão era compensar o cliente para evitar risco. Isso criava dois problemas: custos mensais relevantes com pagamentos indevidos e nenhuma forma de identificar padrões de fraude ou má conduta de entregadores.

Em vez de depender de revisão manual caso a caso, liderei o desenvolvimento de um microsserviço que analisa automaticamente todo o ciclo de vida do pedido no momento em que o cliente abre um ticket. O insight-chave: a evidência já existia nos nossos sistemas — geolocalização, fotos, timestamps, histórico de chat. Só precisávamos conectar tudo e trazer à tona no momento certo, antes de um humano decidir.

Priorizei 'pedido não entregue' frente a outros tipos de defeito (produto danificado, má qualidade) porque era o de maior fricção para o usuário e com a trilha de evidências mais rica.

Montei o diagnóstico no momento de criação do ticket — para o agente de suporte receber a evidência antes de decidir, não depois.

Desenhei o resultado como uma recomendação clara (evidência encontrada / não encontrada) em vez de dados crus — reduzindo a carga cognitiva dos agentes e padronizando as decisões entre times.

Lancei primeiro em mercados menores (Uruguai, Peru) como experimento controlado. Os resultados iniciais ficaram abaixo do esperado, então refinamos o modelo antes de expandir para mercados maiores.

Enquadramento do problema de ponta a ponta & escopo da solução · Alinhamento com os times de engenharia e suporte · Racional de priorização & sequência de rollout · Design de experimentos & iteração pós-lançamento.

Além da economia, o sistema criou um padrão consistente e orientado a dados para resolver entregas contestadas — reduzindo a variação entre agentes e países. A evidência sempre esteve lá. O problema de produto era trazê-la à tona no momento certo.

Durante grandes eventos — blocos de carnaval, protestos, shows grandes, eleições — o time tinha que identificar manualmente quais lojas ficavam dentro da área afetada e fechá-las uma a uma na hora certa. Era lento, sujeito a erro e totalmente dependente de alguém olhando um mapa e lembrando de agir no exato momento em que o evento começava.

Uma ferramenta que automatiza o processo inteiro: você informa um local, define a área afetada e o sistema identifica e agenda os fechamentos automaticamente. Dois modos para os formatos reais de evento: modo raio para eventos pontuais (shows, estádios) e modo linha para eventos lineares (rotas de desfile, passeatas), cada um expansível por uma distância personalizada.

Fechamentos agendados para a hora exata do evento — tirando do time de operação a necessidade de estar presente num horário específico para disparar algo na mão.

Modo linha como segunda iteração — depois de ver que muitos eventos reais (desfiles, passeatas) não cabem num raio simples, ampliando a aplicabilidade sem adicionar complexidade.

Escalado para os 9 países depois de validado — eventos disruptivos (protestos, feriados, eleições) são um desafio operacional universal, não específico de um mercado.

Os clientes não faziam pedidos que não podiam ser atendidos. Os entregadores não eram mandados para áreas inseguras. As lojas não ficavam sobrecarregadas tentando atender uma demanda impossível. E o time não precisava mais monitorar ou intervir na mão no exato momento em que um evento começava.