Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

getboothiq.com

Post reply on HN
Print view View original

51–60 of 91 posts

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

#51

Post by vladraz »

vmg12 wrote: post #25
pmontra wrote: 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…

Why not just write to the db? Just make every test independent, use uuids / random ids for ids.

Frankly this is the better solution for async tests. If the app can handle multiple users interacting with it simultaneously, then it can handle multiple tests. If it can’t, then the dev has bigger problems.

As for assertions, it’s not that hard to think of a better way to check if you made an insertion or not into the db without writing “assert user_count() == 0”

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

#52

Post by tossandthrow »

ogig wrote: post #15
tossandthrow wrote: post #9

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.

What is your secret sauce? How do you organize your project?

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

#53

Post by simmanian »

cpursley wrote: post #30
te_chris wrote: post #27

The imperative thing is so frustrating. Even the latest models still write elixir like a JS developer, checking nils, maybe_do_blah helper functions everywhere. 30 lines when 8 would do.

Try these: - https://github.com/agoodway/.claude/blob/main/skills/elixir-... - https://github.com/agoodway/.claude/blob/main/agents/elixir-... - https://github.com/agoodway/.claude/blob/main/agents/elixir-... Getting pretty good results so far.

Haven't used skills so far -- do you simply store them in your skills directory and have them automatically get used or do you have to specify one of the skills every time?

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

#54

Post by manmal »

jonator wrote: 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.

Is an MCP really required for this?

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

#55

Post by cpursley »

simmanian wrote: post #53
cpursley wrote: post #30

Earlier quoted context omitted.

Try these: - https://github.com/agoodway/.claude/blob/main/skills/elixir-... - https://github.com/agoodway/.claude/blob/main/agents/elixir-... - https://github.com/agoodway/.claude/blob/main/agents/elixir-... Getting pretty good results so far.

Haven't used skills so far -- do you simply store them in your skills directory and have them automatically get used or do you have to specify one of the skills every time?

Yes regarding directory. They merged the concept of slash commands so I often do /elixir-genius to force it. Or if I just need subagents tell it to use "elixir-expert" or "elixir-qa" in parallel with other appropriate subagents. Also helps to put a mention in the Claude.md file.

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

#56

Post by Sharlin »

I don’t understand how the author can simultaneously argue that Claude is great at Elixir because it’s a small language with only one paradigm, and also that Claude is bad at Elixir, spewing out non-idiomatic code that makes little sense in the functional paradigm?

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

#57

Post by dnautics »

ok, so im "vibe-" building out my company's lab notebook in elixir ahead of the first funding check coming in.

im doing some heavy duty shit, almost everything is routed through a custom CQRS-style events table before rollup into the db tables (the events are sequentially hashed for lab notebook integrity). editing is done through a custom implementation of quill js's delta OT. 100% of my tests are async.

I've never once run into the ecto issues mentioned.

I haven't had issues with genservers (but i have none* in my project).

claude knows oban really well. Honestly I was always afraid to use oban until claude just suggesting "let's use oban" gave me the courage. I'll be sending Parker and Shannon a first check when the startup's check comes in.

article is absolutely spot on on everything else. I think at this point what I've built in a month-ish would have taken me years to build out by myself.

biggest annoyance is the over-defensiveness mentioned, and that Claude keeps trying to use Jason instead of JSON. Also, Claude has some bad habits around aliases that it does even though it's pretty explicitly mentioned in CLAUDE.md, other annoying things like doing `case functioncall() do nil -> ... end` instead of `if var = functioncall() do else`

*none that are written, except liveviews, and one ETS table cache.

[0] CQRS library: https://hexdocs.pm/spector/Spector.html

[1] Quill impl: https://hexdocs.pm/otzel/Otzel.html

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

#58

Post by michaelcampbell »

pjmlp wrote: post #46
viktorcode wrote: post #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.

Remember, there used to be a time programmers productivity was measured in LoC per hour. As such, this is high productivity! /s

> Remember, there used to be a time programmers productivity was measured in LoC per hour.

Do you remember such a time or company? I have been developing professionally since the early 1990's (and hobbyist before then), and this "truth" has been a meme even back then.

I'm sure it happened, but I'm not sure it was ever as widespread as this legend would make it sound.

But, there were decades of programmers programming before I started, so maybe it just predated even me.

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

#59

Post by christophilus »

mystifyingpoi wrote: post #40
vmg12 wrote: post #25

Earlier quoted context omitted.

Why not just write to the db? Just make every test independent, use uuids / random ids for ids.

> Just make every test independent That's easier said than done. Simple example: API that returns a count of all users in the database. The obvious correct implementation that will work would be just to `select count(*) from users`. But if some other test touches users table beforehand, it won't work. There is no uuid to latch onto here.

That’s why you run each test in a transaction with proper isolation level, and don’t commit the transaction— roll it back when the test ends. No test ever interferes with another that way.

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

#60

Post by dnautics »

manmal wrote: post #54
jonator wrote: 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.

Is an MCP really required for this?

sure, you could in principle write a script that calls into the running vm, executes code, and just make this a text-based command attached to a script + skill.

6 of one one-half dozen of the other.

At the point where you have a phoenix project in dev, you're already exposing an http endpoint, so the infra to not have to do a full on "attach to the VM and do RPCs" is nice, and you just pull tidewave in as a single dependency, instead of downloading a bunch of scripts, etc.

Post reply on HN