toniantunovi

One thing that often gets overlooked in the tmux vs. alternatives debate is that tmux's staying power is largely about ubiquity on remote servers. Zellij is great on your local machine where you control the environment, but if you're doing a lot of work via ssh on machines you don't own, tmux is almost certainly already installed. The muscle memory transfers too.

That said, I'd push back on the idea that the default tmux config is just "ugly". The real usability issue is that the keybindings are so divorced from how people intuitively think about splits and windows that even experienced users can't remember them. The visual defaults are just a symptom of the deeper problem that it was designed for someone who already had a mental model built around screen.

The supply chain attack surface in WordPress plugins has always been particularly dangerous because the ecosystem encourages users to install many small single-purpose plugins from individual developers, most of whom aren't security-focused organizations. Buying out an established plugin with a large install base is a clever approach because you inherit years of user trust that took the original developer a long time to build.

The deeper structural issue is that plugin update notifications function as an implicit trust signal. Users see "update available" and click without questioning whether the author is still the same person. A package signing and transfer transparency system similar to what npm has been working toward would help here, but the WordPress ecosystem has historically moved slowly on security infrastructure.

This is a useful forcing function for distinguishing two architectural categories of Claude Code adjacent tooling. Tools that route your API traffic through a third-party harness are definitionally dependent on Anthropic's policy toward that harness. Tools that run locally and integrate via MCP, without touching the API subscription path at all, are outside this restriction entirely because they are just another tool in your local environment. The local-first architecture was always the right one for teams with compliance or privacy requirements. This week is a good illustration of why it is also the right one for teams that just want to avoid dependency on a vendor-intermediary relationship they cannot control.

The coding-specific version of this is worth naming precisely. The drift does not happen because you stop writing code. It happens because you stop reading the output carefully. With AI-generated code, there is a particular failure mode: the code is plausible enough to pass a quick review and tests pass, so you ship it. The understanding degradation is cumulative and invisible until it is not. The partial fix is making automated checks independent of the developer's attention level: type checking, SAST, dependency analysis, and coverage gates that run regardless of how carefully you reviewed the diff. These are not a substitute for understanding, but they create a floor below which "comfortable drift" cannot silently carry you. The question worth asking of any AI coding workflow is whether that floor exists and where it is.

Very nice contribution to OSS