Claude a enfin un cerveau permanent.

Chaque chatbot moderne a le même défaut embarrassant : l'amnésie. Les grands modèles de langage comme Claude, ChatGPT et Gemini traitent chaque conversation comme un globe en verre jetable : secouez-le, appréciez la scène, puis jetez-le lorsque le verre se remplit de jetons ou que vous appuyez sur "Nouvelle conversation".

Les développeurs ressentent cela de manière particulièrement aiguë. Vous lancez un refactor multi-fichiers, un plan de migration, une construction de fonctionnalité d'une semaine. Au bout de trois jours, le contexte de 200 000 tokens de Claude est encombré de journaux, de traces de pile et de spécifications partielles, donc vous ouvrez une nouvelle fenêtre—et votre « ingénieur senior » commence soudainement à se comporter comme un nouvel employé au premier jour.

La solution actuelle consiste essentiellement à faire des stocks. Les gens empilent d'énormes spécifications markdown, PRDs et fichiers “project_overview_v7_final_FINAL.md” dans chaque invite, espérant que le volume suffisant puisse remplacer la mémoire. Pour tout code source sérieux, cela peut signifier des dizaines de milliers de tokens consommés avant même que le modèle ne commence à réfléchir.

Cette stratégie échoue de manière prévisible. De gigantesques blocs de texte à prix réduit aplatissent tout en prose, ce qui oblige le modèle à déduire la priorité, les dépendances et l'état à partir d'un mur de texte. Il s'acharnera volontiers sur une tâche à faible priorité tout en ignorant la migration bloquant la sortie enterrée à la page huit.

Vous obtenez également des flux de travail manuels et rigides. Chaque fois que vous ajoutez une nouvelle fonctionnalité ou changez de direction, vous devez mettre à jour le document principal, régénérer les résumés et les re-coller. Oubliez une fois, et Claude optimise un plan obsolète parce que la « source de vérité » et la réalité se sont discrètement éloignées.

Le coût humain semble banal mais brutal à grande échelle. Les équipes perdent des heures par semaine à réexpliquer les architectures, les critères d'acceptation et les cas particuliers dans de nouvelles discussions. Des priorités mal mémorisées se transforment en branches erronées, en refactorisations incorrectes et en tâches à moitié terminées qui disparaissent lorsque quelqu'un efface l'historique.

L'inflation de la fenêtre contextuelle ne résout pas ce problème. Une fenêtre plus grande ne fait que retarder le rétablissement ; elle ne donne pas au modèle un état durable et structuré. Que le plafond soit de 32 000 ou de 1 million de tokens, vous atteignez toujours un mur où le plan d'hier s'efface dans l'oubli.

Ce dont les développeurs ont réellement besoin, ce n'est pas d'un historique de discussions plus long, mais d'un substrat de mémoire : un enregistrement persistant et interrogeable des tâches, décisions et progrès qui survit aux nouvelles sessions, aux nouveaux onglets et même aux nouvelles machines—quelque chose qu'une IA peut considérer moins comme une conversation et plus comme un cerveau de projet vivant.

L'ancien ingénieur de Google, Steve Yegge, a un nouveau projet parallèle qui est en train de modifier en douceur la façon de penser de Claude. Appelé Beads, cet outil attache un cerveau durable au modèle d'Anthropic, transformant Claude Code d'un poisson rouge en quelque chose de plus proche d'un ingénieur senior qui se souvient réellement de ce que vous lui avez demandé de faire la semaine dernière.

Yegge, qui dirigeait précédemment l'ingénierie chez Sourcegraph, n'a pas créé Beads en tant que simple plugin de chat. Il l'a conçu comme un véritable outil de suivi des problèmes, natif aux dépôts, pour des projets logiciels complexes, un outil qui vit aux côtés de votre code et survit aux réinitialisations de contexte, aux nouvelles discussions et même aux nouveaux appareils.

Au cœur de Beads se trouve une couche de mémoire persistante, structurée et interrogeable. Chaque tâche, bogue, épopée et dépendance devient un élément dans une base de données SQLite, reflété en JSONL afin que vous puissiez le versionner dans Git, le comparer et le restaurer comme tout autre fichier dans votre dépôt.

