L'ingénierie robots-first

Le logiciel a été construit pour les gens. Le système de fichiers. Le terminal. JSON. Git. La revue de code. Tout ça a été façonné par ce qu'un humain au clavier peut gérer.

Et si tu jetais tout ça et recommençais à zéro pour les machines ?

C'est ça l'ingénierie robots-first. Et c'est la direction que prend déjà le développement logiciel autonome.

Le développement n'est plus de l'ingénierie

Voilà le clivage qui recadre tout le métier :

Le développement logiciel est maintenant du travail machine. Écrire du code. Lancer des tests. Committer. Les agents s'en chargent déjà. Appelle ça environ 10 € de l'heure, sans sommeil, sans pauses.

L'ingénierie logicielle est la couche humaine qui maintient cette machine fiable. Des rails. Des domaines de panne. Des boucles de vérification. Du back-pressure. Toute la plomberie dans laquelle l'agent tourne.

Ton boulot a changé sous tes pieds. Tu n'embarques plus de cargaison sur le navire. Le conteneur d'expédition est arrivé. Maintenant tu pilotes la locomotive et tu la gardes sur les rails.

Ce basculement mental est ce qui sépare les ingénieurs qui prospèrent dans ce nouveau monde de ceux qui s'y noient.

Le tournevis avant la perceuse

L'ingénierie autonome a des étapes. Saute-les et tu échoues.

Le tournevis. Travail manuel. Tu écris les specs à la main. Tu gères le contexte avec soin. Tu pilotes toi-même la recherche et les liens. Le but c'est d'apprendre comment le système reste sur ses rails avant de lui donner les clés.

La perceuse. À plein régime. Des boucles Ralph qui tournent sans surveillance. Des flottes orchestrées. Des agents parallèles. Des builds de nuit qui shippent des fonctionnalités au matin.

La plupart des ingénieurs font la même erreur. Ils attrapent la perceuse avant de toucher au tournevis.

Plonge direct dans l'automatisation complète sans les fondamentaux et la sortie est catastrophique. Le tournevis, c'est ce qui t'apprend ce dont la perceuse a besoin.

Fais d'abord le manuel. Comprends pourquoi les choses tiennent ensemble. Ensuite attrape les outils électriques.

Loom : une stack conçue pour les agents

Loom pointe vers l'étape suivante : un environnement logiciel qui se reconstruit autour des agents plutôt que des humains.

La règle de conception est stricte. Pour chaque élément de la stack, pose trois questions :

1. Est-ce que ça a été conçu pour les humains ?
2. Si oui, peut-on s'en passer ?
3. Si on s'en passe, qu'est-ce qu'on perd et comment le remplacer ?

Quelques hypothèses qui ne passent pas le test :

• L'espace utilisateur Unix et les conventions TTY. Les agents ne sont pas assis devant des terminaux. Est-ce que tout ça s'applique encore ?
• Les rituels et processus Agile. Les sprints existent parce que les humains planifient en semaines. Les agents ne font pas ça.
• JSON comme format de données. Chaque guillemet et chaque accolade brûle des tokens. JSON est-il le bon format ?
• Les workflows de revue de code. Une boucle de vérification peut-elle remplacer une file de revue ?

Les pièces de Loom incluent :

• Hébergement de code, style GitHub, mais conçu pour les agents
• Contrôle de source via JJ, qui fonctionne mieux avec les workflows machine
• Sandboxes distants style Codespace
• "Alliage" multi-LLM, faire tourner plusieurs providers ensemble
• Patterns de messages acteur et pub-sub
• Chaînage dans le style d'Erlang/OTP

L'idée centrale : des boucles composées en chaînes. Des boucles dans des boucles dans des boucles. Chacune serrée et focalisée. L'ensemble se comporte comme un seul système réactif.

Les fenêtres de contexte ne sont que des tableaux

Un principe central pour penser robots-first :

Une fenêtre de contexte est un tableau. Moins tu remplis ce tableau, moins il glisse, et meilleure est la sortie.

Empile plus de contexte et tu obtiens :

• Plus de glissement
• Une compaction plus précoce
• Une compaction qui perd des données
• Des ancres manquantes
• De la dérive

C'est pourquoi les boucles Ralph fonctionnent du tout. La boucle est conçue pour faire tourner le tableau de façon déterministe. Garde le tableau léger. Évite la compaction. Tiens le pin.

Le pin, c'est ta spec. Le point de référence stable auquel l'agent revient sans cesse. Chaque itération le relit. Sans le pin, les agents commencent à inventer.

