Capa

IA e empregos: como o alerta do FMI afeta desenvolvedores

O dado mais importante do alerta do FMI não é que 40% dos empregos vão desaparecer: é que uma parcela grande do trabalho será reorganizada, e os jovens podem perder justamente as tarefas que hoje servem de porta de entrada para uma carreira. Para quem programa, a pergunta útil não é “a IA vai substituir desenvolvedores?”, mas “quais partes do meu trabalho estão ficando automatizáveis — e como isso muda a forma de aprender e construir experiência?”.

Segundo o Sapo.pt, a diretora-geral do FMI, Kristalina Georgieva, estima que cerca de 40% dos empregos no mundo serão reforçados, desvalorizados ou eliminados pela inteligência artificial. Nas economias avançadas, a parcela afetada pode chegar a 60%; nos países de baixo rendimento, a 23%. “Afetado” não significa necessariamente “extinto”: pode significar que algumas tarefas passam a ser feitas com IA, enquanto outras ganham importância.

O que o alerta do FMI significa para quem trabalha com tecnologia

Georgieva descreveu a transformação como um “tsunami lento”. A imagem é útil porque evita duas leituras erradas: imaginar uma substituição instantânea de profissões ou concluir que, por ser gradual, a mudança não exige preparação. A tecnologia pode avançar em ritmos diferentes entre setores, empresas e países, mas os efeitos acumulados alteram contratações, produtividade e expectativas sobre o que cada profissional deve entregar.

Também é importante separar exposição à IA de perda de emprego. Uma ocupação pode incluir tarefas automatizáveis sem que a ocupação inteira desapareça. Um desenvolvedor, por exemplo, pode delegar a geração de testes simples a uma ferramenta, mas ainda precisar entender requisitos, escolher a arquitetura, revisar segurança e assumir a responsabilidade pelo sistema em produção.

O FMI também observou que o primeiro efeito económico visível veio de procura e investimento: centros de dados, modelos de IA e cadeias de abastecimento relacionadas. Isso ajuda a explicar por que a tecnologia pode criar procura em algumas áreas ao mesmo tempo que reduz a necessidade de certas tarefas noutras. O impacto não é uniforme nem se resume a “mais empregos” ou “menos empregos”.

Por que os jovens podem sentir a mudança primeiro

O risco para profissionais em início de carreira é menos óbvio do que a substituição de um cargo inteiro. Muitas vezes, o trabalho júnior inclui tarefas delimitadas: corrigir erros simples, escrever testes, atualizar documentação, converter dados e implementar mudanças pequenas. Ferramentas de IA podem acelerar ou assumir parte dessas atividades.

O problema aparece quando essas tarefas deixam de existir sem que as empresas criem novas formas de ensinar o trabalho. Um desenvolvedor experiente normalmente já construiu repertório resolvendo problemas menores. Se a equipa automatiza esse percurso e espera que o profissional júnior chegue pronto para tomar decisões complexas, cria-se uma contradição: menos oportunidades para aprender, mas exigências maiores na contratação.

Na minha leitura, isso muda a estratégia de entrada na área. Saber gerar código é útil, mas não prova que alguém sabe avaliar se o código está correto. Portfólio e entrevistas técnicas devem mostrar raciocínio, depuração, leitura de código existente, decisões de arquitetura e capacidade de explicar trade-offs — não apenas a velocidade para produzir uma solução.

O que a IA automatiza melhor — e o que continua a exigir julgamento

Modelos de linguagem costumam ser mais úteis quando a tarefa tem contexto suficiente, resultado verificável e baixo custo de revisão. Gerar um esqueleto de teste, explicar uma função ou transformar um formato de dados conhecido são bons exemplos. O ganho depende de a equipa conseguir validar o resultado sem gastar mais tempo a corrigir erros do que teria gasto a fazer o trabalho diretamente.

Já tarefas com requisitos ambíguos, dados incompletos ou consequências elevadas exigem mais supervisão. Uma resposta plausível não é o mesmo que uma resposta correta. Em código, isso significa verificar comportamento, permissões, desempenho, dependências e casos-limite. A IA não elimina a necessidade de engenharia; altera onde o esforço humano deve concentrar-se.

