Beaucoup d’agents de code savent modifier un fichier parce qu’on leur donne un outil qui remplace du texte. Ça fonctionne très bien jusqu’au moment où le fichier est un YAML indenté, un TOML commenté ou six fichiers qui doivent changer ensemble.
Patchloom essaie de déplacer cette opération vers une couche plus structurée.
L’outil, écrit en Rust et distribué comme un binaire multi-plateforme, sait modifier JSON, YAML et TOML par sélecteur, travailler sur des sections Markdown, effectuer certaines opérations basées sur l’AST et regrouper plusieurs changements dans une transaction avec rollback. Il peut être utilisé en CLI ou exposé comme serveur MCP.
L’idée est moins spectaculaire qu’un nouvel agent autonome. C’est probablement pour ça qu’elle est plus utile.
Le projet ne prétend pas que tout devient plus rapide
Le README est assez honnête sur ce point. Pour une lecture simple, une recherche ou un petit remplacement dans un fichier, les outils natifs restent souvent plus rapides. Même certains benchmarks multi-fichiers publiés par le projet donnent l’avantage aux outils natifs en temps brut.
L’argument de Patchloom est ailleurs : un agent peut dire « change database.port dans ce YAML » sans bricoler une regex, préserver les commentaires, prévisualiser le résultat et annuler une transaction entière si la validation échoue.
La version 0.28.0, publiée le 10 août, continue dans cette direction. Elle fait notamment échouer explicitement les chemins vides ou composés uniquement d’espaces au lieu de les laisser se résoudre de manière ambiguë vers le workspace.
Ce genre de détail semble minuscule jusqu’au jour où un agent possède le droit d’écrire dans votre dépôt.
Les modèles deviennent meilleurs pour décider quoi modifier. Les outils autour d’eux doivent encore devenir meilleurs pour garantir que cette décision se transforme en changement précis, vérifiable et réversible.