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

The problem with "vibe coding"

dylanbeattie.net

Post reply on HN
Print view View original

121–130 of 154 posts

Re: The problem with "vibe coding"

#121

Post by selcuka »

alganet wrote: post #63
selcuka wrote: post #51

Earlier quoted context omitted.

> You're basically polling the consensus answer to the question you're asking. There is nothing wrong with going with the consensus answer. Sure, you can't invent an O(N) sorting algorithm with the consensus, but LLMs can definitely write good, maintainable code. Michelin star analogy might be an exaggeration, but it can help cook a good homemade meal, possibly even better than most wannabe home cooks.

Dude, ask ChatGPT to explain the analogy for you. It understood well enough. It will save both of us some time. Maybe AI is useful for some things after all.

Not sure about the reason for the personal attack, but my comment wasn't a reply to you. Michelin star restaurant was not even your analogy.

I guess you are right, though. AI is useful for some things. At least it reads the prompt before responding.

Re: The problem with "vibe coding"

#122

Post by linsomniac »

tjpnz wrote: post #3
linsomniac wrote: post #2

>they empower people with minimal development experience to create their own programs. The author goes out of their way to play up the toy aspect of the LLMs when driven by the inexperienced. No mention is made of them being used by experienced developers, but I get the impression he feels they aren't useful to the experienced. I'm just playing with a small client/server tool (rsync but for block devices), and vibe c…

How does the inexperienced developer become experienced under said circumstances?

That is a question that is very near and dear to my heart right now because my son is 15 and very interested in programming. I don't have any good answers yet, but you definitely need to know so many of the core concepts to be able to steer the LLM around pitfalls.

Re: The problem with "vibe coding"

#123

Post by linsomniac »

kemayo wrote: post #18
alchemist1e9 wrote: post #8

Earlier quoted context omitted.

I agree they may not and that’s very interesting. As an experienced developer myself I’m starting to think these tools are likely going to increase our market value not decrease it.

It's not implausible that we'll wind up with something like the extremely long-lasting market for COBOL developers. A niche skill that's absolutely essential in a few places, and which can command high salaries as a result... for a few people. Only so many huge legacy banking systems, after all. The problem, as with COBOL, would be the loss of the existing pipeline that created new competent high-level developers.

"The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x." -- Kent Beck

Re: The problem with "vibe coding"

#124

Post by brandensilva »

commandersaki wrote: post #7

One of the genuinely positive things about tools like Copilot and ChatGPT is that they empower people with minimal development experience to create their own programs. Little programs that do useful things - and that’s awesome. More power to the users. I've changed my outlook on vibe coding after seeing the results of this wholesome vibe coding: https://www.youtube.com/watch?v=4pJUXocn7aE . This guy didn't just make…

The funny thing is someone somewhere will find a way to make millions off a vibe coded project. I just suspect it will be the outlier and they will be well positioned to make that happen.

And for the rest of the companies that embrace the 30%~ efficiency spike, it will just accelerate our work goals faster.

I like to use it on stuff that we wanna do to enhance the UX but rarely sees the light of day. Plus my wrists have never felt so good since replacing boring syntax choirs with LLMs.

Re: The problem with "vibe coding"

#125

Post by makeitdouble »

skydhash wrote: post #117
makeitdouble wrote: post #45

> To me, programs are “works on my machine” code. My main takeaway from vibe-coding is that nobody cared enough to fill that niche and expectation. And it was really frustrating, yet we're getting there through convolutated, inefficient and borderline barbaric means. People are still lamenting after HyperCard. Automation on windows or macos didn't go anywhere. Shortcuts were a better step into that direction but I fe…

Python is not exactly a hard language to learn. But the truth is that people generally don’t like to devote time to what they deem unimportant even if the end result would be useful. I’ve seen smart people go though dense mathematics and physics books, but refuses to take an introductory course in programming.

Python is comparatively easy, but you wouldn't say it's easier than the building mechanics in Zelda TOTK for instance.

I think what the target demographics want is that level of modularity and block building.

Re: The problem with "vibe coding"

#126

Post by surajrmal »

pjmlp wrote: post #65
commandersaki wrote: post #7

One of the genuinely positive things about tools like Copilot and ChatGPT is that they empower people with minimal development experience to create their own programs. Little programs that do useful things - and that’s awesome. More power to the users. I've changed my outlook on vibe coding after seeing the results of this wholesome vibe coding: https://www.youtube.com/watch?v=4pJUXocn7aE . This guy didn't just make…

