Welcome and Introductions

Welcome to the Allium community, the home for the LLM-native specification language that talks back.

This is the place to ask questions, share what you’re building, and help shape where Allium goes next.

To kick things off, it would be great to know more about you. No pressure to answer all of these, but here are some ideas:

  • Who are you and what do you work on?
  • How did you find Allium?
  • If you’re using it on a project, how’s it going? How is it helping? Have you discovered areas for improvement?

I’ll go first below. Looking forward to meeting you all.

Henry

I’m Henry. I head up the AI Chapter at JUXT, and Allium came out of a tension I kept seeing in how people write code with AI.

There are the “one-shotters”, who ‘just ask Claude to do it’ and see what comes back. Then there are the “markdown maximalists”, who try to pin everything down in a sprawling context graph. Both hit failure modes: doom loops (where at some point the AI anchors to the code you have rather than the code you want) and drift (where so much context accumulates that you can’t tell whether it’s up to date or what needs changing). Allium is an attempt to mitigate both.

I’ve used it building a few of our internal accelerators, and written up some of that experience here.

What I’d most like from this community is to hear how it’s going for you. The more we learn about where Allium helps and where it doesn’t, the better we can make it for this new age of AI-mediated software engineering.

1 Like

Hey :waving_hand: I’m James, one of Henry’s colleagues at JUXT, and I head up the engineering for XTDB, our bitemporal database.

I’m very much still learning about how best to use Allium on XT - I’ll often find myself thinking “ah, I should have used Allium for that” after I’ve finished a few rounds with Claude, so for me it’s about getting into that habit.

Cheers!

1 Like

Hey there :waving_hand:

I’m John, I’m Chief Architect at Overchain. I’m using Allium to aid the design and build of a new back-office to support our crypto and FX offerings.

I learned about Allium from Henry on LinkedIn! I’ve been using it since v1.

I think to begin with I wasn’t using it perfectly. I wasn’t directly using the Allium skill to help with the elicitation of new specs, something I’ve since rectified.

I think I’ve improved my usage now. Allium helps elicit all new specs, which capture some of the LLD. I then enforce a tri-check (hopefully Henry as per your recent blog post on this) across Alliums, code and tests.

I find using LLD/specs help with the understanding of an LLMs proposed solution, and they also provide useful durable context.

I don’t think I’m overstating it when I say this project wouldn’t be possible for a tiny engineering team without a tool such as Allium. I’m very grateful for all the work that’s gone into this, it’s been a huge enabler.

I’ll look forward to learning more about how you guys are using it and applying best practices.

Cheers folks!

1 Like

Hi :slight_smile:

  • Who are you and what do you work on?

I’m Jeremy and I also work on the XTDB team. Beyond my product management role I have a keen interest in malleable software.

  • How did you find Allium?

Henry mentioned it quite a few times before the penny dropped and I gave it a shot, but in retrospect I feel like Allium found me. “Formalizing intent” is an idea I’ve been independently chasing for well over a decade!

  • If you’re using it on a project, how’s it going? How is it helping? Have you discovered areas for improvement?

If nothing else, Allium has at least been extremely helpful for slowing me down and otherwise burning needless tokens.

I have an idea in the works that could yet become a blog series on my latest experiences of using Allium, watch this space. I’m looking forward to following along with others’ journeys likewise.

Hi I’m Willem, partner in QWAN, sometimes co-founder, long time XP practitioner. I am interested in Allium, as I often work on legacy systems. I took additional courses in formal methods at university (late 90s), and learnt that I was neither smart nor precise enough to use them at the time, and went with TDD instead (which has working in small steps in common with e.g. Edsger Dijkstra’s work).

I used to have more ideas than I could build, so over the past year and a bit I’ve prototyped several visual collaboration tools. I am done prototyping now, so slowly moving a port of a conference session review system to production. That has two Allium specs at the moment, as I am going slower. One for multi-tenancy, and one for flexible forms. I didn’t do the latter before, because before you know it it ends up being a programming language (think ABAP :wink:. I came of age with DBASE ).