Au lieu de gaver Claude avec d'énormes récits de fond markdown, vous l'orientez vers Beads et lui permettez de poser exactement les questions dont il a besoin. L'agent peut demander « tous les problèmes P1 ouverts dans cette épopée », suivre les chaînes de dépendance, mettre à jour les statuts au fur et à mesure de son travail, et reprendre la semaine suivante sans que vous ayez à coller un seul prompt contextuel.

En coulisse, Beads exécute un démon léger dans votre dossier de projet. Il maintient une base de données SQLite locale synchronisée avec une exportation JSONL, donc : - Seules les fichiers JSONL sont enregistrés dans Git, pas les fichiers binaires SQLite - Les conflits de fusion se résolvent comme du texte - Chaque clone reconstruit automatiquement le même graphique de problèmes

Ce truc fait en sorte que Beads se comporte comme une base de données distribuée sans avoir besoin de Kubernetes, de files d'attente ou de services cloud gérés. Un simple socket et une CLI, plus un serveur MCP, donnent à Claude un accès en lecture/écriture, transformant un humble dossier `.beads` en quelque chose qui se comporte comme une mémoire à long terme pour le code.

Beads cache une architecture étonnamment opinionnée derrière son image conviviale de « suiveur de problèmes ». Au centre se trouve une base de données SQLite locale qui se comporte comme l’hippocampe de Claude, stockant chaque problème, projet épique, dépendance, estimation et changement de statut sous forme de lignes structurées. Claude n'a jamais besoin de se souvenir d'une énorme spécification markdown ; il interroge simplement cette petite et rapide base de données chaque fois qu'il a besoin de savoir quoi faire ensuite.

SQLite n'est pas un composant annexe ici, c'est la source de vérité canonique. Chaque fois que vous ou Claude créez, mettez à jour ou fermez un problème, Beads écrit ce changement dans SQLite en premier, l'utilisant comme une chronologie cohérente unique pour le projet. Même dans de grands projets avec des centaines de problèmes et des graphes de dépendance complexes, l'indexation de SQLite permet des recherches et des mises à jour pratiquement instantanées sur un ordinateur portable.

Pour rendre cet état canonique portable, Beads l'exporte en continu dans un fichier JSONL (JSON Lines). Chaque ligne de ce fichier est un objet JSON complet pour un seul problème ou épique, ce qui signifie que la mémoire de votre projet devient simplement un autre artefact texte dans votre dépôt. Vous pouvez l'ouvrir dans n'importe quel éditeur, examiner les modifications dans un diff, ou ajuster manuellement un champ si Claude étiquette mal une priorité.

JSONL transforme la mémoire de Claude en quelque chose que Git comprend réellement. Comme les binaires SQLite n'atteignent jamais le dépôt, seul le fichier JSONL le fait, ce qui permet à Git de : - Afficher des différences détaillées ligne par ligne pour les modifications des problèmes - Fusionner des éditions concurrentes de plusieurs développeurs ou agents - Préserver l'historique pour les audits et les restaurations

Un démon Beads relie ces mondes. Fonctionnant en arrière-plan, il surveille la base de données SQLite pour détecter les changements et les exporte automatiquement au format JSONL, garantissant que l'état de votre Git ne s'écarte jamais. Lorsque vous tirez depuis l'origine et que Git met à jour le fichier JSONL, le démon réintègre ces modifications dans SQLite, effectuant une synchronisation bidirectionnelle afin que chaque machine reconstruise le même graphique d'incidents localement.

Au-dessus de cette boucle de stockage se trouve une interface socket/CLI légère. Le socket expose des commandes pour créer, interroger et mettre à jour des problèmes, que Claude peut utiliser via un serveur MCP ou des outils personnalisés. La CLI offre aux utilisateurs humains les mêmes pouvoirs depuis un terminal, vous permettant de signaler un bug, de changer un responsable ou de lister toutes les dépendances ouvertes sans jamais toucher directement à la base de données.

