Live data from Hacker News

Vibe coding kills open source

arxiv.org

151–160 of 304 posts

Re: Vibe coding kills open source

#151

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?

Exactly, think StarTrek replicator.

Re: Vibe coding kills open source

#152
Yes and no.

---

Concrete example of a no: I set up [1] in such a way that anyone can implement a new blog -> rss feed; docs, agents.md, open-source, free, etc...

Concrete example of a yes: Company spends too much money on simple software.

--- Our Vision ---

I feel the need to share: https://grove.city/

Human Flywheel: Human tips creator Creator engages with audience

Agent Flywheel: Human creates creative content Agent tips human

Yes, it uses crypto, but it's just stablecoins.

This is going to exist in some fashion and all online content creation (OSS and other) will need it.

---

As with everything, it Obvious

[1] https://github.com/Olshansk/rss-feeds

Re: Vibe coding kills open source

#153
Vibecoding is great for open source. Open source is already dominated by strong solo programmers like antirez, linus, etc. People with very strong motivations to create software they see as necessary. Vibecoding makes creating open source projects easier. It makes it easier to get from an idea to "Hey guys check this out!" The only downside to open source is the fly by PRs vibecoding enables which are currently draining maintainer time.

Re: Vibe coding kills open source

#154
All this talk about how you can vibecode all your apps now, "why use OSS?" is making me laugh. Sure for a little website or a small tool, maybe even a change to your somewhat complex codebase that you thoroughly check and test.

Is anyone replacing firefox, chromium, postgres, nginx, git, linux, etc? It would be idiotic to trade git for a vibe coded source control. I can't even imagine the motivations, maybe "merges the way I like it"?

Not sure, but anyone who's saying this stuff hasn't even taken the basic first level glance at what it would entail. By all means, stop paying $10 a month to "JSON validator SaSS", but also don't complain with the little niggling bugs, maintenance and organization that comes with it. But please stop pretending you can just vibe code your own Kafka, Apache, Vulkan, or PostGRES.

Yes, you can probably go faster (possibly not in the right direction if inexperienced), but ultimately, something like that would still require very senior, experienced person, using the tool in a very guided way with heavy review. By why take on the maintenance, the bug hunting, and everything else, unless that is your main business objective?

Even if you can 10x, if you use that to just take on 10x more maintenance, you haven't increased velocity. To really go faster, that 10x must be focused on the right objective -- distinctive business value. If you use that 10x to generate hundreds of small tools you now have to juggle and maintain, that have no docs or support, no searchable history of problems solved, you may have returned yourself to 1x (or worse).

This is the old "we'll write our own inhouse programming language" but leaking out to apps. Sure, java doesn't work _exactly_ the way you want it to, you probably have complaints. But writing your own lang will be a huge hit to whatever it was you actually wanted to use the language for, and you lose all the docs, forums, LSP / debugging tools, ecosystem, etc.

Re: Vibe coding kills open source

#155
I think LLMs also kill off most programming languages. I think we’ll end up with a handful of languages that LLMs most proficient at writing for and the languages required for device or processor compatibility.

The cost improvement for an LLM to emit a feature (with an engineer in the loop) is too much of an improvement. We’ll look at engineers coding in C the same way we look at engineers today who code in assembly. LLM enabled development becomes the new abstraction; probably with a grammar and system for stronger specification formalization.

Re: Vibe coding kills open source

#157

I think LLMs also kill off most programming languages. I think we’ll end up with a handful of languages that LLMs most proficient at writing for and the languages required for device or processor compatibility. The cost improvement for an LLM to emit a feature (with an engineer in the loop) is too much of an improvement. We’ll look at engineers coding in C the same way we look at engineers today who code in assembly.…

I've done a bit of experimentation with that. And the irony is Rust seems to fare best because of the error messages of the compiler.

I have had a lot of conversations with Claude about it and it supports that theory.

Re: Vibe coding kills open source

#158
post #33

Earlier quoted context omitted.

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…

> 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. There are lots of people claiming this. Many of whom have a solid background. Every now and then I check out someone's claim (checking the code they've generated). I've y…

Have you looked at antirez's code?

https://github.com/antirez/flux2.c

Re: Vibe coding kills open source

#159

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…

I was expecting this to be the point of the article when I saw the title. Popular projects appear to be drowning in PRs that are almost certainly AI generated. OpencodeCli has 1200 open at the moment[1]. Aider, which is sort of abandoned has 200 [2]. AFAIK, both projects are mostly one maintainer.

[1] https://github.com/anomalyco/opencode/pulls [2] https://github.com/Aider-AI/aider/pulls

Re: Vibe coding kills open source

#160

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…

To me, an old guy, I would rather have LLM doing (assisting with) the code review than the actual code production. Is that stupid?

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 spec documents.
Post reply on HN