This bothered me at first but I think it's about ease of implementation.
If you've built a good harness with access to lots of tools, it's very easy to plug in a request like "if the linked PR is approved, please react to the slack message with :checkmark:". For a lot of things I can see how it'd actually be harder to generate a script that uses the APIs correctly than to rely on the LLM to figure it out, and maybe that lets you figure out if it's worth spending an hour automating properly.
Of course the specific example in the post seems like it could be one-shotted pretty easily, so it's a strange motivating example.
> We still start all workflows using the LLM, which works for many cases. When we do rewrite, Claude Code can almost always rewrite the prompt into the code workflow in one-shot.
Why always start with an LLM to solve problems? Using an LLM adds a judgment call, and (at least for now) those judgment calls are not reliable. For something like the motivating example in this article of "is this PR approved" it seems straightforward to get the deterministic right answer using the github API without muddying the waters with an LLM.
No, they've been doing "managing stacks of dependent pull requests" for a lot longer than AI code review. I've mostly been a happy user, they simplify a lot of the git pain of continually rebasing and the UI makes stacks much easier to work with than Github's own interface.
Bandwidth is the limiting factor in a lot of circumstances, and networks are very challenging to manage. Especially with an increasing number of users on mobile connections, reducing network usage can be the right call.
But performance matters, too, of course. It's tricky to balance them.
On the other hand, tls/443 is pretty undesirable for media delivery in videoconferencing because a) it's tcp-based and the required ACKs mean a big reduction in throughput and increase in latency, especially in the presence of packet loss, and b) most video services these days (and open source servers) use webrtc which encrypts the data in transit already--so the tls encryption is a waste of resources
Though tls/443 is usually still supported because it's most often allowed by even restrictive firewalls and networks
Of course the specific example in the post seems like it could be one-shotted pretty easily, so it's a strange motivating example.