The headline made me think of a bridge designed by an LLM, and I think to myself: thanks, I'll pass.
You sure? I would turn around :)
Vibe engineering
101–110 of 759 posts
Re: Vibe engineering
#102Funny I'm a professional engineer and happily call myself "vibe coding" when writing code these days, it started as tongue in cheek, but now I've embraced it. Being good at vibe coding is just being good at coding, the best practices still apply. I don't feel we need another term for it. It'll just be how almost everyone writes code in the future. Just like using an IDE.
[deleted]
[dead]
Re: Vibe engineering
#103Re: Vibe engineering
#104These seem like a lot of great ways to work around the limitations of LLMs. But I'm curious what people here think. Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs?
I see how if you can't really code, or you're new to a domain, then it can make a huge difference getting you started, but if you know what you're doing I find you hit a wall pretty quickly trying to get it to actually do stuff. Sometimes things can go smoothly for a while, but you end up having to micromanage the output of the agent too much to bother. Or sacrifice code quality.
Re: Vibe engineering
#105Earlier quoted context omitted.
If you’re looking at the AI-generated output then you’re not Vibe Coding. Period. Let’s not dilute and destroy the term just as it’s beginning to become a useful label.
Wait, are people not reading the AI code they use?
People of course often do read (and even modify) the model-generated code, but doing so is specifically not “vibe coding” according to the original definition, which was not meant to encompass “any programming with an LLM” but something much more specific: https://simonwillison.net/2025/Mar/19/vibe-coding/
Re: Vibe engineering
#106vibe engineering, spending so much time writing documentation for the prompt, just to spend more time debugging the slop you get.
Ill stick with writing code and just use AI for snippets/stackoverflow replacement.
Re: Vibe engineering
#107Funny I'm a professional engineer and happily call myself "vibe coding" when writing code these days, it started as tongue in cheek, but now I've embraced it. Being good at vibe coding is just being good at coding, the best practices still apply. I don't feel we need another term for it. It'll just be how almost everyone writes code in the future. Just like using an IDE.
likewise, for a lot of frontend I "vibe code" it. I mostly don't look at the code anymore while doing it either, after I get where I want, I will look through the code and maybe clean stuff up. But a lot of the code is fine. Works really well I find. (using Augment Code with Claude Sonnet 4.5).
Re: Vibe engineering
#108A better term would be “Augmented Engineering” (AE). You want something to inspire engineers to do their best work. When you can expand your capabilities using the power of AI, then yeah, you can do your best work; hence augmented engineering . But vibing? Not so much. I guess AE could also stand for Advanced Engineering , after all the AI gives you the power to access and understand the latest in engineering knowled…
I wouldn't worry too much about what to call it. Assigning a distinct label separates it from traditional engineering in a way that it assumes AI-assisted coding is only for a subset of developers. At some point the unusual approach will be writing code without any AI assistance. So the transition will leave the "vibe" behind.
Re: Vibe engineering
#109These seem like a lot of great ways to work around the limitations of LLMs. But I'm curious what people here think. Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs? I see how if you can't really code, or you're new to a domain, then it can make a huge difference getting you started, but if you know what you're doing I find you hit a wall pretty quickly trying to…
They're so nice for prototyping ideas and not becoming attached to the code due to sunken cost. I was playing around with generating intelligent diffs for changelogs for a game. I wasn't sure what approach to highlighting changes I wanted to take without being able to see the results.
Prior to vibe-coding, it would've been an arduous enough task that I would've done one implementation, looked at the time it took me and the output, and decided it was probably good enough. With vibe-coding, I was able to prototype three different approaches which required some heavy lifting that I really didn't want to logic out myself and get a feel for if any of the results were more compelling than others. Then I felt fine throwing away a couple of approaches because I only spent a handful of minutes getting them working rather than a couple of hours.
Re: Vibe engineering
#110Earlier quoted context omitted.
I've yet to get any quality code out of one, though I don't try particularly hard either. I'd rather spend my time actually coding, especially since all the positive stories about enhanced productivity are anecdotes, and the hard data remains far less supportive of the claim.
While I don’t agree with you, I keep a healthily skeptical outlook and am trying to understand this too - what is the hard data? I saw a study a while ago about drops in productivity when devs of OSS repos were AI assisted, but sample size was far too low and repos were quite large. Are you referring to other studies or data supporting this? Thanks!
Ithink there are also 2 factors to this.
1. Learning curve: Just like any skill there is a learning curve on how to get high quality output from an LLM.
2. The change in capabilities since recent papers were authored. I started intensively using the agentic coding tools in May. I had dabbled with them before that, but the Claude 3.7 release really changed the value proposition. Since May with the various Claude 4, 4.1 and 4.5 (and GPT-5) the utility of the agentic tools has exploded. You basically have to discard any utility measure before that inflection point, it just isn't super informative.