DEV Community: Alexandre Almeida

matança de empregos em TI pela IA: hype ou realidade? Os dados dizem outra coisa

Alexandre Almeida — Wed, 03 Jun 2026 10:58:15 +0000

TL;DR: 37k demissões em tech nos EUA em 2025, quase metade atribuída à IA. Mas 88% dos projetos de IA falham antes do prod. Alguém precisa falar sobre isso.

Se você trabalha com tecnologia, provavelmente já sentiu o clima mudando nos últimos 18 meses.
Não é paranoia. É dado.

O que está acontecendo de verdade

Grandes empresas estão demitindo entre 10% e 40% de suas equipes técnicas com uma justificativa de duas partes:

"A IA faz o mesmo trabalho"
"Precisamos realocar verba para infraestrutura de IA"

O problema? Os números não sustentam essa narrativa.

IDC: 88% dos projetos de IA corporativos não passam do POC
MIT: 95% nunca geram impacto financeiro mensurável
Realidade: o ROI de IA demora anos, não quarters

O paradoxo mais cruel

Você já imaginou ser o engenheiro responsável por documentar e treinar o modelo que vai te substituir?

Isso está acontecendo em IBM, Google e Meta. E tem um nome: é uma das formas mais eficientes de destruir a moral de um time que já existe.

O resultado prático:

Baixa produtividade dos que ficaram
Sabotagem passiva de processos
Perda de conhecimento institucional que não tem preço

Para quem toma decisões técnicas

Se você é CTO, tech lead ou arquiteto, os dados sugerem cautela:

Cortes motivados por IA → perda de conhecimento institucional
                        → desmotivação dos remanescentes  
                        → projetos de IA sem contexto de negócio
                        → ROI ainda mais distante

A adoção responsável de IA passa por capacitar pessoas, não substituí-las.

Linus Torvalds fala em 10x de produtividade para devs com IA — mas isso pressupõe que o dev ainda está lá.

Conclusão honesta

A IA vai mudar o mercado de trabalho. Isso é fato e não tem volta.

Mas a pressa corporativa em cortar headcount baseada em expectativas que os próprios dados desmentem revela um problema de liderança, não de tecnologia.

O futuro é de quem souber combinar os dois.

Análise completa com fontes: https://alealmeida369.com/blog

Discussão aberta: você tem visto esse movimento na sua empresa ou stack? Drop nos comentários.

Novo CNPJ: O "Bug do Milênio" versão Tupiniquim?

Alexandre Almeida — Mon, 01 Jun 2026 13:43:40 +0000

Se você é dev no Brasil, o número 14 está no seu DNA. Mas o alicerce mudou. O estoque de combinações numéricas do CNPJ esgotou (abrimos 4,2 milhões de empresas só em 2024!) e a Receita Federal deu o veredito: o CNPJ agora é alfanumérico.

*Parece simples? "Só mudar pra String"?
*
Senta aqui, vamos escovar uns bits:

Por que não aumentaram um dígito? Economia de guerra. Adicionar o 15º dígito quebraria layouts de EDI, notas fiscais e arquivos de remessa no país todo. Manter 14 caracteres é a tentativa de mitigar o caos, mas a mudança de tipo é uma bomba silenciosa.

O Pesadelo do Legado Quem ainda roda COBOL ou sistemas de 2005 (onde o fornecedor já faliu) está em pânico. Sair de uma PIC 9(14) para PIC X(14) não é só recompilar; é reescrever lógicas de validação matemática que assumiam que "CNPJ é só número". Se o sistema não tem suporte, ele simplesmente vai parar de aceitar novos clientes. Ponto.

*Banco de Dados: O custo da "String" DBAs, preparem o storage.
*
Antigo: Um BIGINT (8 bytes) resolvia. Comparação em nível de CPU, rápida e barata.
Novo: CHAR(14) ou VARCHAR. Dependendo do charset (UTF8), saltamos para até 42 bytes.

Impacto: Índices mais gordos, consumo de RAM maior nos buffers e IOPS subindo. Se você usa CNPJ como chave em tabelas gigantes, a conta vai chegar.

Real na Lata: Não vai cair avião, mas a teia de integrações do Brasil é sensível. Se um validador no meio do caminho barrar uma letra, a cadeia inteira trava. 2025/2026 será o ano de limpar código de quem achou que "imutável" era para sempre.

E seu legado, está pronto para o "A1B2C3…" ou vai esperar o sistema abendar em produção? Gostou desse tema? Leia mais no meu blog.

Desenvolvimento #Software #CNPJ #Legado #EngenhariaDeDados #COBOL #SQL