Pour des détails techniques plus approfondis, y compris le schéma et le comportement de synchronisation, le dépôt de Steve Yegge Beads – Une mise à niveau de mémoire pour votre agent de codage (GitHub officiel) documente la manière dont SQLite, JSONL, le démon et le socket s'intègrent dans la nouvelle pile de mémoire "permanente" de Claude.

La synchronisation bidirectionnelle est le moment où Beads cesse d’être « seulement un outil de suivi des problèmes » et commence à fonctionner comme une base de données distribuée pour votre équipe d'IA. Au lieu d'insérer un fichier binaire SQLite dans Git et de prier, Beads considère la base de données comme un détail d'implémentation interne et expose une surface claire et textuelle : JSONL.

Le flux de travail semble trompeusement simple. Un coéquipier engage des modifications, vous exécutez `git pull`, Git fusionne un fichier JSONL ligne par ligne, et le daemon Beads se réveille, lit le JSONL fusionné et régénère de manière déterministe votre base de données SQLite locale pour qu'elle corresponde.

Vous ne commitez jamais les binaires `.sqlite`. Vous ne commitez que l'export JSONL, qui est : - Lisible par l'homme - Différenciable dans les outils de revue de code standard - Fusionnable avec les algorithmes de texte existants de Git

Parce que chaque problème est enregistré comme une seule ligne JSON, les modifications concurrentes se comportent comme des changements de code normaux. Si deux développeurs modifient des problèmes différents, Git les fusionne correctement ; s'ils touchent le même problème, vous obtenez un conflit standard dans un fichier texte au lieu d'une corruption binaire opaque.

Une fois la fusion terminée, le démon Beads effectue la synchronisation inverse. Il analyse le JSONL mis à jour, le concilie avec la base de données locale et applique les insertions, mises à jour et suppressions afin que votre fichier SQLite reflète exactement l'état canonique de Git.

Cette boucle—DB → JSONL → Git → JSONL → DB—transforme une simple liste de problèmes en un magasin d'état répliqué. Toute machine capable de cloner le dépôt et d'exécuter Beads se retrouve avec une base de données SQLite équivalente et interrogeable que Claude Code peut utiliser comme « mémoire ».

Pour les équipes d'IA, c'est un changement structurel. Vous disposez d'un graphe de tâches partagé et fortement cohérent sans avoir à configurer Postgres, gérer des migrations ou câbler un service de synchronisation séparé.

Plusieurs agents, même sur différentes machines ou runners CI, peuvent : - Ouvrir le même projet - Interroger le même graphique de dépendances - Mettre à jour les mêmes problèmes et épopées

Tout cela se déroule tout en restant dans des workflows Git normaux et des revues de code, sans fichiers binaires polluant votre historique et sans état mystérieux caché en dehors du dépôt.

Le premier contact avec un Claude surpuissant commence dans votre terminal. Vous exécutez le démarrage rapide de Beads, qui dépose un dossier beads dans votre dépôt avec une base de données SQLite, une exportation JSONL, un daemon et un socket tous connectés. Du point de vue de Claude, ce dossier devient un cerveau externe permanent qu'il peut interroger comme une API.

Vous ouvrez Claude Code contre le projet et lui donnez une seule instruction de haut niveau. Quelque chose comme : « Utilisez Beads pour analyser ce dépôt et générer des épopées et des problèmes avec des priorités P0 à P3 pour une version 1.0. » Claude appelle le serveur Beads MCP, scanne le code, et écrit des problèmes structurés directement dans SQLite.

Au lieu d'un mur de prose, vous obtenez un véritable backlog. Claude regroupe le travail en épopées telles que « Authentification », « Interface utilisateur du visualiseur de paquets Brew » et « CI/CD », puis déploie les problèmes avec des champs comme le titre, la description, les dépendances, le responsable, l'estimation et la priorité. Beads exporte tout cela au format JSONL afin que Git puisse effectuer des différences et des fusions comme n'importe quel autre fichier texte.

Vous pouvez ajuster le plan en langage naturel. Dites à Claude : « Fusionnez ces deux épopées » ou « Supprimez les tâches P3 de faible valeur pour l’instant », et il met à jour les enregistrements Beads via CLI ou MCP, sans réécrire un fichier markdown fragile. La boucle de synchronisation bidirectionnelle rend ces modifications durables sur toutes les branches et machines.