Les specs comme tables de correspondance

Les specs robots-first ne sont pas de la doc. Ce sont des tables de correspondance optimisées pour la recherche par agent.

Une bonne spec ressemble à ça :

## User Authentication
 
**Also known as**: login, sign-in, auth, session management, identity
 
**Related files**: src/auth/, src/middleware/session.ts
 
**Key patterns**: JWT tokens, refresh rotation, secure cookies
 
**What NOT to do**: Don't implement custom crypto, don't store passwords in plain text

Le champ "also known as" augmente les taux de correspondance dans les recherches. Quand l'agent grep pour "login", il atterrit sur la spec auth. Plus de synonymes, plus de correspondances. Plus de correspondances, moins d'invention.

La spec devient le cadre de référence pour toute la fonctionnalité. Les agents cherchent ce qui existe au lieu de deviner ce qui pourrait exister.

Les liens battent les formats sophistiqués

Beaucoup d'ingénieurs sur-construisent leurs plans. Des schémas JSON imbriqués. Des hiérarchies de tâches. Un formatage élaboré.

La vision robots-first : des liens serrés gagnent sur les formats sophistiqués.

Ce qui marche vraiment :

• Des points concis avec des références concrètes
• Cite la section exacte de la spec
• Pointe vers le fichier exact
• Référence des hunks spécifiques (Claude lit les fichiers en hunks)

## Implementation Plan
 
- [ ] Add JWT validation middleware
 
  - Spec: auth-spec.md#token-validation
  - File: src/middleware/auth.ts (lines 45-60)
  - Pattern: Follow existing rate-limit middleware structure
 
- [ ] Create refresh token endpoint
  - Spec: auth-spec.md#refresh-flow
  - File: src/routes/auth/refresh.ts (new file)
  - Pattern: Match existing /auth/login endpoint structure

Maintenant l'agent cherche avec précision. Il trouve les bons hunks. Il copie le pattern déjà dans le repo. Il arrête d'inventer.

La stack robots-first

C'est là que l'idée devient radicale. Possède toute la stack et tu peux l'optimiser pour les machines :

Sérialisation. JSON n'est pas efficace en tokens. Chaque guillemet, chaque accolade, chaque virgule coûte des tokens. Un format binaire, ou un format texte conçu pour les agents, pourrait réduire ce coût drastiquement.

Espace utilisateur. Pourquoi un agent devrait-il hériter de l'espace utilisateur Unix ? TTY a été construit pour les humains aux terminaux. Les agents n'ont pas besoin d'émulation de terminal du tout.

Garbage collection. Qu'est-ce que la gestion mémoire veut dire quand ton "processus" est un appel API stateless ? Les hypothèses habituelles cessent de tenir.

Passage de messages. Erlang et OTP reviennent. Acteurs. Arbres de supervision. Let-it-crash. Les patterns s'appliquent proprement à l'orchestration des agents.

Si tu possèdes la stack, tu peux :

• Optimiser la tokenisation
• Réduire les coûts drastiquement
• Construire des pipes réactifs plus rapides
• Tourner moins cher que l'équipe d'à côté

C'est du territoire d'avantage concurrentiel.

Les Weavers : des agents sans humain dans la boucle

La destination de l'ingénierie robots-first a un nom : les Weavers.

Un Weaver est un agent autonome qui :

• Shippe du code derrière des feature flags
• Déploie sans revue de code
• Surveille les analytics produit
• Décide si un changement a corrigé les erreurs
• Décide s'il faut pousser plus loin
• Itère par lui-même

Personne n'est au-dessus de lui. Pleine autonomie.

Effrayant, oui. C'est la bonne première réaction. Maintenant prends un moment pour y réfléchir.

Chaque objection que tu peux lister est un problème d'ingénierie qui attend d'être construit. Et si ça casse la prod ? Ingénie un rollback. Et s'il prend une mauvaise décision ? Ingénie une boucle de vérification. Et s'il sort des rails ? Ingénie du back-pressure.

Le nouveau boulot de l'ingénierie logicielle : ingénier les problèmes pour les éliminer.

Note tes objections. Puis construis les systèmes qui les neutralisent. C'est le travail maintenant.

L'ingénierie du back-pressure

Les boucles autonomes génèrent des modes de défaillance. Ton boulot devient poser les rails :

• Ajouter des contraintes dans la spec
• Serrer les liens du plan
• Améliorer les guides de recherche
• Élever les gates (tests, linting, formatage, scans de sécurité)

