Conception agent-first : pourquoi Zero existe et ce qu'il échange

La question que pose Zero

La prémisse derrière Zero est simple : quand un agent IA — pas seulement un humain — lit, écrit et répare du code, à quoi le langage lui-même veut-il ressembler ?

Les langages existants ont été conçus bien avant que les agents ne puissent écrire du code. Leurs priorités — syntaxe concise, idiomes expressifs, astuces de bibliothèque — ont du sens pour des humains qui tapent dans un éditeur. Ils tolèrent l'ambiguïté et les conversions implicites parce que les humains comblent les vides. Pas les agents. Ils génèrent du texte exact à partir de distributions de probabilités, et chaque arête floue du langage se paie en un mauvais token quelque part en aval.

Zero recommence avec la contrainte inversée : concevoir pour les agents d'abord, accepter que les humains liront quand même le code, et voir ce qui en sort.

Principe 1 : une surface petite et régulière

La plupart des langages grossissent avec le temps. Chaque nouvelle version ajoute une petite commodité — un nouvel opérateur, une nouvelle forme syntaxique, une nouvelle façon d'exprimer quelque chose que le langage couvrait déjà. Chaque ajout se paie en ergonomie humaine. Chaque ajout coûte à un agent : une autre variante à apprendre, une autre façon de se tromper.

Zero garde délibérément la surface minuscule :

• Une forme de liaison (let).
• Une forme de fonction (fun, optionnellement pub).
• Une boucle aujourd'hui (while).
• Une façon de modéliser les types produit (shape).
• Une façon de modéliser les types somme avec charges utiles (choice).
• Une façon de modéliser les sommes étiquetées (enum).
• Une construction de filtrage par motifs (match).

Pas de surcharge d'opérateurs, pas de décorateurs, pas de macros, pas de conversions implicites, pas de coercition vers la vérité, pas de ternaire. Chaque absence est une fonctionnalité : elle supprime un endroit où un agent pourrait choisir la mauvaise variante.

Le coût est évident — moins de fonctionnalités de confort. Le bénéfice, c'est qu'un agent qui apprend Zero le temps d'une session peut converger sur la bonne syntaxe sans avoir à peser sept quasi-équivalents.

Principe 2 : des effets explicites

La plupart des langages laissent n'importe quelle fonction, n'importe où, faire des E/S. console.log en JavaScript, printf en C, print en Python. La signature de la fonction ne donne aucun indice quant à savoir si elle pourrait écrire dans un fichier ou taper sur le réseau. Le seul moyen de le savoir, c'est de lire le corps, récursivement.

Zero adopte la position opposée : chaque effet d'une fonction apparaît dans sa signature.

• Les E/S sont gardées par la capacité World. Une fonction qui ne prend pas World ne peut pas faire d'E/S. Le système de types impose ça.
• L'échec est gardé par raises et check. Une fonction qui peut échouer le dit dans sa signature. Chaque appelant le reconnaît avec check ou une autre construction explicite.

Depuis la seule signature d'une fonction, vous pouvez répondre à deux questions qui tiennent à cœur à un agent (ou à un analyseur statique, ou à un relecteur humain) :

• « Est-ce que ça pourrait toucher au monde extérieur ? » — oui ssi World apparaît.
• « Est-ce que ça peut échouer ? » — oui ssi raises apparaît.

Cette propriété n'existe pas dans les langages grand public, et elle n'est pas négligeable.

Le coût, c'est la plomberie de paramètres. La valeur World est passée partout où des E/S sont nécessaires ; la clause raises est répétée partout où les erreurs circulent. Zero accepte ça comme le prix de la propriété.

Principe 3 : outillage déterministe

Le troisième principe est celui qui vise le plus directement les agents : chaque sortie produite par le compilateur est de la donnée structurée.

Les diagnostics JSON sont l'exemple phare :

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

Trois propriétés rendent ça différent d'une erreur de compilation classique :

1. Codes stables. NAM003 signifie la même chose aujourd'hui et demain, peu importe la formulation du message destiné aux humains.
2. Plans de réparation structurés. Quand le compilateur estime savoir comment corriger un diagnostic, il émet un plan sous forme de données — une liste d'éditions, pas une suggestion en anglais.
3. Plusieurs canaux structurés. Diagnostics, graphes de dépendances, rapports de taille et explications vivent tous derrière des modes --json.

Tout l'intérêt, c'est qu'un outil — agent ou autre — n'ait jamais à parser de l'anglais pour agir sur la sortie du compilateur. Consulter un code stable est exact ; parser de la prose est flou. Zero traite le premier comme le contrat et le second comme un confort pour les humains.

Principe 4 : une bibliothèque qui vit dans le langage

