Anil Madhavapeddy

2025 Advent of Agentic Humps: Building a useful O(x)Caml library every day / Dec 2025

Agentic programming has been getting a hilariously bad rap in the OCaml community recently, but it's definitely here to stay despite the security and legal concerns. I realised that to form a useful opinion on all this, I needed to really get into using Claude with OCaml for real outputs and not just toy code. So this holiday month, I'm going to release a new useful OCaml library per day until Christmas using Claude Code: the advent of agentic humps is here!

• Day 1: Crockford for Crockford Base32 encoding.
• Day 2: Jsonfeed for an implementation of the JSONFeed 1.1 spec.
• Day 3: XDGe for a XDG Directory specifiction with Eio capabilities.
• Day 4: Claudeio for a Claude OCaml/Eio SDK so I can use Claude to write more Eio.
• Day 5: Bytesrw-eio Bytesrw/Eio adapter and automate opam metadata via a custom Claude skill.
• Day 6: Yamlrw for a pure OCaml Yaml 1.2 library, to replace ocaml-yaml's C binding.
• Day 7: Yamlt to allow jsont codecs to be serialised to Yaml as well as JSON.
• Day 8: Sortal: a contacts management CLI using Yaml, Git and Mosaic.
• Day 9: Sortal-Bonsai: adding a Bonsai_term terminal UI to Sortal via Async.
• Day 10: Sortal-Mosaic: adding a Mosaic terminal UI to Sortal via Eio.

I'm working through a large backlog of ideas that I'll figure out as each days goes on. Ideas thrown on the pile by colleagues include TCP connection reuse and pooling library with TLS support, HTTP cookie jar handling using Eio, Batteries-include HTTP(S) client library with redirect/cookies, digest vast amounts of Git and summarise it (see a preview), Zulip bindings using Requests and Eio, Kitty graphics protocol to show graphics in your terminal, client bindings for the JMAP protocol, client bindings for the Immich self hosted photo service, client bindings for the Peertube video service, generate image srcsets in various resolutions for websites, bindings to the karakeep url hosting service, DOI resolution of papers to structured metadata, and a Parquet library in pure OCaml. I'm also working on an io_uring OxCaml webserver if I can get the Linux kernel not crashing on me before Santa visits...

My overall goal is to accelerate the heck out of how I manage the growing data in this website. I've been building it as homebrew infrastructure for the past twenty five years, and now I want it to move from ad-hoc scripts to principled data management. I am also using the libraries to do data processing in the day job for the remote sensing of nature or evidence synthesis. I'll edit the above list every day to link to what I actually did.

I've picked these choices fairly carefully as they're not "core" libraries that are difficult to write and require functional ingenuity, but are instead problems that involve a fair amount of boilerplate code that is typically quite tedious to write in OCaml. Hand writing code might be on the ropes, but not quite out of action just yet! But first, let's establish some groundrules for if this is a good idea or not.

Isn't this just more AI slop code?

There's a definite gag reflex involved with releasing so much code: by prioritising quantity over quality, aren't I just contributing to the world of AI slop? However, the hypothesis I am exploring is that the software engineering process fundamentally changes when using agents towards specification driven development, which has always been the holy grail of functional programming.

There's been extensive discussion recently about the role of LLMs in open source elsewhere that informed my thinking. I liked Thibaut Mattio stating how he's approaching his own agentic software development:

AI writes a significant amount of the initial code, and I review, revise, and iterate on a large portion of it. That’s how I work these days. But the architecture, design, and core logic are very much the result of deliberate iteration and manual refinement. -- Thibaut Mattio, OCaml Discuss, 2025

Bryan Cantrill came up with a superb set of principles for LLM Usage at Oxide. In particular, he separates out using LLMs for reading, writing and coding. I totally agreed with him that I hate people sending me LLM-generated writing for me to review; I would rather get the raw prompt and use my own LLM+context rather than read through other people's slop.

LLM-generated prose undermines a social contract of sorts: absent LLMs, it is presumed that of the reader and the writer, it is the writer that has undertaken the greater intellectual exertion. (That is, it is more work to write than to read!) For the reader, this is important: should they struggle with an idea, they can reasonably assume that the writer themselves understands it — and it is the least a reader can do to labor to make sense of it. -- Using LLMs at Oxide, RFD0576, Dec 2025

However, there is an undeniable (and growing) power in the ability to generate code at scale using LLMs. I've been doing a lot of this with Python in recent months, but I find myself increasingly frustrated by the lack of typing guardrails involved with agentic coding there.

I believe that a strongly typed, modular language like OCaml could become one of the best languages for agentic coding in the longer term, with advances happening rapidly to cure the data deficiency problem for relatively obscure languages with smaller corpuses. Also, with OxCaml on the horizon, getting help with increasingly complex (but rewarding) code annotations such as modes and kinds sems essential.

Groundrules for the Advent of Agentic Humps

After reflecting on the recent discussions, I decided on these for my little December experiment:

• No AI-driven contributions to other people's code. All my slop stays in my own lane unless the other person agrees. Luckily my own research group is easy to bribe with some festive beer so I hope to get them (or you, my dear reader) to voluntarily help me judge the success or failure.
• Read every line of code that's tagged for release. Even if I haven't written it all, it's vital to look for howlers. However, intermediate pushes may have slop in them, so stick to the tagged releases.
• The library has to be used somewhere in my production code stack, for example this website. Time to eat my own agentic slop on my own knowledge bases!
• Build on great human designed code. LLMs do not replace or compete with well designed foundation libraries in the OCaml ecosystem like Eio, Core, Lwt or the Bunzli-verse. Each of these have different design ethoses, but if they didn't exist there is no scaffolding over which to compose LLM-driven code outputs. So this is not a competition to beat them, but rather to use them more effectively.

And overall, this process should not help me learn more about agentic workflows but also contribute to the wider discussion, so I'll capture what I learn in this blog series at the end.

Some non-rules:

• Keeping agentic code separate from my "real code" seems pointless nowadays, with LLMs everywhere. I tried that earlier in the year, but I fear the poisoning will have to be dealt with by other means.
• I'm trying to keep this specific to my own OCaml workflow, and not generalising this for a hypothetical other user. But you should feel free to fork this stuff.
• I have no idea how I'm going to maintain all these libraries once released. A problem for 2026. I'm not particularly attached to any of these libraries, so maintainance/rewrite offers are all fine by me.
• There's a reasonable chance some of this has some bad bugs, since it's not going through peer review. I'll do my best to handle test coverage, but please be tolerant. Bug reports are welcome.
• I've done my best to manually scan code and attribute copyright where possible, but there remains a chance I have horribly screwed up. Any errors in attribution are my own, but I'm going to press on and take the risk.

If anyone else wants to join in the Advent of Agentic Humps, ping me on whatever communication medium you like. Just remember the groundrules: don't waste other maintainer's time without their permission first.