O programador performático na era da IA e o custo para a sua organização

Quando a demonstração de produtividade se distancia do trabalho necessário para entregar uma solução confiável

Imagine a cena. A pessoa compartilha a tela, mostra um sistema bonito e anuncia que construiu tudo em poucas horas. Tem painel, gráfico, animação, integração com IA e uma apresentação que parece ter saído de uma startup prestes a receber investimento.

A reunião se anima. Alguém já começa a calcular quantas pessoas poderiam ser substituídas por aquela eficiência toda.

Aí aparece uma pergunta: quem pode acessar os dados de quem?

Silêncio. A demonstração estava pronta para mostrar o que acontece quando tudo dá certo. Essa parte ainda não tinha entrado no roteiro.

Essa cena imaginária ajuda a trazer para dentro das organizações uma provocação que o Mano Deyvin fez sobre o “programador performático”. O nome dele é Deyvid Nascimento, desenvolvedor que se apresenta como o responsável pelo @manodeyvin e trabalha com Rails. [1]

Mano Deyvin… ou seria primo Deyvin? Também sou Nascimento e minha família é gigantesca. Vai saber se essa investigação não termina num churrasco em família, hehe.

Nas redes, ele brincou com os sinais de identidade do programador e também com o “vibe coder performático”, incluindo a exibição de equipamentos, ferramentas e consumo de IA. A discussão virou pauta do seu Mano Rage Show. [2][3]

Quero aproveitar essa provocação para discutir o que acontece quando uma organização passa a comprar a aparência de competência como se já tivesse recebido uma entrega confiável.

Minha tese é que a IA pode reduzir o esforço necessário para produzir os sinais visíveis de produtividade. Com isso, fica ainda mais importante verificar o trabalho que esses sinais representam.

Quando o trabalho começa a virar personagem

Uso “performático”, aqui, no sentido de encenação profissional. É o comportamento de sustentar uma imagem de domínio, velocidade ou importância que as evidências da entrega não acompanham.

Isso pode aparecer numa promessa exagerada, numa demonstração que omite limitações ou numa tarefa declarada concluída enquanto outras pessoas ainda precisam descobrir como fazê-la funcionar.

O teclado, o editor de código e a foto do LinkedIn não permitem esse diagnóstico. Produzir conteúdo, explicar decisões e apresentar bem um projeto são atividades legítimas. Uma pessoa pode fazer tudo isso e entregar um trabalho excelente.

Também vale proteger o trabalho que aparece pouco. Investigar um defeito, orientar um colega, simplificar uma solução e impedir uma mudança perigosa podem consumir horas sem produzir uma tela nova para a próxima reunião.

O critério precisa ser a correspondência entre o que foi prometido, o que foi demonstrado e o que a organização efetivamente recebeu.

Um iniciante que explica seus limites e pede revisão oferece condições para o time administrar o risco. Um profissional experiente que esconde as próprias incertezas pode fazer o contrário. Tempo de carreira e quantidade de seguidores não encerram essa conversa.

A IA também ajuda a produzir a apresentação

É fácil perceber o apelo da IA para quem quer construir. Você consegue explorar uma ideia, pedir alternativas, gerar uma primeira implementação e iterar sobre ela. Isso abre espaço para aprender e experimentar.

Mas a mesma facilidade pode dar acabamento profissional a algo que ainda não foi compreendido.

Imagine um projeto com código, documentação, explicação arquitetural e testes produzidos na mesma sequência de pedidos. Cada peça parece confirmar a anterior. O conjunto fica convincente, embora ainda possa compartilhar uma premissa errada sobre o problema.

Se o responsável conhece os limites, verifica as decisões e corrige as falhas, esse material pode ser muito útil. Se aceita tudo porque “a IA explicou direitinho”, a organização ganha uma narrativa de segurança antes de ter evidências suficientes dela.

A situação fica especialmente delicada quando uma demonstração vira compromisso comercial. O cliente entende que comprou um sistema pronto; quem apresentou ainda estava validando uma hipótese.

Um protótipo pode ser uma ótima entrega, desde que esteja apresentado como protótipo. A confusão começa quando essa diferença desaparece da conversa, do prazo e do preço.

A produtividade que sentimos e a que conseguimos medir

Existe pesquisa mostrando como a nossa percepção pode falhar nessa avaliação.

Em julho de 2025, a METR publicou um experimento com 16 desenvolvedores experientes e 246 tarefas em projetos que eles conheciam. Com as ferramentas de IA testadas, as tarefas consumiram 19% mais tempo. Mesmo depois da experiência, os participantes estimavam um ganho de velocidade de cerca de 20%. O estudo retrata aquele contexto e ferramentas do início de 2025. [4]

