Diseño agent-first: por qué existe Zero y qué intercambia

La pregunta que se hace Zero

La premisa detrás de Zero es simple: cuando un agente de IA — no solo un humano — está leyendo, escribiendo y reparando código, ¿cómo quiere ser el lenguaje en sí mismo?

Los lenguajes existentes se diseñaron mucho antes de que los agentes pudieran escribir código. Sus prioridades — sintaxis breve, modismos expresivos, astucias de biblioteca — tienen sentido para humanos tecleando en editores. Toleran la ambigüedad y las conversiones implícitas porque los humanos son buenos rellenando huecos. Los agentes no lo son. Generan texto exacto a partir de distribuciones de probabilidad y pagan por cada borde difuso del lenguaje con un token equivocado en algún lado.

Zero empieza de nuevo con la restricción al revés: diseñar para agentes primero, aceptar que los humanos también van a leer el código y ver qué sale.

Principio 1: una superficie pequeña y regular

La mayoría de los lenguajes de programación crecen con el tiempo. Cada nueva versión añade una pequeña comodidad — un operador nuevo, una forma sintáctica nueva, una manera nueva de expresar algo que el lenguaje ya cubría. Cada adición se justifica por la ergonomía humana. Cada adición cuesta a un agente: otra variante que aprender, otra forma de equivocarse.

Zero mantiene deliberadamente la superficie diminuta:

• Una forma de ligadura (let).
• Una forma de función (fun, opcionalmente pub).
• Un bucle hoy (while).
• Una forma de modelar tipos producto (shape).
• Una forma de modelar tipos suma con payload (choice).
• Una forma de modelar sumas etiquetadas (enum).
• Un constructo de pattern matching (match).

Sin sobrecarga de operadores, sin decoradores, sin macros, sin conversiones implícitas, sin coerción a verdadero/falso, sin ternario. Cada ausencia es una funcionalidad: elimina un sitio donde un agente podría elegir la variante equivocada.

El coste es el obvio — menos funcionalidades de conveniencia. El beneficio es que un agente aprendiendo Zero durante una sesión puede converger en la sintaxis correcta sin tener que sopesar siete cuasi-equivalentes.

Principio 2: efectos explícitos

La mayoría de los lenguajes permiten que cualquier función, en cualquier sitio, haga E/S. console.log en JavaScript, printf en C, print en Python. La firma de la función no da pista alguna sobre si podría escribir en un archivo o hacer una llamada de red. La única forma de saberlo es leer el cuerpo, recursivamente.

Zero adopta la posición opuesta: cada efecto que tiene una función aparece en su firma.

• La E/S está controlada por la capacidad World. Una función que no recibe World no puede hacer E/S. El sistema de tipos lo garantiza.
• Los fallos están controlados por raises y check. Una función que puede fallar lo dice en su firma. Cada llamador lo reconoce con check u otro constructo explícito.

Solo con la firma de una función puedes responder a dos preguntas que importan profundamente a un agente (o a un analizador estático, o a un revisor humano):

• "¿Podría esto tocar el mundo exterior?" — sí solo si aparece World.
• "¿Podría esto fallar?" — sí solo si aparece raises.

Esa propiedad no existe en los lenguajes mainstream, y no es ninguna tontería tenerla.

El coste es el cableado de parámetros. El valor World se va pasando allá donde se necesita E/S; la cláusula raises se repite donde fluyen los errores. Zero acepta eso como el precio de la propiedad.

Principio 3: herramientas deterministas

El tercer principio es el más directamente orientado a agentes: cada salida que produce el compilador son datos estructurados.

Los diagnósticos JSON son el ejemplo estrella:

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

Tres propiedades hacen esto distinto de un error de compilador normal:

1. Códigos estables. NAM003 significa lo mismo hoy y mañana, sin importar cómo se redacte el mensaje para humanos.
2. Planes de reparación estructurados. Cuando el compilador cree que sabe cómo arreglar un diagnóstico, emite un plan como datos — una lista de ediciones, no una sugerencia en inglés.
3. Varios canales estructurados. Diagnósticos, grafos de dependencias, informes de tamaño y explicaciones viven todos detrás de modos --json.

El objetivo es que una herramienta — agente o lo que sea — nunca tenga que parsear inglés para actuar sobre la salida del compilador. Buscar un código estable es exacto; parsear prosa es difuso. Zero trata lo primero como el contrato y lo segundo como una comodidad para humanos.

Principio 4: una biblioteca que vive en el lenguaje

