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

Vibe coding kills open source

arxiv.org

Post reply on HN
Print view View original

251–260 of 304 posts

Re: Vibe coding kills open source

#251

Post by tracker1 »

anticorporate wrote: post #242
tracker1 wrote: post #184

Earlier quoted context omitted.

I've seen plenty of "standardized" (ie, "Enterprise" applications)... I'd just assume a bespoke hammer that's simple and easy to understand over a complex beast of HammerFactoryFactory to deliver you a builder of custom hammer builders so you get the JobHammer you need as part of the IoC loader platform that is then controlled through a 1.2gb service orchestrator that breaks at 11am every third Tuesday for an hour. W…

A standardized hammer can just be a carpenter's hammer, though. Putting a nail pull on the back side is making it opinionated in a way that gives users access to a tool that they may not have thought of if they built their own hammer, but very well might appreciate having. This isn't a defense of enterprise applications, though. They're more like a shed fully of rusty tools with a thirty different coping saws blades…

You forgot to mention the IT Security team locking up all the screwdrivers to prevent potential cross-contamination with hammer usage.

Re: Vibe coding kills open source

#253

Post by hxugufjfjf »

gjadi wrote: post #234
torginus wrote: post #216

Earlier quoted context omitted.

If LLMs are great at reviewing, why do they produce the quality of code they produce?

Imho it's because you worked before asking the LLM for input, thus you already have information and an opinion about what the code should look like. You can recognize good suggestions and quickly discard bad ones. It's like reading, for better learning and understanding, it is advised that you think and question the text before reading it, and then again after just skimming it. Whereas if you ask first for the answer…

Its also because they are only as good as they are with their given skills. If you tell them "code and make no x and y mistakes" they will still make those mistakes. But if you say "perform a code review and look specifically for x and y", then it may have some notion of what to do. That's my experience with using it for both writing and reviewing the same code in different passes.

Re: Vibe coding kills open source

#254

Post by acessoproibido »

dimitri-vs wrote: post #238
Bishonen88 wrote: post #179

Earlier quoted context omitted.

Expertise won't be needed (it already isn't). One can create copies of apps with vague descriptions referencing those big apps: "Create a copy of xyz. It needs to look and behave similarly. I want these features ... And on top of that ...". Millions decisions not needed. A handful of vague descriptions of what one wants is all it takes today. I think claude and co. can even take in screenshots. Documentation won't be…

But millions discussions are needed and will always be needed? "Create a copy of Amazon.com" ok, how did you want to handle 3pl fulfilment and international red tape? "No not that complicated, a minimal copy" How minimal? How many servers should I provision? How vertically integrated should we get? Etc. I really want to see someone build an app of any value with minimal decisions made.

Amazon is not one app, its hundreds of them bundled in some giant monster.

You could easily replicate the store part of it minimally, at its core its just an index of products, a basket and checkout system. There are other parts that make up the whole thing of course.

There is a lot of room between no value and trillion dollar company

Re: Vibe coding kills open source

#255

Post by electroly »

torginus wrote: post #216
electroly wrote: post #160

Earlier quoted context omitted.

LLMs are great at reviewing. This is not stupid at all if it's what you want; you can still derive benefit from LLMs this way. I like to have them review at the design level where I write a spec document, and the LLM reviews and advises. I don't like having the LLM actually write the document, even though they are capable of it. I do like them writing the code, but I totally get it; it's no different than me and the…

If LLMs are great at reviewing, why do they produce the quality of code they produce?

Reviewing is the easier task: it only has to point me in the right direction. It's also easy to ignore incorrect review suggestions.

Re: Vibe coding kills open source

#256

Post by erelong »

echelon wrote: post #43
nicoburns wrote: post #37

Something I've noticed is that AI code generation makes it easier/faster to generate code while shifting more work of the work of keeping code correct and maintainable to the code review stage. That can be highly problematic for open source projects that are typically already bottlenecked by maintainer review bandwidth. It can be mitigated by PR submitters doing a review and edit pass prior to submitting a PR. But a…

The maintainers can now do all the work themselves. With the time they save using AI, they can get much more work done. So much that having other engineers learn the codebase is probably not worth it anymore. Large scale software systems can be maintained by one or two folks now. Edit: I'm not going to get rate limited replying to everyone, so I'll just link another comment: https://news.ycombinator.com/item?id=46765…

