Qual será a primeira linguagem de programação nativa para agentes?

As linguagens de programação foram projetadas para que humanos instruíssem máquinas.

A sintaxe delas reflete essa história. Usamos nomes de variáveis legíveis, palavras-chave memorizáveis, indentação, comentários, arquivos, classes e abstrações que se encaixam em modelos mentais humanos. Erros de compilação são escritos para pessoas. A documentação é organizada para pessoas. Repositórios são estruturados para que pessoas consigam navegar por eles.

Mas as pessoas estão rapidamente deixando de ser responsáveis por escrever o código em si.

Pela Senternet, o estúdio de software onde construo produtos e experimento com desenvolvimento assistido por IA, hoje crio boa parte do meu software dirigindo agentes de codificação. Eu descrevo o que quero, reviso o resultado, testo o comportamento e mando o agente de volta para corrigir o que estiver errado. O agente ainda produz TypeScript, Python, SQL e outros códigos-fonte convencionais, mas isso parece cada vez mais um artefato do ecossistema existente do que uma exigência do trabalho.

O agente escreve código legível por humanos principalmente porque nossos compiladores, bibliotecas, sistemas operacionais, APIs, gerenciadores de pacotes e infraestrutura de implantação esperam isso.

Daí surge uma pergunta da qual não consigo me livrar:

Qual será a primeira linguagem de programação projetada sobretudo para agentes, e não para humanos?

Código legível por humanos está virando um formato intermediário

Na maior parte da história da computação, o código-fonte teve dois públicos.

O primeiro era o computador que iria compilá-lo ou interpretá-lo. O segundo era toda pessoa que talvez precisasse entendê-lo, depurá-lo, mantê-lo ou estendê-lo depois.

Esse segundo público moldou quase toda decisão importante de projeto de linguagem.

Python enfatiza legibilidade. Ruby tenta soar natural e expressivo. TypeScript acrescenta estrutura que ajuda grupos grandes a raciocinar sobre JavaScript. Rust torna explícitas a posse e a segurança de memória, para que quem desenvolve entenda e controle comportamentos que outras linguagens esconderiam.

São recursos valiosos porque, tradicionalmente, o recurso escasso tem sido a atenção humana.

A codificação agêntica muda essa economia.

Um agente não precisa de sintaxe fácil de digitar. Não precisa de palavras-chave fáceis de lembrar. Não precisa de uma linguagem que caiba num semestre ou numa estante de livros. Ele não se cansa ao percorrer um repositório enorme. Consegue processar representações que seriam tediosas, prolixas ou incompreensíveis para uma pessoa.

Ele pode se beneficiar de propriedades bem diferentes:

• semântica sem ambiguidade
• representação compacta em tokens
• dependências e efeitos colaterais explícitos
• transformações determinísticas
• verificação formal
• paralelização automática
• diagnósticos legíveis por máquina
• procedência embutida
• compilação incremental
• otimização específica para o hardware
• expressão direta de restrições e testes

Quando os agentes se tornarem os autores principais do software, a legibilidade humana deixa de ser a restrição central de projeto.

Ela não fica sem valor. Ela vira uma interface gerada.

A representação nativa da máquina pode virar a fonte da verdade, enquanto os humanos recebem a visão mais útil no momento: uma explicação, um diagrama, uma especificação de comportamento, um relatório de segurança, um plano de testes ou até TypeScript gerado.

Código legível por humanos pode acabar não sendo mais fundamental do que a visão gráfica do esquema de um banco de dados.

Por que os agentes ainda escrevem Python e TypeScript

O maior obstáculo para qualquer linguagem nova não é a sintaxe dela.

É o ecossistema.

Uma linguagem nova precisa de compiladores, depuradores, bibliotecas, documentação, gerenciamento de pacotes, suporte em editores, ferramentas de implantação, análise de segurança e acesso às plataformas existentes. Quem desenvolve reluta em adotar uma linguagem que obrigue a reconstruir tudo o que já tem.

Os agentes não eliminam esse problema, mas podem reduzi-lo drasticamente.

Historicamente, uma linguagem nova também tinha de convencer milhões de pessoas a aprendê-la. Era preciso treinamento, exemplos, livros, apoio da comunidade e confiança suficiente para arriscar carreiras e empresas numa tecnologia desconhecida.