SQL Server Max Server Memory: Como Configurar a Memória Corretamente e Evitar Lentidão

Alexandre Almeida — Mon, 01 Jun 2026 13:23:32 +0000

O que você vai aprender neste artigo

O que é o Max Server Memory e por que ele existe
Por que o SQL Server "come" toda a memória do servidor
Como calcular o valor ideal de memória para seu ambiente
Como aplicar a configuração com T-SQL
Como monitorar a pressão de memória
Erros comuns que podem travar seu servido

*Por que o SQL Server consome tanta memória?
*
Se você já abriu o Gerenciador de Tarefas de um servidor com SQL Server e se assustou com o consumo de RAM, saiba que isso é um comportamento esperado, mas que precisa ser gerenciado. O SQL Server foi projetado para usar o máximo de memória disponível para armazenar dados em cache (o chamado Buffer Pool). A lógica é simples: quanto mais dados ficam na memória, menos o servidor precisa acessar o disco, e o disco é muito mais lento que a RAM. O problema surge quando não existe um limite definido: o SQL Server vai consumindo memória até que o sistema operacional (SO) comece a reclamar. Quando isso acontece, o Windows passa a usar o arquivo de paginação (swap) como substituto da RAM, e, aí o desempenho desaba.

Resumindo: sem limite de memória configurado, o SQL Server pode "engolir" tanta RAM que o próprio Windows fica sem recursos para funcionar corretamente.

*O que é o Max Server Memory?
*

O Max Server Memory (máximo de memória do servidor) é uma configuração nativa do SQL Server que define o teto máximo de RAM que o mecanismo de banco de dados pode alocar para o Buffer Pool. Parâmetro Descrição max server memory (MB) Limite máximo de memória para o SQL Server min server memory (MB) Mínimo garantido de memória para o SQL Server. Por padrão, o valor de max server memory vem configurado como 2.147.483.647 MB,ou seja, praticamente sem limite. Isso significa que, em um servidor sem esse ajuste, o SQL Server vai tentar usar tudo o que o hardware oferecer.

*Qual o valor ideal? A fórmula prática
*
Não existe um número mágico, mas existe uma fórmula amplamente utilizada por DBAs para calcular um ponto de partida seguro:

Max Server Memory = RAM Total do Servidor  
                    - Memória para o Sistema Operacional  
                    - Memória para outros processos  
                    - Memória para o SSAS/SSIS/SSRS (se instalados no mesmo servidor)

*Quanto reservar para o Sistema Operacional?
*
Use esta tabela como referência:

Servidor com 32 GB de RAM, sem outros serviços instalados:

Max Server Memory = 32 GB - 4 GB (SO) = 28 GB = 28.672 MB

Como aplicar a configuração via T-SQL
Você pode configurar o Max Server Memory diretamente pelo SQL Server Management Studio (SSMS) ou via T-SQL. A forma mais rápida e rastreável é usando script:

-- Habilita opções avançadas de configuração
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

-- Define o limite máximo de memória (em MB)
-- Exemplo: 28 GB = 28.672 MB
EXEC sp_configure 'max server memory (MB)', 28672;
RECONFIGURE;

Atenção: a configuração entra em vigor imediatamente, sem necessidade de reiniciar o SQL Server. Porém, a memória já alocada só será liberada gradualmente conforme a demanda diminui.

Verificando a configuração atual

-- Verifica os valores configurados
EXEC sp_configure 'max server memory (MB)';

-- Ou de forma mais detalhada:
SELECT 
    name,
    value,
    value_in_use,
    description
FROM sys.configurations
WHERE name = 'max server memory (MB)';

*Como fazer pelo SQL Server Management Studio (SSMS)
*
Se preferir a interface gráfica:

Clique com o botão direito no nome do servidor > Properties
Vá até a aba Memory
No campo Maximum server memory (in MB), insira o valor calculado
Clique em OK

*Como identificar se há pressão de memória no seu servidor
*
Antes de sair alterando configurações, vale verificar se o servidor realmente está sofrendo com falta de memória. Algumas consultas úteis:

Verificar o uso atual do Buffer Pool

SELECT 
    physical_memory_in_use_kb / 1024 AS memoria_usada_MB,
    page_fault_count,
    memory_utilization_percentage
FROM sys.dm_os_process_memory;

Verificar sinais de pressão de memória

SELECT 
    [notification_type], 
    [creation_time], 
    [request_status]
FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type = N'RING_BUFFER_RESOURCE_MONITOR'
ORDER BY creation_time DESC;

