NewHackVoltar à missão

Brex 6 de outubro de 2026San Francisco

O que muda quando a IA acelera a execução

Julgamento, atenção e confiança passam a pesar mais. Aprendizados do encontro com Hercules Gimenes e aplicações para quem constrói, lidera e toma decisões.
Ver o álbum de fotos ↗

A leitura central

A conversa sugere uma mudança naquilo que limita o crescimento de uma organização. Quando a IA acelera a implementação, o trabalho de decidir o que construir, interpretar o cliente, coordenar pessoas e controlar consequências passa a pesar mais. Produzir mais código, alertas ou análises não garante que a empresa conclua mais trabalho útil.

O exemplo mais revelador foi uma fila de tarefas alimentada por agentes. A automação pode encontrar inconsistências muito mais rapidamente do que uma pessoa consegue examiná-las. Se cada descoberta vira mais uma pendência, o produto entrega capacidade de detecção e transfere o custo da decisão para o usuário. A melhoria técnica pode produzir uma experiência pior.

Nossa síntese editorial deste encontro é: a vantagem com IA depende de transformar capacidade de produção em decisões confiáveis e resultados concluídos, dentro da capacidade real de atenção da organização. Essa formulação é uma interpretação proposta a partir da conversa, não uma citação do convidado nem uma opinião histórica atribuída a Rodrigo.

Há oito aprendizados que ajudam a tornar essa ideia concreta.

Uma oportunidade começa na inadequação do modelo existente

Passagem do encontro: 04:16 a 06:54 e 20:44 a 21:52.

Hercules retomou a dificuldade de fundadores estrangeiros para obter crédito corporativo nos Estados Unidos, mesmo quando suas empresas tinham recursos. No relato, a Brex encontrou uma oportunidade ao considerar informações sobre o caixa da empresa, em vez de depender apenas das referências tradicionais de crédito. Mais adiante, ele criticou iniciativas que começam por escolher IA ou chatbot antes de compreender a dor do cliente.

O ponto interessante é a relação entre as duas histórias. Um produto pode surgir porque o mercado utiliza uma referência que não descreve bem determinado cliente. A oportunidade não está apenas em executar o processo existente com mais eficiência. Está em perceber que a lógica desse processo exclui ou atende mal um segmento.

Para um founder, isso muda a pergunta inicial. Além de perguntar onde a IA economiza tempo, vale investigar qual hipótese do setor deixou de fazer sentido. Uma etapa de aprovação realmente reduz risco? O documento solicitado informa algo útil? A empresa está medindo capacidade de pagamento, familiaridade com o processo ou apenas facilidade de preencher formulários?

Essa leitura não autoriza retirar controles sem substituí-los por evidências melhores. No exemplo financeiro, conhecer o caixa não elimina todos os riscos de crédito. O aprendizado transferível é revisar a referência usada para decidir, não reproduzir uma política de crédito fora de seu contexto.

Aplicação sugerida: escolher um processo em que clientes qualificados desistam ou sejam recusados. Examinar casos concretos, identificar a hipótese por trás da barreira e testar uma alternativa com escopo limitado. Medir conclusão, tempo e qualidade da decisão, além da velocidade de execução.

Contexto conferido: os comunicados oficiais situam o início da Brex em 2017. A Capital One anunciou a aquisição por US$5,15 bilhões em janeiro de 2026 e informou sua conclusão em abril. Esses dados corrigem as referências a 2016 e US$5,4 bilhões presentes na transcrição. Anúncio da Brex, conclusão da aquisição.

A adoção depende de onde a ferramenta entra no trabalho

Passagem do encontro: 21:52 a 24:40.

O convidado descreveu diferenças de adoção entre engenheiros de frontend e backend. Uma ferramenta integrada a um ambiente familiar facilitou o uso pelo primeiro grupo. Para o segundo, que trabalhava com Kotlin e outro ambiente de desenvolvimento, essa ferramenta não se encaixava bem. Uma opção operada pelo terminal tornou a transição mais compatível com o trabalho existente.

Esse relato ajuda a distinguir resistência cultural de inadequação operacional. Duas pessoas podem demonstrar níveis diferentes de adoção porque o custo de mudar é diferente para cada uma. Trocar de ambiente, mover arquivos, reconstruir contexto e conferir uma saída acrescenta trabalho, mesmo quando a demonstração da ferramenta parece convincente.