Une fois que le backlog semble raisonnable, vous émettez la phrase magique : « Commencez à traiter les problèmes ouverts par ordre de priorité. » Claude interroge Beads pour le problème ouvert de la plus haute priorité sans dépendances non satisfaites, extrait juste ce contexte et commence à coder contre votre dépôt. Pas de copier-coller manuel, pas de recherche dans de vieilles discussions.

Après chaque tâche, Claude renvoie le statut dans Beads. Il marque les problèmes comme "en cours", "bloqué" ou "terminé", ajoute des notes, des liens vers des commits, et même enregistre le temps approximatif passé. Le daemon synchronise les changements en JSONL, de sorte qu'un membre de l'équipe puisse faire un git pull et voir exactement le même état.

Votre rôle passe de chef de projet à éditeur. Vous approuvez ou ajustez le travail de Claude, réorganisez parfois les priorités et ajoutez de nouvelles questions lorsque les exigences du produit changent. L'IA s'occupe des tâches répétitives : choisir la tâche suivante, respecter les dépendances et ne jamais perdre le fil lorsqu'une fenêtre de discussion se ferme.

Au fil des jours ou des semaines, cette base de données des problèmes devient une mémoire vivante. Claude ne devine plus quoi faire ensuite ; il lit le carnet de commandes, exécute et se met à jour, transformant Beads en un pilote automatique silencieux et implacable pour votre flux de travail de développement.

Oubliez un instant le jargon technique : Beads est livré avec une interface web épurée qui transforme la « mémoire permanente » de Claude en quelque chose que vous pouvez réellement visualiser. Ouvrez un navigateur et vous obtiendrez un tableau de bord en direct des épopées, des problèmes, des assignations et des statuts, directement alimenté par le même stockage SQLite + JSONL que vos agents utilisent. Pas d'étape de synchronisation supplémentaire, pas de SaaS séparé.

L'interface web mise fortement sur la visualisation des dépendances. Vous pouvez développer un epic et visualiser son graphique de dépendances sous la forme d'un ensemble de problèmes liés, voir quelles tâches en bloquent d'autres et suivre en temps réel comment Claude les clôt. Pour les grandes bases de code, cette vue graphique devient une vérification de la cohérence quant à savoir si vos agents IA suivent réellement l'ordre prévu.

L'état du projet évolue au-delà d'un simple backlog. Les surfaces de beads : - Problèmes ouverts vs problèmes fermés dans le temps - Épics avec des estimations restantes - Propriétaires et niveaux de priorité - Tâches récemment modifiées par un humain vs un agent

Parce que l'interface utilisateur lit à partir de la même base de données que vos agents modifient, vous ne vous demandez jamais si le tableau est obsolète ; chaque mise à jour MCP ou CLI arrive directement dans le navigateur.

L'intégration Jira transforme Beads d'un jouet pour hackers en infrastructure d'entreprise. Vous pouvez connecter Beads afin que les problèmes et les épopées se synchronisent avec les projets Jira, permettant à Claude de travailler sur une représentation SQLite locale et rapide, tandis que les responsables restent dans leurs tableaux Jira familiers. Beads devient le cache structuré qui maintient les flux de travail d'IA réactifs sans contourner les processus d'entreprise.

Cette synchronisation signifie que les agents IA peuvent créer, mettre à jour et clôturer des éléments de travail qui apparaissent sous forme de tickets Jira standard, avec des priorités et des dépendances. Les humains peuvent ajuster ces tickets dans Jira, et Beads extrait les modifications pour les intégrer dans son export JSONL et son stockage SQLite, maintenant ainsi les deux côtés alignés.

Cela fait de Beads un pont entre le développement axé sur l'IA et les méthodes de gestion de projet traditionnelles. Vous conservez Jira, les feuilles de route et la conformité, tandis que vos agents fonctionnent sur un graphe de problèmes local et épuré conçu pour les LLM. Pour les détails de configuration, le Guide de démarrage rapide de Beads explique comment connecter le daemon, l'interface web et les intégrations.

