I feel like Opus 4.7 vs GPT 5.4 is pretty much just flavor variants, the big difference is in the harness. I like the Claude Code CLI better than the Codex CLI, it just clicks with how I like to interact with agents. The codex app on the other hand is better than the Claude app in code view, so if I had to stick to an app it would be codex all the way.
If you want to burn tokens making a bespoke podcast player its probably a good learning exercise. I like Overcast, it would be great if i could see the latest episodes on the front page when opening the app, otherwise its fine.
Haha, good luck working with a team with more than 2 people. A good reviewer looks at the end-state and does not care about individual commits. If im curious about a specific change i just look at the blame.
> A good reviewer looks at the end-state and does not care about individual commits.
Then I must be a bad reviewer. In a past job, I had a colleague who meticulously crafted his commits - his PRs were a joy to review because I could go commit by commit in logical chunks, rather than wading through a single 3k line diff. I tried to do the same for him and hope I succeeded.
And then someone comments on a thing, they change it and force-push another "clean" history on top and all of your work is wasted because the PR is now completely different =)
You can, but most of us work in Github and having a PR to dump commits to is very easy and convenient. Then, when you get some feedback on your PR, you can dump more commits and it's very easy for the reviewer to see what has changed since the last time they reviewed it.
I feel like what you're arguing is that you should clean up your commits before anyone else sees them. Fair. But you could also clean it up right before merging to main. It's not that different, except the latter is much less annoying, particularly when going back and forth with people.
I know this is a very github centric workflow, but that's where most engineers work now, and it's nice and easy. This wouldn't work for eg: contributing to linux, but that's not what most of us do.
This is where the "Trunk based development" people live - I personally believe that commits should be atomic, because git bisect on smaller meaningful commits is a hang of a lot better than a monster 90 file change commit
Why is it "wade through" if there are 10 clearly distinct but dependent commits, but comfortable if it's 10 stacked PRs instead? They are basically the same thing, presented ever so slightly differently.
I think in most teams I've worked with, the majority of developers (> 85%) barely undestand what Git is doing or what things mean inside GitHub, have never seen commit history as a graph, have never run something like "git log --oneline --graph --decorate" or "--format", and have never heard of "git range-diff" which is very useful for following commit/PR/unit changes.
Personally I review using "git" itself, so I see the graph structure either way, and there's little difference between stacked PRs, commit chains in a single PR, or even feature branches, from that point of view. Even force-push branch updatea aren't difficult to review, because of the reflog and "git range-diff". The differences are mainly in what kinds of behaviour the web-based tooling promotes in the rest of the team, which does matter, and depends on the team.
I agree with you if you're using Graphite instead of GitHub. Having a place to give feedback and/or approval on the individual "units" (commits in a PR, or PRs in a stack) is useful, grouping dependent but distinct changes is useful, and diff'd commit evolution within each unit PR in response to back-end-forth review feedback is useful in some collaborative settings. Though, if you know "git range-diff" and reflog, that shows diff'd commit evolution quite well.
In GitHub, people are confused by stacked PRs both conceptually and due to the GitHub UX around them. Most times when I've posted a stacked PR to a GitHub project, other people didn't realise it was stacked, and occasinally someone else has merged the tip of a stack made by me, and been surprised to see all the dependent PRs merged automatically as a side effect. Usually before they get to reviewing those other PRs :-)
People understand commit sequences in a PR, though I've rarely seen people treat the individual commits as units for review when using GitHub, unfortunately. In the Linux kernel world where Git was born, the PR flow is completely different from GitHub: Their system tends to result in feedback on individual commits. It also encourages better quality feedback, with less nitpicking, and better quality commits.
Some of these commits even get reviewed by different maintainers before being merged, which is common when a patchset touches several subsystems at once.
iTunes? i wonder what kind of sales we're talking about here. people buying music is few and far between, and i wonder what percentage of that customer base buys their music on iTunes when there are great alternatives offering lossless files
While the current administration has multiple areas of improvement and isnt really taking feedback in an adult manner, the federal workforce has some of the most competent people working for it inside certain parts of the organization. im thinking especially of NASA and NASA JPL.
This is true, but a lot of the top positions are being replaced with unqualified loyalists. It's only a matter of time, if this continues, that the competent workforce gets eroded
JPL has been strangled by both parties. They had huge staff cuts in 2024, and then more in 2025. They've gone from ~6,500 to ~4,500. Trump closed their research library[1].
Of course this is a drop in the bucket, the entire science research apparatus of the United States is being burned to the ground[2]. This administration is doing to the future of scientific research what the Mongols did to Baghdad.
NASA also has some of the most incompetent people working for it, and a lot of them are responsible for overseeing SLS and Orion. JPL hasn’t been doing to well lately either (Mars Return?).
this is such a classic american reply. "vote with your wallet" and "the market decides". thing is most people don't care, don't complain or are not in a situation where they can "vote with their wallet". truth is, some regulation must exist to nudge companies is the right direction. a good example of this is e.g disposable vapes, people love them for some reason, but they are extremely wasteful.
Trouble is that regulation isn't imposed by an omnipotent deity in the sky. In a democracy, regulation must come from the very same people who you say don't care, don't complain, and aren't willing to change their habits. Given that you say the people don't care, aren't willing to change, and perhaps even prefer the status quo, regulation isn't going to magically appear.
reply