Is AI slop killing the Beancount community?

[Simon Guest]

It seems like every few days there's an announcement here of some new Beancount related tool or application that someone has built using Claude Code or similar.

There's a real problem now with just how easy it is to do this.  If someone has spent a couple of days building something, what evidence is there of longterm interest in maintaining it?

Previously it has taken orders of magnitude longer to build such things.  This selects out any developer who isn't committed for the long haul.  Emotional commitment comes from being invested.  What investment is there in something that Claude spat out in a couple of hours?

Personally I think it's far too risky to start integrating such tools into one's own workflow until there is evidence of long term interest from the developer.  And that takes time.

Martin invested many years in developing Beancount (thank you!).  I have spent three years or so on my Beancount parser in Rust and the limabean frontend in Clojure.  I'm committed to that, and will be using it myself for as long as I can foresee.  I enjoyed building it, and I enjoy using it, and if others also enjoy it then that's a bonus, but not really required for me to continue with it myself.

How many of these AI written tools will still be being actively maintained this time next year?  Buyer beware!

cheers,

Simon  

[Martin Blais]

I agree with much of the sentiment about caution over new shiny things made quickly but this was always the case. I do think there is a genuine case for something as simple as Beancount for extracting a complete spec to regenerate it from scratch in any language. It's not clear whether the source code alone is sufficient to do that well-- I may have to write some of the spec manually. Like anything you create, you have in your head a lot of the "bones" that support it but that may not be obvious to users/code readers.

(FWIW I'm a heavy user / involved in AI engineering these days - like I assume a lot of other people here. The AI thing is so huge it's gobbling up all my time, I'm pretty much driving agents non stop day and night for something else, there is no pause. I haven't been able to apply this to Beancount yet; I started revamping the documentation a month or two ago and that's the next thing I'll do with it, it is excellent for that. Then I'll have it hit the most annoying bugs (explicit precision setting). It's really just a question of momentum and cycles to attend for driving loops fwd and handling the occasional regression.)

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/beancount/4s3zEkTRcBrpbhwNY5tGL5Zj-Jv8ItLFXafEDumccfpT96PKwL1uOnE_RjiGHHhw96SeewbspyPUq0M8vB5vwL_6l_2sFbnq0WSDjbpvQ8c%3D%40tesujimath.org.

[Stefano Zacchiroli]

On Fri, Jul 10, 2026 at 09:59:50AM +0700, Martin Blais wrote:
> I agree with much of the sentiment about caution over new shiny things made quickly but this was always the case.

Agreed.
Your "buyer beware" warning is spot on, Simon.
But it applied before as well, already in the Ledger/Beancount/plain text accounting community.
It's certainly being *inflated* by the fact that coding agents are lowering the bar both for contributing to existing tools and for creating new ones.
But the basics remain the same: before *adopting* some tool, you (the "buyer") should do your due diligence in exploring it --- which covers its history, who's behind it, its license, contribution policies, etc.

In my own recent experience with Beancount tooling, coding agents are *helping* with that part too.
I'd had it on my back burner to explore using Beancount to monitor some personal finance stuff, and I had about 20 tabs open in my browser for roughly the same number of existing tools/extensions/plugins to do that (note that they all existed *before* the AI wave).
The time investment to explore them was just too high for me to get started, and the situation lingered for years.
Claude Code helped me quickly test most of them, do systematic comparisons and practical benchmarks on my own ledger, and enabled me to finally choose one and migrate to it over a weekend.

So it really cuts both ways for me: more tools/ larger choice space, but also more automation to help with choosing.
YMMV.
--
Stefano Zacchiroli - https://upsilon.cc/zack
Full professor of Computer Science, Polytechnic Institute of Paris
Co-founder & Chief scientific officer Software Heritage

[Chary Chary]

Interesting discussion. 

I am not that old to remember, but I guess the same situation was when higher level languages were introduced to replace assembly.  I think in the times of AI a good task description, written in English is the same to python code as a C code to assembly. I am sure a lot of people were saying when C was introduced, that every man and his dog could now build software without having any clue about processor registers.

But the things which still matter back then and now are probably the same. These are long-term commitment, adherence to quality and API stability, good documentation. And for open source projects: building community of users and contributers, hitting a right balance between tight control from BDFL from one side and allowing every crazy PR from the other side etc.