Um agente não precisa de meses de treinamento. Assim que um modelo ou sistema de codificação consegue produzir uma linguagem de forma confiável, todo usuário desse sistema ganha acesso a ela na hora.

Isso remove uma das maiores barreiras históricas à adoção de linguagens.

O problema do ecossistema continua, o que significa que a primeira linguagem agent-native bem-sucedida provavelmente não vai substituir Python, JavaScript, Rust e C++ de uma vez. Ela vai absorvê-los.

Pode compilar via LLVM, mirar WebAssembly, chamar interfaces C existentes, importar pacotes atuais e conversar com APIs estabelecidas. Pode começar como uma representação intermediária escondida sob um agente de codificação, e não como uma linguagem que desenvolvedores escolhem conscientemente.

A transição pode acontecer sem que a maioria perceba.

Partes disso já estão acontecendo

Ainda não existe uma linguagem de programação de uso geral, amplamente adotada, escrita e consumida sobretudo por agentes. Há, porém, vários projetos iniciais nessa direção.

Pesquisadores apresentaram o Quasar em 2025 como linguagem para ações de código executadas por agentes baseados em grandes modelos de linguagem. Agentes costumam gerar Python quando precisam chamar ferramentas ou montar fluxo de controle, mas os pesquisadores argumentaram que o Python carece das características de desempenho, segurança e confiabilidade necessárias para esse trabalho.

O Quasar acrescenta paralelização automática, rastreio de incerteza e mecanismos para validar ações potencialmente inseguras. Na implementação atual, o modelo escreve um subconjunto restrito de Python que é transpilado para Quasar. Os pesquisadores relataram redução de 42 por cento no tempo de execução quando a paralelização era possível e de 52 por cento nas interações de aprovação exigidas quando seus mecanismos de segurança se aplicavam.

O Quasar não é a forma final de uma linguagem agent-native. O agente ainda emite código parecido com Python. Mas ele deixa a pressão evidente: uma linguagem projetada para pessoas pode não ser o melhor modelo de execução para agentes.

Pel é outra linguagem experimental criada especificamente para orquestrar agentes de IA. Usa uma gramática mínima e enfatiza geração restrita, controle de capacidades, comunicação entre agentes, execução segura e paralelização automática.

Pel é influenciada por linguagens como Lisp, Elixir, Gleam e Haskell, mas seu projeto assume que a facilidade de geração confiável por um modelo é, ela própria, um recurso da linguagem.

Essa é uma mudança significativa de prioridades. Projetistas tradicionais perguntam se a sintaxe é compreensível para uma pessoa. Projetistas de linguagens agent-native talvez perguntem se um modelo consegue gerá-la de forma consistente, validá-la mecanicamente e se recuperar de erros sem intervenção humana.

Agentes de codificação também começam a mostrar que não precisam aprender linguagens desconhecidas do jeito que humanos aprendem.

Num estudo de 2026 sobre agentes de codificação lidando com linguagens esotéricas, os agentes de ponta frequentemente escreviam programas em Python que geravam e depuravam o código-alvo desconhecido. Quando os pesquisadores proibiram essa estratégia de metaprogramação, o desempenho caiu bastante.

Essa é uma forma primitiva, mas importante, do futuro que estou descrevendo.

Um agente consegue inferir uma representação-alvo, construir um gerador para ela, testar o resultado e revisar o gerador. Ele não precisa entender nem manter o código-alvo no sentido humano. A linguagem-alvo é apenas mais uma representação de máquina que ele pode manipular.

A primeira linguagem agent-native pode não parecer uma linguagem

Quando as pessoas imaginam uma nova linguagem de programação, geralmente imaginam uma nova sintaxe.

Essa pode ser a parte menos importante.

Uma linguagem agent-native poderia ser uma representação estruturada de:

• comportamento desejado
• interfaces
• restrições
• permissões
• invariantes
• testes
• limites de recursos
• metas de desempenho
• políticas de segurança
• modos de falha aceitáveis

O agente de codificação e o compilador poderiam decidir juntos como esses requisitos devem ser implementados.

Para uma carga de trabalho, o resultado pode ser código de máquina nativo. Para outra, WebAssembly. Para outra, um plano de consulta de banco, um kernel de GPU, uma função serverless ou uma composição de serviços existentes.

Pode não haver arquivo-fonte permanente correspondente à implementação.

O artefato durável seria a intenção e a evidência de que a implementação a satisfaz.

