Design Agent-First: por que Zero existe e o que ele troca

A pergunta que Zero faz

A premissa por trás do Zero é simples: quando um agente de IA — não só um humano — está lendo, escrevendo e reparando código, como a própria linguagem quer se parecer?

As linguagens atuais foram desenhadas muito antes de agentes saberem escrever código. As prioridades — sintaxe enxuta, idiomas expressivos, esperteza de biblioteca — fazem sentido para humanos digitando em editores. Elas toleram ambiguidade e conversões implícitas porque humanos são bons em preencher os buracos. Agentes não são. Eles geram texto exato a partir de distribuições de probabilidade, e pagam por cada borda mal definida da linguagem com um token errado em algum lugar mais à frente.

Zero recomeça do zero com a restrição invertida: desenhe para agentes primeiro, aceite que humanos vão continuar lendo o código e veja o que cai.

Princípio 1: superfície pequena e regular

A maioria das linguagens de programação cresce com o tempo. Cada nova versão acrescenta uma pequena conveniência — um operador novo, uma forma sintática nova, um jeito novo de expressar algo que a linguagem já cobria. Cada adição se paga em ergonomia humana. Cada adição custa caro para um agente: mais uma variante para aprender, mais um jeito de errar.

Zero mantém a superfície deliberadamente minúscula:

• Uma forma de criar ligação (let).
• Uma forma de função (fun, opcionalmente pub).
• Um loop hoje (while).
• Uma forma de modelar tipos produto (shape).
• Uma forma de modelar tipos soma com payload (choice).
• Uma forma de modelar somas rotuladas (enum).
• Uma construção de pattern matching (match).

Sem sobrecarga de operadores, sem decoradores, sem macros, sem conversões implícitas, sem coerção de truthiness, sem ternário. Cada ausência é uma funcionalidade: remove um lugar onde um agente poderia escolher a variante errada.

O custo é o óbvio — menos funcionalidades de conveniência. O benefício é que um agente aprendendo Zero durante uma sessão consegue convergir para a sintaxe certa sem precisar pesar sete quase-equivalentes.

Princípio 2: efeitos explícitos

A maioria das linguagens permite que qualquer função, em qualquer lugar, faça I/O. console.log em JavaScript, printf em C, print em Python. A assinatura da função não dá pista nenhuma sobre se ela pode escrever em arquivo ou bater na rede. O único jeito de saber é ler o corpo, recursivamente.

Zero adota a posição oposta: todo efeito que uma função tem aparece na assinatura dela.

• I/O é controlado pela capacidade World. Uma função que não recebe World não consegue fazer I/O. O sistema de tipos garante isso.
• Falha é controlada por raises e check. Uma função que pode falhar diz isso na assinatura. Todo chamador reconhece com check ou outra construção explícita.

Só pela assinatura de uma função você pode responder duas perguntas com as quais um agente (ou um analisador estático, ou um revisor humano) se importa profundamente:

• "Isso pode tocar o mundo externo?" — sim, se e somente se World aparecer.
• "Isso pode falhar?" — sim, se e somente se raises aparecer.

Essa propriedade não existe nas linguagens mainstream, e não é uma propriedade pequena de ter.

O custo é encanar parâmetros. O valor World é passado para onde I/O for necessário; a cláusula raises se repete por onde erros fluem. Zero aceita isso como o preço da propriedade.

Princípio 3: ferramentas determinísticas

O terceiro princípio é o mais diretamente voltado para agentes: toda saída que o compilador produz é dado estruturado.

Diagnósticos em JSON são o exemplo principal:

{
    "code": "NAM003",
    "message": "unknown identifier",
    "line": 3,
    "repair": { "id": "declare-missing-symbol" }
}

Três propriedades tornam isso diferente de um erro de compilador comum:

1. Códigos estáveis. NAM003 significa a mesma coisa hoje e amanhã, independente de como a mensagem voltada para humanos é redigida.
2. Planos de reparo estruturados. Quando o compilador acha que sabe corrigir um diagnóstico, ele emite um plano como dado — uma lista de edições, não uma sugestão em inglês.
3. Múltiplos canais estruturados. Diagnósticos, grafos de dependência, relatórios de tamanho e explicações vivem todos atrás de modos --json.

A ideia toda é que uma ferramenta — agente ou não — nunca precise interpretar inglês para agir na saída do compilador. Procurar um código estável é exato; interpretar prosa é nebuloso. Zero trata o primeiro como contrato e o segundo como conveniência para humanos.

