With many thanks to Anthropic for supporting the Ledger project

[John Wiegley]

As some of you who watch the GitHub activity may have noticed, I've been using AI a lot recently to help me increase the amount of testing coverage, address bugs, clean up some of the documentation and comments, add many more validation steps into our CI, and even modernize the codebase by updating it to C++17 standards. And then there's the rledger port to Rust as well that's been underway…

Yesterday, Anthropic gifted six months of usage of their Opus model to help further this development. With many thanks to them, my hope is that, using gifts like these, we will be able to get down to zero open bugs, 100% code coverage, and at least 10% further improvement in overall performance of common operations. And hopefully it won't even take six months to get there!

I also have a few other improvements planned, like rewriting the report query parser to use a real parser instead of the token-based hack that it uses now, as well as a better approach to external scripting that may allow for languages other than Python (while also improving the Python support that we have currently).

Stay tuned!

  John

[mb...@mbork.pl]

While I'm rather an LLM skeptic (even if I use Claude Code myself), this
is good news. May I humbly ask whether there's a chance of improving
the documentation, too? (Emacs Ledger mode, while great, could also use
some minor improvements.)

Since the common answer to such questions is "this is a FOSS project,
PRs are welcome", I think I can safely say that I can try and work on
a few aspects - either via submitting patches (especially for the docs)
or reporting bugs/feature requests.

Thanks for your work on Ledger, John! (BTW, I've been using it for well
over a decade now, being a former GNUCash user.)

Best,

--
Marcin Borkowski
https://mbork.pl

[Igbanam Ogbuluijah]

This is exciting news, John! 

Could Ruby be considered as one of those scripting languages? I will do my best to help with this one. Also, since you're already thinking about Reports — if it's not too much trouble — could you consider tabular views for these reports?

Thanks for the awesome work here as always. 

Igbanam

--

---
You received this message because you are subscribed to the Google Groups "Ledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ledger-cli/874imuke49.fsf%40mbork.pl.

[John Wiegley]

>>>>> "m" == mbork <mb...@mbork.pl> writes:

> While I'm rather an LLM skeptic (even if I use Claude Code myself), this is
> good news. May I humbly ask whether there's a chance of improving the
> documentation, too? (Emacs Ledger mode, while great, could also use some
> minor improvements.)

Hi Marcin!

Yes, I’m in the middle of a fairly large documentation revision -- both in the
code and the manual. The remaining stages of this plan are in the file:

https://github.com/ledger/ledger/blob/main/DOC-WORK-PLAN.md

I hadn’t considered updating the Emacs mode until you mentioned it, but that’s
a worthwhile next project after this.

John

[John Wiegley]

>>>>> "IO" == Igbanam Ogbuluijah <xigb...@gmail.com> writes:

> This is exciting news, John!
>
> Could Ruby be considered as one of those scripting languages? I will do my
> best to help with this one. Also, since you're already thinking about
> Reports — if it's not too much trouble — could you consider tabular views
> for these reports?

Alexis Hildebrandt has been talking about using SWIG so that almost any other
scripting language could be used. This would entirely remove all Python bits
from within Ledger, changing it to a calculational “core” library that
provides exports any other scripting languages can link into. It will depends
on all of the core types being able to map into that language (such as
amounts, balances, etc), but I intend to explore this further once my Claude
allocation resets tonight. Turns out that the Max 20x plan is nowhere near
enough for all the work I want to get done in this project!

> Thanks for the awesome work here as always.

Thank you all!

John

[John Wiegley]

>>>>> "IO" == Igbanam Ogbuluijah <xigb...@gmail.com> writes:

> Also, since you're already thinking about Reports — if it's not too much
> trouble — could you consider tabular views for these reports?

On the reporting question, it may be better for Ledger to provide better data
exporting so that other languages can turn that data into fancy reports of
various kinds. The core C++ engine already does quite a lot, and reports are a
much more highly personal thing that should be easier for the user to
customize and modify than what the current reporting schemes in Ledger allow
for (or that I could ever be able to fully predict).

John

[mb...@mbork.pl]

On 2026-03-05, at 06:22, "John Wiegley" <jwie...@gmail.com> wrote:

