Construire un moteur ML local-first en Rust en solo
Le parcours technique derrière Brainlet — pourquoi Rust, pourquoi le local-first, pourquoi des modèles spécialisés plutôt que des LLM plus grands.
Brainlet a commencé comme un petit outil pour un seul développeur.
Le problème était simple : chaque assistant de code pouvait lire des fichiers, mais aucun ne comprenait le projet. Ils pouvaient trouver du texte correspondant. Ils pouvaient récupérer du code voisin dans le contexte. Ils pouvaient résumer ce qui était déjà devant eux. Mais ils rataient encore l'architecture.
La réponse n'était pas une fenêtre de contexte plus grande. C'était un autre type de contexte.
C'est devenu la contrainte de conception de Brainlet : construire un petit moteur qui apprend la forme d'un codebase avant qu'un LLM soit invité à agir dessus. L'objectif n'est pas de remplacer le modèle. L'objectif est d'arrêter de gaspiller le raisonnement du modèle à reconstruire le contexte projet depuis des fichiers dispersés.
Pourquoi Rust
Le moteur doit indexer de grands dépôts, parser de nombreux langages, entraîner des modèles légers et répondre rapidement sur une machine locale. Rust correspond bien à cette contrainte. Il donne au moteur des performances prévisibles, une faible empreinte mémoire et assez de contrôle pour garder le pipeline local-first.
Brainlet est construit pour fonctionner sur un laptop développeur ou un petit serveur d'entreprise. Pas de dépendance cloud. Pas de code qui quitte la machine.
Ce choix influence chaque partie de l'architecture. Le parsing doit être incrémental. Les représentations intermédiaires doivent rester compactes. La couche de requête doit répondre assez vite pour être utile dans les workflows développeur normaux, pas comme un travail de recherche hors ligne.
Pourquoi local-first
Le code est sensible. Pour beaucoup d'équipes, envoyer tout un codebase à un service hébergé n'est pas acceptable. Pour les entreprises régulées, c'est souvent impossible.
Brainlet garde le projet là où il vit déjà. La couche d'intelligence est calculée localement. Le LLM connecté au moment de l'inférence peut être celui que l'équipe choisit, y compris des modèles open-source exécutés sur son propre matériel.
C'est particulièrement important pour les équipes avec dépôts privés, données régulées ou revue fournisseur stricte. Un moteur d'intelligence de code qui exige d'uploader tout le dépôt crée une discussion sécurité avant de créer de la valeur. Brainlet est construit pour éviter ce compromis.
Pourquoi des modèles spécialisés
Brainlet n'entraîne pas un LLM généraliste. Il entraîne plusieurs modèles légers sur la structure du projet spécifique qui se trouve devant lui.
Ces modèles apprennent des signaux propres aux tâches : comment les composants se relient, quels fichiers se comportent de manière similaire, où les changements se propagent, quels patterns sont normaux dans ce codebase et quelles contraintes comptent.
Le résultat n'est pas une pile de fichiers récupérés. C'est une compréhension projet calculée.
Cette distinction est le cœur de Cognitive Augmented Generation. La récupération demande : "quels chunks ressemblent à ce prompt ?" Brainlet demande : "qu'est-ce que ce modèle doit savoir sur le projet avant de répondre ?" Ce sont des problèmes différents, et ils produisent des systèmes différents.
Le pari du petit cerveau
L'industrie continue de supposer que plus grand signifie meilleur. Modèles plus grands. Fenêtres de contexte plus grandes. Factures plus grandes.
Brainlet prend le pari inverse. Un moteur plus petit qui comprend le projet peut rendre n'importe quel modèle plus utile. Le but n'est pas de remplacer le LLM. Le but est de lui donner le contexte qu'il aurait dû avoir dès le départ.
La méthodologie et les résultats de benchmark publics seront publiés en juin 2026. D'ici là, l'affirmation honnête est architecturale : un meilleur contexte projet devrait réduire le raisonnement que le LLM consacre à redécouvrir le codebase.