Earlier quoted context omitted.
Why the hostility? We can have a civil discussion without relying on throwaway accounts.
[flagged]
This isn't X, please maintain community standards.
Vibe engineering
111–120 of 759 posts
Re: Vibe engineering
#112These 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…
> Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs?
No, I just put in less effort to arrive at the same point and do no more.
Re: Vibe engineering
#113These 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 a…
I agree, prototyping seems like a great use-case.
Re: Vibe engineering
#114A 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.
Hear, hear.
Re: Vibe engineering
#115These 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…
I would say I get more (I've been coding 40+ years). I get pretty good results, I find a lot has to do with crafting your prompts well. I think knowing what the outcome should be, technically, makes a big difference. It's getting less and less where I have to argue with the AI / do it myself. Not to mention the amount of little productivity / quality of life scripts I get it to create. They really smooth out a lot of things. I feel like its more heading towards "solution engineering" rather than coding where I'm getting a lot more time to think about the solution and play with different ideas.
Re: Vibe engineering
#116Earlier quoted context omitted.
> My issue with this term is that it muddies the waters for people who are using LLMs to assist with types of engineering beyond just writing code. I'm now imagining me dying as a vibe-engineered truck has a steering/brake failure and crashes into me sending flying through the vibe-engineered papier-mâché bridge guardrails, and feeling sweet sweet release as I plummet to my doom.
It's easy to confuse cynicism for humor. Look, if you enjoy calculating a table of dozens of resistor value combinations for a feedback network that prefers reels you have on your PnP, you keep knocking yourself out.
If you're using LLMs for a large number of arithmetic calculations, you're exactly the problem GP is talking about.
If you absolutely must use AI get it to generate code that will perform the calculations instead, so that you can actually verify the result.
Re: Vibe engineering
#117These 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…
My experience is it often generates code that is subtlety incorrect. And I'll waste time debugging it.
But if I give it a code example that was written by humans and ask it to explain the code, it gives pretty good explanations.
It's also good for questions like "I'm trying to accomplish complicated task XYZ that I've never done before, what should I do?", and it will give code samples that get me on the right path.
Or it'll help me debug my code and point out things I've missed.
It's like a pair programmer that's good for bouncing ideas, but I wouldn't trust it to write code unsupervised.
Re: Vibe engineering
#118Earlier quoted context omitted.
wait you were unfamiliar with a behemoth Java project to the point of dreading making the change yourself, and yet only spent 5 minutes reviewing "someone else's" PR?
Yup. Replacing a single hard-coded parameter with a command line argument is hardly an earth shattering change. It's trivial to verify that the argument properly gets passed down the stack (and that passing it has no side-effects), but figuring out that stack in the first place would have taken a much longer time. Think of it like an NP-complete problem: hard to solve, but easy to check that a solution is correct. Fo…
> It's trivial to verify that the argument properly gets passed down the stack
It's not so trivial to verify that the change doesn't cause problems elsewhere, where it also should have been propagated.
Re: Vibe engineering
#119I would add to the list of the vibe engineer’s tasks:
Knowing when the agent has failed and it’s time to roll back. After four or five turns of Claude confidently telling you the feature is done, but things are drifting further off course, it’s time to reset and try again.
Re: Vibe engineering
#120A better term is agentic coding, agentic software engineering, etc. rather than being vibe based.
My process starts from a Claude Code plan, whose first step is to write a spec. I use TDD, and enforce my "unspoken rules of code quality" using a slew of generated tools. One tiny tool blocks code which violates our design system. Another tool blocks code which violates our separation of layering - this forces the HTTP route handler code to only access the database via service layer. Watching the transcript I have to occasionally remind the model to use TDD, but once it's been reminded it doesn't need reminding again until compaction. Claude 4.5 is far better at remembering to do TDD than 4.1 was.
Code reviews are super simple with TDD due to the tests mirroring the code. I also create a simple tool which hands the PR and spec to Gemini and has it describe any discrepancies: extra stuff, incorrect stuff, or missing stuff. It's been great as a backup.
But ultimately there's no substitute for knowing what you want, and knowing how to recognize when the agent is deviating from that.
The opposite of "garbage-in garbage-out" is quality in => quality out.