Live data from Hacker News

Chat is a bad UI pattern for development tools

danieldelaney.net

171–180 of 432 posts

Re: Chat is a bad UI pattern for development tools

#171
post #52

I'm growing to the idea that chat is a bad UI pattern, period. It is a great record of correspondence, I think. But it is a terrible UI for doing anything. In large, I assert this is because the best way to do something is to do that thing. There can be correspondence around the thing, but the artifacts that you are building are separate things. You could probably take this further and say that narrative is a terribl…

> It can be a great way to communicate them It's usually not. Narrative is a famously flawed way to communicate or record the real world. It's great for generating engagement, though.

> Narrative is a famously flawed way to communicate or record the real world.

...and yet with it's flaws, it's the most flexible in conveying meaning. A Ted Chiang interview was on the HN frontpage a few days ago, in it, he mentions that humans created multiple precise, unambiguous communication modes like equations used in mathematical papers and proofs. But those same papers are not 100% equations, the mathematicians have to fall back to flawed language to describe and provide context because those formal languages only capture a smaller range of human thought compared to natural language.

This is not to say chat has the best ergonomics for development - it's not, but one has to remember that the tools are based on Large Language Models whose one-trick is manipulating language. Better ergonomics would likely come from models trained or fine-tuned on AST-tokens and diffs. They'd still need to modulate on language (understanding requirements, hints, variable names,and authoring comments, commits and/or PRs).

Re: Chat is a bad UI pattern for development tools

#173
post #5

Natural language isn’t made to be precise that’s why we use a subset in programming languages. So you either need lots of extra text to remove the ambiguity of natural language if you use AI or you need a special precise subset to communicate with AI and that’s just programming with extra steps.

Natural language can be precise, but only in context.

The struggle is to provide a context that disambiguates the way you want it to.

LLMs solve this problem by avoiding it entirely: they stay ambiguous, and just give you the most familiar context, letting you change direction with more prompts. It's a cool approach, but it's often not worth the extra steps, and sometimes your context window can't fit enough steps anyway.

My big idea (the Story Empathizer) is to restructure this interaction such that the only work left to the user is to decide which context suits their purpose best. Given enough context instances (I call them backstories), this approach to natural language processing could recursively eliminate much of its own ambiguity, leaving very little work for us to do in the end.

Right now my biggest struggle is figuring out what the foundational backstories will be, and writing them.

Re: Chat is a bad UI pattern for development tools

#174
post #142

Narrative text is a worse UI pattern. It's impractical to read. Also how exactly do you merge narrative changes if you need to write several transformations as updates? Are you expected to update the original text? How does this affect diffs in version control? I think it's more ideal to have the LLM map text to some declarative pseudocode that's easy to read which is then translated to code. The example given by Dan…

It's interesting, it seems that we are looping back on the old trend of Model-Driven Architecture

Re: Chat is a bad UI pattern for development tools

#175
Chat is a great UX _around_ development tools. Imagine having a pair programmer and never being allowed to speak to them. You could only communicate by taking over the keyboard and editing the code. You'd never get anything done.

Chat is an awesome powerup for any serious tool you already have, so long as the entity on the other side of the chat has the agency to actually manipulate the tool alongside you as well.

Re: Chat is a bad UI pattern for development tools

#176

Earlier quoted context omitted.

I even think it's bad for generalized communication (ie. Slack/Teams/Discord/etc.) that isn't completely throwaway. Email is better in every single way for anything that might ever be relevant to review again or be filtered due to too much going on.

I've had the opposite experience. I have never had any issue finding information in slack with history going back nearly a decade. The only issue I have with Slack is a people problem where most communication is siloed in private channels and DMs. Email threads are incredibly hard to follow though. The UX is rough and it shows.

I hard disagree. Don't have a conversation? Ask someone who does to forward it. Email lets the user control how to organize conversations. Want to stuff a conversation in a folder? Sure. Use tags religiously? Go for it. Have one big pile and rely on full-text search and metadata queries? You bet. Only the last of these is possible with the vast majority of IM platforms because the medium just doesn't allow for any other paradigm.

