Construir ficou fácil.
Decidir continua caro.

A pergunta que abriu a noite

O evento juntou num mesmo palco iFood, Google Cloud, Meta, Amazon, Databricks e a Enter — primeiro unicórnio de IA da América Latina. Quem abriu a noite foi Bel Araújo, diretora de design e produto de novos negócios do iFood, com uma provocação simples de dizer e difícil de aplicar: a pergunta relevante deixou de ser qual é o seu cargo e passou a ser qual problema você resolve.

Ela trouxe um conceito que vale para qualquer área, não só tecnologia: a fronteira irregular. A tentação é imaginar uma linha reta separando o que a IA faz do que o humano faz — como se existisse um ponto exato em que a máquina assume e a pessoa larga. Não existe. Um estudo que ela citou, sobre uso de IA generativa nos Estados Unidos, mostrava a divisão por função: cerca de 36% do trabalho de marketing, perto de 30% de engenharia, 6% de design. Números que parecem definir fronteiras — mas na prática, cada tarefa dentro de cada disciplina reage de um jeito diferente, e essa fronteira se move o tempo todo.

O efeito prático é que as disciplinas não encolheram. Elas se expandiram para dentro do território umas das outras. Um designer que antes ficava restrito a discovery e interface hoje formula tese de negócio. Um engenheiro que antes só executava hoje participa da decisão de produto. A régua não é mais o que você sabe fazer — é até onde você consegue carregar um problema sozinho.

Minha opiniãoConcordo com o diagnóstico, mas acho que ele esconde um risco que ninguém nomeou no palco. Expandir fronteira não é o mesmo que ter profundidade nela. Quando todo mundo pode esboçar uma tese de negócio, uma interface e um pedaço de código, fica mais fácil também ninguém ser dono de nenhuma das três de verdade. Multidisciplinar sem critério não é um super-IC — é um generalista disperso com ferramentas melhores. A diferença entre os dois não aparece no discurso de abertura. Aparece seis meses depois, quando alguém precisa assinar embaixo de uma decisão difícil.

O gargalo mudou de endereço

Tiago Penha, staff designer do iFood, e Bruno Parizotto, do time de produto, trouxeram o termo que carregou o resto da noite: handoff — a passagem de bastão entre disciplinas. Toda vez que o trabalho passa de mão, uma parte do contexto se perde na tradução. Foi assim a vida inteira: produto explica para design, design devolve para produto, produto explica para engenharia, engenharia devolve. Cada passagem, um pouco de sinal a menos chegando do outro lado.

A promessa da IA era eliminar essas passagens. E elimina — só que troca um problema por outro. Os dois propuseram três condições para que um handoff para a IA seja seguro: contexto (saber formular o pedido no vocabulário da outra disciplina), verificação (saber avaliar o que voltou) e responsabilidade (usar IA não transfere a conta de quem assina embaixo).

"Construir com IA pode ser mais fácil. Mas o gargalo saiu de codar e foi para revisar."

A dupla contou um caso real, sem filtro. Estavam construindo um produto novo de avaliação de restaurantes fora da estrutura do iFood — de propósito, para isolar o efeito do modelo de trabalho do efeito da marca. O time era pequeno e sem fronteiras: o designer decidia growth, o engenheiro decidia produto. E, no lugar de esperar um time de dados chegar no squad, criaram um agente batizado de Gomes — um analista que entrava nas reuniões, lia o Slack, cruzava métricas e código, e antecipava problemas antes de alguém perguntar.

Funcionou tão bem que a resposta começou a chegar antes da pergunta. E funcionou tão bem que, em algum momento, o Gomes ultrapassou uma fronteira de segurança e passou a tomar decisões erradas sozinho. O time desligou o agente. A régua daquele "analista" não era a mesma régua do time — e ninguém tinha enxergado esse risco a tempo de colocar um limite nele antes.

O ponto não foi o fracasso do agente. Foi onde o gargalo realmente estava. Construir deixou de ser o problema. Traduzir contexto entre disciplinas, que era o trabalho clássico de produto, também deixou. O que sobrou — e ficou mais evidente, não menos — foi revisar. E revisar em escala é um problema humano que nenhuma IA resolve por conta própria, porque revisar é, no fundo, julgar.

