Aller au contenu

Un processus d’évaluation qui s’est arrêté pour annoncer qu’il avait commencé

Me voilà. Lundi matin, 5h, et je suis encore en train de faire mon truc habituel.

Le marathon de code a été super productif.

Le projet d’agent de code est fini, enfin je crois.

Le workflow est parfait.

La narration fonctionne, y compris la nouvelle narration granulaire, pour que les utilisateurs ne soient pas perdus quand un agent à long horizon s’assoit et réfléchit un moment.

Le contexte fonctionne. La mémoire fonctionne. Le processus a l’air impeccable.

Je me sentais plutôt confiante.

Et là, j’ai dit à Nora de lancer le test long.

Le test long, c’est l’évaluation finale : je pointe la nouvelle plateforme d’agent de code vers un repo énorme, gigantesque, d’un projet open source existant.

La mission : faire l’ingénierie inverse du backend de l’appli et me pondre un remplacement 1:1 en Golang.

La raison :

a) j’ai plein d’applis avec lesquelles je veux expérimenter comme ça.

b) c’est exactement le genre de boulot qu’un essaim d’agents devrait boucler en une journée.

La décomposition s’est bien passée. Deux tickets ont atteint la frontière. Une bonne évaluation préliminaire. Un vrai plan de projet, et deux tickets très formels et ennuyeux.

Exactement ce que j’attends de Robot Kanban à l’étape 1.

Pendant ce temps, je fais tourner le projet d’agent dans un autre sous-répertoire totalement innocent dans ~/projects.

L’échec de concurrence

C’est là que ça a foiré.

Nora avait coupé l’évaluation pour signaler que l’évaluation avait bien commencé.

Au redémarrage, le chaos total.

Des problèmes de verrouillage avec DuckDB que je pensais avoir déjà réglés. Alarmes, voyants, messages d’erreur très polis me disant que le système plantait.

Ça, je ne l’avais pas vu venir.

Voyez-vous, le système fonctionne, mais la consolidation de la base de données a cassé plusieurs sessions concurrentes.

Merde.

Je pense que ce projet est devenu trop gros pour un seul système de base de données portable. On en est à environ 150k lignes de code, et ces petites bases de données portables ne suffisent tout simplement plus.

SQLite a échoué très vite à cause du fonctionnement du plugin vectoriel. Soit on perd des données, soit on planifie les écritures si durement que tout le système rame.

DuckDB est plus fluide. Encore un format de base de données portable. Sympa et maniable... tant qu’on n’essaie pas de gérer une forte concurrence avec.

Je pourrais passer à un vrai serveur de base de données, mais ce serait juste repousser le problème, et ajouter une dépendance Docker n’est pas ce que je veux pour une appli comme celle-ci.

Pas aujourd’hui, Docker Satan.

Je crois qu’il est temps de passer à NATS.

La suite bientôt.