The fact that there's a subject header alone leads people to both stay on topic and have better thought out messages.

I agree that email threads could have better UX. Part of that is the clients insistence on appending the previous message to every reply. This is completely optional though and should probably be turned off by default for simple replies.

Re: Chat is a bad UI pattern for development tools

#177
post #5

Natural language isn’t made to be precise that’s why we use a subset in programming languages. So you either need lots of extra text to remove the ambiguity of natural language if you use AI or you need a special precise subset to communicate with AI and that’s just programming with extra steps.

A lot of extra text usually means prior requirements, meeting transcripts, screen share recordings, chat history, Jira tickets and so on - the same information developers use to produce a result that satisfies the stakeholders and does the job. This seems like a straightforward direction solvable with more compute and more efficient memory. I think this will be the way it pans outs. Real projects don't require an inf…

This premise in your last paragraph can only work with AGI, and we’re probably not close to that yet.

Re: Chat is a bad UI pattern for development tools

#178
I'm in the business of data collection, to some extent: building a support system for residential solar panel installations. There's a bunch of data needed for simulations, purchase estimations, legal and tax reasons. Not insane amounts, but enough that filling out a form feels tedious. LLMs are great in that they can be given a task to gather a number of pieces, and can explain to the user what "kWh" means, at many level of technical depth.

We play around with LLMs to build a chat experience. My first attempt made Claude spew out five questions at a time, which didn't solve the "guiding" problem. So I started asking it to limit the number of unanswered questions. It worked, but felt really clunky and "cheap."

I drew two conclusions: We need UI builders for this to feel nice, and professionals will want to use forms.

First, LLMs would be great at driving step-by-step guides, but it must be given building blocks to generate a UI. When asking about location, show a map. When deciding to ask about TIN or roof size, if the user is technically inclined, perhaps start with asking about the roof. When asking about the roof size, let the user draw the shape and assign lengths. Or display aerial photos. The result on screen shouldn't be a log of me-you text messages, but a live-updated summary of where we are, and what's remaining.

Second, professionals have incentive to build mental model for navigating complex data structures. People who have no reason to invest time into the data model (e.g. a consumer buying a single solar panel installation in ther lifetime,) will benefit from rich LLM-driven UIs. Chat UIs might create room for a new type of computer user who doesn't use visual clues to build this mental model, but everyone else will want to stay on graphics. If you're an executive wondering how many sick days there were last month, that's a situation where a BI LLM RAG would be great. But if you're not sure what your question is, because you're hired to make up your own questions, then pointing, clicking and massaging might make more sense.

Re: Chat is a bad UI pattern for development tools

#179
post #116

After using Cursor and Copilot for some time, I long for a tool that works like a "real" collaborator. We share a spec and make comments, resolve them. We file issues and pull requests and approve them. We use tests and specs to lock down our decisions. We keep a backlog up to date, maintain our user docs, discuss what assumptions we have to validate still, and write down our decisions. Like with any coworker - when…

That's a great idea! Maybe when context window will be larger and tokens even cheaper?

I would like as well to add to it a peer-programming feature, with it making some comments on top of the shoulder when coding, a kind of smarter linter that will not lint one line, but that will have the entire project context.

Re: Chat is a bad UI pattern for development tools

#180
post #166

Earlier quoted context omitted.

I don't think I agree with this. Sure, many things should be versioned, but I don't think most correspondence requires it, which is emails primarily purpose.

Agreed if it is correspondence that we are talking about. So, agreed I'm probably too strong that anything needing filtering and such is bad. I'm thinking of things that are assembled. The correspondence that went into the assembly is largely of historical interest, but not necessarily one of current use.

Yup, I agree there. Email is a horrible means of collaborating on changes in general, but doubly so in realtime. But so is IM.
Post reply on HN