Um questionamento que há algum tempo me assombra é: até quando teremos linguagens de programação?
Pra muita gente isso soa como filosofia barata. Pra quem já encostou em compiladores, arquiteturas e infraestrutura de build, a pergunta é bem mais concreta: a linguagem é mesmo o centro do desenvolvimento… ou só a interface que a gente acostumou a usar?
O hardware não “entende” sua linguagem
O hardware, no fim do dia, recebe instruções bem definidas. E isso não mudou tanto em décadas: sejam binários, assembly, instruções vetoriais, microcódigo, ou operações especializadas. O que muda é a quantidade de camadas que a gente empilha entre a intenção e a execução.
Quem mexe com baixo nível sabe: cada arquitetura tem suas peculiaridades, suas instruções, seus registradores, suas convenções. Mesmo quando você está “alto nível”, existe uma floresta de especificações por trás. É por isso que existem drivers, toolkits e APIs intermediárias.
GPU é o exemplo perfeito:
O sistema operacional precisa mediar acesso ao hardware.
O driver precisa traduzir e otimizar comandos.
Frameworks e toolkits entram por cima (CUDA, tecnologias de upscaling, pipelines específicos).
APIs gráficas fazem o papel de “contrato” (DirectX/Vulkan/Metal).
Linguagens de shader (HLSL/GLSL) viram outra linha de montagem dentro da linha de montagem.
E mesmo assim, uma parte enorme desse ecossistema nasceu — ou foi consolidada — em cima de C/C++.
Seu .cpp não roda. Quem roda é o compilador.
Aqui está o ponto que muita gente ignora: o código que você escreve não é o que o hardware processa.
Muito longe disso.
O compilador desmonta seu código em etapas:
Análise lexical (tokens)
Parsing (estrutura)
AST (árvore sintática)
Verificação de tipos
Otimizações
Geração de código / IR
Emissão do binário final
A “mágica” da performance, na prática, está muito mais no compilador e no pipeline do que na sintaxe. Sintaxe é ergonomia. Performance é engenharia.
E por isso surgiram camadas de abstração: C#, Java, máquinas virtuais, runtimes, JIT, AOT, e frameworks como LLVM para padronizar e reutilizar uma parte enorme do trabalho pesado.
No fim das contas, dá pra resumir assim:
“Não importa a cor do sabonete, a espuma vai ser sempre branca.”
O binário é o destino. A linguagem é o caminho.
Então por que ainda brigamos tanto por linguagem?
Porque linguagem é onde o humano encosta. Linguagem é o volante. Só que volante não é motor.
A discussão real deveria ser:
qual pipeline gera software mais confiável?
qual ecossistema tem melhor capacidade de verificação?
qual workflow reduz erro humano e erro de máquina?
qual stack dá evidência de qualidade (testes, builds, métricas, rastreabilidade)?
E é aqui que a IA entra como um martelo quebrando vitrine. IA expôs um fato inconveniente: liberdade demais vira lixo rápido.
LLMs foram treinadas em cima das linguagens e códigos existentes. Mas elas não “vivem” dentro do compilador. Elas não sentem o peso da semântica de verdade; elas preveem texto. Resultado: a taxa de erro é alta, mesmo com acesso a “todo código do mundo”.
O que reduz isso? Feedback fechado:
build rodando
testes rodando
linter/formatter/analizadores
execução real
validações e contratos
Ferramentas como Cursor, Claude Code e setups com MCP melhoram muito porque colocam a IA numa coleira: ela tenta, quebra, vê o erro, corrige, tenta de novo. Isso é essencial. Mas não é o bastante.
Porque ainda dá pra gerar:
código que compila e é ruim
código que passa teste e é frágil
arquitetura incoerente
acoplamento que explode em escala
“soluções” que parecem corretas mas geram dívida técnica silenciosa
Nos últimos meses eu testei vários modelos em muitas linguagens diferentes. E a conclusão prática que eu cheguei — que bate de frente com meu instinto de 22 anos como dev — é dura:
O melhor cenário, na minha experiência, é:
linguagem compilada
debug simples e objetivo
tipagem forte e verbosa
documentação ampla e fácil de indexar
TDD no centro (como trilho, não como enfeite)
workflow rígido (regras de branch, PR, revisão)
CI/CD que não perdoa
hooks locais (format, lint, tests, build antes do push)
tasks pequenas, claras e segmentadas
padrões arquiteturais com limites explícitos
Para humanos, esse combo parece tortura. Para IA, é o paraíso.
E isso não é detalhe: isso aponta para onde o mercado está indo.
Linguagens não vão acabar. O “ato de programar” é que vai mudar de dono.
A pergunta “até quando teremos linguagens de programação?” é boa — mas a resposta é mais precisa se a gente ajustar o alvo:
linguagens sempre vão existir, porque sempre vai existir execução.
O que tende a morrer é a ideia de que “programar” é principalmente escrever código manualmente.
O futuro mais plausível não é uma “super linguagem universal” que todo mundo vai adotar. O futuro é uma pilha de artefatos que reduzem ambiguidade:
Contratos de dados (schema/IDL/proto)
Contratos de comportamento (invariantes, pré/pós-condições)
Testes e propriedades (unit, integração, property-based, fuzz)
Regras de arquitetura (boundaries, imports, camadas, budgets)
Evidência (logs de build, coverage, benchmarks, auditoria)
Isso é o que realmente escala com IA. Porque a IA não precisa “adivinhar” o que você quer — ela precisa obedecer o que foi definido.
E aqui vai a provocação: prompt em linguagem natural é uma UX, não uma especificação.
Ótimo para rascunhar. Péssimo para sustentar software grande.
A partir daqui, quem não aprender a construir sistemas “verificáveis por padrão” vai ficar preso no inferno do retrabalho: humano improvisando e IA cuspindo variações do mesmo erro, pra sempre.
