Why "in the public API"? Does this imply it's using unsafe behind the hood? If so, what for?

As a side note and this isn't a knock on your project specifically. I think the community needs to normalize disclaimers for "vibe-coded" packages. Consumers really need to understand the potential risks of relying on agent-generated code upfront.

This is a point I've tried to advocate for a while. Specially to empower non coders and make them see that we CAN approach automation with control.

Some aspects will be the classic unit or integration tests for validation. Others, will be AI Evals [1] which to me could be the common language for product design for different families/disciplines who don't quite understand how to collaborate with each other.

The amount of progress in a short time is amazing to see.

- [1] https://ai-evals.io/

It’s time to make this mandatory.

Nothing against AI - just to inform people about quality, maintainability and future of this library. No human has mental model of the code, so don’t waste your time creating it - the original author didn’t either.

libxml2 is always one of those libraries that i used to have trouble with for different platforms

I think its great that more and more OSS projects get attention now with ai coding agents

Doesn't seem to have shut down or even be unmaintained. Perhaps it was briefly, and has now been resurrected?

I know a few companies have programs where engineers can designate specific projects as important and give them funds. But it doesn't happen enough to support all the projects that currently need work, maybe AI coding tools will lower the cost of maintenance enough to improve this.

I do think there are two possible approaches that policy makers could consider.

1) There could probably be tax credits or deductions for SWEs who 'volunteer' their time to work on these projects.

2) Many governments have tried to create cyber reserve corps, I bet they could designate people as maintainers of key projects that they rely on to maintain both the projects as well as people skilled with the tools that they deem important.

As for the workflow, I think the best advice I can give is to setup as many guardrails and tools as possible, so Claude and do as many iterations before needing any intervention. So in this case I setup pre-commit hooks for linting and formatting, gave it access to the full testing suite, and let it rip. The majority of the work was done in a single thinking loop that lasted ~3 hours where Claude was able to run the tests, see what failed, and iterate until they all passed. From there, there was still lots of iterations to add features, clean up, test, and improve performance - but allowing Claude to iterate quickly on it's own without my involvement was crucial.

The only usages of unsafe are in src/ffi, which is only compiled when the ffi feature is enabled. ffi is fundamentally unsafe ("unsafe" meaning "the compiler can't automatically verify this code won't result in undefined behavior") so using it there is reasonable, and the rest of the crate is properly free of unsafe.

Unlike the development work of old (pre-2025), work with high-end models incurs a very direct monetary cost, one burns tokens which cost money, and you can't have something as powerful to be running locally (even if you happened to have a Mac Pro Ultra with RAM maxed out).

Some of my friends burned through hundreds of dollars a day while doing large amounts of (allegedly efficient) work with Claude Code.

none of your arguments make sense here