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

Vibe Coding and the Future of Software Engineering

alexp.pl

Post reply on HN
Print view View original

21–30 of 103 posts

Re: Vibe Coding and the Future of Software Engineering

#21

Post by sergiotapia »

PartiallyTyped wrote: post #3
antirez wrote: post #2

As I said in one of my latest YT videos: if you can't code , sure, go all for it, the difference with x -> 0 in the denominator tends to infinity. But if you can code, there are much better ways to use generative AI to aid you in your coding tasks. Ways that will make you faster while you learn more, understand every single line of the code that is in your application, never letting badly written code go into your co…

Are you willing to elaborate about how they can accelerate you?

One example: I had to send a report to a slack webhook, showing how many oban jobs were completed in the last 24 hours for specific uses cases based on oban job params.

That's:

sql query, slack webhook api docs reading, ecto query for oban jobs with complex para filtering, oban job to run cron, cron syntax.

easily like a 2 hour job?

it took me 5 minutes with AI. then we decided to send the slack alert at 7am EST instead of 12pm PST. instead of doing all that math, I just ctrl+k and asked it to change it. 1 second change.

these gains are compounding. if you're an experienced engineer, you let go of minutae and FLY. i believe syntax memorization is dead.

Re: Vibe Coding and the Future of Software Engineering

#22

Post by PartiallyTyped »

antirez wrote: post #4
PartiallyTyped wrote: post #3

Earlier quoted context omitted.

Are you willing to elaborate about how they can accelerate you?

I have a youtube channel with a playlist of coding with AI, where I show what I do with it (a small part, actually, but representative enough I hope). This is is the first video of the series I believe: https://www.youtube.com/watch?v=_pLlet9Jrzc&list=PLrEMgOSrS_... And here, Redis bugfixing with Claude Sonnet: https://www.youtube.com/watch?v=rCIZflYEpEk&list=PLrEMgOSrS_...

Many thanks! I will take a look!

Re: Vibe Coding and the Future of Software Engineering

#23

Post by AlwaysRock »

LPisGood wrote: post #17
Karrot_Kream wrote: post #6

If you're writing one-off scripts though, I find vibe coding fantastic. I found myself in a work meeting where I was mostly there to let a junior present some joint work we did and answer any questions the junior couldn't. Since I wasn't really needed (the junior eng was awesome), I was fidgeting and wanted to analyze the results from an API I had access to. A few prompts from Claude and I was hitting the API, fetchi…

I recently tried this _exact_ same thing (except it was less of a meeting and more like a phone call) and I got stuck because it kept making up fake API endpoints OR I had to go manually login somewhere to get the API key.

When? I've found over the last 6 months or so there has been a drastic change in quality of results. I used to have a ton of hallucinations like that. It still happens, but it is significantly less common now.

I also get better results when using a prompt window built into and ide than something detached like the openai website.

Re: Vibe Coding and the Future of Software Engineering

#24

Post by AlwaysRock »

brundolf wrote: post #8
Karrot_Kream wrote: post #6

If you're writing one-off scripts though, I find vibe coding fantastic. I found myself in a work meeting where I was mostly there to let a junior present some joint work we did and answer any questions the junior couldn't. Since I wasn't really needed (the junior eng was awesome), I was fidgeting and wanted to analyze the results from an API I had access to. A few prompts from Claude and I was hitting the API, fetchi…

Agreed. I've had a lot of success using ChatGPT for nontrivial bash one-liners. They're small in scope and there must be a huge amount of training data for them, I use them rarely enough that I don't remember details off the top of my head, and they're intrinsically throwaway code

I was doing some file management last weekend and wanted a little script to remove any numbers at the start of a file name and any region values at the end. I also wanted to ensure any duplicate files were moved into a separate folder so i could remove them.

I could have written that code. I'm sure there is a program that can do exactly that for me that I could have downloaded. But one prompt, a few tests to make sure it wasnt going to nuke all my files, and within 5 minutes I was completely done with the file management. For this type of stuff it just saves time.

Re: Vibe Coding and the Future of Software Engineering

#25

Post by 65 »

Yeah, and I can be a novel writer with AI. I'll have my Amazon best seller in no time thanks to AI!

It completely misses nuance. Are any of these apps actually useful?

I'm not sure how this is any better than jamming a bunch of Wordpress plugins together to kinda get the software to do what you want.

Re: Vibe Coding and the Future of Software Engineering

#26

Post by spion »

oortoo wrote: post #13
zero_shift wrote: post #7

Earlier quoted context omitted.

Data point of one: ChatGPT 3.5, even the free product, is so much better at answering technical questions than Google. Some questions I had successfully answered recently: > "I would like to animate changing a snippet of code. I'll probably be using Remotion. Is there a JavaScript library that can animate changing one block of text into another?" > "In Golang, how can I unit test a http mux? How can I test the routes…

ChatGPT is better on average for sure than Google for arriving at a correct answer, but they fail in different ways. When Google fails, it's usually in the form of, "I cannot find an answer. Better ask someone smart for help." but when ChatGPT fails, it's often giving an incorrect answer. Depending on your fault tolerance and timeline, one will be better than the other. If you have low tolerance for faults, ChatGPT i…

Google doesn't really say it can't find an answer; instead it finds less relevant (irrelevant) search results. LLMs hallucinate, while search engines display irrelevance.

Re: Vibe Coding and the Future of Software Engineering

#27

Post by jstummbillig »

goosejuice wrote: post #12
PartiallyTyped wrote: post #3

Earlier quoted context omitted.

Are you willing to elaborate about how they can accelerate you?

antirez's series looks awesome. My two cents w/ composer: Don't rely on the LLM for design. Start by defining some tests via comments or whatever your tools allow. The tab completion models can be helpful here. Start the interfaces / function defs and constrain them as much as possible. Let the LLM fill in the rest using TDD. The compiler / test loop along with the constraints can get you pretty far. You'll always ne…

If you are optimizing for less tool calls, I think you are rapidly and increasingly optimizing for the wrong thing here.

Re: Vibe Coding and the Future of Software Engineering

#28

Post by Wowfunhappy »

_bin_ wrote: post #19
Wowfunhappy wrote: post #16

Earlier quoted context omitted.

> they still can't really fix bugs. syntax errors sure, but actual time-costing logic bugs? figuring out lifetimes with rust? forget about it. all they do is add freaking print statements and say "try these things to fix it." no. you're the robot, you work for me, you do it. Have you tried the reasoning models? I find that o1 really is able to find logic bugs, even tricky ones!

i'm glad they seem to work better for you. i sometimes seem to be the only person out there who can't get the same level of utility out of these models as others. my guess is for some applications they can, but even reasoning models (o3-mini-high, grok3, sonnet 3.7, o1, deepseek, etc.) often fail to fix logic bugs. note that this isn't necessarily a form validation logic bug I'm referring to but, say, a pretty in-the…

> even reasoning models [...] often fail to fix logic bugs.

I think "often" is the key word here. To be clear, they often fail for me to! But they also often work.

Re: Vibe Coding and the Future of Software Engineering

#30

Post by 0x696C6961 »

nighthawk454 wrote: post #29

Some things don’t require scratch build, some do, some are in between. But there’s no prompt for taste.

I disagree. When I prompt for Go, I request that it be written in the style of the Go standard library and Go authors. This very much changes the style of the output.
Post reply on HN