Hence why software developers are out of job, eventually. The day of only a few people around the factory floor to babysit the robots will come, but lets keep celebrating the day they start unloading them from the delivery trucks for installation.

It's not clear if the overall number of needed software developers will decrease or simply stop growing. The amount of software necessary in the future will only keep growing. Using the same folks to produce more is a large possibility. I imagine it will take decades to see a shrinking workforce that meaningfully displaces many existing software developers.

Re: The problem with "vibe coding"

#127

Post by gyesxnuibh »

linsomniac wrote: post #120
SteveDR wrote: post #4

Earlier quoted context omitted.

> vibe coding allowed me to figure out some rough edges of my design document, and experiment with "what would it look like built with threads? As async code? As procedural?” This doesn’t fall under my understanding of the phrase “vibe coding”. In the tweet from Karpathy which many point to for coining the phrase, he says that when vibe coding you essentially “forget the code exists”. I think it’s distinct from regul…

I surely did a hybrid approach, but for a large swath of it I was pretty purely "vibe coding", where I wasn't looking at the produced code at all. I initially had Gemini 2.5 build some code and then did a code review of it. I tweaked my design document and then had Claude and ChatGPT take a stab at it and at this point I wasn't looking at the code at all. These implementations had some deadlock or early termination p…

I'm a little confused on how this helped your design doc? It seems like you picked the design that the LLM could best implement?

I was really curious about how it helped you iron out the problems but couldn't figure it out from your description

Re: The problem with "vibe coding"

#128

Post by linsomniac »

gyesxnuibh wrote: post #127
linsomniac wrote: post #120

Earlier quoted context omitted.

I surely did a hybrid approach, but for a large swath of it I was pretty purely "vibe coding", where I wasn't looking at the produced code at all. I initially had Gemini 2.5 build some code and then did a code review of it. I tweaked my design document and then had Claude and ChatGPT take a stab at it and at this point I wasn't looking at the code at all. These implementations had some deadlock or early termination p…

I'm a little confused on how this helped your design doc? It seems like you picked the design that the LLM could best implement? I was really curious about how it helped you iron out the problems but couldn't figure it out from your description

Running the first generated version to test, I realized I needed to specify: "Make sure that the client processes messages from the server while it is generating and sending hashes of the source file", because the first implementation would spin on generating the hashes and deadlock because the server end would write messages back to the client that the client wasn't reading and fill up the output buffers, which would fill up the client output buffers once the server stalled. This was obvious just from running it and knowing how all this stuff works (rather than by code review).

Then I started seeing issues with how I had phrased the terminal conditions, the client terminating immediately upon reaching the EOF on input file, and not reading any further server messages. I considered making a 3-way ACK to signal end, but instead changed the design to tell it to keep track of outstanding un-acked packets and only send the EOF/EOFACK when there were no outstanding messages.

The design is that the client generates a bunch of "xxhash64" messages for each block of data, and the server replies to each one with either "ok" (I already have that data) or "send" (send me that data). The "send" is replied to with either "data" (here's the data) or "zero" (the block is entirely NUL).

Re: The problem with "vibe coding"

#129

Post by cco »

int_19h wrote: post #76
noman-land wrote: post #26

Earlier quoted context omitted.

I love this so much. It's hacky, janky, and absolutely phenomenal and life changing. This is like perfectly in the spirit of the hacker ethos. This dude scraped together pieces around him and made a useful product that solves the problems he wants to solve, the way he wants to solve them. The code is probably garbage. You can tell the UI is weird and jumpy. He's using timed delays to manipulate the browser with keybo…

> perfectly in the spirit of the hacker ethos I would strongly disagree on this count. Hacker ethos, at least as traditionally understood, emphasizes grokking and elegance.

I couldn't think of any two concepts less associated with "hacking".

I think you may have an understanding of that word that is not very common.

Re: The problem with "vibe coding"

#130

Post by motorest »

alganet wrote: post #68
motorest wrote: post #62

Earlier quoted context omitted.

> No, copilot is not endlessly variable. It works best with typed languages and an enterprise mindset. I don't think your assumption is true. The key factor is the corpus used to train it, and the context you fed it. I already experienced Copilot fumbling references to methods of a simple Java class, whereas it pulled off thinks like ARM templates flawlessly. You need to understand that internally LLMs do probability…

Please, think about what you just said. How can I feed to it context about a DSL that does not exist yet?

> How can I feed to it context about a DSL that does not exist yet?

My example referred to ARM templates. They do exist, don't they?

Post reply on HN