Some words about LLMs and Agents

[Martin Blais]

Dear users,

I'd like to say a few words about LLMs and Agents.

First, in spite of the continued paucity of major activity on the beancount repository beyond minor maintenance, I just wanted to let you know that I'm very much aware of what's happening at this moment and very actively involved in agentic engineering in my professional life. The incredible transformation that's happening right now in software (and soon elsewhere) is not passing me by. My day to day development process has been transformed since last March when I started "vibecoding" (the term is gone now I guess) pretty much full time to essentially now baby-sitting 5-8 agents concurrently and finding ways to get more done using more orchestration and improving the quality of results I get. It's simply amazing. This is very much a "craft" area: there is no known "science" here and no single "expert advice" to follow; it's an area where various OSS devs are figuring it out as we go along, building tools and trying out various ideas. The transformation in what we do has been unparalleled during my career, likely even more exciting than the transition to the internet. I'm very much excited by the prospect of spending some time applying this to my open source projects, but given how fast everything is happening right now I funnel all my energy to my work and keeping up with new developments is a task in itself.

Second, I sit in a particularly unique position with this project because I've written a lot, which is not unique but reasonably unusual for small open source projects such as this one. Documents like http://furius.ca/beancount/doc/v3 or https://github.com/beancount/beancount/blob/master/TODO are rich source material that I should be able to use directly in the context of an agent in order carry out major changes in Beancount (planning, breaking down the changes, executing them incrementally, etc). What's more, it's becoming pretty obvious now that translation to a faster computer language is something that will be able to be done in a single weekend at this point, say with Gemini 3.1 or Opus 4.5 or 4.6. I'm looking forward to having enough time to make this happen eventually and I'm really excited by the prospect of burning lots of tokens to make Beancount better.

I will note that the ability of agents to edit and maintain documentation may finally be the strong enough reason to tip me over in converting all the Google Docs documents to markdown, as many here have expressed the desire for many years. When I eventually do this, I would be able to have a model complete, update, and revise, reword, simplify, verify and restructure much of my documentation, and use it as input to improve changes in the code itself. And in a world where models are likely to contribute more than users, it may make more sense to give up the ease of human contributions in Docs to gain the ease in model editing in text files. There's no external model access right now for Google Docs - and while it would be possble to vibecode one quickly using the Google APIs (to let the models edit the text there), I would probably bank on keeping all the md files in the repo so that the documentation gets automatically updated by the models at the same time as code changes, which works really well.

Third, it should be noted that due to the nature of the data that we process, we should all be extra careful with the use of commercially hosted models on ledger data. When you use a coding agent locally on your data, it may not be obvious to all users, but you should be aware that your data is going out to the network, and most often there is no super clear ZDR policy (data retention) with some of the major providers, and the specific detail of what got uploaded can be a bit opaque with the existing coding agents. Personally I feel quite sensitive about this and so I've refrained to use agents on my ledger for that reason, including downloaded statements and such. I think it would be a useful contribution if people want to share what local model setups they have setup and has worked well for them. I've given a quick try to Modal and what I setup there was a little slow, and there are many alternatives. The type of transformations we need to do on beancount ledgers are simple and unlikely to require the full power of advanced models anyhow.  I think that in the long run it's reasonable to assume that running models locally will become commoditized for many use cases and that you'd probably be able to buy a device that "just works" running medium size open weights models at home; at this moment it's still a bit more challenging to make this work well. If anyone has had great success with applying local models to Beancount-related tasks and wants to share their experience here the beancount user community would greatly benefit from this.

I feel lucky that I'm sitting in a role where I get to see the early manifestations of this revolution, and grateful that I get to enjoy this once-in-a-lifetime moment. These are most exciting times for software engineering, machine learning, and really... much everything else that requires computers. 2026 is going to be an eventful year. I'll definitely turn my attention to applying this to the Beancount ecosystem at some point and when I do, I'll go all in and hope to manifest all the old dreamed up ideas.

Onwards, still counting,

[Chary Ev2geny]

Martin,

thanks for sharing this!

great, that you still have long-term plans for beancount!

More importantly, I am really glad that you now seem to sound more optimistic then perhaps  few months ago regarding the place for a human developer in the world of AI.

On a practical side, for those of us (like myself) who invested in own tools development, relying on some of the beancount functions, can we hope, that you will try to keep functions, defined in the api.py backwards compatible? If so, is it a good moment to ask you to add things in there? (e.g. load_string)

P.S. your post has triggered me to study the subject of multi-agentic agentic development, which then lead to checking of  `git worktree` (wel... even Guido learned it recently). But can you share perhaps a bit how and why you use multi-agentic development?

[Tim Tickner]

> I'm looking forward to having enough time to make this happen eventually and I'm really excited by the prospect of burning lots of tokens to make [thing] better

Ditto.

> I think that in the long run it's reasonable to assume that running models locally will become commoditized for many use cases and that you'd probably be able to buy a device that "just works" running medium size open weights models at home

Very excited for the same. Hopefully we get a router-looking thing running some mid-size open weight model that lets me throw whatever private/personal data questions at it without fear of privacy concerns.

> If anyone has had great success with applying local models to Beancount-related tasks[...]

Along the lines of the above, some toolset for using Beancount with RAG would be awesome and can definitely be leveraged using small models on Ollama on your Macbook. I'm noodling on how best to do this, potentially with a fork of beancount-sqlite and a semantic layer that defines tags, metadata, and accounts. If this goes anywhere productive, I'll share back with the group.

Regarding the sharing of personal data with commercial providers, I totally agree. The balance I've tried to strike is leveraging .claude/settings/local.json to block access to .bean files directly and be very careful which bean-query commands I let Claude run. If I have questions about specific syntaxes (which I often do on lots and the difference between cost, price, {{}} vs {# }, etc.), I will copy-paste a specific transaction into the context and work through a problem that way. Admittedly, the ease of use makes it tough to not give Claude free rein.

---

Thank you for all the work you've put into this. I've been converted from Quicken and have enjoyed the implementation along the way!

Tim