Live data from Hacker News

150k lines of vibe coded Elixir: The good, the bad and the ugly

getboothiq.com

11–20 of 91 posts

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#11
> In Elixir tests, each test runs in a database transaction that rolls back at the end. Tests run async without hitting each other. No test data persists.

And it confuses Claude.

This way of running tests is also what Rails does, and AFAIK Django too. Tests are isolated and can be run in random order. Actually, Rails randomizes the order so if the are tests that for any reason depend on the order of execution, they will eventually fail. To help debug those cases, it prints the seed and it can be used to rerun those tests deterministically, including the calls to methods returning random values.

I thought that this is how all test frameworks work in 2026.

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#12
post #11

> In Elixir tests, each test runs in a database transaction that rolls back at the end. Tests run async without hitting each other. No test data persists. And it confuses Claude. This way of running tests is also what Rails does, and AFAIK Django too. Tests are isolated and can be run in random order. Actually, Rails randomizes the order so if the are tests that for any reason depend on the order of execution, they w…

I did too, and I've had a challenging time convincing people outside of those ecosystems that this is possible, reasonable, we've been doing it for over a decade.

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#13

It's interesting that Claude is able to effectively write Elixir, even if it isn't super idiomatic without established styles in the codebase, considering Elixir is a pretty niche and relatively recent language. What I'd really like to see though is experiments on whether you can few shot prompt an AI to in-context-learn a new language with any level of success.

I tried different LLMs with various languages so far: Python, C++, Julia, Elixir and JavaScript.

The SOTA models come do a great job for all of them, but if I had to rank the capabilities for each language it would look like this:

JavaScript, Julia > Elixir > Python > C++

That's just a sample size of one, but I suspect, that for all but the most esoteric programming languages there is more than enough code in the training data.

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#14
post #4

I can attest to everything. Using Tidewave MCP to give your agent access to the runtime via REPL is a superpower, especially with Elixir being functional. It's able to proactively debug and get runtime feedback on your modular code as it's being written. It can also access the DB via your ORM Ecto modules. It's a perfect fit and incredibly productive workflow.

Some MCP's do give the models superpowers. Adding playwright MCP changed my CC from mediocre frontend skills, to really really good. Also, it gives CC a way to check what it's done, and many times correct obvious errors before coming back at you. Big leap.

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#15

It seems like the 100% vibe coded is an exaggeration given that Claude fails at certain tasks. The new generation of code assistants are great. But when I dogmatically try to only let the AI work on a project it usually fails and shots itself in its proverbial feet. If this is indeed 100% vibe coded, then there is some magic I would love to learn!

My last two projects have been 100% coded using Claude, and one has certain complexity. I don't think there is coming back for me.

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#16
post #13

It's interesting that Claude is able to effectively write Elixir, even if it isn't super idiomatic without established styles in the codebase, considering Elixir is a pretty niche and relatively recent language. What I'd really like to see though is experiments on whether you can few shot prompt an AI to in-context-learn a new language with any level of success.

I tried different LLMs with various languages so far: Python, C++, Julia, Elixir and JavaScript. The SOTA models come do a great job for all of them, but if I had to rank the capabilities for each language it would look like this: JavaScript, Julia > Elixir > Python > C++ That's just a sample size of one, but I suspect, that for all but the most esoteric programming languages there is more than enough code in the tra…

I've used CC with TypeScript, JavaScript and Python. Imo TypeScript gives best results. Many times CC will be alerted and act based on the TypeScript compile process, another useful layer in it's context.

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#17
I'm a bit lost on few bad and ugly points.

They could've been sorted with precise context injection of claude.md files and/or dedicated subagents, no?

My experience using Claude suggests you should spend a good amount of time scaffolding its instructions in documents it can follow and refer to if you don't want it to end in the same loops over and over.

Author hasn't written on whether this was tried.

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#18
post #11

> In Elixir tests, each test runs in a database transaction that rolls back at the end. Tests run async without hitting each other. No test data persists. And it confuses Claude. This way of running tests is also what Rails does, and AFAIK Django too. Tests are isolated and can be run in random order. Actually, Rails randomizes the order so if the are tests that for any reason depend on the order of execution, they w…

I did too, and I've had a challenging time convincing people outside of those ecosystems that this is possible, reasonable, we've been doing it for over a decade.

Story of my life in so many dimensions.

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#19
It's the second time today when I see that the higher number of LoC is served as something positive. I would put it strictly in "Ugly" category. I understand the business logic that says that as long as you can vibe code away from any problems, what's the point of even looking at the code.
Post reply on HN