Les outils de développement axés sur les spécifications comme SpecKit traitent l'IA comme un stagiaire enseveli sous un PRD de 40 pages. Vous remettez à Claude un énorme fichier markdown et priez pour qu'il survole les bonnes sections. Beads inverse cette dynamique : Claude devient celui qui pose des questions ciblées, et la spécification vit comme une base de données consultable plutôt que comme un mur de texte.

Les spécifications Markdown semblent simples mais vous coûtent cher en tokens. Un PRD de 50 Ko peut atteindre des dizaines de milliers de tokens une fois que vous ajoutez du code, des commentaires et des messages précédents. Chaque fois que vous "rappelez" à Claude la spécification, vous payez à nouveau ce coût, et vous risquez toujours qu'il ne remarque pas une contrainte enfouie dans la section 7.3.

Beads considère le contexte comme un problème de base de données, et non comme un examen de compréhension de lecture. Claude ne précharge pas toutes les exigences ; il émet des requêtes structurées telles que « donnez-moi toutes les issues ouvertes pour l'épopée X triées par priorité » ou « récupérez les bloqueurs pour BEAD‑42 ». Seules les lignes retournées atteignent la fenêtre de contexte, de sorte qu'un projet de 5 000 issues peut sembler aussi léger qu'un dépôt de jouets de 5 issues.

SpecKit et ses amis s'appuient sur un markdown hiérarchique : titres, listes numérotées, puces imbriquées. Les LLM gèrent cette structure de manière incohérente, surtout après plus de 100 échanges de modifications et de citations partielles. Les dépendances se cachent dans le texte comme "faire Y après X", que les modèles interprètent ou oublient régulièrement lorsque la liste sort de la fenêtre.

Beads encode ces relations sous forme d'un graphe explicite. Chaque problème a des champs pour les dépendances, les épopées, les assignés et le statut, stockés dans SQLite et reflétés en JSONL. Lorsque Claude planifie le travail, il parcourt un graphe acyclique orienté de tâches, et non une liste de contrôle imbriquée, de sorte que « faire A avant B avant C » devient un ordonnancement imposé par la machine plutôt qu'une suggestion au paragraphe quatre.

L'efficacité contextuelle s'accumule avec le temps. Avec les spécifications markdown, chaque affinement gonfle le fichier et rend la ré-ingestion plus lente et plus coûteuse. Avec Beads, clore ou re-prioriser un problème met simplement à jour quelques lignes ; Claude ne récupère que le delta, ce qui maintient les coûts et la charge cognitive stables au cours de projets s'étalant sur plusieurs semaines.

Le développement axé sur les spécifications reste précieux pour une réflexion en amont, et Beads ne cherche pas à remplacer cela. Vous pouvez rédiger un PRD détaillé dans SpecKit, puis le traduire en épiques et en problèmes dans Beads, préservant ainsi la planification tout en déplaçant l'exécution dans un monde orienté requête. Claude cesse de relire le roman et commence à opérer sur une machine d'état partagée en direct.

Imaginez un petit outil de développement appelé BrewView : une application à une seule page qui affiche tous les paquets `brew` sur votre machine, signale ceux qui sont obsolètes et propose des mises à jour sûres. Pas de SaaS, pas de connexion, juste un backend local en Rust et un frontend en React. Vous voulez que Claude aide, mais vous ne voulez pas surveiller sa mémoire.

Le jour 1 commence avec un nouveau dépôt et Beads initialisé, créant un dossier `beads` avec SQLite, JSONL et le démon Beads. Vous ouvrez Claude Code et dites : « Planifiez BrewView comme une petite application. Créez 5 épopées et environ 20 problèmes dans Beads, avec des priorités et des dépendances. » Claude se connecte au serveur Beads MCP, et soudain, votre projet prend forme.

Claude crache des épopées telles que :

• 1Intégration de Core CLI et brew
• 2Modèle de données et stockage local
• 3Interface utilisateur React
• 4Améliorer les flux de travail et les contrôles de sécurité
• 5Tests, documents et emballage

