That seems very reasonable, doesn't it? Otherwise the fork could pollute the training data through bad modifications, and tracing that would be a pain.
> every product manager fundamentally misunderstands that users just want a chat window for AI,
I would actually argue chat windows are terrible ui/ux for most cases and users. It does the opposite of `don't make me think`. Too much potential for user error.
Not saying there shouldn't be any LLM integration/features, just that it should be in the form of a button press or something (familiar ux), not the same chatgpt interface that all the early apps are trying to mimic for no good reason.
A tool for non technical people to build things within reason.
I don't know how you're trying to define vibe coding, but I would definitely put it as more of a pejorative/negative term.
I have 20+ years of coding experience, I use coding agents well, and I'm not a vibe coder.
I would also bet that vibe coding will never become good enough to replace me because the models will never have enough context window for an entire repo of a complex app. LLMs can output code for you, but coding is only part of the job.
Not really. Vibecoding is the new code-completion, where every single developer uses extensively but is so mundane that no one bothers to blog about it. You don't see blog posts on how intellisense I'd a kin to magic, or how project starter templates speed up prototyping. No, people just use them and it's so mundane they don't think twice.
Disagree, I think vibe coders should become synonymous with no-code and continue to be somewhat of a pejorative.
I don't like the term vibe engineer, but do agree there needs to be a term to signifiy the difference.
It's also possible in the future just being called a developer/engineer already implies you use coding agents and the people who do it "by hand" will not be the norm.
it depends on your usecase, but i tried both coolify and caprover.
ended up going with caprover because i can more quickly spin up a nodejs app on there with git hooks (so it builds on each commit to a specific branch).
both offer this functionality, there's just less friction on caprover. but coolify is probably more extensive.
> it seems like a blockchain doesn't make sense for this use case.
given, most traffic will likely be from ai agents, does it make more sense to try to hack agents into using credit cards, having shared social security numbers, opening bank accounts, dealing with chargebacks and slow settlement?
or
does it make sense to use technology that is
- internet native
- programmable
- near instant
- secure
- permissionless
the volatility issues are resolved through the use of stablecoins.
Apple doesn't support VR/AR standards like OpenXR, so really developers haven't had a lot of time to iterate. They've had a lot of time to experiment, and then were asked to write a program from scratch for a headset without motion-tracked controllers.
When they released visionos and a bespoke version of safari and it had zero support for openxr. After years of closed development and a full year of open development and they launched without support for the one api that was mandatory... Thats how you knew it was DOA
> shouldn't it just take advantage of what's already there?
It's not a good idea to have any coding agent put unnecessary amounts of lines into the context window in order to understand your code base.
Performance of all llms drop drastically when the context window is filled or full. The purpose of being more specific with your prompts is that you spend a little bit more tokens up front to make the task a lot more efficient and more likely to result in success.
At least that's how it is today. We're probably a breakthrough or two away from the type of vibe coding experience non-coders want. Or it may never happen, and the developers who have coding knowledge will be the only ones to fully utilize coding agents and it will only become more powerful over time.
I'm not sure exactly what you mean by the vibe coding experience non-coders want, but if it's one-shotting a buildable codebase off of an unspecific prompt, the major breakthrough would have to be brain-computer interfaces so the agent can literally read the user's mind.
If that same person approached a software development company with the same prompt without following up with any other details, they won't get good code back, either. You're not saying it, but this idea that in the future you can tell a computer something like "create photoshop" and get what your expecting is an unrealistic dream that would need mind-reading or a major breakthrough and paradigm shift in understanding and interpreting language.
> the major breakthrough would have to be brain-computer interfaces so the agent can literally read the user's mind.
And even that would not be enough.
In reality, it would have to put the user to sleep and go through various dream scenarios to have the user's brain really build an internal model that is not there in the first place. No brain interface can help find what is not there.
We usually need interactions with reality to build the internal model of what we actually want step by step, especially for things we have not done before.
Even for info that is there, that's also a limit to fantasy or sci-fi brain scanning. The knowledge is not stored like in a RAM chip, even when it is there. You would have to simulate the brain to actually go through the relevant experiences to extract the information. Predicting the actual dynamic behavior of the brain would require some super-super sub-molecular level scan and then correctly simulating that, since what the neurons will actually do depends on much more than the basic wiring. Aaaaand you may get a different result depending on time of day, how well they slept, mood and when and what the person ate and what news they recently read, etc. :)
That is also not enough. An agent could build an application that functions, but you also need to have a well-designed underlying architecture if you want the application to be extensible and maintainable - something the original dreamer may not even be capable of - so perhaps a shared extended dream share with a Sr. architect is also needed. Oh wait .. I guess we're back to square 1 again? lol
> What is the incentive of someone to create an app and just pay for all the hosting involved?
If you're creating a social app, website, or whatever, you still have to host all your users' data regardless. This is just about the protocol you use which enables universal compatibility, meaning users have the choice to store elsewhere.
> Also, does everyone need to have their own domain name in order to have an identity cuz that seems like a non-starter.
Not really. Bluesky is a good example; when you first sign up it does it for you under their own top domain by default iirc, but the great thing is you can actually use your own domain.
You can run stock, or any fork simply by providing the URL of the version you want to run.
Where exactly is the restriction?