"It writes 100% of our code" - Silently closes the tab, and makes a remark to avoid given software at any cost.
150k lines of vibe coded Elixir: The good, the bad and the ugly
31–40 of 91 posts
Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly
#32> 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.
Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly
#33Async or mildly complex thread stuff is like kryptonite for LLMs.
Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly
#34It'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.
Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly
#35It'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.
Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly
#36> 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
#37It'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.
[flagged]
Just in case not, consider whether the short function
def is_even(x):
return (x%2) == 0
Handles a wider range of input conditions than the higher LOC function def is_even(x):
if x == 0:
return True
if x == 2:
return True
if x == 4:
return True
...
return FalseRe: 150k lines of vibe coded Elixir: The good, the bad and the ugly
#38It'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.
[flagged]
Why would I ever want a language with less capabilities?
Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly
#39It'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.
[flagged]
https://genius.com/Jorge-luis-borges-on-exactitude-in-scienc...
Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly
#40> 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.
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.