Yeah, it should change things but also free up other energies to work on things

Re: Vibe coding kills open source

#257

Post by tomaytotomato »

eichin wrote: post #237
tomaytotomato wrote: post #6

I have been trying to use Claude code to help improve my opensource Java NLP location library. However trying to get it to do anything other than optimise code or fix small issues it struggles. It struggles with high level abstract issues. For example I currently have an issue with ambiguity collisions e.g. Input: "California" Output: "California, Missouri" California is a state but also city in Missouri - https://gi…

Trying not to turn this into "falsehoods developers believe about geographic names", but having done natural-language geocoding at scale (MetaCarta 2002-2010, acquired by Nokia) the most valuable thing was a growing set of tagged training data - because we were actually building the models out of that, but also because it would detect regressions; I suspect you needed something similar to "keep the LLMs in line", but…

Thanks for this - its interesting how I have come to this conclusion as well.

My reworked approach is to return a list of results with a probability or certainty score.

In the situation of someone searching for London, I need to add some sort of priority for London, UK.

My dataset is sourced from an opensource JSON file which I am now pre-processing and identifying all collisions on it.

There are so many collisions!

Could I pick your brains and you could critique my approach? Thanks

Re: Vibe coding kills open source

#258

Post by seniorThrowaway »

spamizbad wrote: post #240
seniorThrowaway wrote: post #188

Earlier quoted context omitted.

AI's / LLM's have already been trained on best practices for most domains. I've recently faced this decision and I went the LLM custom app path, because the software I needed was a simple internal business type app. There is open source and COTS software packages available for this kind of thing, but they tend to be massive suites trying to solve a bunch of things I don't need and also a minefield of licensing, freem…

> AI's / LLM's have already been trained on best practices for most domains. I've been at this long enough to see that today's best practices are tomorrow's anti-patterns. We have not, in fact, perfected the creation of software. And the your practices will evolve not just with the technology you use but the problem domains you're in. I don't mean this as an argument against LLMs or vibe coding. Just that you're alwa…

I've been doing this a long time too. The anti-patterns tend to come from the hype cycles of "xyz shiny tool/pattern will take away all the nasty human problems that end up creating bad software". Yes, LLMs will follow this cycle too, and, I agree we are in a kind of sweet spot moment for LLMs where they were able to ingest massive amounts of training material from the open web. That will not be the case going forward, as people seek to more tightly guard their IP. The (open) question is whether the training material that exists plus whatever the tools can self generate is good enough for them to improve themselves in a closed loop cycle. LLM generated code was the right tool for my job today; doesn't mean it's the right tool for everyone's job or that it always will be. One thing constant in this industry is change. Sold as revolutionary, which is the truth, in the sense of going in circles/cycles.

Re: Vibe coding kills open source

#259

Post by onraglanroad »

panta wrote: post #212
WarmWash wrote: post #29

Small bespoke personalized on the spot apps are the future with LLMs. The future will absolutely not be "How things are today + LLMs" The paradigm now for software is "build a tool shed/garage/barn/warehouse full of as much capability for as many uses possible" but when LLMs can build you a custom(!) hammer or saw in a few minutes, why go to the shed?

StanLLM-generated hammer: "Dear valued customer, our automated systems have flagged activity on your StanLLM account that appears to be non-compliant with our Acceptable Use Policy. As a precautionary measure your account has been suspended. If you believe this suspension is in error, feel free to contact our customer support at /dev/null^H^H^H^H^H^H^H^H^Hsupport@..."

That's what you get for using proprietary software instead of the GNU version: StaLLMan

Re: Vibe coding kills open source

#260

Post by seniorThrowaway »

jcarrano wrote: post #245
WarmWash wrote: post #29

Small bespoke personalized on the spot apps are the future with LLMs. The future will absolutely not be "How things are today + LLMs" The paradigm now for software is "build a tool shed/garage/barn/warehouse full of as much capability for as many uses possible" but when LLMs can build you a custom(!) hammer or saw in a few minutes, why go to the shed?

The 3d-printer of software: get a custom part quickly and cheaply, even if not suitable for mass production.

I think this is a great analogy
Post reply on HN