A atualização de fevereiro de 2026 trouxe indícios de melhora, mas a própria METR explicou que a seleção de participantes e tarefas, entre outros problemas de medição, impedia estimar o efeito atual com confiança. Usar os 19% como sentença sobre toda programação com IA em 2026 seria extrapolar o resultado. [5]

Em maio de 2026, outro levantamento da METR reuniu 349 trabalhadores técnicos e encontrou ganhos relatados pelos próprios participantes. Os pesquisadores distinguiram percepção de velocidade e de valor produzido, além de apontar limitações da amostra e das estimativas pessoais. Esse tipo de pesquisa ajuda a entender a experiência das pessoas, mas não comprova o ganho por medição direta. [6]

Há evidência positiva importante. Três experimentos empresariais, reunindo 4.867 desenvolvedores, estimaram um aumento de aproximadamente 26% nas tarefas concluídas como efeito da adoção do GitHub Copilot. A medida se apoiava principalmente em solicitações de alteração de código concluídas, os pull requests. O artigo saiu na Management Science em fevereiro de 2026; seus resultados variaram entre empresas. Esse indicador não equivale automaticamente a lucro ou qualidade duradoura. [7][8]

Esses trabalhos estudam condições diferentes. E nenhum deles identifica uma categoria de “programadores performáticos” nem calcula quanto ela custa.

O que eles ajudam a sustentar é uma exigência mais razoável: precisamos observar o resultado, além da sensação de velocidade.

Alguém pode acreditar sinceramente que está produzindo muito mais. Pode até estar. A responsabilidade da gestão é criar condições para verificar isso sem depender exclusivamente do entusiasmo de quem apresenta ou da desconfiança de quem assiste.

O custo que muda de mesa

Uma forma de parecer extremamente produtivo é encerrar a própria parte da tarefa antes que todo o trabalho necessário tenha sido contabilizado.

Imagine alguém que entrega uma alteração enorme, comemora o prazo e segue para a próxima. Outro profissional precisa entender o que mudou, conferir se o comportamento faz sentido, pedir correções e descobrir como a novidade conversa com o restante do sistema.

Revisar faz parte do desenvolvimento. O problema aparece quando a entrega foi anunciada como concluída e esse esforço restante ficou invisível na conta de quem recebeu o crédito.

O trabalho pode continuar migrando: do desenvolvimento para a revisão, da revisão para o suporte, do suporte para quem precisa explicar o problema ao cliente.

Depois vem a manutenção. Uma decisão que ninguém consegue justificar, uma dependência desnecessária ou uma integração sem tratamento de falhas pode tornar as próximas alterações mais trabalhosas. A conta acompanha o sistema por muito mais tempo que a empolgação do lançamento.

Na apresentação, uma pessoa parece ter economizado dois dias. Na operação, várias pessoas podem ter consumido três para completar o que faltava. Essa hipótese precisa ser medida no projeto, mas já mostra por que avaliar apenas a velocidade de implementação é insuficiente.

Também há o custo de oportunidade. Enquanto um profissional experiente reconstrói decisões que deveriam estar claras, outra melhoria espera. Convém medir esse atraso com cuidado, para não contar a mesma perda duas vezes ao somar horas e oportunidades adiadas.

A pergunta útil passa a ser: quanto esforço a equipe inteira precisou investir até que essa entrega pudesse ser usada com confiança?

A tela bonita e o administrador por senha mágica

Já encontrei uma situação em que a condição para alguém ser administrador se resumia a verificar se a senha era admin123.

Era essa a lógica usada para definir o acesso administrativo. Uma regra desse tipo pode parecer funcionar numa demonstração: alguém digita a senha e o painel abre. Só que o sucesso da demonstração não torna o controle de acesso adequado.

O caso, sozinho, não permite concluir que uma IA escreveu o código nem que seu autor tentou enganar alguém. Ele ilustra como é possível demonstrar uma funcionalidade sem resolver corretamente a responsabilidade que ela carrega.

As orientações da OWASP para autorização incluem conceder apenas os privilégios necessários, negar acessos por padrão e verificar permissões em cada requisição. A validação precisa ocorrer num componente confiável do sistema; esconder um botão no navegador não basta. [9]

Para uma organização, a consequência possível de um controle inadequado vai além de “tem um bug”. Pode envolver acesso indevido, alteração de registros, interrupção de atividades e trabalho para investigar e corrigir a exposição. A extensão depende dos dados, das permissões e do que efetivamente ocorreu.