Los agentes son buenos escribiendo código que sigue patrones existentes. Son peores escogiendo la dependencia externa adecuada en un mar de opciones, integrándola correctamente y siguiendo cuándo su API deriva. Cada dependencia externa es fricción.

El diseño de Zero empuja capacidades a la biblioteca estándar — documentadas explícitamente, coherentes y estables a medida que el lenguaje se estabiliza. La meta es que un programa de Zero rara vez necesite salir de la distribución estándar para trabajo de rutina. Eso mantiene acotada la superficie sobre la que un agente debe razonar.

Es una aspiración más que un estado finalizado hoy. La biblioteca estándar pre-1.0 es real pero sigue creciendo. El principio es la dirección, no el destino.

Lo que Zero intercambia

Cada decisión de diseño cuesta algo. Las concesiones honestas que hace Zero:

• Verbosidad sobre concisión. Las funciones puras no reciben World. Las que pueden hacer E/S sí. Los errores aparecen en las firmas. El resultado es más anotaciones que el equivalente en JavaScript o Python.
• Explícito sobre mágico. Sin metaprogramación reflexiva, sin decoradores que envuelven comportamiento en silencio, sin globales implícitas. Cosas que parece que "simplemente funcionan" en los lenguajes dinámicos hay que cablearlas a mano.
• Estático sobre dinámico. Se exigen tipos en parámetros, valores de retorno y campos de shape. El compilador hace mucho trabajo; el coste es que cada firma es algo que un autor (o generador) tiene que escribir.
• Estabilidad sobre ritmo de cambio. El lenguaje es pre-1.0 y cambia rápido, pero la intención de diseño es fijar la superficie una vez se asiente. El coste es que añadir una nueva funcionalidad de conveniencia luego se vuelve más difícil, porque el listón para añadidos es "¿ayuda esto a un agente más de lo que le cuesta?"

Si las concesiones valen la pena depende de qué optimices. Si eres una persona escribiendo un script puntual, la fricción es real y los beneficios para agentes son abstractos. Si operas un agente que produce miles de programas pequeños al día, la fricción se amortiza muchas veces.

Lo que Zero no intenta ser

Algunas afirmaciones negativas que conviene hacer explícitas:

• No es "el futuro de toda la programación". Zero es una hipótesis, no un manifiesto. La hipótesis es que las restricciones agent-first producen un lenguaje útil. Si los lenguajes mainstream deberían adoptar esas restricciones es una conversación distinta y más larga.
• No es una funcionalidad de la plataforma de despliegue de Vercel. Aunque venga de Vercel Labs, Zero no está atado a Next.js ni al hosting de Vercel. Es un lenguaje de sistemas independiente.
• No es un reemplazo para Rust, Go o Zig en producción. Pre-1.0. Experimental. Úsalo para aprender y dar feedback; no envíes software a clientes con él aún.
• No está terminado. Trozos de la biblioteca estándar, la sintaxis para la mutabilidad, las formas de manejo de errores y las restricciones en genéricos pueden moverse antes de la 1.0.

Lo que es interesante incluso si no lo usas

Aunque nunca escribas una línea de Zero, el experimento es informativo:

• Es el ejemplo más claro de un sistema de efectos basado en capacidades real, funcional y en un lenguaje de sistemas pequeño. El modelo mental — pasa el permiso, mira el efecto en la firma — es portátil.
• La historia de diagnósticos es lo que cada compilador debería haber estado haciendo durante la última década. La salida estructurada le gana a la prosa siempre, y el compromiso de Zero con códigos estables es algo que otras herramientas podrían adoptar sin cambios de lenguaje.
• El principio de "una forma de hacer cada cosa, superficie deliberadamente pequeña" va a contracorriente del diseño de lenguajes tal y como se practica habitualmente. Observar dónde ayuda ese principio y dónde aprieta es útil sea cual sea el lenguaje que escribas mañana.

Dónde leer a continuación

Si ya has terminado el resto de estas páginas, las próximas lecturas más útiles son externas:

• El repositorio de Zero en github.com/vercel-labs/zero — ejemplos, fuentes y AGENTS.md con la propia declaración de intenciones del equipo.
• El sitio oficial en zerolang.ai — instrucciones de primeros pasos y la introducción canónica.

Ambos evolucionan. Lo que encuentres allí será más actual que cualquier tutorial de terceros. Los principios de esta página son la parte que se mueve despacio; la sintaxis a su alrededor irá cambiando mientras el lenguaje se asienta.