Hacker News Reader

The issue is, though ChatGPT and the likes definitely speed up development in one respect, they create a bottleneck in various other places.. “vibe coders” have essentially no idea what the code their LLM cranked out even does and are unaware the code they generated is often riddled with bugs yet still looks plausible. Not only that, they are often trying to develop things, that for the most part you could have just googled. Of course an LlM can write your CRUD app to a pint but then try to add a novel aspect and you see it pretending to reason and make progress when in reality you’re just spinning your wheels. I do research at MIT, my day to day involves developing systems/solutions/technologies that did not previously exist. When the bulk of your work lies in novel things such as R&D the limits of LLMs become very apparent and they offer no further help.

Every single day friends of mine ( many who aren’t programmers just wanna be CEOs of the next trend) tell me about these “project” of theirs. At the beginning it amazed them. They got a GUI up displaying some numbers up in Python with just a few queries! So cool! To them this probably looks like black magic. As the project grows to anything beyond the trivial, they cannot push it further along. They can’t look at the code themselves to fix the minor issue any human would immediately see because they have no clue/haven’t read the bulk of generated code (often trash quality riddled with vulnerabilities)… They often resort to trying a million different tools and platforms, spinning in circles, praying another model can fix their abomination… You get the idea. Sorry for poor grammar typing on small phone on bus.

> When the bulk of your work lies in novel things such as R&D the limits of LLMs become very apparent and they offer no further help.

Yes, but most people here do CRUD websites, so they’re extatic.

I know they are very visible on Twitter and the like but how many people are truly "vibe coding" versus just being a SWE that uses an LLM to summarize documentation, scaffold some test cases, implement some tedious data transformations, and still implement the truly interesting bits on their own? I'm not sure how to actually figure that out but it would be very interesting to know.

I know IRL none of the former but am myself/know plenty of engineers who are the latter. It very well could be I'm the one with the biased sample but my experience is that I only hear about vibe coding from "influencers" and articles/comments decrying it.

I made a quick throwaway to share my anecdote.

I'm at a YC company. We have a dev team < 15 engineers. We all expressed concerns about going full vibe coding, so the technical co-founder hired a bunch of vibe coders and has them on a private "SEAL team" building vibe coded monstrosities without any regard to safety, integrating with our main product, hosting consistency, or anything else.

I don't know if this is anyone else's experience. But I'm WAY more concerned about vibe coding than others seem to be just due to my proximity to the nonsense.

the founders think they can do it without any real developers, they will fail. But you have a bigger problem, the tech co-founder (CTO) is an idiot, that company is not going anywhere.

Sorry you have to deal with that and I hope they see the ramifications of their decision soon, but if this is your technical co-founder I'd recommend looking for a new role.

Can you share more about what the workflow of this new team looks like? I consider myself a strong proponent and heavy user of AI tools for development but it's still hard for me to fathom how true "vibe coding" at this scale is possible.

My founders are certainly already in this thread, so I don't want to say a whole lot more. The more specific I get, the increased likelihood I get called in for a chat today for being "unwilling to adapt." But it's far worse than you're probably expecting from a company with good investors and revenue. I expect things will go terribly wrong very soon.

The PM just decided they didn't want to queue up tickets or designs anymore, so they're on this vibe coding team. We aren't even in interviews with devs going onto that team, though you can hardly call them devs (Maybe that's elitist of me. but that's how I'm feeling.)

And sorry this is turning into a therapy session, but all of us devs actually like AI tooling. We're getting decent to good value out of claude code and the like. We've implemented a fairly neat little MCP for our CS team to use as a walled-garden admin tool. And yet, since we criticize things, we're branded as "non-believers" and the implication is that we are impeding the company's growth.

Suffice it to say, all us career devs are already interviewing and on our way out here.

I come from the same space and I agree wholeheartedly. My current work also has me working with APIs that aren’t public so no help there either.

This has me questioning the level of complexity most people on HN are working at day to day. For so many to be amazed at the ability to spontaneously generate CRUD apps that already exist in a thousand different iterations I’m guessing it’s pretty low.

> Do you think the _process_ of making music is the important part, or the final sounds that are produced?

It is both, for different reasons. Not caring for the process is the path of the mid-wit.

Ultimately, you’re arguing for generalism over specialism. Any specialist must be ignoring part of the larger process.

“All specialists are midwits” is obviously false.

Alternatively, even “most expert musicians are their own luthiers”… maybe more obviously false?

I'm interested for you to elaborate a bit more! I'd like to see more clearly the connection of my statements and the argument for generalist over specialist.

Overall, I think I'm arguing that you cannot become an expert without continually improving the process; and to do that you need to continually understand and study the process at progressively deeper levels. If a person cares nothing for the process, just the outcome - they therefore cannot achieve mastery (I'm like 85% convinced this is true).

If we assume a specialist is also an expert, then by definition specialists are not midwits - I agree.

An expert musician I would suspect should know how the different qualities of the instrument they play affect the outcome. Whether they can actually construct an instrument is a different question, but they ought to know the differences. Can you also be an expert musician and not know, nor care about the differences in instrument construction quality and material? Can you be an expert on a piano and not know what makes for a good piano?

I think the most exact analogy would be a musician who does not care about how an instrument is played - they don't study it, they don't care, just do something that makes for a nice sound, and that is all they desire. I don't think a person can achieve mastery in that manner, to achieve mastery - the 'how' does matter; the master should know everything about the different 'hows' and the trade-offs; and that is what makes them a master.

> Do you think the _process_ of making music is the important part, or the final sounds that are produced?

Pharmaceuticals are regulated not just by testing the end product but by regulating the entire production process[1]. How this came to be has an interesting story but I believe that it's essentially the correct way to do things.

Saying that process is irrelevant, that only the end product matters is a very persuasive idea but the problem comes when it's time to validate the end product. Any test you can perform on a black box can only show the presence or absence of a specific problem, never the absence of problems.

“Program testing can be used to show the presence of bugs, but never to show their absence!” - Dijkstra

[1] If you're interested in how this regulatory structure has failed to regulate international drug manufacturers, check out "Bottle of Lies" by Katherine Eban.

The main issue with AI I think is that it is exposing slop in the process people have handwaved away for some time. If the issue is you ask an AI for a prompt and it issues a function that doesn't work as expected, and this breaks your workflow, then the issue is your workflow. A junior dev or anyone else really could write a function that doesn't work as expected. Your workflow shouldn't go down to its knees in response, it should have tests and other debugging surrounding the putative function call to ensure that its output is as expected and it is not causing downstream issues in the stack.

This is why a stack overflow copy paster and a gen ai cruch wielder are both the same kind of bad. Both don't understand the context of the code hence grasping for "please solve this for me someone/thing" tooling instead of the underlying documentation that explains every thing for someone with knowledge to apply. Both require the same care to either not hire or to disempower such that one stupid bug pushed on friday isn't going to bring down the stack on the weekend, that it can be reviewed by people with an understanding of what is happening.