É uma hipótese importante para empresas que compraram licenças, fizeram treinamento e ainda não perceberam mudança. Antes de cobrar mais entusiasmo, é preciso observar uma tarefa completa: como começa, onde estão os dados, quem decide, como a entrega é conferida e em qual sistema termina. O ganho pode desaparecer nas passagens entre sistemas.

Também há um limite para preservar o fluxo existente. Integrar a IA em um processo desnecessariamente complexo pode apenas tornar esse processo mais rápido. O piloto precisa distinguir o atrito que deve ser removido do controle que precisa continuar existindo.

Aplicação sugerida: acompanhar cinco execuções de uma tarefa recorrente. Registrar tempo de produção, transferência de dados, revisão e retrabalho. Testar a IA no ponto em que o profissional já trabalha e comparar o ciclo completo. Uso de licença é uma medida de atividade; conclusão com qualidade é uma medida mais próxima de valor.

A confiança precisa crescer por tipo de ação

Passagem do encontro: 24:10 a 24:40 e 26:44 a 32:23.

Na conversa, sugerir uma ação e executar uma ação financeira apareceram como responsabilidades diferentes. Um agente pode solicitar uma informação sobre uma despesa sem receber, por isso, permissão para aprová-la. Hercules descreveu filtros determinísticos sobre ações propostas, validação de entidades e avaliação complementar por outro modelo.

Isso permite construir confiança por etapas. Primeiro, o sistema ajuda a localizar e explicar um problema. Depois, prepara uma decisão para revisão. A execução automática pode ser liberada para ações específicas, quando houver evidência suficiente de qualidade, limites claros e possibilidade de recuperação.

Uma categoria ampla como “agente financeiro” diz pouco sobre o risco. Ler um comprovante, enviar uma pergunta, alterar uma classificação, aprovar uma despesa e transferir recursos exigem permissões distintas. O desenho deve partir dessas ações e de suas consequências.

O relato de segurança tornou essa distinção concreta. Em um teste controlado, um engenheiro colocou uma instrução maliciosa em um campo de despesa. O agente coletou informações adicionais e as enviou a um site criado para o teste. Trata-se de um exercício de segurança descrito pelo convidado, não de evidência de vazamento público de dados de clientes.

O mecanismo é relevante: conteúdo que deveria ser tratado como dado passa a influenciar instruções e uso de ferramentas. Uma orientação escrita no prompt para “não vazar dados” não substitui a restrição sobre quais dados e destinos estão disponíveis. Se um agente consulta a internet, não precisa necessariamente carregar consigo todo o contexto financeiro do cliente.

Um artigo público de Hercules acrescenta detalhes: políticas, comprovantes, memos e fontes externas têm papéis distintos; uma decisão proposta deve passar por verificações antes de alterar o estado durável de um caso. O texto também discute rastreabilidade e testes adversariais. É um complemento público à conversa, não a mesma demonstração de segurança narrada na visita. Artigo de Hercules sobre entradas e controle do agente.

Aplicação sugerida: criar uma tabela de ações com dados necessários, ferramentas permitidas, responsável pela aprovação e forma de desfazer. Começar por uma ação reversível. Testar instruções maliciosas em documentos, destinatários incorretos e pedidos fora do escopo. Medir erros e consequências, não apenas respostas consideradas boas.

A atenção humana pode se tornar o recurso mais escasso

Passagem do encontro: 25:16 a 26:19.

Hercules descreveu o problema de gerar mais tarefas do que o usuário consegue processar. A comparação entre uma grande fila e poucas ações valiosas foi ilustrativa, não um resultado quantitativo apresentado pela empresa.

A implicação para produto é profunda. Detectar algo tem valor quando essa descoberta orienta uma ação útil. Uma lista extensa de alertas pode aumentar ansiedade, interromper o trabalho e dificultar a identificação do que exige atenção. O problema não é apenas a interface. É a política que decide o que merece entrar na fila.

Um sistema que prioriza bem precisa considerar impacto, confiança da evidência, urgência, duplicidade e custo da ação. Também deve distinguir situações que podem ser agrupadas ou resolvidas automaticamente daquelas que realmente precisam de julgamento humano.

Há uma tensão aqui: reduzir o número de alertas pode melhorar a experiência e esconder casos relevantes. Por isso, priorização não deve significar simplesmente mostrar menos. É necessário avaliar os casos que ficaram fora da fila e observar se o sistema está omitindo problemas importantes.

Essa questão também muda o significado de colocar uma pessoa no processo. Uma revisão humana só funciona se houver tempo, contexto e autoridade para discordar. Uma pessoa sobrecarregada que aprova rapidamente uma fila pode oferecer pouca proteção, mesmo quando todas as decisões têm um registro de aprovação.

