I’ve had Claude Code diagnose bugs in a compiler we wrote together by using gdb and objdump to examine binaries it produces. We don’t have DWARF support yet so it is just examining the binary. That’s not security work, but it’s adjacent to the sorts of skills you’re talking about. The binaries are way smaller than real programs, though.
As a complete aside, I beat that game along with the DLC, lvl 170 (scadu 19), all by myself, and it was by far the biggest gaming accomplishment of my life.
People who lie about things like that make me sad. It's actually a hard thing to do. Waste of time? Absolutely.
Yes. This specific aspect of GitHub is the reason why many teams don't want you to modify commits, but instead, add more commits. Which then also leads to squash-merging branches.
Other systems, like Gerrit, handle this much better!
How do you communicate the results of this review to your colleagues?
(This is a genuine question, I think local first review is very interesting, but at some point, you've gotta send that feedback to the person you're reviewing.)
Yes, it is unfortunate. I did link an announcement below that some form of this feature is coming, we'll see what it actually looks like when it goes public.
If your PRs are more than one commit, you've already introduced work that builds on top of previous work before it's been reviewed.
Stacked diffs just let you review one commit at a time, rather than requiring a full review of the entire thing, while still letting you see that these changes are related, so you can go look at the full context if you'd like.
This lets you do things like "hey, backend person, please review this backend commit, frontend person, please review this frontend commit" instead of "both of you review this full PR". This can save the frontend person time if, for example, the frontend code passes review, but the backend reviewer hasn't had time to review the backend changes yet. They won't be pinged by the other review.
I just want the simple feature of PRs updating when the target branch changes. For example, say I have two tickets: T-100 and T-101. Both are targeting main, but T-101 builds on top of T-100. I put up a PR for the T-100 branch against main, and put up a PR for the T-101 branch against main.
The T-101 PR can't really be reviewed yet, since you are looking at changes from both T-100 and T-101 (because T-101 was based on T-100).
Ideally, after T-100 is reviewed and merged, the T-101 PR would automatically update to show only the T-101 changes. But it doesn't. You have to manually rebase or merge main and push changes to the branch to get it to update. It would be great if GitHub handled this automatically.
I have had good success lately with asking Claude to do your last option. jj also works fantastically for this, because you can easily jj new up a bunch of empty changes with the descriptions you want to have, and then jj restore the state from your original stack into them. If the process goes poorly for any reason, you still have your original stack around.
You don’t have to do it this way, you could use the oplog to undo it all if it’s not to your satisfaction, but it’s much simpler than trying to edit the commits into the right shape directly.
Just to be clear about it, we’re not “the stacked diffs company,” that is, we consider stacked diffs table stakes for good code review, not the entire point and focus of the product.
That said, we haven’t talked a ton publicly about what exactly we’re building yet, because we’re very focused on building it. But if you or anyone else is dealing with pain around source control management, I’d love to hear about it: steve@ersc.io
> Last week, I wrote a tail-call interpreter using the become keyword, which was recently added to nightly Rust (seven months ago is recent, right?).
reply