Isso sugere uma progressão em três estágios.

Estágio um: agentes escrevem linguagens de programação humanas

É onde estamos agora. Agentes produzem código que parece algo que um desenvolvedor humano poderia ter escrito.

Estágio dois: agentes escrevem representações intermediárias voltadas à máquina

Humanos revisam principalmente comportamento, testes, especificações, explicações geradas e mudanças de capacidades. A implementação subjacente perde importância na revisão de rotina.

Estágio três: agentes geram sistemas executáveis diretamente

A fonte da verdade passa a ser um conjunto de intenção, políticas, interfaces, restrições e evidências de verificação. O agente gera e regenera implementações executáveis conforme a necessidade.

Nesse ponto, perguntar em que linguagem uma aplicação está «escrita» pode deixar de fazer muito sentido.

Legível por humanos não significa auditável por humanos

O argumento mais forte contra esse futuro é que o código-fonte não serve apenas para escrever software.

Ele também serve para depurar, auditar, governar, revisar segurança, manter e responsabilizar.

Não dá para operar com segurança sistemas importantes cujo comportamento ninguém consegue inspecionar.

Mas código-fonte legível já é um substituto fraco para entendimento real. Uma aplicação moderna grande pode ter milhões de linhas de código próprio e depender de outros milhões via pacotes, arquivos gerados, serviços de nuvem, sistemas operacionais e firmware. Quase ninguém entende o sistema inteiro.

O código pode ser legível sem que o sistema seja compreensível.

Um sistema agent-native precisaria oferecer formas de inspeção mais fortes do que uma pilha de arquivos-fonte. Ele poderia gerar:

• explicações de comportamentos específicos
• mapas de movimentação de dados
• provas de propriedades importantes
• relatórios de permissões e capacidades
• históricos de dependências
• simulações de mudanças propostas
• testes executáveis
• registros do porquê de cada decisão
• implementações legíveis por humanos quando necessário

A meta não deveria ser preservar código legível a qualquer custo.

A meta deveria ser preservar o controle humano.

Não são a mesma coisa.

O custo ambiental do código amigável para humanos

Há outra razão pela qual os agentes podem acabar indo além das linguagens de hoje: energia.

Um estudo de 2017 sobre eficiência energética em 27 linguagens de programação, muito citado, comparou tempo de execução, uso de memória e consumo de energia em dez problemas de referência.

Nos resultados normalizados, o Python consumiu cerca de 76 vezes mais energia que o C e exigiu cerca de 72 vezes mais tempo de execução. O Python ficou perto do fim da lista em eficiência energética.

Esse resultado costuma ser simplificado na afirmação de que o Python é uma das piores linguagens para o meio ambiente.

A realidade é mais complicada.

Uma reanálise de 2024 da eficiência energética de linguagens de programação concluiu que essas comparações podem confundir a linguagem com sua implementação, com a qualidade do programa de benchmark, com o número de núcleos ativos, com o comportamento das bibliotecas, com a atividade de memória e com outros detalhes de execução.

Depois de controlar esses fatores, os pesquisadores concluíram que a implementação da linguagem não teve efeito significativo sobre o consumo de energia além do tempo de execução.

A questão central não era que a sintaxe de uma linguagem de alguma forma consumisse mais eletricidade. Programas mais lentos geralmente usavam mais energia total porque o hardware ficava ativo por mais tempo.

Essa distinção não faz o problema sumir.

O Python padrão costuma ser bem mais lento que código compilado otimizado em trabalho computacionalmente intenso. Um programa que leva muito mais tempo para fazer a mesma coisa pode consumir muito mais energia, mesmo que o processador consuma potência num ritmo parecido enquanto executa.

A boa notícia é que a ineficiência não é inevitável.

Um estudo de 2025 sobre implementações compiladas de Python comparou o CPython com vários sistemas de compilação e otimização, incluindo PyPy, Numba, Codon, Cython, Nuitka, Mypyc e Pyston-lite.

Os pesquisadores descobriram que a compilação podia melhorar bastante tempo de execução, uso de memória e consumo de energia. Codon, PyPy e Numba produziram ganhos de velocidade e energia acima de 90 por cento em algumas das cargas testadas.

A conclusão mais precisa não é que o Python seja inerentemente destrutivo para o meio ambiente.

É que os humanos muitas vezes escolheram linguagens com base na produtividade humana, tratando a eficiência de execução como preocupação secundária.