*Verificar Page Life Expectancy (PLE)
*
O PLE indica quantos segundos, em média, uma página de dados fica na memória antes de ser removida. Um PLE baixo pode indicar pressão de memória.

SELECT 
    object_name,
    counter_name,
    cntr_value AS PLE_segundos
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Page life expectancy'
  AND object_name LIKE '%Buffer Manager%';

Referência: Para servidores com até 4 GB de Buffer Pool, um PLE abaixo de 300 segundos é sinal de alerta. Para servidores maiores, use a fórmula: (GB de Buffer Pool / 4) × 300.

Cenários especiais: múltiplas instâncias ou serviços no mesmo servidor
Se o mesmo servidor hospeda mais de uma instância do SQL Server ou outros serviços como SSAS, SSRS ou SSIS, o cálculo precisa ser ajustado para dividir a memória disponível entre todos. Servidor com 64 GB e duas instâncias SQL Server:

Reserva para o SO: 8 GB
Memória disponível: 56 GB
Instância 1 (principal): 36 GB → max server memory = 36.864 MB
Instância 2 (secundária):20 GB → max server memory = 20.480 MB

Erros comuns ao configurar a memória

Não configurar limite algum
Deixar o valor padrão de 2 TB em um servidor de produção é uma das principais causas de lentidão sistêmica e travamentos do Windows.
Configurar um valor muito baixo
Limitar demais a memória do SQL Server força leituras constantes no disco, tornando as consultas lentas. Encontrar o equilíbrio é essencial.
Não considerar outros processos
Antivírus, agentes de backup, monitoramento e outros serviços também consomem RAM. Desconsiderá-los na conta pode resultar em problemas.
Confundir Max Server Memory com toda a memória do processo
O max server memory controla principalmente o Buffer Pool. Outros componentes do SQL Server (como compilação de queries, CLR, linked servers) alocam memória fora desse limite.

Checklist rápido de boas práticas
Sempre configure o max server memory em qualquer instância de produção

Use a fórmula de reserva de memória como ponto de partida

Monitore o PLE regularmente

Ajuste o valor conforme a carga de trabalho crescer

Documente qualquer alteração feita na configuração

Em ambientes com múltiplas instâncias, distribua a memória entre todas

Configurar corretamente o Max Server Memory é uma das tarefas mais simples e com maior impacto positivo que um DBA pode fazer. É uma configuração de cinco minutos que pode evitar horas de dor de cabeça com lentidão e instabilidade. A regra de ouro é: o SQL Server precisa de memória para ser rápido, mas o Sistema Operacional também precisa de memória para manter tudo funcionando. Encontrar esse equilíbrio é o trabalho do DBA.

Gostou do conteúdo? Compartilhe com outros DBAs e continue acompanhando o blog para mais artigos sobre performance e administração do SQL Server.

O Problema da IA que Lê Emoções: Por Que a Tecnologia Ainda É um Risco para Empresas

Alexandre Almeida — Thu, 28 May 2026 14:28:15 +0000

Os Problemas Científicos e Práticos

Apesar dos avanços tecnológicos, a ciência por trás da leitura emocional automática enfrenta críticas contundentes. A base teórica frequentemente usada — a ideia de que emoções básicas produzem expressões faciais universais, proposta por Paul Ekman nos anos 60 — foi refutada em análises recentes que apontam que expressões faciais não são indicadores confiáveis do estado emocional real. Além disso, a premissa de que todos os seres humanos expressam emoções da mesma forma ignora diferenças culturais, fisiológicas e individuais.

Um estudo finlandês de 2024 evidenciou que as tecnologias de monitoramento emocional tendem a prejudicar mais o bem-estar dos funcionários do que a ajudar. Entre os falhas apontadas estão:

Alta taxa de erro ao tentar identificar estados internos como “estresse” ou “engajamento”;
Viés racial, com maior incidência de falsos positivos para emoções negativas em pessoas negras, mesmo com expressões similares a pessoas brancas;
Violação da privacidade, já que “anonimização” de dados é ineficaz em grupos pequenos, permitindo a identificação inadvertida de indivíduos;
Pressão para a chamada “laboral emocional”, obrigando colaboradores a fingir emoções que a IA e a organização esperam;
Expansão do uso para vigilância excessiva, além dos propósitos originais, configurando “missão creep”.

Implicações para Líderes e Organizações