I found Allium through Henry’s posts on LinkedIn.

How it helps on projects:

With Allium I prototyped a Federated Business Intelligence app (the blogpost there was written by Claude Code, apart from the Afterword) in under a day. I have built something like that before, would have taken months with a small team. Six domains, 200+ tests in a few hours (and then 250 more coming back with Allium after going too much ‘yes,yes yes’ on my phone). Paraphrasing Henry, I was mostly an iterative one-shotter in this. It would have taken longer with synthetic tests only. This was vibe formal methods - I did not look at the specs.

So Allium helps me go even faster. Not that I want to, I am now going at the speed of my comprehension. Being in a flow state is great, not knowing the day after what it is that I did, less so.

I think the Allium skills used to be two skills, now there are six. I am still getting to grips with that, mostly using the ‘router’ skill lazily.

For the conference session review system, I am going slower now. conversations with Claude Code and Allium helped me to get a language for flexible forms. Initially vibe formal methods as well. I integrated more of it with a kind of wizard in the application, making a small extension to the spec, and reading it. It does read like a small programming language, but as Henry calls it, the triple check seems to work well here.

A gap, and I doubt this is for Allium, is that it doesn’t help me to keep track of longer workflows in an application. I’m taking some inspiration from Swim the System by Ward Cunningham and others to tie test flows together visually. Correctness of validations etc. I can do with Allium and unit-ish tests, but longer flows I need to see (not to mention my users are not going to discuss abstractions in this case, so screenshots FTW).

Sorry, can’t make it shorter apparently :-). Thanks.

1 Like

How has it helped you slow down? (I am reading the specs now, that has helped me slow down, but it also ‘helped’ me go much faster, well past the speed of my understanding.).

I’m Dorab. Long time Clojure fan and user. Along with Nate and Ticean, I run the Los Angeles Clojure Users Group. Previously a Co-founder, CTO, and Chief Science Officer at MatchCraft. Currently self-employed and open to opportunities. Working on a few projects to learn new technologies.

I came to Allium via the JUXT - Clojure connection.

I first started using Allium about two months ago on a project. I prefer to spend most of my time and energy in defining and refining the architecture. Allium has been very helpful in that domain. Mainly to catch inconsistencies and missing items. I found that once the spec was written, LLMs could generate working code from that pretty reliably.

Henry has been incredibly responsive in fixing issues I’ve raised in the allium-tools repo.

1 Like

It’s fantastic to have you with us, Dorab! I remember you submitting PRs to another library of mine several years ago, which I appreciated. It has been great to see your contributions to Allium. :folded_hands:

Hi :waving_hand: I’m Tobias, an independent software architect and coach based in
Dortmund. Fifteen-odd years of Domain-Driven Design, and most of my work
sits in the step before the code: getting a domain’s language precise
enough that it survives contact with an implementation.

I found Allium through one of Henry’s LinkedIn posts, while building
Weltenwanderer — an event sourcing DSL and compiler. Reading the Allium
material was slightly uncanny: a lot of the same shapes, arrived at from
a different direction.

I’ve been sold on it ever since. The clearest win so far: it caught a
component that had been written but never wired in — the kind of gap that
looks fine in a diff, passes review, and surfaces much later.

What struck me is how much Allium already does before any code exists:
parse, validate, invariants, reachability, deadlock detection. A front end
with no back end — or rather, one where the back end emits tests and the
LLM writes the implementation, instead of the other way round.
Weltenwanderer goes the opposite way: it emits the implementation and
takes its correctness from the emission. Allium emits the oracle and takes
its correctness from three artefacts, produced separately, agreeing.

So my question for people using it in earnest: where has that agreement
caught something a generated implementation would have got right by
construction — and where has it let something through?


:robot: Transparency note: I often feel overwhelmed when writing introductions so I asked Claude to support me.