Sous ceux-ci, cela crée environ 20 problèmes : analyser `brew list --json`, concevoir un schéma `Package`, construire `/api/packages`, connecter un tableau React, ajouter des filtres, implémenter des mises à jour en mode dry-run, rédiger des tests d'intégration. Chaque problème porte une priorité (P0–P3), un responsable (vous ou Claude), et des dépendances explicites.

Vous modifiez quelques éléments dans l'interface web de Beads, rétrogradant une tâche de finition de l'interface utilisateur et ajoutant un bug « prendre en charge les cas particuliers d'Apple Silicon ». Le démon de Beads synchronise les modifications en JSONL, donc Git suit désormais chaque problème en tant que ligne de texte. Vous faites un commit, poussez sur GitHub, et fermez votre ordinateur portable.

Jour 2, nouvelle machine, nouvelle discussion avec Claude. Vous ouvrez le dépôt, Beads reconstruit la base de données SQLite à partir du JSONL, et vous dites à Claude : « Quelle est la prochaine étape pour BrewView ? » Claude interroge Beads, trouve le problème ouvert le plus prioritaire—« Implémenter `/api/packages` en Rust en utilisant la sortie de `brew list --json` »—et commence à structurer le code, les tests et la documentation.

Le contexte ne s'évapore jamais car Beads détient la source unique de vérité du projet. Vous pouvez changer de branche, effacer l'historique des discussions ou faire venir un deuxième développeur ; tout le monde partage les mêmes épiques, états et graphiques de dépendance. Claude ne cesse de demander à Beads quoi faire ensuite, un problème à la fois, jusqu'à ce que BrewView se livre discrètement.

Les systèmes de mémoire comme Beads ressemblent moins à des sidecars excentriques et plus à la moitié manquante de l'ingénierie logicielle moderne en IA. Une fois que vous voyez Claude parcourir méthodiquement un volume de travaux et de problèmes sur plusieurs jours au lieu de quelques heures, l'ancien flux de travail « collez une spécification dans une nouvelle discussion et priez » semble primitif. Les agents sans état commencent à ressembler à des stagiaires amnésiques ; ceux avec état commencent à ressembler à des coéquipiers persistants.

Pour les configurations multi-agents, une mémoire externe et structurée ne peut plus être optionnelle. Plusieurs instances de Claude, un bot GitHub et un assistant CI doivent tous se coordonner sur le même graphique de problèmes, de dépendances et de priorités. Un store SQLite + JSONL soutenu par Git leur fournit une source de vérité partagée et résoluble en cas de conflit, au lieu de fenêtres de contexte en concurrence.

Les équipes d'entreprise se soucient moins de l'ambiance et plus de l'auditabilité. Une base de données d'incidents sous contrôle de version signifie que chaque décision d'IA repose sur un artefact concret : qui a créé un incident, quand une dépendance a changé, quel agent a clôturé une tâche. Cette traçabilité est importante pour la SOX, le PCI et les commissions d'examen internes qui n'accepteront pas "le modèle l'a dit" comme journal des modifications.

Vous pouvez déjà voir les contours d'une nouvelle architecture : des LLMs en tant que moteurs de raisonnement sans état reposant sur des machines d'état durables et interrogeables. Beads transforme un outil de suivi des problèmes en cette machine d'état ; d'autres équipes feront de même avec des plans de test, des diagrammes d'architecture et des manuels d'incidents. La question ne sera plus « Quelle est la taille de votre fenêtre contextuelle ? » mais « Quelle est la richesse et la cohérence de votre modèle de mémoire externe ? »

Une fois que vous avez une couche d'état persistante, l'orchestration multi-agents cesse d'être un jouet de recherche et commence à ressembler à un schéma de production. Un agent peut se spécialiser dans la planification, un autre dans l'implémentation, un autre dans le refactoring, tous se coordonnant à travers le même stockage structuré. Des systèmes comme Beads – Système de mémoire et gestionnaire de problèmes pour agents IA (Liste de serveurs MCP) laissent entrevoir un avenir où vous connectez des agents à des backends avec état de la manière dont vous connectez des microservices à des bases de données.

