Things that I’d consider table stakes that Phabricator had in 2016 - code movement/copying gutter indicators and code coverage gutters - are still missing, and their UI (even the brand new review UI that also renders suggestion comment diffs incorrectly) still hides the most important large file changes by default.

And the gutter “moved” indicators would be more useful than ever, as I used to be able to trust that a hand-written PR that moves a bunch of code around generally didn’t change it, but LLM refactors will sometimes “rewrite from memory“ instead of actually moving, changing the implementation or comments along the way.

And the system is designed to set up drivers for failure.

An HCI challenge with mostly autonomous systems is that operators lose their awareness of the system, and when things go wrong you can easily get worse outcomes than if the system was fully manual with an engaged operator.

This is a well known challenge in the nuclear energy sector and airline industry (Air France 447) - how do you keep operators fully engaged even though they almost never need to intervene, because otherwise they’re likely to be missing critical context and make wrong decisions. These days you could probably argue the same is true of software engineers reviewing LLM code that’s often - but not always - correct.

There are always systemic factors that can be improved, for example working on street design to separate dangerous cars from children, or transportation policy by shifting transportation to buses, bikes, and walking where the consequences of mistakes are significantly reduced.

Cars are the #2 killer of children in the US, and it’s largely because of attitudes like this that ignore the extreme harm that is caused by preventable “accidents”

But yeah, you definitely need a native experience to make side by side diffs viable on mobile.

[0] https://github.com/scottbez1/superdiff — I wish I had recorded some videos of the app back then. My code review workflow back then eventually stopped including diff attachments on code review emails, so I abandoned development on it.

I’ve actually considered a neck/shoulder support for a laptop in the past but decided against it because it’d be cumbersome and make me a theft target.

As for AI, personally speaking I use AI coding tools to allow me to continue enjoying some hobby side projects with less free time available with a kid. It’s been a massive boost to my happiness in a generally low stakes area. I’m curious to see if I can get a similar unlock on my short and interrupted commute times as well, which is why I (personally) find this article interesting.

I spend hours each week riding transit, and use Claude for a bunch of side projects and have Tailscale set up already, so looks like I’ll be giving this a try this week!

Doom coding might be doomed while I’m in the transbay tube though, with awful cell service…

How’s the diff review? I rely heavily on the vs code integration for nice side by side diffs, so losing that might be a problem unless there’s some way to launch the diffs into a separate diff viewer app on the phone.

There are some very real benefits to touch interfaces in cooking (primarily ease of cleaning a solid flat surface, and manufacturers don’t need to worry about moisture ingress), but it’s pretty hard to make one that actually consistently works in a way that won’t accidentally burn your house down when your cat walks across the cooktop in the middle of the night. I’m personally going to stick to knobs and buttons in the meantime.

IIHS doesn’t have any mandate power over manufacturers (they are not a regulatory body) but they do align with insurance company interests, whose goals are to pay out less for damages from vehicle incidents, and therefore IIHS logically would theoretically be focused on actuarial data-driven analysis. If you have specific examples of where this has not been the case, I’d love to learn more.

To always auto land it needs to be as good as a fully trained and competent pilot, a much higher standard.

And I believe Waymo remote access only allows providing high level instructions (like pull over, take the next right, go around this car, etc) precisely because full direct control with a highly and variably latent system is very hard/dangerous.

And in an emergency situation you’re likely to have terrible connectivity AND high level commands are unlikely to be sufficient for the complexity of the situation.

Imagine a model that works real well for detecting cars and adults but routinely misses children; you could end up with cars that are 1/10th as deadly to adults but 2x as deadly to children. Yes, in this hypothetical it saves lives overall, but is it actually a societal good? In some ways yes, in some ways it should never be allowed on any roads at all. It’s one of the reasons aggregated metrics on safety are so important to scrutinize.

The scale of car travel plus the inherent kinetic energy involved make a correlated risk particularly likely to lead to a mass casualty event. There are very few information system vulnerabilities with that magnitude of short-term worst case outcome.

Arduino took over for 3 reasons: a thoughtful and relatively low cost (at the time) development board that included easy one-click flashing, a dead-simple cross-platform packaging of the avr-gcc toolchain, and a simple HAL that enabled libraries to flourish.

Only the first item, and a bit of the second), is really outdated at this point (with clones and ESP32 taking over the predominant hardware) but the framework is still extremely prominent and active even if many don’t realize it. ESPHome for example still will generally use the Arduino HAL/Framework enabling a wide library ecosystem, even though it’s using platformio under the hood for the toolchain.

Even folks who “don’t use Arduino any more” and use platformio instead are often still leveraging the HAL for library support, myself included. Advanced users might be using raw esp-idf but the esp-idf HAL has had a number of breaking API changes over the years that make library support more annoying unless you truly need advanced features or more performance.

They are all completely aligned with a policy reducing non-essential public exposure, with a tiered approach for transport that limits public exposure where better alternatives exist.

The latter is a huge reason companies strive to establish "platforms" and suites of connected apps - even if competition is cheaper/better in a vacuum, it still may not be worth the effort to switch if you're already established within an ecosystem. The goal is vendor lock-in even if they're not holding your data hostage (though they might do that too).

Recently bought a 14TB HDD and downloaded my entire Dropbox, Google Photos, and Lightroom photos. Planning to set up an off-site copy as well, and will probably build out a proper NAS within a few years.

I keep meaning to design some PCBs with them [1] but it's too far down my ever-growing list of projects to see the light of day...

[0] https://www.evilgeniuslabs.org/one-inch-fibonacci128

[1] https://www.lcsc.com/product-detail/C5349953.html

In particular, code review is one layer of the conventional swiss cheese model of preventing bugs, but code review becomes much less effective when suddenly the categories of errors to look out for change.

When I review a PR with large code moves, it was historically relatively safe to assume that a block of code was moved as-is (sadly only an assumption because GitHub still doesn't have indicators of duplicated/moved code like Phabricator had 10 years ago...), so I can focus my attention on higher level concerns, like does the new API design make sense? But if an LLM did the refactor, I need to scrutinize every character that was touched in the block of code that was "moved" because, as the parent commenter points out, that "moved" code may have actually been ingested, summarized, then rewritten from scratch based on that summary.

For this reason, I'm a big advocate of an "AI use" section in PR description templates; not because I care whether you used AI or not, but because some hints about where or how you used it will help me focus my efforts when reviewing your change, and tune the categories of errors I look out for.