Tipo de tarefa Abordagem que eu avaliaria primeiro Por quê
Regras estáveis e entradas previsíveis Script ou automação determinística É reproduzível, testável e tende a ter custo menor.
Texto ou conteúdo variado, com revisão possível Modelo de IA com validação humana Lida com variação, mas pode produzir erros convincentes.
Decisão de alto impacto ou difícil de reverter Processo humano apoiado por ferramentas O custo de uma falha pode superar qualquer ganho de velocidade.

Essa comparação evita um erro comum: usar um modelo generativo para qualquer problema só porque está disponível. Se uma tarefa é uma transformação previsível, uma função normal ou uma consulta SQL pode ser mais barata, rápida e confiável. Se envolve linguagem ambígua, a IA pode ajudar — desde que exista uma forma realista de conferir a resposta.

Na Prática: como avaliar uma tarefa antes de automatizá-la

Eu começaria por decompor o fluxo de trabalho em tarefas, em vez de tentar classificar profissões inteiras. Para cada etapa, identificaria a repetição, a estabilidade das regras, a ambiguidade do contexto e o custo de uma falha. O exemplo abaixo produz uma triagem simples; não é uma previsão de emprego nem uma métrica do FMI.

def avaliar_tarefa(repetitiva, regras_estaveis, ambiguidade, custo_falha):
    """
    Valores entre 0 e 1.
    Resultado orientativo: não substitui avaliação humana.
    """
    facilidade_automacao = (
        0.35 * repetitiva
        + 0.35 * regras_estaveis
        + 0.15 * (1 - ambiguidade)
        + 0.15 * (1 - custo_falha)
    )

    if facilidade_automacao >= 0.75:
        recomendacao = "Testar automação com verificações"
    elif facilidade_automacao >= 0.45:
        recomendacao = "Usar IA como apoio e revisar cada resultado"
    else:
        recomendacao = "Manter decisão humana; automatizar só partes seguras"

    return round(facilidade_automacao, 2), recomendacao


tarefas = {
    "gerar teste de unidade": (0.8, 0.8, 0.3, 0.2),
    "aprovar acesso administrativo": (0.4, 0.5, 0.6, 0.95),
    "formatar dados CSV": (0.9, 0.95, 0.1, 0.15),
}

for nome, valores in tarefas.items():
    nota, recomendacao = avaliar_tarefa(*valores)
    print(f"{nome}: {nota} — {recomendacao}")

O valor do exercício não está no número produzido. Está na conversa que ele força: quais regras são realmente estáveis? Quem confere o resultado? O que acontece se a automação falhar? Na prática, eu adicionaria ainda volume, tempo de revisão, sensibilidade dos dados e facilidade de reverter uma ação. Automatizar a formatação de um ficheiro é diferente de aprovar permissões de produção.

  1. Registe a tarefa e o tempo atual. Inclua execução, revisão e correção de erros.
  2. Escolha uma ferramenta adequada. Compare script determinístico, automação tradicional e modelo de IA.
  3. Defina testes antes do piloto. Use exemplos normais, entradas inesperadas e casos de falha.
  4. Mantenha revisão humana proporcional ao risco. A supervisão deve ser maior quando o erro é caro ou difícil de reverter.
  5. Compare o fluxo completo. Meça tempo total e qualidade, não apenas a rapidez para gerar uma resposta.

Erros comuns ao adotar IA no desenvolvimento

Confundir código gerado com código pronto

Uma sugestão que compila ainda pode ter falhas de autorização, validação, concorrência ou tratamento de erros. Eu trataria código gerado como uma contribuição que precisa de revisão, testes e análise de dependências — tal como código escrito por outra pessoa. A ferramenta não assume a responsabilidade por uma vulnerabilidade em produção.

Medir produtividade pelo número de linhas