Les futurs outils de développement en IA tourneront presque certainement autour de cette idée : les LLM comme unité de calcul, la mémoire externe comme système d'exploitation. Les fenêtres de contexte restent importantes pour le raisonnement à court terme, mais le véritable levier provient d'un état persistant et structuré qui survit aux pannes, aux nouvelles discussions, et même aux nouveaux modèles. Les outils qui n'exposent pas cet état en tant qu'objet de première classe, versionné, sembleront aussi obsolètes que le FTP dans un monde Git.

Claude sans mémoire ressemble à une version de démonstration ; Claude avec Beads ressemble à un ingénieur. Vous obtenez un état de projet durable, un rappel parfait de chaque problème et épopée, et une pile de priorités qui survit aux effacements de contexte, aux nouvelles discussions et même aux nouveaux ordinateurs portables. Au lieu de forcer un fichier markdown de 20 Ko dans chaque prompt, Claude interroge un cerveau compact SQLite et ne tire que ce dont il a besoin.

Beads transforme votre agent IA en un gestionnaire de projet discipliné. Les problèmes, les épopées, les dépendances et les assignations résident dans une base de données miroir en JSONL que vous pouvez comparer, examiner et restaurer comme du code. La synchronisation bidirectionnelle signifie que plusieurs humains et plusieurs agents restent en accord sur une seule source de vérité, même à travers des branches et des machines.

Commencer prend des minutes, pas des jours. Installez Beads, lancez le daemon, et pointez Claude Code ou votre client MCP vers le socket. Vous gagnez immédiatement une mémoire persistante pour les tâches, les progrès, et les décisions qui autrement disparaîtraient lorsque la fenêtre de contexte se réinitialise.

Vous n'avez pas besoin de rétroconcevoir quoi que ce soit. Le dépôt est public à https://github.com/steveyegge/beads et le guide de démarrage rapide se trouve à https://github.com/steveyegge/beads/blob/main/docs/QUICKSTART.md. Suivez le guide de démarrage rapide une fois, puis intégrez Beads dans votre modèle de projet par défaut.

Traitez cela comme un labo pour de nouveaux flux de travail, et non simplement comme un jouet. Essayez des schémas tels que : - Une base de données Beads par monorepo - Des bases de données séparées pour le travail infra et produit - Plusieurs agents partageant le même graphique de problèmes

Partagez ce qui fonctionne et ce qui ne fonctionne pas. Signalez les problèmes, ouvrez des demandes de tirage et publiez vos expérimentations afin que d'autres puissent reproduire votre configuration. Les premiers utilisateurs de la mémoire AI persistante définiront comment les outils futurs planifient le travail, coordonnent les agents et livrent des logiciels à grande échelle ; vous pouvez faire partie des personnes qui valident ce modèle dès maintenant.

Qu'est-ce que Beads et pourquoi a-t-il été créé ?

Beads est un outil de suivi des problèmes léger et sous contrôle de version, créé par Steve Yegge, pour offrir aux agents IA comme Claude une mémoire persistante pour des tâches de codage complexes. Il résout le problème des modèles d'IA perdant le contexte ou oubliant les priorités des tâches entre les sessions.

En quoi Beads est-il différent de la mémoire intégrée de Claude ?

La mémoire native de Claude se remémore des conversations et des fichiers passés. Beads offre une base de données externe et structurée d tâches, d'épopées et de dépendances que l'IA peut interroger et mettre à jour, agissant comme la 'liste de choses à faire' à long terme et le gestionnaire d'état d'un projet.

Dois-je engager ma base de données sur Git lorsque j'utilise Beads ?

Non. Vous ne vous engagez qu'à un fichier JSONL basé sur du texte. Un daemon synchronise automatiquement les modifications entre le fichier JSONL dans Git et votre base de données SQLite locale, rendant ainsi le contrôle de version convivial.

Les perles sont-elles réservées uniquement aux développeurs solo ?

Non, Beads est conçu pour la collaboration. Son mécanisme de synchronisation bidirectionnelle via Git permet à plusieurs développeurs et même à plusieurs agents AI de travailler sur le même projet avec une compréhension partagée de l'état actuel et des tâches.