Princípio 4: uma biblioteca que vive na linguagem

Agentes são bons em escrever código que segue padrões já existentes. São piores em escolher a dependência externa certa num mar de opções, integrá-la corretamente e acompanhar quando a API dela muda. Cada dependência externa é atrito.

O design do Zero empurra capacidades para a biblioteca padrão — documentadas explicitamente, coerentes e estáveis à medida que a linguagem se estabiliza. A meta é que um programa Zero raramente precise sair da distribuição padrão para trabalho rotineiro. Isso mantém limitada a superfície que um agente precisa raciocinar sobre.

Hoje, isso é uma aspiração, não um estado terminado. A biblioteca padrão pré-1.0 é real, mas ainda está crescendo. O princípio é a direção, não o destino.

O que Zero abre mão

Toda decisão de design custa algo. Trade-offs honestos do Zero:

• Verbosidade em vez de concisão. Funções puras não precisam de World. Funções que fazem I/O precisam. Erros aparecem nas assinaturas. O resultado é mais anotações do que num equivalente em JavaScript ou Python.
• Explícito em vez de mágico. Sem metaprogramação reflexiva, sem decoradores que envolvem comportamento em silêncio, sem globais implícitos. Coisas que parecem "simplesmente funcionar" em linguagens dinâmicas precisam ser cabeadas à mão.
• Estático em vez de dinâmico. Tipos são obrigatórios em parâmetros, retornos e campos de shape. O compilador faz muito trabalho; o custo é que toda assinatura precisa ser escrita por um autor (ou gerador).
• Estabilidade em vez de ritmo de mudança. A linguagem é pré-1.0 e está mudando rápido, mas a intenção do design é congelar a superfície depois que assentar. O custo é que adicionar uma nova conveniência esperta depois fica mais difícil, porque a régua para adições é "isso ajuda mais um agente do que custa para ele?".

Se essas trocas valem a pena depende do que você está otimizando. Se você é um humano escrevendo um script único, o atrito é real e os benefícios para agentes são abstratos. Se você opera um agente que produz milhares de pequenos programas por dia, o atrito retorna o investimento muitas vezes.

O que Zero não está tentando ser

Algumas afirmações negativas que vale deixar explícitas:

• Não é "o futuro de toda programação". Zero é uma hipótese, não um manifesto. A hipótese é que restrições agent-first produzem uma linguagem útil. Se as linguagens mainstream deveriam adotar essas restrições é uma conversa separada, mais longa.
• Não é uma funcionalidade da plataforma de deploy da Vercel. Apesar de vir da Vercel Labs, Zero não está atrelado ao Next.js nem à hospedagem Vercel. É uma linguagem de sistemas independente.
• Não é um substituto para Rust, Go ou Zig em produção. Pré-1.0. Experimental. Use para aprender e dar feedback; não coloque software de cliente no ar com ela ainda.
• Não está finalizado. Pedaços da biblioteca padrão, sintaxe para mutabilidade, formas de tratamento de erro e restrições de generics podem todos mudar antes da 1.0.

O que é interessante mesmo se você não usar

Mesmo que você nunca escreva uma linha de Zero, o experimento é informativo:

• É o exemplo mais claro de um sistema de efeitos baseado em capacidades, funcionando, em uma linguagem de sistemas pequena. O modelo mental — passe a permissão, veja o efeito na assinatura — é portável.
• A história dos diagnósticos é o que todo compilador deveria estar fazendo nos últimos dez anos. Saída estruturada vence prosa toda vez, e o compromisso do Zero com códigos estáveis é algo que outras ferramentas poderiam adotar sem mudar de linguagem.
• O princípio de "uma forma de fazer cada coisa, superfície deliberadamente pequena" vai contra o que costuma ser feito no design de linguagens. Observar onde esse princípio ajuda e onde aperta é útil independente da linguagem que você vai escrever amanhã.

Onde ler em seguida

Se você terminou o resto desta documentação, as leituras mais úteis a seguir são externas:

• O repositório do Zero em github.com/vercel-labs/zero — exemplos, código-fonte e AGENTS.md com a declaração de intenção dos próprios mantenedores.
• O site oficial em zerolang.ai — instruções iniciais e a introdução canônica.

Ambos estão evoluindo. O que você encontrar lá vai estar mais atual do que qualquer tutorial de terceiros. Os princípios desta página são a parte que muda devagar; a sintaxe ao redor deles vai mexer enquanto a linguagem assenta.