{"slug": "work-the-tool-to-work-the-thing", "title": "Work the Tool to Work the Thing", "summary": "Beagle, a new revision control system built on a lightweight JavaScript runtime called JAB, aims to provide adaptability for evolving development processes, especially those involving LLMs. Its creator emphasizes malleability through an HTTP-verb-based interface and AI-assisted tool generation, allowing users to easily modify or extend functionality as needed.", "body_md": "I have worked **with** revision control and **on** revision control systems for quite some time now and I had every opportunity to develop strong opinions. Many of those opinions have changed as parallel LLM development became the norm. Tomorrow, the process will likely evolve even further. So, how do I see **modern** revision control? Can I really have any stable opinion here?\n\nThe only stable thing now is constant change. How can source code management help here? Should we use worktrees, patch stacks, CRDT merges, trunk-based development? The correct answer is that I do not know what will work tomorrow. So the revision control system must, first and foremost, be adaptable to any new process, including project-specific processes.\n\nBeagle, the revision control system, is built to fit this exact condition. There is [libdog](https://github.com/gritzko/libdog), the layer of fast and deterministic tools of the trade: git compatibility, source code tokenization, indexing, data exchange format, diff and merge algorithms. There is a minimalistic JavaScriptCore-based JS runtime [JAB](https://github.com/gritzko/jab/). I do not use node.js and others because of their weight and ridiculous supply chain issues. Finally, on top of JAB there is the malleable part - the revision control system itself. [Beagle](https://github.com/gritzko/beagle-ext) is made in a very specific way - it uses an orthogonal basis of HTTP verbs (GET, HEAD, POST, PUT, PATCH, DELETE) to do any work and URIs to address any resource. The runtime itself can execute any \"verb\", so `diff`\n\n, `status`\n\n, `list`\n\n, `log`\n\nand many other normally expected things are there. In fact, I write it as I go. I need a tool, I tell Claude to make a tool.\n\nSo the stack is like this:\n\nChanges to `libabc`\n\nI carefully read, changes to `libdog`\n\nI look at, `beagle`\n\nI can vibe. This way I keep the actual behavior malleable without devolving the codebase into slop. Frankly, Netscape invented JavaScript exactly for this kind of use.\n\nYesterday I wanted a new `blame`\n\nview. It took me a couple of hours, and I called it `why`\n\n. Because, when you work with LLMs, you can only blame yourself! It is all JavaScript, all the heavy lifting is done by the `libdog`\n\nbackend, and it works. If I do not like how it works, I can tell Claude to correct things. JavaScript is sufficiently safe and malleable to make this process painless. In fact, that became the norm: I have a terminal to work on a thing and another terminal on the side to work the tool to work the thing.\n\nBeagle likes dogfood!", "url": "https://wpnews.pro/news/work-the-tool-to-work-the-thing", "canonical_source": "https://replicated.live/blog/js", "published_at": "2026-07-07 07:37:50+00:00", "updated_at": "2026-07-07 07:59:44.539565+00:00", "lang": "en", "topics": ["developer-tools", "large-language-models", "ai-tools"], "entities": ["Beagle", "JAB", "libdog", "Claude", "Netscape", "JavaScriptCore"], "alternates": {"html": "https://wpnews.pro/news/work-the-tool-to-work-the-thing", "markdown": "https://wpnews.pro/news/work-the-tool-to-work-the-thing.md", "text": "https://wpnews.pro/news/work-the-tool-to-work-the-thing.txt", "jsonld": "https://wpnews.pro/news/work-the-tool-to-work-the-thing.jsonld"}}