Em dezembro de 2025, a Stack Overflow publicou seu levantamento anual com mais de 49 mil desenvolvedores em todo o mundo. O número central: 80% deles já usam ferramentas de IA no trabalho, um salto em relação ao ano anterior. Um mês antes, o relatório Octoverse do GitHub tinha mostrado outro ângulo do mesmo fenômeno — quase 80% dos novos desenvolvedores que se cadastram na plataforma já usam um assistente de IA na primeira semana de conta.
A pesquisa da JetBrains, com mais de 24 mil desenvolvedores em 194 países, chega a um número parecido pelo lado do uso contínuo: 85% dos desenvolvedores usam IA regularmente no trabalho, e 62% dependem de pelo menos um assistente de código, agente ou editor com IA embutida para completar tarefas, revisar trechos, gerar testes ou escrever documentação.
Poucas categorias de software tiveram uma curva de adoção tão rápida entre um público técnico específico. E é exatamente aí que mora o ponto deste texto: um público específico. Essas ferramentas foram desenhadas, testadas e otimizadas para uma pessoa que já sabe programar, já convive com terminal e controle de versão, e já entende o que é revisar um trecho de código antes de aceitá-lo. Quando a mesma ferramenta chega à mesa do financeiro, do RH ou do comercial, ela carrega consigo pressupostos que deixam de valer.
Onde essas ferramentas realmente brilham
Assistentes de IA para código foram construídos em cima de um pressuposto simples: quem está do outro lado sabe programar. Completar uma função, sugerir um teste, refatorar um trecho, explicar um erro de compilação — cada um desses usos, listados pela própria pesquisa da JetBrains como os mais comuns, pressupõe que a pessoa consegue ler o resultado, perceber quando ele está errado e corrigir o rumo.
Essa é uma tarefa que o desenvolvedor já faz há décadas ao revisar o código de um colega. A IA entra como um acelerador de um julgamento técnico que a pessoa já tinha antes da ferramenta existir — e isso explica por que a adoção foi tão rápida: o produto encaixou exatamente na rotina que já existia, dentro do ambiente de programação que a pessoa já usava, sem exigir que ela mudasse de ferramenta ou de vocabulário.
O próprio dado de confiança da pesquisa da Stack Overflow confirma esse encaixe, ainda que de forma indireta. Apenas 29% dos desenvolvedores confiam plenamente na precisão do que a IA produz — uma queda forte frente ao ano anterior — e 66% relatam gastar mais tempo revisando código gerado por IA do que esperavam. Isso não é o fracasso da ferramenta: é o profissional aplicando exatamente o ceticismo técnico que o cargo dele exige. Setenta e cinco por cento disseram que, na dúvida, preferem buscar ajuda de outra pessoa a confiar na resposta da IA.
Por que a mesma ferramenta tropeça fora do código
Esse ceticismo treinado é a primeira peça que falta quando a ferramenta sai do time técnico. Uma pessoa do financeiro que recebe uma resposta sobre uma cláusula contratual não tem o mesmo instinto de desconfiar de um número que "parece certo, mas não está certo" — porque ela nunca precisou treinar esse instinto. O problema não é essa pessoa ser menos capaz. É que a ferramenta foi desenhada supondo um tipo de revisão que só quem programa pratica todos os dias.
A segunda peça que falta é estrutural, e explica por que isso é uma questão de arquitetura, não de personalidade dos times. Essas ferramentas costumam pedir uma conta pessoal, criada por quem instalou o programa na própria máquina — muitas vezes com uma credencial própria, comprada com cartão corporativo ou pessoal, fora do controle de identidade da empresa. Quando essa pessoa muda de time ou sai da empresa, o acesso não é revogado automaticamente junto com o resto dos sistemas: alguém precisa lembrar de cancelar aquela conta específica.
A terceira peça é a ausência de papel e de aprovação. A ferramenta não sabe, nem precisa saber, se quem está do outro lado é estagiário ou diretor financeiro — porque foi construída para um cenário em que isso não importa: o código passa por revisão de outro programador e por um processo de aprovação de código antes de ir para produção. Fora do código, não existe esse segundo colega revisando por padrão. E não existe registro central que a área de TI ou de compliance possa consultar depois, porque a conversa aconteceu numa ferramenta que a empresa nem sabia que estava em uso.
Nada disso é defeito do produto. É o produto certo, desenhado para o público certo, chegando a um público diferente daquele para o qual foi pensado.
O que precisa existir na prática
Levar IA para a empresa inteira — não só para quem programa — exige um desenho diferente, verificável em cinco pontos.
Identidade corporativa, não conta pessoal criada na hora. O acesso vem do mesmo diretório que já controla e-mail e sistemas internos, então desligamento e mudança de função atualizam o acesso à IA junto, sem depender de alguém lembrar de uma conta avulsa.
Acesso conforme o papel de cada pessoa. O financeiro enxerga o que o financeiro precisa; o comercial, o que o comercial precisa — sem exigir que ninguém entenda o conceito de permissão de programador para trabalhar com segurança.
Aprovação antes de uma ação sensível. Quando o pedido envolve algo que pode gerar impacto — enviar uma mensagem, alterar um cadastro, aprovar um valor — o fluxo para e pede confirmação de uma pessoa, dentro da própria conversa, em vez de assumir que quem está ali sabe revisar como um programador revisaria.
Conhecimento aprovado da própria empresa. As respostas partem de documentos, políticas e processos com dono e versão vigente — não do conhecimento geral da internet que qualquer assistente traz de fábrica.
Trilha de auditoria central. Quem pediu o quê, quando e com qual resultado fica registrado num único lugar que a área de TI consegue consultar — não espalhado em contas pessoais que a empresa nem sabe que existem.
É assim que a Skyller foi desenhada: identidade vinda do diretório da empresa, permissão por papel, aprovação e registro como padrão para qualquer área — não só para quem já sabe programar.
Onde cada ferramenta faz sentido
Isso não torna as ferramentas agênticas de programador piores no que fazem. Um assistente afinado para ler um repositório inteiro, sugerir uma refatoração ou gerar um teste continua sendo, para quem programa, a ferramenta certa — e continuará sendo enquanto existir código para escrever. O erro é de encaixe: pegar uma ferramenta desenhada e testada para esse público específico e oferecê-la, sem adaptação nenhuma, para o restante da empresa, esperando que a mesma curva de adoção e o mesmo julgamento técnico apareçam sozinhos em quem nunca precisou deles.
Uma plataforma pensada para a empresa inteira resolve o problema pelo outro lado: já chega com identidade, papel, aprovação e auditoria embutidos, e com agentes prontos por área — a Skyller, por exemplo, já vem com mais de 100 agentes pré-configurados para rotinas de financeiro, RH, comercial e outras áreas — em vez de pedir que cada departamento reinvente, sem apoio, o que o time técnico levou anos para aprender a fazer com segurança.
Perguntas para levar à próxima reunião de TI
Antes de expandir para o resto da empresa uma ferramenta que hoje só o time técnico usa, valem estas perguntas:
- Quem fora do time técnico já usa IA por conta própria, com conta pessoal e sem o conhecimento da empresa? Se a resposta for "não sabemos", o primeiro passo é descobrir — não proibir.
- Se essa pessoa sair da empresa amanhã, o acesso dela a essas ferramentas cai junto com o resto? Se a resposta depender de alguém lembrar de cancelar uma conta avulsa, o problema é de identidade, não de ferramenta.
- Existe um lugar central onde a área de TI consegue ver o que foi pedido e com que resultado? Se a resposta for "não", a empresa está exposta a um risco que não consegue nem medir.
- A ferramenta que o time técnico ama é a mesma que deveria chegar ao financeiro, ao RH e ao comercial? Quase sempre a resposta é não — e está tudo bem. São problemas diferentes, e cada um merece a ferramenta certa.
