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?
Vibe coding kills open source
151–160 of 304 posts
Re: Vibe coding kills open source
#152---
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
Re: Vibe coding kills open source
#153Re: Vibe coding kills open source
#154Is 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
#155The 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
#156Re: Vibe coding kills open source
#157I 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 have had a lot of conversations with Claude about it and it supports that theory.
Re: Vibe coding kills open source
#158Earlier 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…
Re: Vibe coding kills open source
#159Something 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…
[1] https://github.com/anomalyco/opencode/pulls [2] https://github.com/Aider-AI/aider/pulls
Re: Vibe coding kills open source
#160Something 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?