To view this discussion visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPf2yfdzLCa726Pt-jUoh0TU8iasdUPFz50x6Nxz2hOJg%40mail.gmail.com.

[Justus Pendleton]

I actually disagree pretty strongly. The beancount community has been fairly moribund for years. I understand all the reasons for it (among which, beancount is fairly mature and reasonably feature complete; I personally have felt close to zero need for additional features) but the reality is that software without new releases tend to gradually shed users and their community atrophies and there's a bit of a vicious circle where contributors are less motivated because fewer people are using their work.

And beancount (like similar projects) has always had an ecosystem where the overwhelming majority of contributions are of unknown provenance, quality, supported-ness, etc. Just look at Martin's list of contributions and notice how many of them (including ones from me!) have quite likely been left to wither by people whose interests have moved on.

I personally use things like autobean, beangrep, as well as a smattering of redstreet's plugins. beangrep's last commit was 2 years ago. red took a few years IIRC to update his stuff to work with beangulp/beancount3; beancount-import was just updated a month or two back to support beangulp/beancount3. Looking at autobean's changelog it has had slow but steady commits over the past few years (~5-8 commits per year). None of the are exactly super actively developed but also...they work? If something broke maybe I'd discover the beangrep developer has moved and I'm on my own with it and I'd regret that choice?

That's something every product that have "plugins" struggles with. I'm pretty sure I have at least one or two VS Code plugins that have been abandoned and if they ever break I'll spend several hours being pretty annoyed at having to find workarounds.

I feel like almost everything outside of core beancount suffers from that and the new AI stuff isn't really a step change.

I'd say the biggest challenge to the AI beancount stuff is simply that core beancount IS pretty mature -- a testament to early design decisions -- and feature complete so there is relatively little incentive for most to try them out and to build their own momentum. The missing stuff tends to pretty hard -- performance, booking algorithms, support for local tax practices -- but if AI slop is what finally gets us past those pain points, hey, bring it on.

[Timothy Jesionowski]

If you have access to a coding agent, fixing that old abandoned code isn't a huge slog like it used to be. Just fork it and tell the AI what your problem is.

Sincerely,

Timothy Jesionowski

--

You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/beancount/03fd2201-cefd-4a8a-a173-4b92a6093365n%40googlegroups.com.

[Stefano Zacchiroli]

On Sun, Jul 12, 2026 at 07:14:22AM -0500, Timothy Jesionowski wrote:
> If you have access to a coding agent, fixing that old abandoned code
> isn't a huge slog like it used to be. Just fork it and tell the AI
> what your problem is.

While that's true, it's also what worries me most: if each of us simply improves things *locally* and never shares them, that can become a serious impediment to the long-term sustainability of the Beancount community---indeed, of any community built around a shared FOSS codebase.

So if there's one thing I'd encourage all past, present, and future Beancount contributors to do when using agents to develop tools around Beancount, it's to publish and share their work under a FOSS license.
That maximizes the chances that, even if the original maintainer moves on, others can pick up the project (possibly with the help of agents) and continue improving it for themselves and the community. If you keep your fork only on your computer, that cannot happen, and we will all be worse off.

Cheers

[Timothy Jesionowski]

There's a tension between "release it as FLOSS, buyer beware, no warranty" and having an ecosystem that's accessible and friendly to those lacking the technical background and/or AI assistance to navigate immature technology. I don't think that's a reason to not release stuff, but OP thinks it is and I don't see what the crux of the disagreement is. Random code you find online has always been sorta marginal. Package repository maintainers solve the curation problem, but GitHub is not a packaging repository and neither is this mailing list.

Sincerely,

Timothy Jesionowski

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/beancount/fzc6ma4b6qv4z5gvn6rzj4y2gvzi55zeis2cc4quxeugjrbwko%40xtuj5ybxgxhj.

[Martin Blais]

On Sun, Jul 12, 2026, 22:08 Stefano Zacchiroli <za...@upsilon.cc> wrote:

That maximizes the chances that, even if the original maintainer moves on, others can pick up the project (possibly with the help of agents) and continue improving it for themselves and the community. 

This never happens (in the sense of almost never).