Em sistemas que apoiam atendimento ao cidadão, comércio ou rotinas administrativas, a falha também pode chegar a pessoas que nunca participaram daquela reunião animada.

É por isso que uma pergunta aparentemente chata sobre permissões merece espaço antes dos aplausos.

Até o teste precisa demonstrar o que está testando

Outro risco é tratar uma tela cheia de testes aprovados como prova suficiente de que tudo está correto.

Um teste pode verificar exatamente o comportamento implementado e, ainda assim, deixar de verificar a regra que o usuário precisava. Se o sistema deveria impedir uma operação, mas o teste foi escrito para confirmar que ela acontece, o sinal verde ajuda pouco.

A OWASP alerta para agentes que enfraquecem verificações ou removem testes que falham. Também recomenda responsabilidade humana pelas mudanças geradas com IA. O resultado da ferramenta precisa ser revisado, inclusive quando ela produz a própria validação. [10]

Isso exige perguntas concretas. Qual requisito o teste comprova? Que falha ele detectaria? Existe algum cenário importante que ficou de fora?

A IA pode ajudar a encontrar esses cenários. O cuidado é manter uma referência independente para o que significa “correto”: a necessidade do usuário, as regras do negócio e as restrições do sistema.

O mesmo vale para documentação. Um texto elegante sobre a arquitetura ganha valor quando corresponde ao sistema que outra pessoa vai precisar operar e modificar.

Uma simulação para colocar essa conversa em reais

Vamos usar um exemplo inteiramente hipotético, com o mesmo escopo e o mesmo padrão de aceitação. Para simplificar, cada hora de trabalho custa R$ 100, independentemente da função.

As duas entregas podem usar IA. A comparação abaixo representa uma entrega de referência e outra que foi anunciada cedo demais como concluída.

Trabalho necessário	Entrega de referência	Entrega anunciada cedo demais
Implementação	12 h	4 h
Revisão	3 h	6 h
Correções	2 h	10 h
Suporte inicial	1 h	4 h
Total de trabalho	18 h	24 h
Custo das horas	R$ 1.800	R$ 2.400

Se alguém mostrar apenas a implementação, a segunda entrega parece ter economizado R$ 800. Quando o trabalho restante entra na conta, ela termina R$ 600 mais cara.

Esses valores não são uma estimativa de mercado. São uma forma de mostrar a conta que cada organização deveria fazer com seus próprios dados. Uma utilização competente da IA também pode reduzir revisão, correções e suporte, melhorando o resultado completo.

O custo real ainda pode incluir ferramentas, infraestrutura e consequências de incidentes. Cada parcela precisa ser apurada sem misturar custos já incorridos com riscos que talvez nunca se materializem.

O ponto é acompanhar a entrega até o estágio em que a economia anunciada possa ser confirmada.

Há uma gestão por trás do espetáculo

Seria cômodo colocar toda a responsabilidade no profissional que exagera na apresentação. Só que alguém escolheu quais sinais seriam premiados.

Se a empresa valoriza a quantidade de código, as pessoas têm incentivo para produzir mais código. Se premia demonstrações constantes, o que aparece na tela ganha vantagem sobre o trabalho de manutenção que sustenta aquilo.

Com IA, dá para acrescentar outros indicadores vistosos: quantidade de agentes, volume de tokens e percentual de código gerado automaticamente. Essas informações podem ajudar a administrar ferramentas. Isoladamente, dizem pouco sobre o benefício entregue ao usuário. O print da fatura comprova o consumo. O progresso ainda precisa ser demonstrado.

O framework SPACE, publicado por pesquisadores da Microsoft, do GitHub e da Universidade de Victoria, trata produtividade como algo multidimensional. Sua proposta inclui satisfação e bem-estar, desempenho, atividade, comunicação e colaboração, além de eficiência e fluxo. Reduzir tudo a uma única contagem perde parte relevante do trabalho. [11]

O DORA 2025 oferece outra contribuição: apresenta a IA como amplificadora das condições existentes na organização. A retrospectiva oficial aponta melhora no volume de entregas, acompanhada de risco para a estabilidade quando a base é frágil. É pesquisa organizacional, não uma garantia causal para qualquer equipe. [12][13]

A partir disso, minha leitura é que acelerar a geração de mudanças sem cuidar da capacidade de avaliá-las pode apenas deslocar o gargalo. A empresa precisa observar o fluxo inteiro.

Às vezes, o programador só aprendeu a entregar exatamente o espetáculo que a gestão resolveu comprar.