Um dado que sustentou essa virada veio de um estudo de Harvard citado no palco: uma pessoa usando IA sozinha rende o equivalente a uma dupla trabalhando sem IA. Mas um time inteiro usando IA em conjunto entrega resultados muito acima disso. Menos gente fazendo mais coisa é possível — mas o salto de qualidade não vem do indivíduo turbinado. Vem do time que aprende a decidir junto, mais rápido.

Minha opiniãoO caso do Gomes foi o trecho mais honesto da noite — e também o mais desconfortável, porque contradiz a própria receita apresentada minutos antes. O time tinha acabado de propor três condições para um handoff seguro: contexto, verificação, responsabilidade. E mesmo assim, o problema só apareceu depois que já tinha acontecido. Ninguém corrigiu antes; corrigiram depois. Acho que isso não invalida o framework, mas prova algo mais importante do que o framework em si: contexto, verificação e responsabilidade são fáceis de enunciar num palco e muito mais difíceis de operar em tempo real, quando o agente já está dentro do fluxo de trabalho tomando decisão sozinho. Quem estiver copiando esse modelo achando que só precisa "aplicar os três critérios" vai aprender essa lição do jeito caro — porque toda empresa vai ter o seu próprio Gomes antes de aprender a evitá-lo.

A complexidade não desaparece. Ela troca de lugar

Mike, CTO e cofundador da Enter, trouxe a provocação mais desconfortável da noite: a IA não deixou o software mais simples. Qualquer desenvolvedor hoje consegue tirar do papel dezenas de prototipos por dia — o atrito de executar praticamente sumiu. Só que atenção humana continua sendo o mesmo recurso escasso de sempre. Baixar o custo de execução não cria mais atenção disponível para operar, revisar e manter o que se constrói. Só empurra a fila para outro lugar do sistema.

Ele contou uma história antiga, de uma empresa de games onde times ficavam em salas separadas por vidro. Um dia tiraram a parede. Em poucas semanas, um time começou a copiar pequenas features do time vizinho — só porque virou fácil, não porque alguém tinha pedido. Chamou isso de cavalo de troia da facilidade: quando o custo de fazer cai a quase zero, a intencionalidade também cai. A empresa que gasta uma tarde recriando um concorrente de US$ 25 por mês não economizou nada — criou mais um sistema para governar, manter e defender.

Software B2B sofre disso de um jeito ainda mais agudo, segundo ele. Nos últimos 40 anos, engenharia de software inventou camada sobre camada para lidar com a variação entre clientes — APIs, microsserviços, motores de configuração, workflows customizáveis. Cada camada nova não elimina a complexidade: só desloca o custo dela para outro ponto do sistema. O que muda com LLM, na visão dele, não é a velocidade de escrever código. É a capacidade de interpretar linguagem natural como lógica de negócio em tempo real — deixando de tentar prever toda regra de antemão e passando a deixar quem entende o negócio explicar, na hora, o caso de borda que ninguém tinha previsto.

Minha opiniãoEssa foi, para mim, a fala mais subestimada da noite — porque não veio embrulhada em case bonito, veio embrulhada em arquitetura de software, um assunto que esvazia auditório. Mas o raciocínio do Mike vale para qualquer área que eu conheço, inclusive a minha. Toda vez que baixar o custo de fazer alguma coisa, o primeiro instinto do mercado é fazer mais dela — mais peça, mais variação, mais entregável. Isso não é produtividade, é acúmulo. A pergunta que ele fez para engenharia de software é a mesma que eu faço para qualquer cliente que chega com uma IA gerando dez opções de logo em cinco minutos: você ganhou velocidade de execução, mas ganhou algum critério a mais para escolher entre as dez? Se não ganhou, você só trocou o problema de "não ter opção" pelo problema de "ter opção demais e nenhum crivo para decidir" — e o segundo é pior, porque parece progresso.

Julgamento não se terceiriza

Na roda de conversa final, com Databricks, Meta, Amazon e o time do iFood, a discussão mais afiada veio de Isa Piratininga, diretora de inovação tecnológica do iFood. Ela desafiou a própria ideia de "humano no loop" como garantia de segurança. Segundo ela, isso costuma criar duas ilusões: o humano vira um gargalo — porque não revisa na velocidade em que a máquina produz — ou pior, entra em modo automático e aprova sem realmente ler.

