Live data from Hacker News

Vibe coding kills open source

arxiv.org

31–40 of 304 posts

Re: Vibe coding kills open source

#31
post #16
post #9

Earlier quoted context omitted.

We need a new git. (could be built on the current git) > One incredible thing was the ability to easily merge what was worth merging from forks, for instance I agree, this is amazing, and really reduces the wasted effort. But it only works if you know what exists and where.

More we need a new GitHub.

There are a pile of alternatives which have similar UIs.

Re: Vibe coding kills open source

#32
post #8

I believe we will see a new huge wave of useful open source software. However don't expect the development model to stay the same. I was finally able to resurrect a few projects of mine, and many more will come. One incredible thing was the ability to easily merge what was worth merging from forks, for instance. The new OSS will be driven not much by the amount of code you can produce, but from the idea of software y…

The real question is how much of the new wave of vibe-coded software will be able to graduate from pet project to community-maintained project.

It feels that vibe coding may exacerbate fragmentation (10 different vibe-coded packages for the same thing) and abandonment (made it in a weekend and left it to rot) for open source software.

Re: Vibe coding kills open source

#33
post #8

I believe we will see a new huge wave of useful open source software. However don't expect the development model to stay the same. I was finally able to resurrect a few projects of mine, and many more will come. One incredible thing was the ability to easily merge what was worth merging from forks, for instance. The new OSS will be driven not much by the amount of code you can produce, but from the idea of software y…

I don't trust software that has .claude in its GitHub repo.

You won't have to ignore this stuff for long. Pretty soon it'll be mandatory to keep up.

I've been a senior engineer doing large scale active-active, five nines distributed systems that process billions of dollars of transactions daily. These are well thought out systems with 20+ folks on design document reviews.

Not all of the work falls into that category, though. There's so much plumbing and maintenance and wiring of new features and requirements.

On that stuff, I'm getting ten times the amount of work done with AI than I was before. I could replace the juniors on my team with just myself if I needed to and still get all of our combined work done.

Engineers using AI are going to replace anyone not using AI.

In fact, now is the time to start a startup and "fire" all of these incumbent SaaS companies. You can make reasonable progress quickly and duplicate much of what many companies do without much effort.

If you haven't tried this stuff, you need to. I'm not kidding. You will easily 10x your productivity.

I'm not saying don't review your own code. Please do.

But Claude emits reasonable Rust and Java and C++. It's not just for JavaScript toys anymore.

- - - - - - - - - - - -

Edit:

Holy hell HN, downvoted to -4 in record time. Y'all don't like what's happening, but it's really happening.

I'm not lying about this.

I provided my background so you'd understand the context of my claims. I have a solid background in tech.

The same thing that happened to illustration and art is happening here, to us and to our career. And these models are quite usable for production code.

I can point Claude to a Rust HTTP handler and say, "using this example [file path], write a new endpoint that handles video file uploads, extracts the metadata, creates a thumbnail, uploads them to the cloud storage, and creates the relevant database records."

And it does it in a minute.

I review the code. It's as if I had written it. Maybe a change here or there.

Real production Rust code, 100 - 500 LOC, one shotted in one minute. It even installs the routes and understands the HTTP framework DSL. It even codegens Swagger API documentation and somehow understands the proc macro DSL that takes Rust five minutes to compile.

This tech is wizardry. It's the sci fi stuff we dreamed of as kids.

I don't get the sour opinions. The only thing to fear is big tech monopolozation.

I suppose the other thing to worry about is what's going to happen to our cushy $400k salaries. But if you make yourself useful, I think it'll work out just fine.

Perhaps more than fine if you're able to leverage this to get ahead and fire your employer. You might not need your employer anymore. If you can do sales and wear many hats, you'll do exceedingly well.

I'm not saying non-engineers will be able to do this. I'm saying engineers are well positioned to leverage this.

Re: Vibe coding kills open source

#34
post #9
post #8

I believe we will see a new huge wave of useful open source software. However don't expect the development model to stay the same. I was finally able to resurrect a few projects of mine, and many more will come. One incredible thing was the ability to easily merge what was worth merging from forks, for instance. The new OSS will be driven not much by the amount of code you can produce, but from the idea of software y…

We need a new git. (could be built on the current git) > One incredible thing was the ability to easily merge what was worth merging from forks, for instance I agree, this is amazing, and really reduces the wasted effort. But it only works if you know what exists and where.

That sounds a little extreem, why not just a new auto merge feature?

Re: Vibe coding kills open source

#35

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…

I find that asking it to write a design doc first and reviewing that (both you and the bot can do reviews) gets better results.

Re: Vibe coding kills open source

#36
It is effective but once cost of creating something is down, then you have less reason to collaborate and depend on each other vs asking your own LLM to build your own bubble. When paired with new-found cognitive laziness and lack of motivation when you then use no AI it's not sure of the second order effects.

Re: Vibe coding kills open source

#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 lot of submitters don't currently do this, and in my experience the average quality of PRs generated by AI is definitely significantly lower than those not generated by AI.

Re: Vibe coding kills open source

#39
post #7

Earlier quoted context omitted.

What do you think of the paper's research claims that the returns for maintainers are reduced and sharing is decreasing?

Without real finance model innovation, what returns?

The same kind of returns that power research academia, where the amount of money you make is determined by the number of citations on your papers.

Except it's on Github and it's forks and starts.

Re: Vibe coding kills open source

#40

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?

Maybe true for some apps, but I suspect we will still have a vibrant ecosystem of package managers and open source libraries and coding agents will know how to use them.
Post reply on HN