O anúncio do Barclays não prova que a inteligência artificial, sozinha, causou 5.000 demissões. Ele mostra algo mais importante para quem programa: IA, reorganização operacional e redução de custos estão sendo tratadas como partes do mesmo plano. Segundo o Abril.com.br, cerca de 60% dos postos eliminados serão em áreas de apoio, incluindo desenvolvimento de sistemas; mil vagas já tinham sido cortadas no primeiro semestre, e as demais estavam previstas até dezembro.
Essa distinção importa. Quando uma empresa diz que a IA aumenta a produtividade, isso não significa automaticamente que cada desenvolvedor passou a produzir mais código útil. Significa que a organização está tentando mudar o custo, o ritmo ou a composição do trabalho. Para entender o que pode acontecer com equipes de tecnologia, é preciso olhar além da ferramenta e examinar processos, métricas e decisões de gestão.
O que o plano do Barclays informa — e o que não informa
A redução anunciada equivale a aproximadamente 5% da força de trabalho do banco. A instituição relacionou parte da economia ao aumento de produtividade com IA, mas os cortes fazem parte de uma reestruturação mais ampla, com mudanças operacionais e investimentos em tecnologia. O banco também informou gastos de 307 milhões de libras com a reestruturação nos primeiros nove meses do ano e projetou outros 300 milhões até dezembro.
Isso não permite concluir quantas vagas foram eliminadas especificamente por uma ferramenta de IA, quais funções foram automatizadas ou quanto a produtividade aumentou. A notícia não apresenta esses dados. A leitura responsável é que o banco está combinando tecnologia e reorganização para reduzir custos — uma estratégia diferente de simplesmente substituir cada pessoa por um modelo.
Na minha análise, esse é o ponto que profissionais de software precisam acompanhar. A automação pode reduzir tarefas repetitivas, mas a decisão de converter esse ganho em menos horas, novos produtos, redução de equipe ou maior volume de trabalho é uma escolha da empresa. A tecnologia viabiliza possibilidades; não determina sozinha como o benefício será distribuído.
Como a inteligência artificial muda o trabalho de desenvolvimento
Em uma equipe de engenharia, IA pode ajudar a gerar testes, explicar trechos desconhecidos, sugerir consultas SQL, criar documentação inicial e acelerar tarefas de manutenção. Essas aplicações economizam tempo quando o contexto está bem definido e alguém consegue validar o resultado. Elas não eliminam a responsabilidade de entender o sistema nem de responder por uma falha em produção.
O trabalho de desenvolvimento também inclui decisões que são difíceis de reduzir a uma sugestão de código: compreender regras de negócio, escolher limites entre serviços, avaliar riscos de segurança, negociar requisitos e diagnosticar incidentes com informação incompleta. Um modelo pode apoiar essas atividades, mas o valor depende de dados confiáveis, integração com o fluxo de trabalho e revisão humana competente.
Há ainda uma diferença entre automatizar tarefas e automatizar cargos. Um assistente pode diminuir o tempo gasto escrevendo testes, sem retirar a necessidade de alguém decidir quais cenários importam. Para transformar esse ganho em uma redução de equipe, a empresa precisa redesenhar responsabilidades, aceitar um nível diferente de risco ou simplesmente optar por capturar a economia no orçamento.
IA generativa não é a única alternativa para aumentar produtividade
Antes de atribuir qualquer ganho à IA, vale comparar a solução com outras formas de melhorar operações. Um pipeline de CI/CD mais rápido pode economizar tempo de toda a equipe. Uma arquitetura menos acoplada pode reduzir o custo de mudanças. Testes automatizados bem escolhidos podem evitar regressões. Em alguns processos, automação tradicional ou RPA é mais previsível e barata do que um modelo generativo.
| Abordagem | Funciona melhor quando | Risco principal |
|---|---|---|
| IA generativa | Há tarefas com linguagem, padrões repetidos e revisão possível | Resposta plausível, mas incorreta ou insegura |
| Automação determinística | As regras são estáveis e os casos podem ser especificados | Exceções não previstas quebram o fluxo |
| Melhoria de processo | O gargalo vem de esperas, aprovações ou retrabalho | Automatizar uma etapa sem corrigir o fluxo completo |
| Rearquitetura | Acoplamento e dívida técnica tornam cada mudança lenta | Custo inicial alto e retorno mais demorado |
Uma ferramenta de IA não resolve um processo mal desenhado. Se um pull request espera dias por aprovação, gerar o código alguns minutos mais rápido pode ter pouco efeito no tempo total de entrega. Se o sistema não tem testes, a geração de código pode aumentar a velocidade de produção de defeitos. O gargalo deve ser medido antes de se escolher a solução.
Na Prática: como medir se uma ferramenta de IA gera valor
Eu começaria com um piloto pequeno, limitado a uma tarefa e com uma linha de base. Não compararia apenas a quantidade de linhas produzidas ou o número de sugestões aceitas. Esses números são fáceis de inflar e não demonstram que o software ficou melhor ou que a equipe entregou valor mais rápido.
- Escolha uma tarefa delimitada. Por exemplo, criar testes unitários para módulos existentes ou resumir documentação técnica. Evite começar com uma promessa ampla como “automatizar o desenvolvimento”.
- Registre o processo atual. Meça tempo gasto, retrabalho, defeitos encontrados depois da revisão e tempo de espera. Use algumas semanas de dados, se possível, para não tomar uma semana atípica como padrão.
- Inclua o custo de revisão. Se a IA gera uma solução em dez minutos, mas um desenvolvedor leva quarenta minutos para entender e corrigir a saída, a economia aparente desaparece.
- Compare com um grupo ou período semelhante. Separe o efeito da ferramenta de mudanças no tamanho da tarefa, experiência da equipe, sazonalidade e alterações no processo de aprovação.
- Defina limites de segurança. Não envie segredos, dados pessoais ou código restrito a serviços sem autorização. Determine também quem aprova código, dependências e alterações de infraestrutura.
- Decida com base em qualidade e custo total. Inclua licenças, consumo de API, manutenção, incidentes, revisão e treinamento. Pare ou ajuste o piloto se a qualidade cair ou o custo superar o benefício.
Para fazer uma estimativa inicial, este script Python calcula o benefício mensal aproximado a partir do tempo economizado, do tempo adicional de revisão e do custo da ferramenta. Ele não prevê demissões nem prova causalidade: serve para tornar explícitas algumas premissas antes de escalar um piloto.
def estimar_retorno(
tarefas_mes: int,
minutos_economizados_por_tarefa: float,
minutos_revisao_por_tarefa: float,
custo_hora_completo: float,
custo_ferramenta_mes: float,
) -> dict:
valores = {
"tarefas_mes": tarefas_mes,
"minutos_economizados_por_tarefa": minutos_economizados_por_tarefa,
"minutos_revisao_por_tarefa": minutos_revisao_por_tarefa,
"custo_hora_completo": custo_hora_completo,
"custo_ferramenta_mes": custo_ferramenta_mes,
}
if any(valor < 0 for valor in valores.values()):
raise ValueError("Os valores não podem ser negativos.")
horas_liquidas = (
tarefas_mes
* (minutos_economizados_por_tarefa - minutos_revisao_por_tarefa)
/ 60
)
beneficio_estimado = horas_liquidas * custo_hora_completo
saldo = beneficio_estimado - custo_ferramenta_mes
roi = None
if custo_ferramenta_mes > 0:
roi = saldo / custo_ferramenta_mes
return {
"horas_liquidas": horas_liquidas,
"beneficio_estimado": beneficio_estimado,
"saldo_apos_ferramenta": saldo,
"roi_sobre_custo_da_ferramenta": roi,
}
if __name__ == "__main__":
resultado = estimar_retorno(
tarefas_mes=400,
minutos_economizados_por_tarefa=12,
minutos_revisao_por_tarefa=5,
custo_hora_completo=120,
custo_ferramenta_mes=2500,
)
for nome, valor in resultado.items():
print(f"{nome}: {valor}")
O cálculo considera apenas o tempo líquido estimado e o custo mensal da ferramenta. O custo por hora deve refletir o custo completo usado pela empresa, não apenas salário. Também é importante evitar uma interpretação enganosa: horas “economizadas” não são necessariamente horas disponíveis para reduzir equipe. Elas podem ser consumidas por revisão, incidentes, tarefas que antes não cabiam no planejamento ou pela melhoria de qualidade.
Implicações para desenvolvedores e equipes de software
Para quem programa, a consequência prática não é tentar competir com uma IA na velocidade de digitação. É fortalecer as habilidades que permitem orientar, avaliar e integrar ferramentas: testes, observabilidade, segurança, arquitetura, revisão de código e entendimento do domínio. Quem sabe detectar uma resposta errada ou uma mudança perigosa agrega valor que a geração automática, sozinha, não entrega.
Também vale aprender a trabalhar com contexto. Uma instrução genérica tende a produzir respostas genéricas. Um pedido útil delimita o objetivo, as restrições, os arquivos relevantes, o comportamento esperado e como validar o resultado. Ainda assim, contexto bem escrito não substitui testes nem revisão independente.
Para gestores técnicos, a lição é não usar “produtividade de IA” como um número sem definição. Medir sugestões aceitas pode incentivar código desnecessário. Medir linhas produzidas pode premiar verbosidade. Indicadores mais úteis combinam tempo de ciclo, frequência de falhas, retrabalho, estabilidade e satisfação de quem usa o software, sempre considerando o tipo de produto e o perfil da equipe.
Erros comuns ao avaliar IA e cortes de vagas
- Afirmar que a IA causou todos os cortes. No caso divulgado, a tecnologia aparece dentro de uma reestruturação mais ampla. A notícia não quantifica a parcela atribuível à IA.
- Confundir atividade com resultado. Mais código ou mais tickets fechados não significam, por si só, um produto melhor ou uma entrega mais rápida ao usuário.
- Ignorar revisão e manutenção. Código gerado continua tendo custo. Se ninguém entende o que foi aceito, a dívida técnica pode crescer mais rápido que a produtividade.
- Usar IA sem política de dados. Copiar credenciais, dados de clientes ou código confidencial para ferramentas não aprovadas cria riscos que podem superar qualquer economia.
- Automatizar antes de entender o gargalo. Se o atraso está em aprovações, dependências entre equipes ou ambientes instáveis, um copiloto de código pode não mudar o resultado.
- Tratar estimativas como previsões de emprego. Uma conta de ROI ajuda a discutir custos; não determina quantas vagas serão eliminadas nem como a empresa usará o ganho.
Perguntas frequentes sobre IA e empregos em tecnologia
O Barclays confirmou que a IA causará 5.000 demissões?
O banco planeja cortar cerca de 5.000 empregos e relaciona parte da redução de custos à produtividade com IA. Mas, segundo as informações publicadas pelo Abril.com.br, os cortes fazem parte de uma reorganização mais ampla. Não há uma divisão que atribua cada vaga eliminada diretamente à IA.
Desenvolvedores estão entre as áreas afetadas?
A matéria informa que aproximadamente 60% dos postos eliminados serão em áreas de apoio, incluindo desenvolvimento de sistemas. Ela não detalha funções específicas, senioridade, equipes ou a distribuição completa das vagas.
A IA generativa vai substituir programadores?
Ela pode automatizar ou acelerar partes do trabalho, mas isso não equivale a substituir integralmente a função de desenvolvimento. O resultado depende da complexidade do sistema, dos requisitos de segurança, da qualidade da revisão e das decisões da empresa sobre como usar os ganhos de produtividade.
Como um desenvolvedor pode se preparar?
Aprenda a usar ferramentas de IA com validação, mas invista também em fundamentos: testes, depuração, segurança, arquitetura e conhecimento de domínio. Saber verificar uma sugestão e responder pelo código em produção é tão importante quanto gerar um primeiro rascunho rapidamente.
Conclusão: produtividade precisa ser demonstrada, não presumida
O caso do Barclays mostra como a adoção de tecnologia pode aparecer junto a cortes e reorganizações, mas não permite reduzir toda a decisão a “a IA substituiu 5.000 pessoas”. Para avaliar o impacto real, precisamos de métricas transparentes, comparação com alternativas e atenção ao custo de revisão, à qualidade e aos riscos operacionais.
Como desenvolvedor, eu trataria a IA como uma ferramenta capaz de mudar o fluxo de trabalho — não como justificativa automática para promessas de produtividade. A pergunta útil é: qual tarefa melhorou, quanto melhorou, com que custo e sem comprometer segurança ou manutenção?
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.