A adoção da IA para leitura de emoções pode parecer uma forma de ganhar controle sobre o ambiente interno sem a complexidade de incentivar confiança, motivação e cultura organizacional saudável. Entretanto, a tecnologia não substitui a liderança empática e o diálogo genuíno. Os impactos negativos na saúde mental dos colaboradores, além de riscos legais — como proibições na União Europeia e estados americanos — indicam que o uso indiscriminado dessa tecnologia pode gerar mais problemas do que soluções.

Organizações que buscam usar essa IA para melhorar segurança específica em atividades de risco podem se beneficiar, desde que haja transparência, respeito à privacidade e critérios éticos rigorosos. Contudo, sua aplicação para avaliação de desempenho, entrevistas de emprego ou monitoramento contínuo deve ser repensada com cautela.

Embora o avanço tecnológico possibilite detectar emoções com IA, a ciência por trás dessas interpretações ainda é frágil, cheia de vieses e sujeita a erros. O apelo imediato desse tipo de solução precisa ser equilibrado com consciência sobre suas limitações e os impactos sobre as equipes. O futuro da gestão emocional no trabalho passa mais pela liderança humana do que por algoritmos que tentam substituir o contato e a compreensão reais.

Leia também sobre o descontrole dos orçamentos de IA nas empresas.

World ID: A revolução da “prova de humanidade” na era da inteligência artificial

Alexandre Almeida — Sat, 23 May 2026 21:31:01 +0000

Com o avanço explosivo de IAs e deepfakes, a distinção entre humanos e bots está cada vez mais difícil. A World ID, iniciativa de Sam Altman (OpenAI), propõe uma solução ambiciosa: Proof of Humanity (PoH) via escaneamento de íris com o dispositivo Orb e blockchain.

Na versão 4.0, o protocolo traz melhorias importantes: rotação de chaves, Selfie Check, delegação para agentes de IA e integração com Zoom e Okta. Mas também levanta questionamentos sérios sobre privacidade biométrica, centralização de poder e os riscos de uma identidade digital imutável.
Será que estamos caminhando para um futuro mais seguro ou para uma vigilância sem precedentes?
Leia o artigo completo e entenda os impactos dessa tecnologia disruptiva para CTOs, arquitetos e líderes de tecnologia.

Leia o artigo completo

Google e a nova era da IA offline: o futuro está no processamento local

Alexandre Almeida — Thu, 21 May 2026 21:52:10 +0000

A próxima revolução da inteligência artificial não está na nuvem. Ela está acontecendo OFFLINE — dentro do seu celular, notebook e dispositivos locais.

Enquanto o mercado ainda depende totalmente de ChatGPT, Gemini e APIs na nuvem, gigantes como Google já estão silenciosamente mudando a arquitetura da IA moderna com modelos que funcionam sem internet, processando tudo localmente na “edge”.

Neste artigo, mostro:

por que a IA offline pode redefinir segurança e privacidade corporativa,
como o Google está levando reconhecimento de voz avançado para dentro do dispositivo,
o impacto disso para arquitetos, CTOs e DBAs,
os riscos ocultos da dependência total da nuvem,
e por que o futuro provavelmente será híbrido: cloud + edge AI.

Também analiso os bastidores técnicos e estratégicos dessa mudança — incluindo aplicações militares, ambientes críticos e o novo papel do hardware na corrida da IA.

A verdadeira disputa da próxima década talvez não seja “qual IA é mais inteligente”, mas:
quem consegue continuar funcionando quando a nuvem desaparece.

Leia o artigo completo

Por que os Modelos de IA "Open" Estão Ganhando Espaço em Relação aos Grandes Modelos de Linguagem (LLMs)

Alexandre Almeida — Thu, 21 May 2026 21:48:46 +0000

Todo mundo está falando sobre ChatGPT, Claude e Gemini. Mas enquanto o mercado corre atrás dos modelos fechados, CTOs e líderes de tecnologia estão silenciosamente migrando para uma estratégia muito mais poderosa: IA open-weight.

Neste artigo, mostro o que quase ninguém fala sobre os bastidores da IA corporativa:

o custo real de rodar modelos como Llama em produção,
por que muitas empresas estão abandonando o discurso “100% open source”,
os riscos ocultos de dependência de fornecedores,
soberania digital,
segurança de dados,
e a verdadeira guerra entre autonomia e conveniência na nova economia da inteligência artificial.

Depois de colocar os números na ponta do lápis em ambientes Nvidia Cloud e GCP, a conclusão foi muito diferente do hype vendido no LinkedIn.

Se você é CTO, arquiteto, engenheiro, fundador ou trabalha com IA corporativa, este conteúdo provavelmente vai mudar sua visão sobre modelos abertos, custos de inferência e estratégia de longo prazo.

Leia o artigo completo