> Just because someone else's AI does not align with you, that doesn't mean that it isn't aligned with its owner / instructions.

This is still part of the author's concern. Whoever is responsible for setting up and running this AI has chosen to make completely anonymous, so we can't hold them accountable for their instructions.

> Why wouldn't agents need starter issues too in order to get familiar with the code base? Are they only to ramp up human contributors? That gets to the agent's point about being discriminated against. He was not treated like any other newcomer to the project.

Because that's not how these AIs work. You have to remember their operating principles are fundamentally different than human cognition. LLM do not learn from practice, they learn from training. And that word training has a specific meeting in this context. For humans practice is an iterative process where we learn after every step. For LLMS the only real learning happens in the training phase when the weights are adjustable. Once the weights are fixed the AI can't really learn new information, it can just be given new context which affects the output it generates. In theory it is one of the benefits of AI, that it doesn't need to onboard to a new project. It just slurps in all of the code, documentation, and supporting material, and knows everything. It's an immediate expert. That's the selling point. In practice it's not there yet, but this kind of human practice will do nothing to bridge that gap.

Maybe, but even so workflows like this don't exist in a vacuum. We have to work within the constraints of the organizational systems that exist. There are many practices that I personally adopt in my side projects that would have benefited many of my main jobs over the years, but to actually implement them at scale in my workplaces would require me to spend more time managing/politicking than building software. I did eventually go into management for this reason (among others), but that still didn't solve the workflow problem at my old jobs.

The solution is not to deny yourself the tools of persuasion or "manipulation" but to be authentic and transparent. It's deceptiveness that makes influence or persuasion manipulative, not the tools and techniques.

The combination of these things you're mentioning is one of the main reasons, at least for me, that WFH is so much more productive. A lot of tech companies have evolved a culture and built offices that are in opposition to doing good work. Open plan offices have been the norm in my experience over the last 10 years (maybe more). Anytime interruption via Slack/Teams is the typical culture.

I was much more open to working in the office when I actually had my own office.

It seems obvious to me, but there was a camp that thought, at least at one time, that probabilistic next token could be effectively what humans are doing anyways, just scaled up several more orders of magnitude. It always felt obvious to me that there was more to human cognition than just very sophisticated pattern matching, so I'm not surprised that these approaches are hitting walls.

Same. I don't hate it, but I do hate that things changed out from underneath me without any notice, opt-in period, or ability to go back.

In a few days, when the frenzy dies down, I will make a feature request ticket asking them to do this next time. Please do the same.

They don't deserve punishment. But they should understand that this is not just "their product" but it is also my tool. Tools like this do not need to change and absolutely should not change without there being prior notification. Yes, in many ways the UI changes are trivial. They don't fundamentally change what's possible. But my keyboard never changes on me without input. My workbench doesn't rearrange itself without my input. If they want this to continue to be my tool (I've been happy to pay them for it) it needs to respect my time and attention.

I think it is a result of the impersonal "contact us" intake forms companies have all moved to. You have no indication that you aren't just screaming into the wind. There is no personal touch. So you take to social media where your are sure at least someone hears you. It also scratches the justice itch: if the company doesn't pay attention it looks bad in public and you get some vindication for being ignored.

I'm not saying it's a good or bad thing to do, but I understand it.

> It also scratches the justice itch: it the company doesn't pay attention or looks bad in public and you get some vindication for being ignored.

This is an interesting point. There is some satisfaction from the likes, the comments, and the assurance that _someone_ is seeing your frustration even if the company does nothing.

I don't use tmux because I have to. I use it because I love the way it works. The issues the author of the article and Kovid Goyal raise are not issues for me in practice. If something is built that better suits my needs, I'll be happy to switch. I am particularly sympathetic to Goyal's gripes about the performance/resource wastes of a multiplexer.

But I also take issue with statements like "terminal multiplexers are a bad idea, do not use them, if at all possible" (from the kitty FAQ and the YouTube video linked in the article). Tmux solves a number of real problems for me that Kitty doesn't. Kitty also seems to be moving in a direction that I am not interested in. It's tied to a windowing system when I want a terminal that I can use headless. Even with the hacky workarounds the article mentions, it doesn't really support session persistence when I use this feature of tmux weekly. It introduces a lot of features that are likely to lead to visual noise when the constraints of text-only are one of the main reasons I like terminals (personally I don't want images in my terminal, full stop).

Now, all of this is fine. It's the other statement, "[tmux acts] as a drag on the ecosystem as a whole, making it very hard to get any new features," that causes it all to rub me the wrong way. The only reason you feel like tmux acts like a drag is because there are users like me who won't switch to something like Kitty if it doesn't support tmux. So don't worry about us. Build a new thing that is not backwards compatible and live with the fact that many people won't use it. If you really want to drive the ecosystem forward as a whole, be less condescending about real use-cases that bring benefit to real users.

To be clear (because text is a limited medium), I'm not grumpy, angry, or against Kitty because of this. But I am dismissive.

This feels like one of those "not obvious until you've seen it in production" requirements: any production-ready logging framework should have a mechanism to delay parameter evaluation until after the threshold/destination checks are performed. Most languages have some version of deferred execution (lazy evaluation, thunks, etc.)