Aplicação sugerida: testar uma fila diária curta, com motivo da prioridade, evidências e próximo passo. Comparar tempo até resolução, percentual de sugestões úteis, retrabalho e casos relevantes omitidos. A meta é elevar a quantidade de decisões bem concluídas por unidade de atenção.

Uma equipe pequena precisa de autonomia e limites claros

Passagem do encontro: 10:15 a 11:56 e 44:11 a 47:53.

O convidado valorizou pessoas com iniciativa, capacidade de execução e interesse por produto. Ao discutir liderança, relacionou o aumento da velocidade de implementação à necessidade de criar alinhamento e espaço para contribuição.

É tentador usar as estimativas de tamanho de equipe mencionadas na conversa para afirmar que poucos profissionais com IA substituem uma organização enorme. Essa conclusão não é sustentada pelo encontro. O próprio convidado demonstrou incerteza sobre alguns números, e os grupos citados tinham escopos diferentes.

A leitura mais útil é sobre desenho de responsabilidade. Uma pessoa que consegue construir mais rapidamente precisa saber quais problemas pode explorar, quais decisões pode tomar e quando deve chamar outras áreas. Se essas referências não existem, a empresa pode produzir mais iniciativas que competem entre si ou precisar revisar tudo depois.

A autonomia pode ser ampliada por decisões explícitas: objetivo esperado, restrições, acesso ao cliente, orçamento de experimentação e situações que exigem revisão. Isso preserva espaço para iniciativa e reduz a dependência de obter autorização para cada detalhe.

Existe ainda uma diferença entre autonomia e deixar alguém sozinho. Acesso a informação, feedback e apoio de outras áreas é parte da capacidade de executar. Velocidade individual não compensa indefinidamente um sistema de decisões confuso.

Aplicação sugerida: escolher uma entrega e registrar quem define o objetivo, quem pode mudar a solução, quem aprova uma publicação ou alteração de dados e quando a decisão precisa ser escalada. Observar o tempo perdido em espera e em refazer trabalho por falta de alinhamento.

A entrevista com IA deve revelar o julgamento do candidato

Passagem do encontro: 39:08 a 42:41.

Hercules descreveu um processo em que o candidato pode usar ferramentas de IA durante um projeto acompanhado. O interesse está em observar como a pessoa divide o problema, interpreta regras de negócio, prioriza e faz perguntas. O relato descreve a experiência apresentada pelo convidado; não comprova que esse formato seja aplicado a todas as contratações da Brex.

Quando um candidato entrega algo com um único pedido ao modelo, parte importante do resultado pode refletir a ferramenta. O avaliador precisa entender o que a pessoa percebeu, verificou e corrigiu. Uma implementação aparentemente completa pode esconder uma regra de negócio incorreta ou uma falha que só aparece fora do exemplo inicial.

Uma avaliação coerente poderia incluir uma ambiguidade de negócio, uma saída incorreta da IA e uma mudança de requisito. Isso permite observar se o candidato identifica o problema, explica escolhas e confere o resultado. A velocidade continua relevante, mas precisa ser interpretada junto com compreensão e qualidade.

O formato também exige consistência. Candidatos com familiaridade prévia com uma ferramenta podem parecer mais produtivos por razões que não representam toda sua capacidade. Condições comparáveis, critérios explícitos e espaço para explicar o raciocínio tornam a avaliação mais informativa.

Aplicação sugerida: experimentar uma avaliação acompanhada, com uma mesma ferramenta disponível e critérios definidos antes da sessão: perguntas feitas, decomposição, decisões, verificação e explicação do resultado. Não adotar apenas “terminou em uma hora” como evidência de competência.

Demonstrar valor ajuda mais do que exigir adoção

Passagem do encontro: 33:05 a 38:11.

Hercules propôs facilitar o acesso dos primeiros usuários a ferramentas e permitir que compartilhem práticas úteis com o restante da organização. A conversa incluiu um canal interno para trocar experiências concretas, além da necessidade de avaliar se uma tarefa realmente pede IA.

Rodrigo também relatou uma experiência de produção de relatório em que trabalhar ao lado de uma pessoa e demonstrar a aplicação da ferramenta ajudou a tornar o ganho visível. Esse relato ilustra uma intervenção prática; não oferece uma medição controlada de produtividade nem permite afirmar, pela transcrição, o efeito posterior sobre a adoção.