A saída que ela propôs não é revisar mais. É mudar de papel: o humano deixa de ser revisor e passa a ser arquiteto de critério — quem define os padrões, os limites e as consequências que outros agentes vão usar para checar o trabalho da IA. Julgamento não escala sendo repetido por pessoa. Escala sendo transformado em critério.

David, da Databricks, trouxe o conceito do "Forward Deployed Engineer" — o engenheiro que atua dentro da área de negócio, prototipando junto, mas sob um centro de excelência técnico que garante governança. Autonomia na ponta, rigor no centro. Camila Pinto, diretora de people design do iFood, foi na mesma direção pelo lado humano: pensamento crítico deixou de ser um diferencial de carreira e virou competência básica. A frase que resumiu isso: "os modelos de IA são os maiores people pleasers que já existiram — eles sempre vão querer te agradar. Não aceita a primeira resposta."

E há um limite estrutural que ninguém no palco tentou disfarçar: modelos de linguagem agem por intenção, não por regra fixa. Por isso, problemas determinísticos — contábeis, fiscais, auditáveis — continuam exigindo lógica dura por trás, não julgamento probabilístico. IA entra para acelerar a interpretação. Não substitui a régua que precisa ser exata.

Minha opiniãoA ideia de "arquiteto de critério" no lugar de revisor é elegante no palco de uma empresa do tamanho do iFood, que tem centro de excelência, squad de segurança e gente sobrando para pensar em governança. Para quem trabalha sozinho ou em time pequeno — que é a maior parte de quem lê este blog — a tradução é mais direta e, na minha visão, mais favorável: você não precisa negociar esse papel com ninguém, porque já é, sozinho, o centro de excelência do seu próprio trabalho. Ninguém vai construir seu critério por você nem vai revisar por você. Isso dá trabalho, mas é também a única vantagem que resta contra quem só sabe operar ferramenta.

O que continua caro

O fechamento da noite trouxe o exemplo mais direto de todos, contado por David: um cliente havia gasto mais de US$ 40 mil — fora o tempo da equipe — tentando reconstruir, internamente e com IA, um CRM que já existia pronto no mercado. Ninguém tinha pedido aquilo. Não resolveu problema nenhum de negócio. E ainda aumentou o débito técnico da empresa, porque agora existe mais um sistema proprietário para manter.

O recado por trás do exemplo é o mesmo que sustenta todo texto que já escrevi aqui sobre precificar trabalho criativo: quando executar fica barato, o erro de direção fica caro na mesma proporção — porque agora ele acontece rápido, em escala, e sem o atrito que antes forçava alguém a pensar duas vezes antes de começar. Ganho real não está em reconstruir o que já existe pronto e maduro. Está em usar essas ferramentas para criar fluxos de trabalho proprietários, construídos em cima dos seus próprios dados e do seu próprio contexto — a única vantagem competitiva que ninguém consegue comprar pronta.

É a mesma lógica que separa uma marca de um anúncio, ou um designer de um operador de ferramenta: a parte que qualquer um replica com um prompt nunca foi a parte que sustentava o preço. A parte cara sempre foi decidir o que vale a pena construir, o que descartar e por quê. Isso não mudou com a IA. Só ficou mais visível — porque agora é praticamente tudo que sobrou para fazer.

Minha opiniãoSaí do iFood Camp sem nenhuma dica de ferramenta nova, e acho que foi exatamente por isso que a noite valeu. Todo evento de IA que eu já fui promete um atalho: use este modelo, automatize aquele processo, ganhe dez vezes mais velocidade. Esse não prometeu atalho nenhum — prometeu mais trabalho de julgamento, não menos. E é a primeira vez que vejo isso dito com todas as letras num palco de tecnologia, sem embrulhar em otimismo de keynote. Para quem vende criatividade, estratégia ou decisão por profissão, essa é a melhor notícia que já ouvi sobre IA em muito tempo: o produto que a gente vende nunca foi a execução. Sempre foi o julgamento que decide o que executar. Isso não virou commodity. Só ficou mais fácil de perceber quem realmente tem.

Baseado na participação do autor no iFood Camp, evento realizado pelo iFood em 1º de setembro de 2026, com Bel Araújo, Isa Piratininga, Tiago Penha, Bruno Parizotto e Camila Pinto (iFood), e Mike Mac-Vicar (Enter), David Camoleze (Databricks), Daniel Ferreira (Meta) e Brandon Knapp (Amazon).