Critical Software termina 2026 com menos 200 pessoas e aponta à IA

Segundo a notícia do ECO de 30 de outubro, a Critical Software, fundada em Coimbra, prevê terminar 2026 com cerca de 1.300 colaboradores, menos 200 do que os cerca de 1.500 do início do ano, uma redução próxima de 13% associada à inteligência artificial; o presidente executivo, João Carreira, resumiu o efeito nas funções: «Há umas que desaparecem, outras que são transformadas e outras que são criadas». O valor anunciado é uma projeção para o fecho do ano, não uma contagem final de pessoas que já deixaram a empresa.

A E24 descreve uma reorganização que combina saídas com novas contratações especializadas, centrada na automatização de tarefas repetitivas de programação e testes; refere ainda um investimento estimado em oito milhões de euros em formação e projetos experimentais de IA. Para quem desenvolve software ou faz testes em Portugal, a distinção central é esta: o quadro deverá encolher, mas o saldo previsto não identifica por si só quantas pessoas foram despedidas.

O saldo previsto e os despedimentos são medidas diferentes

A diferença entre a equipa no início do ano e a dimensão esperada no fim mede a redução líquida. Entradas e saídas são movimentos separados: as admissões compensam parte das saídas, enquanto estas podem ter origens distintas. O saldo dá a dimensão da mudança no quadro, mas não revela quantos contratos cessaram por decisão da empresa, por iniciativa dos trabalhadores ou pelo termo de um vínculo.

Num exemplo puramente hipotético, se saíssem 250 pessoas e entrassem 50, o quadro diminuiria 200. O exemplo mostra por que motivo uma diminuição dessa dimensão não pode ser automaticamente descrita como 200 despedimentos; não representa os movimentos reais da Critical Software. Da mesma forma, a existência de novas admissões não elimina a possibilidade de despedimentos entre as saídas.

A sequência temporal também importa. A comparação começa no quadro do início de 2026, a previsão tornou-se pública em outubro e o valor final só poderá ser apurado no encerramento do ano. Até lá, contratações e outras saídas podem mudar o resultado. Os dados divulgados até agora não discriminam o saldo por tipo de saída, detalhe necessário para avaliar a dimensão efetiva dos despedimentos.

Que trabalho de programação e testes fica mais exposto

O foco indicado pela gestão são as tarefas repetitivas de programação e teste. A unidade de mudança, aqui, é a atividade executada, não necessariamente o cargo completo de programador ou profissional de qualidade. A mesma pessoa pode produzir código padronizado, interpretar um requisito ambíguo e decidir se um resultado é aceitável para um sistema específico; essas partes do trabalho não são equivalentes.

Esta matriz organiza as tarefas a partir das áreas identificadas pela empresa e da forma como um projeto de software é produzido. É uma análise do trabalho potencialmente transformado, não uma lista de funções eliminadas ou de vagas futuras:

• Entrada — definir o problema: transformar necessidades do cliente em requisitos, condições de aceitação e casos a testar. Se as instruções forem incompletas ou contraditórias, alguém terá de decidir qual é o comportamento pretendido antes de avaliar o código produzido.
• Transformação — executar trabalho repetível: criar trechos rotineiros de código, preparar testes semelhantes e correr verificações padronizadas. É nesta parcela que a substituição de tarefas por IA se aproxima mais do que o presidente executivo descreveu.
• Supervisão — assumir o resultado: investigar falhas, confrontar o comportamento observado com os requisitos e validar o produto. A geração automática de código ou de testes desloca trabalho para esta fase sempre que o resultado precisa de ser explicado e aceite.

Para profissionais em início de carreira, há uma consequência possível: algumas tarefas rotineiras também servem de treino para conhecer a arquitetura de um sistema, as convenções da equipa e a origem dos erros. Se essas tarefas forem automatizadas, a aprendizagem terá de passar por outras atividades, como rever resultados e compreender critérios de aceitação. Isto é uma implicação da mudança nas tarefas, não uma política de recrutamento que a empresa tenha anunciado.

A ambição da empresa para a IA já estava definida

Num texto de 22 de julho de 2026 publicado pela Critical Software, o diretor de tecnologia Patrick Machado apontou o nível L4 de automação como objetivo para o fim do ano: a IA implementaria o software e as pessoas validariam o produto, em vez de reverem cada linha de código. O texto apresenta esse nível como uma meta e menciona iniciativas em curso, não como um estado já alcançado em todos os projetos.

A diferença entre rever cada linha e validar o produto ajuda a perceber por que motivo a automatização atinge tarefas e altera responsabilidades ao mesmo tempo. Quem verifica o resultado precisa de conhecer os requisitos, os riscos do sistema e os limites dos testes realizados. No caso de software usado em contextos críticos, um resultado gerado depressa continua a ter de satisfazer exigências de segurança, fiabilidade e projeto; a própria estratégia técnica da empresa reconhece que nem todos os projetos poderão seguir o mesmo nível de automação.

O investimento comunicado em formação e experiências indica que a reorganização inclui adaptação das equipas, além da redução prevista do quadro. O impacto concreto para cada função dependerá da proporção de trabalho repetível que a IA absorver e do peso que a validação passar a ter. Essa combinação pode mudar a composição das equipas sem permitir uma previsão direta sobre o emprego em todas as tecnológicas portuguesas.

No fecho de 2026, o dado decisivo será comparar a equipa efetiva com a projeção e conhecer, se forem divulgados, os números separados de admissões, saídas e despedimentos. Para quem trabalha em programação e testes, essa distinção mostrará com mais precisão como a automação de tarefas se traduziu em mudanças de emprego.

Leia também:

• AMALIA, ChatGPT ou Claude: privacidade local troca-se por menos acertos?