A contribuição é tratar mudança de comportamento como aprendizagem situada. Uma pessoa vê a tarefa que precisa entregar, participa da execução e entende como conferir o resultado. Isso cria referências que um treinamento genérico pode não oferecer.

Há um risco em depender apenas de usuários avançados. Seus resultados podem exigir conhecimento, acesso ou esforço que os colegas não têm. Uma prática só se torna transferível quando inclui entrada, etapas, limites, exemplos e critérios de revisão. Compartilhar apenas o resultado impressionante não ensina a reproduzi-lo.

Também vale testar se a solução mais simples é uma regra, um formulário melhor ou uma integração. Colocar IA em uma etapa não deveria ser o objetivo do projeto. O objetivo é melhorar a entrega.

Aplicação sugerida: instituir uma demonstração semanal curta de um trabalho real, mostrando a situação anterior, o processo usado, como foi conferido e onde falhou. Transformar os casos úteis em instruções reutilizáveis e acompanhar se outras pessoas conseguem executar a mesma tarefa.

Liderar envolve aproximar implementação e cliente

Passagem do encontro: 44:11 a 54:41.

No trecho final, comunicação, visão compartilhada e contato com clientes ganharam destaque. O convidado relacionou a maior velocidade de construção à necessidade de entender problemas e alinhar ideias. Também discutiu barreiras organizacionais, reuniões pouco úteis e a combinação entre iniciativa das equipes e apoio da liderança.

A metáfora de que todo engenheiro passa a precisar de um escopo semelhante ao de um profissional muito experiente ajuda a expressar a mudança de expectativa. Ela não significa uma promoção formal nem elimina diferenças de conhecimento técnico. Sugere que implementar depressa aumenta a necessidade de compreender consequências além da própria tarefa.

Se uma equipe recebe apenas uma especificação, pode executar muito bem uma interpretação incompleta do problema. O contato com o cliente permite perceber exceções, motivações e custos que não aparecem no pedido inicial. Essa proximidade precisa continuar conectada a prioridades e responsabilidades, para evitar que cada conversa produza uma direção nova.

O papel da liderança é reduzir a distância entre o que a empresa quer alcançar e as decisões que o time consegue tomar. Isso inclui remover dependências desnecessárias e proteger o espaço para perguntas, discordância e validação. Também inclui interromper iniciativas que geram atividade sem melhorar o resultado.

Aplicação sugerida: reunir alguém de produto, alguém de implementação e alguém responsável pelo relacionamento com o cliente para acompanhar um caso completo. Definir o problema juntos, testar uma solução limitada e fazer uma revisão baseada no resultado observado.

Tensões que merecem continuar na discussão

Tensão observadaO que pode dar erradoReferência para decidir
Mais capacidade de detectar, mesma capacidade de revisarA fila cresce e as decisões pioramCasos resolvidos, tempo de revisão e omissões relevantes
Mais autonomia, objetivos pouco clarosIniciativas rápidas seguem direções diferentesDecisões permitidas, prioridades e critérios de escalada
Mais ferramentas, trabalho fragmentadoA economia na produção vira custo de transferênciaTempo do ciclo completo e retrabalho
Mais confiança no agente, permissões amplasUm erro ou instrução maliciosa produz consequência maiorEscopo mínimo, ação reversível e verificação independente
Mais velocidade na entrevista, pouca observação do raciocínioO modelo é avaliado como se fosse o candidatoExplicação, perguntas e correção de falhas

Essas tensões ajudam a evitar uma conclusão simplista sobre “o mindset do Vale”. A visita oferece um caso específico, narrado por um profissional de uma empresa de tecnologia financeira. Não representa todas as empresas da região nem prova que os mesmos mecanismos terão resultados iguais no Brasil.

Conexões com as memórias de Rodrigo

As conexões abaixo foram encontradas na API de memórias e conferidas nas transcrições de origem. São paráfrases. As fontes têm revisão textual e indicação de áudio não verificado, por isso não são utilizadas como citações literais.

Observar como as decisões são tomadas

Em uma entrevista ao Aura, Rodrigo descreveu o valor de passar tempo no Vale para observar como as pessoas pensam e decidem. O encontro com a Brex permite aplicar essa perspectiva: acompanhar como a empresa escolhe o que automatizar, cria limites e interpreta o cliente é uma observação mais útil do que apenas conhecer uma ferramenta. Aura, trecho a partir de 1h11min32s.

