But I agree that Delve is a special case and should naturally be held to a higher standard here because their whole business is around being compliant with the law. When most other startups break the law, they do it to get an advantage over competition. Delve did it in a way that sacrificed their core value towards customers.

XCode is usually the first example that comes to mind of a terrible native app in comparison to the much nicer VSCode.

After covid, it was never the same. Open for shorter windows, closed on Sundays, reduced selection, no more meal kits etc.

I had many friends who worked on Amazon Go, so it's a bit sad to see that work come to an end.

AI code review does not replace human review. But AI reviewers will often notice little things that a human may miss. Sometimes the things they flag are false positives, but it's still worth checking in on them. If even one logical error or edge case gets caught by an AI reviewer that would've otherwise made it to production with just human review, it's a win.

Some AI reviewers will also factor in context of related files not visible in the diff. Humans can do this, but it's time consuming, and many don't.

AI reviews are also a great place to put "lint" like rules that would be complicated to express in standard linting tools like Eslint.

We currently run 3-4 AI reviewers on our PRs. The biggest problem I run into is outdated knowledge. We've had AI reviewers leave comments based on limitations of DynamoDB or whatever that haven't been true for the last year or two. And of course it feels tedious when 3 bots all leave similar comments on the same line, but even that is useful as reinforcement of a signal.

To go back to your question around why people still use these workarounds on top of git, it's because the CLI is just one piece of it. With Graphite, I also get a stack-aware merge queue and review dashboard.

https://github.com/rubygems/rubygems/blob/master/LICENSE.txt

The kitchen sink example in particular is one that trips up people. Without knowing the specifics of how a library may deal with failure edge cases, it can catch you off guard (e.g., axios errors including API key headers).

A lot of these problems come from architectures where secrets go over the wire instead of just using signatures/ids. But in cases where you have to use some third party platform, there's often no choice.

In many ways, this debacle is reminiscent of the Python 2 to 3 cutover. I wish we had started with bidirectional import interop and dual module publications with graceful transitions instead of this cold turkey "new versions will only publish ESM" approach.

2. You don't need to use axios. The main value was that it provides a unified API that could be used across runtimes and has many convenient abstractions. There were plenty of other lightweight HTTP libs that were more convenient than the stdlib 'http' module.