> Hi Marcin!
>
> Yes, I’m in the middle of a fairly large documentation revision -- both in the
> code and the manual. The remaining stages of this plan are in the file:
>
> https://github.com/ledger/ledger/blob/main/DOC-WORK-PLAN.md

I'm getting 404.

> I hadn’t considered updating the Emacs mode until you mentioned it, but that’s
> a worthwhile next project after this.

Thanks! I'll try to either submit a PR or at least report one annoying
bug I've noticed.

[John Wiegley]

>>>>> mbork <mb...@mbork.pl> writes:

>> https://github.com/ledger/ledger/blob/main/DOC-WORK-PLAN.md

> I'm getting 404.

I moved quickly enough that the result of all the work is now in main and has
been completed. At least for this first phase.

>> I hadn’t considered updating the Emacs mode until you mentioned it, but
>> that’s a worthwhile next project after this.

> Thanks! I'll try to either submit a PR or at least report one annoying bug
> I've noticed.

Thank you!

John

[Tavis Ormandy]

On 2026-03-05, John Wiegley wrote:
> Yesterday, Anthropic gifted six months of usage of their Opus model to help
> further this development. With many thanks to them, my hope is that, using
> gifts like these, we will be able to get down to zero open bugs, 100% code
> coverage, and at least 10% further improvement in overall performance of
> common operations. And hopefully it won't even take six months to get there!
>

