How an experienced developer teamed up with Claude to create Elo programming language

Bernard Lambeau, a Belgium-based software developer and founder of several technology companies, created a programming language called Elo with the help of Anthropic's Claude Code. Starting on December 25, 2025, he published a series of posts about the project. The first post names Claude as a co-author. "In roughly 24 hours …

[Anonymous Coward]

Someone with appropraite skills manages to use 'AI' in useful way !!!

"Lambeau, who has a PhD in software engineering and 30 years of experience as a developer"

Says everything you need to know !!!

'AI' in the hands of 'Joe Public' will not be creating any new language 'soon' ...

All these exercises do is to confirm what we already know ... 'AI' is not a tool that is useful to the general public, it requires skills to 'guide' it to give meaningful output. Those skills need to include some knowledge about the 'thing' you are querying the 'AI about.

'AI' is not a black box that gives 'right' answers to general questions.

It 'may' sometimes BUT as you cannot predict when this happens you need to have some method to cross-check the output against 'reality' and 'truth'.

:)

[LessWileyCoyote]

Re: Someone with appropraite skills manages to use 'AI' in useful way !!!

Also if you use AI to drastically reduce the workforce now, you run the risk in future of not having a supply of people with enough experience to know how to use the tool safely and productively.

Cue more recruiters searching for 18-year-olds with 20 years' experience.

[Not Yb]

Fairly sure I saw a similar one back in 1997...

"Seeking Java Programmer, must have 5 years experience." which in 1997, narrowed it down to the people who were involved in writing Java.

[Jason Hindle]

Re: Fairly sure I saw a similar one back in 1997...

Back in the early 90s, I worked with a (highly skilled and capable) chancer who claimed ten years Visual Basic experience.

[sketharaman]

Re: Someone with appropraite skills manages to use 'AI' in useful way !!!

No RISC no return.

[JLV]

Re: Someone with appropraite skills manages to use 'AI' in useful way !!!

If anyone gets a chance, go read Flatline, a short story by Walter Jon Williams from 1988.

https://www.goodreads.com/book/show/1343099.Facets

