O que devs de IA ainda não aprenderam sobre comunicação

Fui convidado para palestrar sobre IA num evento do Sebrae. A plateia era de empreendedores: donos de pequenas empresas, comerciantes, prestadores de serviço. Nenhum dev. Nenhuma pessoa que soubesse o que é um token ou uma embedding.

Fui preparado para falar de tecnologia. Saí de lá com um aprendizado que mudou como eu trabalho com sistemas de LLM até hoje.

A pergunta que quebrou minha apresentação

No meio da palestra, uma senhora levantou a mão e perguntou:

"Mas isso vai substituir minha atendente?"

Não era uma questão técnica. Era uma questão humana, carregada de medo de demitir alguém que trabalhava com ela há anos.

Naquele momento, todo o conteúdo técnico que eu tinha preparado foi para segundo plano. RAG, LangChain, embeddings, chunking — nada daquilo importava ali. O que importava era entender o que ela estava realmente perguntando e responder de um jeito que fizesse sentido para o negócio dela, não para a minha cabeça de engenheiro.

Essa é a habilidade que a maioria dos devs nunca desenvolve.

O gap que os cursos de programação ignoram

A formação técnica em desenvolvimento de software é excelente para ensinar como construir. É péssima para ensinar o quê construir e para quem.

Aprende-se algoritmos, estruturas de dados, padrões de projeto, boas práticas de código. Não se aprende a sentar com um dono de negócio, ouvir os problemas dele com atenção real, e identificar onde a tecnologia resolve de verdade e onde ela só adiciona complexidade desnecessária.

Esse gap aparece o tempo todo em projetos de IA.

No Athena, agente integrado ao TOTVS Protheus que responde perguntas de negócio gerando SQL dinamicamente, a parte técnica foi mais rápida do que eu esperava. A parte difícil foi entender como cada área da empresa usava o sistema, quais eram as exceções que ninguém havia documentado em lugar algum, e como fazer o modelo lidar com variações de contexto que só faziam sentido para quem tinha anos de casa.

No GITFLOW, plataforma que substituiu o TOTVS Fluig na Guaraves automatizando processos internos para mais de três mil colaboradores, o desafio técnico foi real. Mas o que consumiu mais tempo e cuidado foi conseguir que as áreas de negócio adotassem a ferramenta de verdade, não apenas tolerassem ela existindo. Tecnologia que ninguém usa não resolve nada.

O que separa quem constrói demos de quem constrói soluções

Existe uma diferença entre quem sabe programar e quem sabe resolver problemas com programação.

Quem sabe programar pega um requisito e implementa. Quem resolve problemas questiona o requisito, entende o contexto por trás dele, e muitas vezes propõe uma solução diferente da que foi pedida porque identificou que o problema real era outro.

No contexto de IA isso é ainda mais crítico.

Um dev que só sabe chamar APIs de LLM consegue fazer uma demo funcionar em 30 minutos. O que não está ao alcance de uma tarde é entender por que aquela solução vai falhar em produção, como o usuário real vai interagir com ela, e o que acontece quando o modelo alucina numa situação crítica de negócio.

Essas respostas só aparecem quando você conhece profundamente o contexto onde a solução vai operar. E esse conhecimento vem da comunicação, não do código.

As três habilidades que ninguém lista mas todo projeto exige

Depois de alguns anos construindo sistemas de IA para empresas brasileiras, identifiquei um conjunto de habilidades que fazem mais diferença do que qualquer framework ou biblioteca.

Saber ouvir sem pressa de chegar à solução. A tendência de quem é técnico é ouvir o problema e já começar a pensar na arquitetura. O problema real aparece depois de algumas perguntas, quando a pessoa se sente ouvida o suficiente para ser honesta sobre o que realmente não funciona.

Conseguir falar o mesmo assunto em dois idiomas: o técnico e o de negócio. Com o time de desenvolvimento você fala de RAG, embeddings, latência, custo de tokens. Com o diretor financeiro você fala de horas economizadas, redução de retrabalho, retorno sobre investimento. É a mesma solução descrita de formas completamente diferentes para públicos completamente diferentes.

Saber dizer quando IA não é a resposta certa. Chegar numa reunião e dizer que o problema pode ser resolvido com uma planilha bem estruturada, sem uma linha de código de ML, exige mais maturidade do que construir um modelo desnecessariamente complexo para justificar o projeto.

O que acontece quando a barreira técnica cai

As ferramentas de IA estão ficando mais acessíveis. A barreira técnica para construir uma demo com LLM está caindo todo mês.

Quando qualquer pessoa consegue gerar código com IA e integrar uma API de LLM em horas, o que diferencia o engenheiro sênior não é a velocidade de escrever código. É a capacidade de identificar qual problema merece ser resolvido, arquitetar a solução certa para aquele contexto específico, e garantir que ela vai funcionar para pessoas reais em situações reais.

Invista no técnico. Mas invista também em saber ouvir, em aprender a fazer perguntas melhores, em conseguir explicar uma decisão de arquitetura para alguém que nunca programou.

A palestra no Sebrae foi um lembrete de que tecnologia sem comunicação é só tecnologia. Com comunicação, ela tem chance de se tornar solução.

Qual habilidade não técnica você acha mais subestimada em projetos de IA?