O Python é bem-sucedido porque é legível, expressivo, tolerante e apoiado por um ecossistema enorme. Em muitas organizações, poupar tempo de quem desenvolve compensa gastar mais tempo de computação.

Os agentes não enfrentam o mesmo dilema.

Um agente de codificação não precisa de sintaxe amigável para continuar produtivo. Não precisa de uma linguagem fácil de ensinar, digitar ou lembrar. Ele poderia gerar uma representação escolhida para a carga específica, compilá-la para o hardware disponível, medir o resultado e trocá-la quando surgisse uma implementação mais eficiente.

O consumo de energia poderia virar uma propriedade de primeira classe da programação, em vez de uma otimização tentada depois que o software já foi escrito.

Isso importa porque os agentes não vão simplesmente substituir código humano linha a linha. É provável que aumentem o volume total de software produzido e executado.

Agentes podem gerar dezenas de implementações, rodar milhares de testes, criar programas descartáveis para tarefas isoladas e regenerar continuamente sistemas em funcionamento. A ineficiência que era tolerável quando o software era produzido devagar por humanos fica mais consequente quando máquinas podem gerar código quase ilimitado.

Por isso a primeira linguagem agent-native pode otimizar mais do que correção e velocidade. Ela poderia considerar:

• consumo total de energia
• frequência esperada de execução
• processadores e aceleradores disponíveis
• movimentação de memória
• custo de compilação
• a intensidade de carbono da eletricidade disponível
• se uma carga pode ser adiada ou realocada
• se uma implementação vai rodar uma vez ou bilhões de vezes

Pode não existir uma representação universalmente ótima.

Uma conversão de dados única pode favorecer o menor custo de compilação. Um serviço que deve atender bilhões de requisições pode justificar otimização nativa agressiva. Uma carga rodando num dispositivo a bateria pode priorizar energia sobre latência. Um job num data center poderia ser agendado conforme a disponibilidade de energia de menor carbono.

Um agente poderia tomar essas decisões automaticamente.

Talvez o erro ambiental não fosse deixar agentes escreverem código ilegível. Fosse obrigá-los a continuar escrevendo Python só porque humanos gostam de ler.

O que será do programador?

Nada disso significa que humanos param de construir software.

Significa que nosso trabalho sobe de nível.

Em vez de gastar a maior parte do tempo descrevendo passos de implementação numa sintaxe pensada para compiladores, vamos gastar mais tempo definindo:

• o que o sistema deve realizar
• o que ele nunca pode fazer
• quais trade-offs são aceitáveis
• quem pode acessar o quê
• como o sucesso é medido
• como as falhas devem ser tratadas
• que evidências são exigidas antes da implantação

Isso ainda é programar.

De muitas formas, é programar mais diretamente do que traduzir manualmente essas decisões em laços, classes, funções e arquivos de configuração.

O papel de quem programa passa a ser menos produzir código-fonte e mais estabelecer intenção, restrições, arquitetura e julgamento. É mais uma razão pela qual eu sempre volto à ideia de que bom gosto é o gargalo assim que construir fica barato.

A parte difícil do desenvolvimento de software nunca foi digitar a sintaxe. A parte difícil era decidir o que deveria acontecer.

Os agentes estão removendo a camada de tradução.

Quem vai criá-la?

A primeira linguagem verdadeiramente agent-native talvez não seja lançada numa conferência de desenvolvedores.

Pode não ter um nome esperto, uma especificação pública nem uma comunidade debatendo sua sintaxe.

Ela pode surgir silenciosamente dentro de uma plataforma de agentes, como representação intermediária privada usada para planejar, gerar, verificar, otimizar e compilar software. Pode inicialmente mirar linguagens convencionais e cadeias de ferramentas existentes e, aos poucos, dispensar mais delas.

Quando os humanos a reconhecerem como linguagem de programação, os agentes talvez já estejam usando-a para escrever uma parcela relevante do software do mundo.

A vencedora não será necessariamente a linguagem que os humanos mais gostam de ler.

Será a representação que os agentes conseguirem usar para produzir os sistemas mais confiáveis, seguros, eficientes e verificáveis, ainda dando aos humanos controle significativo sobre o resultado.

Linguagens de programação foram inventadas para que humanos pudessem dizer aos computadores o que fazer.

A próxima pode ser inventada para que os computadores digam a si mesmos.