I'm less enthusiastic about this, I feel like I have to keep watching
the repo like a hawk to make sure the features I use won't get broken by
claude in the next release :(

I know humans can break features too, but humans generate code at a
pace that other humans can keep up with.

Tavis.

--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger tav...@sdf.org
_\_V _( ) _( ) @taviso

[mb...@mbork.pl]

On 2026-03-21, at 03:41, Tavis Ormandy <tav...@gmail.com> wrote:

> On 2026-03-05, John Wiegley wrote:
>> Yesterday, Anthropic gifted six months of usage of their Opus model to help
>> further this development. With many thanks to them, my hope is that, using
>> gifts like these, we will be able to get down to zero open bugs, 100% code
>> coverage, and at least 10% further improvement in overall performance of
>> common operations. And hopefully it won't even take six months to get there!
>>
>
> I'm less enthusiastic about this, I feel like I have to keep watching
> the repo like a hawk to make sure the features I use won't get broken by
> claude in the next release :(

My (admittedly limited) experience with Claude is that it's a nice
productivity tool in the hand of a senior (or mid) programmer,
a possible time sink/procrastination tool in the hand of anyone, and
an analogue of a (sometimes slightly jamming) chainsaw operated by
a teenager with a hangover in the hand of a junior.

So, given John's expertise, I would be pretty assured that no breakage
should occur.

[Tavis Ormandy]

No, I mean, it's literally breaking features right now. I would strongly
recommend you check main branch to see if your ledger still works -
there's a good possibility you will have to make changes.

For example, if you use effective dates in automated transactions, they
probably won't work anymore:

= expr "cleared and aux_date"
assert aux_date != date

This was caused by a claude change:
https://github.com/ledger/ledger/commit/227dac58bf816ce687d1954d0c542f92d71ae7e1
Co-Authored-By: Claude Sonnet 4.6 <nor...@anthropic.com>

In fact, the way balance assertions work with effective dates is now completely
different, so if you use effective dates (e.g. 2001/12/12=2002/12/12 or
[=2021/12/12]), I would *strongly* recommend testing with main!

There's more, you used to be able to do this:

2018/12/31 * Test
Assets:Foo = $78.90
Assets:Bar

That won't work with --permissive anymore, another claude change broke it:

https://github.com/ledger/ledger/commit/a5e80a1cb2510b11c9756af5b483295201a10795
Co-Authored-By: Claude Sonnet 4.6 <nor...@anthropic.com>

The way the format directive works has also changed, you used to be able
to do things like this:

commodity $
format $1,000.00

But now that will generate warnings in strict mode if you use any
expressions, e.g.:

define salestax = 1.09625

2024/12/05 * Foo
Expenses:Bar ($6.99 * salestax)
Assets:Baz

https://github.com/ledger/ledger/commit/8da7395f23670f1d616617bb29f04b96b0be94dc
Co-Authored-By: Claude Sonnet 4.6 <nor...@anthropic.com>

I'm not sure if this is a bug or not, but the way regexes are escaped is
now different and this broke my ledger, e.g. this will now cause an
error, but used to work fine:

tag rating
assert value =~ /^\\*{0,5}$/

This was changed in:
https://github.com/ledger/ledger/commit/d84f628801b3babaacfebd240ba7a9f2907b86c0
Co-Authored-By: Claude Sonnet 4.6 <nor...@anthropic.com>

These are just the changes I bisected tonight that caused my ledger
files to stop working. If I don't use the feature I won't notice the
problem so can't report it. I would strongly recommend everyone on the
list check the features they use.

I still haven't got my ledger parsing fully with main yet, I'm slowly
working through the changes.

I personally value the stability, predictability and reliability of
ledger, and I'm just saying these changes worry me.

[Tavis Ormandy]

On 2026-03-21, Tavis Ormandy wrote:
> I still haven't got my ledger parsing fully with main yet, I'm slowly
> working through the changes.
>
> I personally value the stability, predictability and reliability of
> ledger, and I'm just saying these changes worry me.
>
> Tavis.
>

There was only one more change I needed to get my ledger to parse, the
way computed lot prices work has changed (e.g. 100 FOO @@ $1,000 and
{{$,1000}}).

This isn't really a bad idea, but it will break old ledgers that rely
on the way precision used to work, like mine :(

https://github.com/ledger/ledger/commit/b7029e469fbc6002bcf6bcddf0e7c895b252c2a6

Co-Authored-By: Claude Sonnet 4.6 <nor...@anthropic.com>

I think occasional breakage for complicated ledgers like mine is
understandable - that's why I test main to report problems before
release...but claude is making these rapidfire changes daily,
and I can't keep up.

[Simon Michael (sm)]

Those are some excellent regression reports.

I'm interested in this topic too of course. I will say it's incredibly
hard to avoid causing regressions for some existing data or workflows
when changing or fixing things in a PTA app, even with an extensive test
suite.

I wouldn't be sure if the AI use specially is the cause, or if AI was
simply the enabling factor allowing the human dev to become active.
Any dev activity increases the risk of breaking somebody's usage.

How could the risk be reduced ? More tests ? (AI could help with that.)
Stable and unstable branches ? Easy quick reporting & fixing of regressions ?

[John Wiegley]

>>>>> "TO" == Tavis Ormandy <tav...@gmail.com> writes:

> I'm less enthusiastic about this, I feel like I have to keep watching the
> repo like a hawk to make sure the features I use won't get broken by claude
> in the next release :(
>
> I know humans can break features too, but humans generate code at a pace
> that other humans can keep up with.

Hi Travis,

My apologies in advance for some of the breakages that will happen, although
it’s also true I’ve broken things as a human creating commits in the recent
past, so it doesn’t surprise me that Claude would sneak some of these past…

I had tried very hard to increase test coverage before letting the AI “loose”,
so to speak, in the hopes of nailing down existing behavior and restricting
modifications to only the bug being fixed. It appears, however, that the test
coverage is still not nearly good enough.

Given that, I think it’s likely time to let this experiment slow down, after
this weekend (more fixes coming tomorrow). Perhaps we need a few months now of
catching up and making sure that everything broken is righted again. Your
recent bug reports will help greatly with this, as I can turn each into a
regression test to guard these future breakage.

My goal right now is to get the issue list down to zero, if possible; to
increase testing and stability; and to get C++Ledger to a point where it
represents as much of a bug-free, stable base for accounting as possible.
There are further changes to be made to move further from Boost toward the
standard libraries, and to begin adopting some of the improvements in C++20.
But other than that I have no further major plans beyond testing and
stability.

John

[John Wiegley]

>>>>> "SM(" == Simon Michael (sm) <si...@joyful.com> writes:

> How could the risk be reduced ? More tests ? (AI could help with that.)
> Stable and unstable branches ? Easy quick reporting & fixing of regressions?

Good questions!

If I know there is a more active core of “early adopters”, I’d be happy to
move this AI development to a `next` branch, where it only release into `main`
once that group is happened that nothing significant has broken.

As it stands, the current `main` seems a little far from being ready for
release. It will need a good while for the dust to settle and the remaining
regression reports to come in, before I’m confident that it won’t break others
upon release.

John