Dystopian future. Hero is very smart and he is revolting against the AIs and the 2% (that's literally the number and it matches our 1%). They're gonna spike their code or something with a cyber-virus (Williams is a contemporary of Gibson, less lyrical, more tech-savvy). Humans haven't been written out of the loop. He's not oppressed, doesn't even seem really poor (short story, the world building is narrow). But he doesn't matter - the 2% top folk, to whom he repeatedly alludes, work with the AIs, everyone else seems to be on a generous universal basic income, feeling pointless. I suspect that is closer to the likely mark, under those conditions, than Banks' Culture.

Mind you, the AIs there seem a LOT more competent than our Mecha Hitler wannabes.

Do I believe we are going to end up there? Not necessarily. 1984 didn't really happen (at least not until its 2016/2024 stirrings), partially because it was written in the first place. But it served a purpose.

One worrying thing with the AI boom (besides its current unreliability) is that it is NOT matched by a commensurate gain in manufacturing / physical things capability by robots or the like. I.e. if all the customer service, white collar workers, programmers are out of a job, there is NO Star Trek / Culture handwavium to take up the slack to make things for cheap. The well paid jobs nuked, there is no Post-Scarcity mechanism to match even this story. You'll still need people to pick up garbage, till the fields... With no one with money to pay them for doing hard physical labor. What about the 2%? Could they pay that UBI? Well, look at how historically those folk have approached their 300x pay packages: all the heartwarming generosity and selflessness of a dragon sitting on a hoard of gold, angling to pickpocket a kid for his lunch money.

Snake Ouroboros, eating its tail

Maybe HG Well's Morlock / Eloi is an even better match. Hope not. We'll figure it out, eventually, and probably not by going Communist. But it need not be pretty along the way.

[Alumoi]

Re: Someone with appropraite skills manages to use 'AI' in useful way !!!

I'm sorry, but for 1984 to happend Idiocracy has to be completed. I'd say 10 years top and we're there.

[rshpount]

Re: Someone with appropraite skills manages to use 'AI' in useful way !!!

In case you missed the memo, 1984 was written based on Orwell's personal experiences working for the BBC. Putting all the events in the future was just a way to get it published.

[sketharaman]

Re: Someone with appropraite skills manages to use 'AI' in useful way !!!

Kudos for self-serving answer but "meaning" depends on the eyes of the beholder. AI is a tool that's very much useful to general public to do stuff that *they* find meaningful.

[frankvw]

Re: Someone with appropraite skills manages to use 'AI' in useful way !!!

"'AI is not a tool that is useful to the general public, it requires skills to 'guide' it to give meaningful output."

Indeed. However, isn't that just as true for every tool? I've seen a seasoned carpenter wield a hammer in a way I (as an amateur woodworker) can't ever hope to even imitate, far less approximate. On the other hand, I can solder electronic components according to military specs, which is quite a bit beyond the average repair tech with access to the same fancy tools as I used.

That's the thing - AI is a tool. It's not the tool; it's the skill with which it is used.

[Paul Crawford]

It seems a common thing for software engineers to try and "solve" today's problems by inventing yet another new language, rather than creating tools that can help fix/mitigate the risks in the already written code that so much of the world now depends upon.

[ecofeco]

This.

We have all the tools we need already. But it's such a shit shambles with only a few bright gems scattered among it. And LLM will fail for the same reason.

As I've said, the cart is so far ahead of the horse you can't even see it any more. The world needs to consolidate and refine what it already has.

[that one in the corner]

> rather than creating tools that can help fix/mitigate the risks in the already written code that so much of the world now depends upon

You do know that languages *are* tools, don't you?

> Elo is intended as a portable way to handle form validation, e-commerce order processing, and subscription logic

So, if you have "already written code" that has problems (and maybe a few interesting risks) because it is spreading its form validation etc across all sorts of strange places, maybe the best thing to do is to look for a language that is designed to represent them, gather together all the necessary logic from the old code, write it out in a consistent fashion using this new (to you) language and, in doing so, make it easy to spot where the inconsistencies and unfortunate holes have crept in. Run the compiler, generate new, fixed, code. Oh, and make damn sure that your build system now treats ONLY the new descriptions as "the source" for those bits, no committing any compiler output into the source tree, even if it does happen to be readable to you.

The "big languages" that we've all heard of are, numerically, only a small fraction of the set of (very practical and *extremely* useful, in their domain) computer languages in daily use. There is a whole field of "Little Languages" dedicated to creating task-specific languages. (An awful lot of them seem to be written in XSLT at one point in time, resulting in too much XML being written by hand, but that is yet another topic we can get sidelined into).

Not all risks and other problems can be fixed by this method, of course. Well-known issues like memory overruns, for example. But there is no point in railing against a method because it doesn't immediately fix all the problems - and piecewise replacing unsafe old stuff with new code generated from (hopefully) a declarative form will zorch any overruns that may have been lurking in there...

[Paul Crawford]

So, if you have "already written code" that has problems (and maybe a few interesting risks) because it is spreading its form validation etc across all sorts of strange places, maybe the best thing to do is to look for a language that is designed to represent them, gather together all the necessary logic from the old code, write it out in a consistent fashion

Meanwhile in the real world if you have an X-kloc project written in in $LEGACY_LANGUAGE you are very, VERY, unlikely to rewrite the whole thing. Not only is that a massive cost in time, it also opens a whole set of new opportunities for logic errors to be introduced (e.g. who is still around who really understood how it should work?). So folks just apply sticking plaster after plaster to deal with it.

This is the problem. If you take C/C++ as the current whipping boy of languages as it offers such a wide and interesting range of opportunities to shoot one's own feet, many say "Why not use a memory-safe language?" and today the language du jour is Rust. But that is missing the obvious point that (a) the code already exists, and (b) there have been many safer languages available over the past 50 years that could have been used, such as Pascal, Ada, Java, FORTRAN (yes, generally memory safe as usually without dynamic memory use and offers array bounds checking at runtime...). But there were not. So why is someone suddenly going to take on a re-write in something else now?

So if AI was genuinely capable, and someone could wrangle it well enough, maybe they could write a tool that would take some existing code, for example C/C++, and then apply all of the existing tools to check it. Such as full compiler flags, static analysis like lint/Coverity scan/ etc, and run-time memory tools like valgrind and electric_fence, to analyse, fuzz-test, and offer fixes for the daemons within.

[Daniel Pfeiffer]

And again we reduce Rust to memory safety… That overlooks Sir Tony Hoare’s billion dollar mistake, null pointers, for which pretty much only Rust (and SQL) enforces safety. Then most people don’t understand, that memory safety actually comes in two flavours:

- memory access safety (enforced through ownership and borrow checker,) which is a fundamental basis of good software engineering. Few talk about it, because in other languages it’s only optional.

- memory management safety is what lack of dynamism gives you. The fairly expensive garbage collector (especially when you have one on each microservice, competing to ruin your latency) does too. Only Rust gives this for dynamic memory without garbage collection, enabled through memory access safety.

There are more safeties that Rust gives:

- data race safety, again because the compiler knows what’s going on with your values, in combination with the strong type system. The latter marks those types and/or wrappers that are safe to use in sync, or to be sent to another thread. Anything else will not compile saving you nasty debugging down the road.

- dead lock safety is not automate-able. However, after giving up on their deadlock prone Netstack2 in Go-lang, Google ported it to Rust. Here again thanks to the strong type system, they embedded each lock in a compiler verified state machine they created inside the type system. This allows all threads to only ever acquire locks in the same order – guaranteed at compile time.

[Paul Crawford]

And again it misses my point completely: Existing software is a big problem that is very unlikely to be solved by a re-write in any new language.

Is this new Elo better than Rust? Is Rust any better than Ada? How many angels can dance on the head of a pin?

A tool to fix the sea of existing C/C++ code that is of dubious quality would be more valuable than ecumenical discussions.

[Paul Crawford]

That overlooks Sir Tony Hoare’s billion dollar mistake, null pointers, for which pretty much only Rust (and SQL) enforces safety.

I'm not much of an expert in other languages, but I'm pretty sure that Pascal, Python and many other languages don't allow direct memory access (i.e. pointer manipulation).

Null pointers are pretty much only a crash risk, they segfault programs and possibly allow denial of service attacks. More dangerous by far is memory array overrun and use-after-free as they allow injection in to the running process and from there the possibility of code execution, etc. Again, I'm pretty sure that many languages (other than C/C++ and minor variants thereof) protect against this sort of error by default

[Not Yb]

Inventing a new computer language just moves the problem a bit...

(You in this is the 'generic you', not specific to the previous poster.)

If you invent a new language that more closely matches what you want to be able to solve, you have (at best) moved the problem from "how do I write the code" to "how do I fix the compiler/interpreter so that it's secure against x/y/z attacks." Sure it's 'easier' to write in some new language you've just created. It's less secure against anything that you didn't consider when writing the compiler and language.

I think we've already got too many special-purpose languages. A list consisting of only 'notable' ones (current or historically used) runs to several hundred for various purposes (including general code, but also... COBOL).

[myhandler]

So there'll be a language for every type of action?

language-model–view–controller? kewl

[Anonymous Coward]

In this language, 90% of functions must start with 'use'.

Oh, wait, that language already exists, doesn't it?

[b0llchit]

Reflections on Trusting Trust

"In roughly 24 hours of collaboration, we built a complete expression language with a parser, type system, three compilers, a standard library, a CLI tool, and a documentation website. Not bad for a day's work,”

I think everybody must (re-)read: Reflections on Trusting Trust by Ken Thompson (yeah, that Ken) and ask yourself who and what you could/would/should trust.

[vtcodger]

Re: Reflections on Trusting Trust

A good point.

And consider also this quote I just came across from the guy who created the first chatbot (ELIZA) in 1966 which may or may not be apropos Weizenbaum was surprised by this, later writing: "I had not realized ... that extremely short exposures to a relatively simple computer program could induce powerful delusional thinking in quite normal people." https://en.wikipedia.org/wiki/ELIZA

[Ropewash]

Re: Reflections on Trusting Trust

A quote that remains just as true for ELIZAs current descendants as it was back then.

Just because they've built an n-dimensional ELIZA doesn't mean it's not subject to the same fundamental limitations.

[Anonymous Coward]

Re: Reflections on Trusting Trust

AI guys are all "We've invented this WHOLE NEW THING that is completely unrelated to anything before it."

Actual Computer Scientists "A 300B parameter Eliza is sometimes useful, but please stop calling it intelligent."

[Roland6]

Re: Reflections on Trusting Trust

Perhaps those pushing AI aka ChatGPT et al know this and want to create lots of “addicts” by encouraging general public to use AI so they think the AI is doing more than it really is; a stochastic parrot.

[William Towle]

@b0llchit - Recommended reading?

> I think everybody must (re-)read: Reflections on Trusting Trust by Ken Thompson _[...]

...not least because AI already has. --> /o\

[b0llchit]

Re: @b0llchit - Recommended reading?

I rest my case.

[Paul Herber]

Elo - It's a Living Thing.

[Pickle Rick]

It's the latest in technology, almost mythology.

[Paul Herber]

it's magic.

[ecofeco]

It's a livin' thing

It's a terrible thing to lose

It's a givin' thing

What a terrible thing to lose

I'm takin' a dive

Dive

[that one in the corner]

I've looked at Claude from both side now

Oops, sorry, that was Joni; forget I said that, don't want to cause any violinski to this threadski.

[m4r35n357]

Don't bring me down

[O'Reg Inalsin]

Silence speaks loudler than words

The cost to do this, Lambeau said, has been a Claude Max subscription that he purchased in December for €180 a month. In that time, he says, he wrote Elo, completed Bmg.js , completed Bmg's documentation, and created the first version of the Try page.

Claude uses rolling 5‑hour “sessions” with a usage cap per session - once that limit is hit, ordinary users must wait for the clock to reset the limit. Some power user of Max have, on occasion, reported running into that wall, [BUG] Instantly hitting usage limits with Max subscription #16157, but Prof. Lambeau doesn't mention the topic at all. Of course those could just be glitches.

There is absolutely no evidence that Prof. Lambeau was given any extraordinary access to resources, implicitly or explicitly, to enable continuous and autonomous agent performance: "I've started by making sure the testing methodology was effective and scientifically sound. Claude writes the tests, executes them, discovers where it's wrong, and corrects itself. Impressive." It also possible he did run into limits, but just didn't mention it.

[david 12]

" It's not built-in in any mainstream language"

Language design took a strange u-turn after 4GL languages

[Not Yb]

Next week's article:?:

"_______ has written a new AI-only programming language that only LLMs can code in. Vibe coding is required to use it, and is actually the only tool that can successfully write programs in it. Here's how it works: You ask Claude to write code only it can understand..."

[ecarlseen]

Creating a language / toolchain is the ultimate in cherry-picking

Honestly, is there any topic in computer science that has been more heavily researched, written about, examples created, real-world polish applied with excruciating care over decades, in academia, business, and in the hobbyist / open source world, than language and compiler design?

There is ~75 years of thoroughly-documented history here.

As a topic for an LLM to crunch on, this is absolute cheat mode compared to pretty much any other meaningful product-size project.

If somebody uses AI in this manner, at this scale, to create a work product that can be used by a meaningful number of real people in the real world doing valuable things, then I will be genuinely impressed and amazed.

Don't get me wrong: this is still a very cool trick, but it's a trick with no real-world value (at least for now) and is not even close to being generally reproducible.

[A.Lizard]

You don't have to create program languages

I'm getting KICAD ECAD.schematic symbols based on module images with labeled pinouts and building original web apps using the regular chat interface at the free account level of Claude.ai

Clear, unambiguous instructions, reviewing output based on deep understanding of task & context.

At this point in AI development, AI is useful as an amplifier for your ideas, but:

"The machine has no brain. Use your own.

[DougieElDougo]

News flash

Kernighan and Ritchie credit paper and pencil as co-authors of C programming language.

Brendan Eich names his computer as co-author of JavaScript language.

AI is a tool not a person.