Chat is a bad UI pattern for development tools

My preferences are the opposite, but my mental frame is more about utility than about safety. I'm not worried about someone fishing for something I said that could be construed as commitment or admission - they can just as easily do that with e-mail[0]. For me, conversations can be extremely valuable, and I gravitate towards people and places where that's a common case. HN is one of such places - the comment threads here are conversations (half-way in form between chat and e-mail), and they often are valuable, as people often share deep insights, interesting ideas, worthwhile advice and useful facts. Because they're valuable, my instinct is that they need to be preserved, so that myself and others can find those gems again, or (re)discover them when searching for solutions, or read again to reevaluate, etc.

So now imagine such (idealized) HN threads transplanted to Discord or Slack. Same people, same topics, same insights, just unrolling in the form of a regular chat. All that value, briefly there to partake in, and then forever lost after however much time it takes for it to get pushed up a few screens worth of lines in the chat log. People don't habitually scroll back very far on a regular basis (and the UI of most chat platforms starts to rapidly break down if you try), and the lack of defined structure (bounded conversations labeled by a topic) plus weak search tools means you're unlikely to find a conversation again even if you know where and when it took place.

That, plus ephemeral nature of casual chat means not just the platform, but also some of the users expect it to quickly disappear, leading to what I consider anti-features such as the ability to unilaterally edit or unsend any message at arbitrary time in the future. It takes just one participant deciding, for whatever reason, to mass-delete their past messages, for many conversations to lose most of their value forever.

--

[0] - Especially that the traditional communication style, both private and business, is overly verbose. Quite like a chat, in fact, but between characters in a theatrical play - everyone has longer lines.

IMHO, I would agree with you.

I think chat is a nice intermediary evolution between the CLI (that we use every day) and whatever comes next.

I work at Augment (https://augmentcode.com), which, surprise surprise, is an AI coding assistant. We think about the new modality required to interact with code and AI on a daily basis.

Beside increase productivity (and happiness, as you don't have to do mundane tasks like tests, documentations, etc), I personally believe that what AI can open up is actually more of a way for non-coders (think PMs) to interact with a codebase. AI is really good at converting specs, user stories, and so on into tasks—which today still need to be implemented by software engineers (with the help of AI for the more tedious work). Think of what Figma did between designers and developers, but applied to coding.

What’s the actual "new UI/UX paradigm"? I don’t know yet. But like with Figma, I believe there’s a happy ending waiting for everyone.

> Typing "make the bar a bit more like a fizzbuzz" in some textbox is awful UX compared to, say, clicking on the "bar" and selecting "fizzbuzz" or drag-and-dropping "fizzbuzz" on the "bar" or really anything that takes advantage of the fact we're interacting with a graphical environment to do work on graphics.

That assumes that you have a UX capable of determining what you're clicking on in the generated image (which we could call a given if we assume a sufficiently capable AI model since we're already instructing it to alter the thing), and also that it can determine from your click that you've intended to click on the "foo" not the "greeble" that is on the foo or the shadow covering that part of the foo or anything else that might be in the same Z stack as your intended target. Pixel bitching adventure games come to mind as an example of how badly this can go for us. And yes, this is solvable, Squeak has a UI where repeatedly clicking in the same spot will iterate through the list of possibilities in that Z stack. But it could also get really messy really quickly.

Then we have to assume that your UX will be able to generate an entire list of possible things you might want to be able to to do with that thing that you've clicked, including adding to it, removing it, removing part of it, moving it, transforming its dimensions, altering its colors, altering the material surface and on and on and on. And that list of possibilities needs to be navigable and searchable in a way that's faster than just typing "make the bar more like a fizzbuzz" into a context aware chat box.

Again, I'm not arguing the chat interface should be the only interface. In fact, as you point out we're using a graphical system, it would be great if you could click on things or select them and have the system work on too. It should be able to take additional input than just chat. But I still think for iterating on a fuzzy idea, a chat UI is a useful tool.

AI "Agents" that can do tasks outside of the confines of just a chat window are probably the next stage of utility.

The company I work for integrated AI into some of our native content authoring front-end components and people loved it. Our system took a lot of annotating to be able to accurately translate the natural language to the patterns of our system but users so far have found it WAYYY more useful than chat bc it's deeply integrated into the tasks they do anyway.

Figma had a similar success at last year's CONFIG when they revealed AI was renaming default layers names (Layer 1, 2, etc)... something they didn't want to do anyway. I dare say nobody gave a flying f about their "template" AI generation whereas layer renaming got audible cheers. Workflow integration is how you show people AI isn't just replacing their job like some bad sci-fi script.

Workflow integration is going to be big. I think chat will have its place tho; just kind of as an aside in many cases.

  > Building the wrong thing fast is about as useful as not building anything at all.

SAY IT LOUDER

Fully agree. Plus, you may be faster in the short term but you won't in the long run. The effects of both good code and bad code compound. "Tech debt" is just a fancy term for "compounding shit". And it is true, all code is shit, but it isn't binary; there is a big difference between being stepping in shit and being waist deep in shit.

I can predict some of the responses

  Premature optimization is the root of all evil

There's a grave misunderstanding in this adage[0], and I think many interpret it as "don't worry about efficiency, worry about output." But the context is that you shouldn't optimize without first profiling the code, not that you shouldn't optimize![1] I find it also funny revisiting this quote, because it seems like it is written by a stranger in a strange land, where programmers are overly concerned with optimizing their code. These days, I hear very little about optimization (except when I work with HPC people) except when people are saying to not optimize. Explains why everything is so sluggish...

[0] https://softwareengineering.stackexchange.com/a/80092

[1] Understanding the limitations of big O analysis really helps in understanding why this point matters. Usually when n is small, you can have worse big O and still be faster. But the constants we drop off often aren't a rounding error. https://csweb.wooster.edu/dbyrnes/cs200/htmlNotes/qsort3.htm