Les agents savent bien écrire du code qui suit des motifs existants. Ils sont moins bons pour choisir la bonne dépendance externe parmi une mer d'options, l'intégrer correctement, et suivre la dérive de son API. Chaque dépendance externe est de la friction.

La conception de Zero pousse les capacités dans la bibliothèque standard — explicitement documentées, cohérentes, et stables à mesure que le langage se stabilise. L'objectif est qu'un programme Zero ait rarement besoin de sortir de la distribution standard pour le travail courant. Ça garde bornée la surface sur laquelle un agent doit raisonner.

C'est une aspiration plutôt qu'un état achevé aujourd'hui. La bibliothèque standard pré-1.0 est réelle mais encore en croissance. Le principe est la direction, pas la destination.

Ce que Zero échange

Chaque choix de conception coûte quelque chose. Compromis honnêtes que Zero fait :

• Verbosité contre concision. Les fonctions pures n'ont pas besoin de World. Les fonctions à E/S, si. Les erreurs apparaissent sur les signatures. Le résultat est plus d'annotations qu'un équivalent JavaScript ou Python.
• Explicite contre magique. Pas de métaprogrammation réflexive, pas de décorateurs qui emballent silencieusement un comportement, pas de globales implicites. Ce qui paraît « marcher tout seul » dans les langages dynamiques doit être câblé à la main.
• Statique contre dynamique. Les types sont requis sur les paramètres, les valeurs de retour, et les champs de shape. Le compilateur fait beaucoup de travail ; le coût, c'est que chaque signature est quelque chose qu'un auteur (ou un générateur) doit écrire.
• Stabilité contre vitesse de changement. Le langage est pré-1.0 et change vite, mais l'intention de conception est de figer la surface une fois qu'elle se sera posée. Le coût, c'est qu'ajouter une nouvelle fonctionnalité de confort astucieuse plus tard devient plus difficile, parce que la barre pour les ajouts est « est-ce que ça aide un agent plus que ça ne lui coûte ? »

Que les compromis en valent la peine dépend de ce que vous optimisez. Si vous êtes un humain qui écrit un script jetable, la friction est réelle et les bénéfices pour les agents sont abstraits. Si vous opérez un agent qui produit des milliers de petits programmes par jour, la friction se rembourse plusieurs fois.

Ce que Zero n'essaie pas d'être

Quelques affirmations négatives qui valent la peine d'être explicites :

• Pas « l'avenir de toute la programmation ». Zero est une hypothèse, pas un manifeste. L'hypothèse, c'est que des contraintes agent-first produisent un langage utile. Que les langages grand public devraient adopter ces contraintes est une conversation séparée et plus longue.
• Pas une fonctionnalité de la plateforme de déploiement Vercel. Même s'il vient de Vercel Labs, Zero n'est pas lié à Next.js ni à l'hébergement Vercel. C'est un langage système autonome.
• Pas un remplaçant pour Rust, Go ou Zig en production. Pré-1.0. Expérimental. Utilisez-le pour apprendre et donner du feedback ; ne livrez pas encore de logiciels destinés à des utilisateurs finaux avec.
• Pas terminé. Des pièces de la bibliothèque standard, la syntaxe de la mutabilité, les formes de gestion d'erreurs et les contraintes sur les génériques pourraient toutes bouger avant la 1.0.

Ce qui est intéressant même si vous ne l'utilisez pas

Même si vous n'écrivez jamais une ligne de Zero, l'expérience est instructive :

• C'est l'exemple le plus clair d'un système d'effets à base de capacités réel et fonctionnel dans un petit langage système. Le modèle mental — passer la permission, voir l'effet sur la signature — est portable.
• L'histoire des diagnostics est ce que chaque compilateur aurait dû faire ces dix dernières années. La sortie structurée bat la prose à chaque fois, et l'engagement de Zero envers des codes stables est quelque chose que d'autres outils pourraient adopter sans aucun changement de langage.
• Le principe « une seule façon de faire chaque chose, surface délibérément petite » va à rebours de la conception de langage telle qu'on la pratique habituellement. Voir où ce principe aide et où il pince est utile peu importe le langage dans lequel vous écrirez demain.

Où lire ensuite

Si vous avez fini le reste de ces docs, les lectures suivantes les plus utiles sont externes :

• Le dépôt Zero sur github.com/vercel-labs/zero — exemples, code source et AGENTS.md pour la déclaration d'intention des mainteneurs.
• Le site officiel sur zerolang.ai — instructions pour démarrer et introduction canonique.

Les deux évoluent. Ce que vous y trouverez sera plus à jour que n'importe quel tutoriel tiers. Les principes dans ce document sont la partie qui bouge lentement ; la syntaxe autour d'eux bougera tant que le langage se posera.