> Even if it's broken (which it didn't seem to be) it's just FE anyway so not the end of the world.
Last week alone I was unable to access two major websites because their auth flow was broken (I was attempting to log in with Apple, so not "the happy path"). I was just locked out, had to contact support. I guess this mentality is what causes it.
We had safeguards and best practices built over the years of learnings to avoid introducing these kind of regressions. And we threw them away in half a year to...gain some productivity in delivering features that most likely the users don't even want.
I'm a mobile dev and know the iOS ecosystem quite well, i can assure you that iOS APIs are locked and developers can access very little user data without user consent. What an iOS user is vulnerable to is fingerprinting (not too different than what happens on web tbh) and 0days. But given how valuable iOS 0days are it's unlikely they are used inside large scale generic apps and not for targeted attacks. Also it's unlikely that a random company sits on a 0days and uses it against its users.
So ultimately yes, installing an app on iOS is not a trust decision because the dev are very limited in what they can do. The biggest trust decision is toward Apple that might have private secret APIs allowing them to do things developers cannot. That's a possibility, but overall Apple business has never been around ads, big data and users profiling so the chances are not this high.
Actually there are a lot of information that an app can do by default without asking for any permissions.
You can check this opensource iOS app: https://github.com/mysk-research/loupe
For instance: check if some apps are installed or not, and a lot of small informations about your device that can fingerprint your phone with 100% accuracy (like the exact time where the phone was setup).
I know Loupe, very cool project. Yes, as I said fingerprinting is the biggest risk, but personal data, photos, location, microphones, camera access are locked (which is what concerns most people).
Fingerprinting I would argue it's a problem on all platforms though, web included.
This is a step in an interesting direction for many reasons. First of all it reduces the "conversation in english" aspect and goes back to kinda "writing code" which I think would reduce a lot of fatigue and bring back some joy in making software. But then it also gives more control over the output in a way that makes sense: I know how i want to code this, but I can save time not having to deal with the syntax/boilerplate/actual writing. Also since I structured everything precisely, reviewing is going to be way easier.
It requires though yet another mental shift in how to code: you stop chatting and you go back to writing in a text editor similarly to what you did before, the difference is that now you write some kind of scaffold instead than the actual code.
It has two problems though: if my approach has flaws the agent would implement it as-is even if could instead suggest an improvement. Also, an advantage of agents in huge codebases is that they can find where to make the change and draft it, which wouldn't work with this system.
In practice I think a lot of engineers would do this. My recommendation would be to avoid this at all costs. In my opinion, the way to scale a codebase with AI is to have some part of the codebase that is reserved only for human hands. You need to be able to look at something written, and to know that it expresses human intent. Once you deviate from that constraint, then you might be even worse off than before, because now you have 2 sets of generated source code to sift through, not 1.
Of course the Logitech mouse can be plugged and will just work without installation. The software allows to customize buttons, macros, DPI ranges, lights, etc.
Still sucks, but it's not really needed to make it work or use it.
That works now because there are human made sources that the AI can find and summarize for you. But now there are no incentives at all for humans to write anything on the internet and if they do the content will be buried by hallucinated content someone else posted at a larger scale.
I had the similar experience to yours yesterday and it lead nowhere. Funnily enough I was also trying to configure a vpn on a router, google didn't return anything useful (besides a blog post clearly written by AI and with absolutely no information in it). Claude managed to give some interesting pointers, but its suggestions were not working and I also noticed that it started to hallucinate badly about ipv6 and gave me some suggestions that were just plain untrue. Claude Opus is smart, usually when it gets so convinced about something is after researching the internet and not just based on its training data. I wonder where it got so convinced about it. Maybe reading some other hallucinated blog post like the one I stumbled upon?
Isn't this only a transitionary problem though? Right now, during the transition there is no incentive for humans to write anything, it will get drowned in AI slop.
As time goes on, more and more people will recognize this problem and we'll develop new ways of measuring information quality and trustworthiness. Nothing about this problem is fundamental, it's just that we're in the middle of a very chaotic transition.
> What's the benefit of this type of stacked PRs over a well-curated set of commits, and reviewing per commit?
Even if the reviewer does the review commit-by-commit, all the comments and discussions will be on the same PR leading to multiple ongoing conversations about different topics that would be split if the PR are stacked. Also, all the new commits addressing the comments with spoil this commit-by-commit design, as the previous commits will be outdated and the new changes will be on top of those. I think it's beneficial for new changes to be a separate commit and not rewriting history, to not force the reviewers to re-read everything but just the latest changes.
They don't need to be the majority. One big company paying 200/300k in credits each month easily makes up for the majority of single users not doing so. I believe AI companies today make money through b2b enterprise deals and not selling to individual users, the latter is mostly a marketing expense to get people to use their product instead than the competitors one.
As long as you are fine with everything your team puts into Claude being retained by Anthropic. Afaik only enterprise API plans provide non data retention policies.
One would think that it could be possible to make a tool that takes some text and "anonymizes" it by making it a little more standard and boring (uniforming punctuation and sentence structure, changing words with some synonyms, etc). Maybe wouldn't make it particularly compelling, but would be valuable for political dissidents and other people with a high threat model.
Last week alone I was unable to access two major websites because their auth flow was broken (I was attempting to log in with Apple, so not "the happy path"). I was just locked out, had to contact support. I guess this mentality is what causes it.
We had safeguards and best practices built over the years of learnings to avoid introducing these kind of regressions. And we threw them away in half a year to...gain some productivity in delivering features that most likely the users don't even want.
reply