Quand les sorties dérapent, la correction est une autre boucle :

• Boucle de refactoring
• Boucle de conventions
• Boucle de sécurité
• Boucle i18n

Le back-pressure garde le générateur sur les rails. La locomotive reste en ligne parce que tu as ingénié la ligne.

L'échelle de montée en puissance

L'ingénierie robots-first monte par composition. Quatre échelons.

Niveau 1 : Fondamentaux manuels

• Génère les specs par conversation
• Serre les contraintes à la main
• Garde le contexte aussi petit que possible
• Reste au clavier

Niveau 2 : Boucle sans surveillance

• Des runs while true
• Un objectif par itération
• Tests automatisés plus commit et push
• État checkpointé

Niveau 3 : Orchestration multi-boucles

• Plusieurs boucles qui tournent en même temps
• Des chaînes réactives câblées entre elles
• Patterns acteur et pub-sub

Niveau 4 : Systèmes produit autonomes

• Des Weavers qui shippent des fonctionnalités
• Les analytics pilotent les décisions
• Pas de file de revue
• Autonomie produit de bout en bout

Chaque échelon repose sur celui du dessous. Sauter au niveau 4 sans les niveaux 1 à 3 ne fonctionne pas.

Le changement de mindset

L'ingénierie robots-first nécessite une autre tête :

Ancien mindset : "Comment j'écris ce code ?" Nouveau mindset : "Comment je conçois un système qui écrit ce code de façon fiable ?"

Ancien mindset : "Comment je révise cette PR ?" Nouveau mindset : "Comment je construis une vérification qui rend la revue inutile ?"

Ancien mindset : "Comment je débogue ce problème ?" Nouveau mindset : "Comment j'ingénie des boucles de feedback qui arrêtent cette classe de bug ?"

Tu n'écris plus du code. Tu conçois des systèmes autonomes. Tu es ingénieur en chef de locomotive, pas docker.

Commencer aujourd'hui

Tu n'as pas besoin de Loom pour commencer à penser robots-first. Commence par des questions :

1. Quelles hypothèses humaines est-ce que j'intègre ? Audite tes workflows. Quelles étapes n'existent que parce qu'un humain les faisait ?

2. Qu'est-ce qui pourrait devenir une table de correspondance ? Tes specs. Tes patterns. Tes conventions. Tu peux les façonner pour qu'un agent puisse les rechercher ?

3. Où les liens sont-ils faibles ? La plupart des plans pointent vers les choses de façon vague. Tu peux coder en dur les chemins de fichiers, les plages de lignes et les hunks à la place ?

4. Où est le back-pressure ? Quand l'agent part en vrille, qu'est-ce qui l'attrape ? Construis ces freins avant d'en avoir besoin.

5. Qu'est-ce que la pleine autonomie nécessiterait ? Imagine que tu sors de la boucle. Qu'est-ce qui s'effondre ? Ces défaillances sont tes prochaines priorités d'ingénierie.

Où ça mène

On est en 2026. Accroche-toi.

L'écart entre les équipes qui peuvent lancer des boucles autonomes fiables et celles qui ne peuvent pas se creuse vite. L'économie est brutale. Le développement automatisé coûte environ 10 € de l'heure. Les développeurs humains coûtent 100 € et plus.

Les équipes qui construisent robots-first shippent à une cadence entièrement différente. Elles tournent moins cher. Elles itèrent plus vite. Leurs améliorations s'accumulent pendant qu'elles dorment.

Les ingénieurs coincés dans des workflows human-first vont prendre du retard. Pas parce que leurs compétences sont mauvaises. Parce que leur cible d'optimisation est mauvaise.

L'ingénierie logicielle vient de changer. Elle a changé avant. Elle changera encore.

Les ingénieurs qui s'en sortent sont ceux qui voient chaque changement comme une autre chance de concevoir à partir des premiers principes. Ça a toujours été vrai. C'est juste plus difficile à ignorer maintenant.

Commence avec le tournevis. Mets les fondamentaux au point. Ensuite attrape la perceuse.

La locomotive t'attend.

Lectures associées

• Technique Ralph Wiggum. La fondation pour les boucles autonomes
• Ingénierie par threads. Un cadre pour scaler le travail avec les agents
• Boucles d'agents autonomes. Ralph plus les threads ensemble
• Boucles de feedback. Des patterns de vérification qui maintiennent les boucles honnêtes
• Context engineering. Gérer le tableau