O que vale perguntar antes de aprovar uma entrega

Uma organização não precisa transformar cada mudança numa defesa de doutorado. Precisa fazer perguntas proporcionais ao risco e aceitar respostas verificáveis.

Eu começaria por estas:

1. Que problema ficou resolvido para quem usa? Uma funcionalidade disponível ainda precisa demonstrar utilidade. Vale observar uma tarefa real: ficou mais rápida, mais clara ou menos sujeita a erro?
2. O que está pronto e o que continua sendo hipótese? Protótipo, piloto e operação com usuários reais exigem compromissos diferentes. Essa distinção deve estar clara para quem contrata e para quem vai manter.
3. Como foram verificados acessos, dados e falhas importantes? A profundidade muda conforme o sistema. Um formulário informativo e uma rotina que altera pagamentos pedem cuidados diferentes.
4. Que trabalho ainda ficou para outras pessoas? Revisão, integração, documentação e suporte precisam aparecer no planejamento e na avaliação do resultado.
5. Outra pessoa consegue continuar a partir daqui? O responsável precisa conseguir mostrar decisões, dependências e limitações. A explicação pode ser escrita ou demonstrada; não precisa virar competição de eloquência numa reunião.
6. Como vamos perceber e corrigir um problema depois da entrega? Dependendo do risco, isso envolve registros, acompanhamento, reversão de mudanças e recuperação da operação.

Essas perguntas também ajudam a contratar. Em vez de premiar apenas a apresentação mais impressionante, dá para observar como a pessoa lida com uma limitação, explica uma escolha e incorpora uma revisão.

Para acompanhar o trabalho, eu combinaria o tempo até uma mudança chegar ao usuário com retrabalho, falhas relevantes, esforço de manutenção e resultado do serviço. Compararia períodos e entregas semelhantes, considerando complexidade e maturidade do sistema.

Transformar esses dados numa classificação automática de funcionários recriaria o problema. O uso mais útil é descobrir onde o processo está funcionando e onde o custo está sendo escondido.

A oportunidade continua enorme

Há muito espaço para construir melhor com IA. Ela pode ajudar quem está começando, ampliar a capacidade de profissionais experientes e tornar viáveis experimentos que antes consumiriam recursos demais.

Para aproveitar isso, uma organização precisa permitir aprendizado e admitir incerteza. Se toda dúvida for tratada como incompetência, a empresa incentiva justamente a confiança teatral que depois vai reclamar de receber.

Quero trabalhar com pessoas que consigam dizer “esta parte está validada, esta outra precisa de revisão”. Essa clareza permite decidir prazos, riscos e prioridades de forma mais responsável.

É perfeitamente possível usar várias IAs, apresentar bem um projeto e entregar valor. Também é possível fazer isso com uma estrutura discreta e poucas ferramentas. A comprovação está no resultado que a organização consegue usar, manter e entender.

Ao primo Deyvin, fica o crédito pela provocação. O parentesco a gente investiga depois.

Para quem contrata tecnologia, eu deixaria uma pergunta na próxima apresentação: quanto trabalho ainda falta depois dessa demonstração, e quem vai assumir essa conta?

Fontes

[1] Deyvid Nascimento. Site pessoal. Identificação e apresentação profissional.

[2] Mano Deyvin. Post sobre o vibe coder performático. Publicação no perfil do autor.

[3] Mano Deyvin. Post anunciando a pauta no episódio 262. Episódio Programadores Performáticos do Mano Rage Show.

[4] METR. Measuring the Impact of Early 2025 AI on Experienced Open Source Developer Productivity. 10 de julho de 2025.

[5] METR. We are Changing our Developer Productivity Experiment Design. 24 de fevereiro de 2026.

[6] METR. Measuring the Self Reported Impact of Early 2026 AI on Technical Worker Productivity. 11 de maio de 2026.

[7] Cui, Demirer, Jaffe, Musolff, Peng e Salz. The Effects of Generative AI on High Skilled Work. Management Science. Publicação online em 27 de fevereiro de 2026.

[8] Cui e colaboradores. Versão integral disponibilizada pelo MIT. Fevereiro de 2025. Detalhamento das medidas de produtividade.

[9] OWASP. Authorization Cheat Sheet.

[10] OWASP. Secure Coding with AI Cheat Sheet.

[11] Forsgren e colaboradores. The SPACE of Developer Productivity. ACM Queue, 2021.

[12] DORA. State of AI Assisted Software Development 2025.

[13] DORA. DORA 2025 Year in Review. 7 de janeiro de 2026.