I've published a new, general-purpose terminal specification that gives any program a way to tell the terminal what it's doing: idle, working, waiting, finished, or failed, and why. It is easy to implement on both sides. I've written more about why: mitchellh.com/writing/progra… The problem this solves is generic and applies in compelling ways to all sorts of use cases (e.g. package managers, build tools), but it really rears a hideous head when it comes to AI and the "agentic inbox" problem. I found over 250 different agent orchestrators (with various goals) that all individually implement a heuristic based approach to detecting whether things like Claude Code are working, blocked, done, etc. If you look at @herdrdev's commit history, you can see around 10 compatibility changes to detect Claude Code within just the past 3 months. (This isn't a dig at Herdr! They're doing great work with what they have, and everyone else is doing the same thing). Heuristics are not the way. And over-indexing on agentic use cases isn't the way, because this problem is really interesting for other tools too: Homebrew, Terraform, Cargo, etc. etc. Proprietary protocols and out of band APIs are not the way. They have an O(N) integration problem and require extra work to work over SSH or within local VMs/containers. The program status specification (OSC 7501) solves this in a reliable, deterministic way that is general-purpose and can be easily adopted by the entire industry. Read more: mitchellh.com/writing/progra…

The "whiteboard defense:" I should be able to pull you aside at any moment and ask you to explain any customer-facing system you've shipped. You should be able to clearly explain how it works and defend the decisions you made. This is my benchmark for responsible AI usage. I don't expect line-level familiarity with the code. I don't care if you remember the exact function name or implementation detail. You may not even know it. I don't care. But if I ask "why did you do X instead of Y?", "what happens if this actor behaves maliciously?", "what data structure did you use here and why?", or "where does this fail?" you should be able to answer confidently. For PoCs, demos, experiments, whatever: I don't care. Generate 100% of it and understand none of it. Speed over quality every time in those specific scenarios. But if you're shipping customer-facing work, you can't be shipping things you don't understand at a high level.

A quick look into remote persistent sessions with Superlogical! Not just remote sessions, but some functionality like remote directory lists, too. Superlogical can actually be a full SSH replacement (I don't run SSH on my servers anymore), and I talk about that briefly, too.

Quick Superlogical demo to end the week. This demo is just of the basic functionality, but I want to highlight just how FAST it is. There's a WHOLE lot more functionality already present and coming but I wanted to keep the demo short. But seriously, check out that speed. I'm showing the macOS app here and I get asked a lot so let me just say up front: its not macOS only. We're still figuring out exactly what platforms will be stable enough for the initial public release, but we're working on others. In particular, the web interface is very functional but I'll demo that another time (or someone else will). This is also all showing off the architecture I previously talked about for terminal multiplexing which is significantly different from other mainstream multiplexers: this is all a custom binary protocol where the server is maintaining N replica distributed terminal state machines. It works! Tons of hard work going into this by the team @almonk @dizzyup @pearkes. Hope we can bring you something you can use soon. ❤️ Happy to answer questions in the replies.

The problem with the "if it works who cares what the code looks like" mindset for agentic work is that it assumes the agent has a perfect understanding of "works." Realistically, things are underspecified, agents make bad assumptions, etc. To be fair, agents are pretty good at unit test coverage. They're pretty bad at designing human experiences (API, CLI flags, etc.), especially cohesive ones for future roadmap plans they may not have visibility into (unless your backlog is perfect and vision fully laid out, which I doubt). They're bad at knowing where performance matters and what type (CPU vs memory tradeoffs). They're bad at where compatibility matters and where it doesn't (and tend to err on the side of preserving it without further guidance). Etc. Unless you have this ALL specified, you can't possibly claim "it works" without taking a look and thinking about it.