Re: privacy though, there's many solutions. Single tailored chains for privacy, mixers, encrypted tokens, permissioned chains, etc.

In my experience, privacy, while important, is not something users actually care about enough to demand a solution for. Most web3 users today just want to degen and gamble, and they're okay with KYC to do so.

The Software Engineer will know what decision to make even without looking at the code.

To save on inference, I had Claude create a lightweight typescript library to handle translations and detection. Now I get the previous functionality for 200mb~ ram versus paid API credits.

I also built a home assistant menu bar in osx, let's me easily monitor activity, toggle devices, view cameras, etc.

You can run stock, or any fork simply by providing the URL of the version you want to run.

Where exactly is the restriction?

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.

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.

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.

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.

But ya, apple should be more Dev friendly overall.

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.

Also, does everyone need to have their own domain name in order to have an identity cuz that seems like a non-starter.

How are AI agents going to open up a credit card or bank account?

You think the government will grant them a SSN?

It's a good thing we have a Internet native, programmable money, that is permissionless, near instant, and already supports USD(c).

- Didn't even know fb dating was a thing.

- people still use fb?

If you have someone who knows what they're doing with the latest and greatest coding agents it's just not comparable. You can have a Dev open up four or more terminals with multiple prompts running at the same time. A manual person just can't keep up.

The protocol is pretty simple. Make a request and get back payment headers.

Sign the data, with the proper amounts. The signed transaction is sent to a facilitator. The facilitator validates the transaction, then broadcasts it onto the block chain. The payload is now sent to the agent or user.

The failure would be if an agent is unable to call a tool to perform it in the first place. The failure wouldn't be in the payment protocol.