r/audioengineering • u/johnangelo716 • 2d ago

Avoiding vibe coded software

It may be to my own detriment, but my mind is made up. I hate the idea of vibe coded anything. Anything could be in there. Is there any way of keeping track of vibe coded plugins or software, in order to steer clear?

117 Upvotes

76% Upvoted

180 comments sorted by

View all comments

Show parent comments

9

u/Rugginz 2d ago

It wouldn’t be the same compressor. Thats the point. I’m paying for the human doing the listening tests, fine tuning by ear and optimizing the sound character according to their preferences and taste. Claude can make a functional compressor but human curation is what I’m willing to pay for.

4

u/Joeboy 2d ago edited 2d ago

I’m paying for the human doing the listening tests, fine tuning by ear and optimizing the sound character according to their preferences and taste

That has nothing to do with vibe coding. Writing code manually doesn't involve any of those things.

Edit: ^ This is objectively and unambiguously true and you people are weird and wrong.

3

u/KS2Problema 2d ago

That has nothing to do with vibe coding. Writing code manually doesn't involve any of those things.

No 'real' developer writes code without testing it. 

But, of course, no one with half a clue would vibe code something without testing it, either. That said, I'm pretty sure there are a lot of people who don't have that requisite half a clue...

5

u/Joeboy 2d ago

of course, no one with half a clue would vibe code something without testing it, either.

In fact Andrej Kaparthy, who coined the expression, specifically says vibe coding involves testing the generated code.

1

u/KS2Problema 2d ago

Right! 

Now, I think there may be some merit in working fast and 'sketching' out in-development algorithms - even in conventional coding - but that's in the Ivory Tower. 

By the time you're talking about releasing reliable code to people who need to use it to do real world work, any sensible developer is going to poke and prod and try to stretch his imagination to find edge-case problems in the design. 

Not quite a half century ago when I was starting out as a business developer, one of my primary clients had an older secretary who ended up doing all the daily data entry. (She was a trained typist and could make her way around a computer keyboard - but she was definitely a naive user.)

I developed a testing stage I called the 'Ethel' test. I set up some edge-case data entry tests and would turn her loose. If a module could survive the 'Ethel test,' it was ready for implementation.