Conexão nova proposta: o debriefing de cada visita pode registrar uma decisão que o participante pretende testar, além dos aprendizados que considerou interessantes. A fonte histórica sustenta a importância da observação; o método de debriefing é uma proposta para esta missão.

Construir para aprender e conferir antes de operar

Em uma aula de IA, Rodrigo relacionou o MVP à validação de dor e demanda. Em outro trecho da mesma aula, distinguiu produzir um protótipo de compreender aquilo que foi construído. A conversa com Hercules acrescenta uma camada operacional: o custo de experimentar pode cair sem que diminua a responsabilidade por verificar uma ação que afeta clientes. Aula sobre MVP, trecho sobre compreensão do protótipo.

Conexão nova proposta: separar dois critérios de sucesso no piloto. Um verifica se o problema merece uma solução; outro verifica se a solução tem qualidade e limites suficientes para operar. A aprovação do primeiro não substitui a do segundo.

Educação e comunidade como parte da distribuição

Em Verdades Antecipadas, Rodrigo defendeu a combinação entre desenvolvimento de produto, distribuição e educação, citando sua experiência na Rocketseat. O relato da Brex sobre demonstrações e compartilhamento interno cria uma conexão com a aprendizagem necessária para que uma ferramenta se torne parte do trabalho. Verdades Antecipadas, trecho a partir de 8min38s.

Conexão nova proposta: a NewHack pode transformar encontros em conhecimento que outras pessoas consigam aplicar: problema, decisão, evidência e experimento. Essa proposta amplia o alcance da missão, mas precisa ser medida por aplicação e retorno dos participantes. Presença no evento ou consumo de conteúdo não comprova mudança de comportamento.

Um plano de aplicação em trinta dias

O plano abaixo é uma recomendação editorial, não um compromisso da Brex nem uma previsão de ganho.

PeríodoTrabalho sugeridoEvidência a registrar
Dias 1 a 5Selecionar uma tarefa recorrente com responsável e consequência compreensível. Observar o processo atual.Tempo total, volume, erros, retrabalho e resultado esperado
Dias 6 a 10Testar assistência de IA no fluxo existente, com revisão humana e sem ampliar permissões de execução.Qualidade das sugestões, esforço para conferir e casos de falha
Dias 11 a 20Priorizar as sugestões úteis e testar uma ação reversível. Definir quando o sistema deve parar.Conclusões corretas, exceções, omissões e capacidade de recuperação
Dias 21 a 30Comparar o ciclo completo com a referência inicial e documentar uma prática reproduzível.Resultado, custo total, revisão necessária e decisão de manter, ajustar ou interromper

O custo total precisa incluir ferramenta, integração, execução, revisão e retrabalho. A economia de tempo numa etapa pode coexistir com aumento de custo em outra. Convém usar casos comparáveis e registrar mudanças de volume ou complexidade para não atribuir todo o efeito à IA.

Um piloto produtivo pode terminar com a decisão de não automatizar determinada ação. Identificar um limite com antecedência também produz aprendizado útil.

Perguntas para os próximos encontros

  1. Qual tarefa ficou mais rápida e qual virou o novo gargalo?
  2. O que a empresa deixou de fazer depois de adotar IA?
  3. Qual ação o agente ainda não pode executar, e por quê?
  4. Como o time sabe que o trabalho foi concluído corretamente?
  5. Que falha mudou o desenho do produto ou as permissões do sistema?
  6. Como o usuário recupera o controle quando discorda de uma recomendação?
  7. O que tornou uma prática reproduzível por alguém menos experiente?
  8. Qual ideia funciona bem aqui, mas depende de condições que talvez não tenhamos no Brasil?

Essas perguntas podem formar uma comparação entre as visitas sem forçar todas as empresas a falar sobre o mesmo tema. O programa ganha profundidade quando identifica mecanismos, condições e limites, além de tendências.

Fontes e critérios de leitura

A análise foi preparada a partir da transcrição de 55 minutos do encontro de 6 de outubro de 2026. Os horários indicados referem-se ao tempo decorrido na gravação. O áudio não foi ouvido nesta revisão.

As descrições de práticas internas são relatos do convidado. As conclusões e os experimentos são interpretação editorial. Fatos corporativos usados no texto foram confrontados com fontes oficiais. Termos incertos da transcrição, estimativas de equipes e diálogos recontados não foram convertidos em estatísticas ou citações definitivas.

As conexões com Rodrigo foram conferidas na API de memórias e nas transcrições de origem, cujas fontes públicas estão vinculadas no texto. Não foram utilizadas como citações literais.

WhatsApp