I think you're right, though you're talking about an old era, where the iPhone was truly revolutionary, but how do you think the Duo is different from the other folds now?
the first iPhone was years ahead of its time, but the first Apple foldable is arguably the exact same (if not inferior) to the competition, with the exception of the good user experience we're used to from Apple
Based on the marketing materials, the Duo is different from other folds because:
- Runs iOS with lots(?) of attention to UI
- Won't break from a piece of dust
- IP68 rated
- Will actually receive software updates unlike many Android devices
et cetera et cetera
> the first iPhone was years ahead of its time
Not really, not if you were paying attention to the market at the time. It was the first smartphone to put everything in a cohesive package instead of being a weird little computer that could make phone calls, but technologically it was comparable to features that already existed when it released. The real innovation was in UI and product design.
How can you make a computer or smartphone that's distinct from the competition? These are commodity appliances built to a price point with some graphic design slapped on top to pretty it up.
The iPhone launch was met with a lot of derision and eye-rolling despite that being the result of a half decade "effort to make themselves distinct from the competition".
Those events are rare, the opportunities to really shake things up are fleeting, as everyone is driving forward with relentless, incremental progress that quickly closes up all but the biggest gaps.
What could they possibly do that wouldn't be slammed as derivative?
I’ve been in your same situation for a long time now and I’ve been building a platform to help myself navigate through so many PRs, and doing all of this on github wasn’t sustainable, you could try it out and see if it helps your situation.
https://pyor.review
humans are still better at coding, AI is just faster and cheaper, not better.
the cheap code is still cheap, and we need real engineers to review it still to convert it to high quality code.
I read the summary which for me focuses on intent: What's the current state, why it's not good, what is being changed and how, and then look at performance numbers.
Then I read the code but only after it got scrutinized by pr review skills on multiple models and those feedback got marked completed by the author.
Yeah, same here, but I do not pay that much attention to the PR description since it's all written by the same AI, it just narrates its own code. I prefer to skim it then jump to the code.
The problem thesis is already in the ticket, so we could just reference it in the PR without duplication. The current state and how it's being changed are already the code diff itself under the changes tab, right? Reading it straight makes me question the code better since the AI is usually overconfident in its writing, so I don't focus on it unless I face a hard blocker or constraint that should be mentioned there.
I also do this with my swarm of review agents, asking them to review the code without context, that way, they produce more high-quality feedback that is backed by self-sourcing the context from the codebase instead of relying on the AI-provided PR description that might justify a code change that others might disagree with otherwise. it works well especially with code changes that could miss other parts of the codebase during refactoring or implementing features that touch multiple domains.
Interesting, I built https://pyor.review to fix this exact issue, though it uses AI to categorize the files and groups them by complexity to speed up the review process because most AI generated code is noise, especially migration PRs.
Curious to know if this could be done in a deterministic way without the help of AI
The only way to scale reviews is by using AI to skip rather than add more walls of text
reply