Mais linhas, commits ou tarefas fechadas não significam necessariamente mais valor. Uma boa automação pode reduzir código e trabalho manual; uma sugestão errada pode aumentar o volume de revisões e incidentes. Métricas mais úteis incluem tempo de ciclo, defeitos encontrados após a entrega, retrabalho e tempo gasto na revisão.

Enviar dados internos para serviços sem avaliar a política

Prompts podem conter tokens, dados pessoais, código proprietário ou detalhes de arquitetura. Antes de integrar uma ferramenta externa, confirme retenção, uso dos dados, controlos de acesso e regras da empresa. Redigir segredos do prompt é uma medida básica, não substitui uma avaliação de segurança e privacidade.

Automatizar antes de estabilizar o processo

Se a equipa não sabe qual é a regra correta, automatizar apenas torna a inconsistência mais rápida. Primeiro clarifique entradas, exceções e critérios de aceitação. Depois escolha a técnica. Cuidado também com processos em que ninguém sabe explicar como a ferramenta chegou ao resultado: isso complica auditoria, depuração e resposta a incidentes.

Como um programador pode se preparar sem perseguir cada ferramenta

Eu investiria em competências que continuam valiosas quando o código fica mais barato de produzir: decompor problemas, compreender sistemas existentes, fazer perguntas melhores, rever alterações e comunicar riscos. Fundamentos de redes, bases de dados, segurança, testes e observabilidade continuam a ser o que permite identificar quando uma solução aparentemente elegante não funciona no contexto real.

Também é útil aprender a trabalhar com IA de forma verificável. Em vez de pedir “faz a funcionalidade”, defina requisitos, contexto, limites e testes esperados. Peça uma proposta pequena, examine as alterações e execute a suíte de testes. Para um profissional júnior, explicar por que rejeitou uma sugestão incorreta pode demonstrar mais competência do que apresentar código gerado sem compreender as decisões.

O cenário que o alerta do FMI descreve não é um destino fechado. A tecnologia pode complementar trabalhadores, pressionar certas funções ou eliminar tarefas. O resultado dependerá de decisões de empresas, políticas de formação, acesso à tecnologia e capacidade de criar novas formas de entrada no mercado. Para quem desenvolve software, a melhor resposta não é competir com a velocidade de geração de código, mas melhorar a capacidade de orientar, validar e integrar sistemas.

Perguntas frequentes sobre IA e empregos em tecnologia

O FMI afirmou que 40% dos empregos vão desaparecer?

Não. Segundo o Sapo.pt, a estimativa refere-se a empregos que podem ser reforçados, desvalorizados ou eliminados pela IA. Ser afetado não é sinónimo de ser extinto; o efeito pode ocorrer em tarefas, competências exigidas e produtividade.

Por que os jovens estão entre os mais expostos?

Profissionais no início da carreira costumam executar tarefas estruturadas que podem ser automatizadas. Se essas atividades diminuírem sem alternativas de aprendizagem, fica mais difícil adquirir experiência prática e avançar para responsabilidades maiores.

Um desenvolvedor júnior deve deixar de usar assistentes de código?

Não. Deve usá-los como apoio, sem delegar o entendimento. Leia o código, teste os casos relevantes, verifique as dependências e explique as decisões. O objetivo é aprender mais depressa, não esconder lacunas de conhecimento.

Quando um script é melhor do que um modelo de IA?

Quando as regras são estáveis, as entradas previsíveis e o resultado precisa ser reproduzível. Um script determinístico costuma ser mais simples de testar e operar. A IA é mais adequada quando há variação ou linguagem ambígua e a resposta pode ser validada.

Como saber se a IA realmente aumentou a produtividade da equipa?

Compare o fluxo completo antes e depois: tempo de execução, revisão, correções, defeitos e retrabalho. Se a geração ficar mais rápida, mas a revisão e os incidentes aumentarem, a equipa pode não ter obtido ganho real.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.

Y

Yuri Sousa

Front-End Developer / Designer

Desenvolvedor apaixonado por criar experiências digitais acessíveis e visualmente perfeitas. Escrevo sobre desenvolvimento web, design e tecnologia.