Live data from Hacker News

Chat is a bad UI pattern for development tools

danieldelaney.net

81–90 of 432 posts

Re: Chat is a bad UI pattern for development tools

#81
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…

Voice messages within a chat UI is even worse. I can't search it, I can't listen to it in the same situations I can read a message. I wish I could block them within all these chat apps. "Sorry, you can't bother to send voice messages to this person."

Oh dear lord yes. I am always baffled when I hear that some folks send voice memos to people.

Re: Chat is a bad UI pattern for development tools

#82
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…

Email threads seem better for documenting and searching correspondence. The last counter argument I read got buried on Discord or Slack somewhere.

Discord and slack baffle me. I liked them specifically because they were more ephemeral than other options. Which, seems at odds with how people want them to be? Why?

Re: Chat is a bad UI pattern for development tools

#83

The nice thing about chat is it's open ended, the terrible thing is that holy crap I have to write a paragraph describing exactly what I want when I should just be able to hit a button or navigate through a couple menus.

> I should just be able to hit a button or navigate through a couple menus.

The problem with this is that you need a gazillion of menus, dialogs and options to find that modal which does the thing _exactly_ what you want. Menus and likes are a means to an end, we don't really want them, but up until recently we couldn't live without them. With instruct based computing this is all changing.

Re: Chat is a bad UI pattern for development tools

#84
Has anyone invited an LLM inside their lisp process that can be accessed from the repl? Being able to empower an LLM to be able to affect the running lisp image (compile functions etc), and having changes reflected back to the source on disk would be interesting.

Re: Chat is a bad UI pattern for development tools

#85
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…

Midjourney is an interesting case study in this I think, building their product UI as a discord bot. It was interesting to be sure, but I always felt like I was fighting the "interface" to get things done. It certainly wasn't all bad, and I think if I used it more it might even be great, but as someone who doesn't use Discord other than that and only rarely generated images, I had to read the docs every time I wanted…

I'm curious if you find their new website interface more tractable--there's some inherent friction to the prompting in either case, but I'd like to know if the Discord chat interface can be overcome by using a different interface or if the issue is more intrinsic.

Re: Chat is a bad UI pattern for development tools

#86
post #77

My nuclear fire hot take is that the chat pattern is actively hampering AI tools because we have to square peg -> round hole things either into the chat UI (because that's what people expect), or that as developers you have to square peg -> round hole into the chat API patterns. Last night I wrote an implementation of an AI paper and it was so much easier to just discard the automatic chat formatting and do it "by ha…

Whoa! You broke my brain a bit there (but your posts often do, in a Good way!)

Would you be so kind as to ELI5 what you did in that index.js?

I've used ollama to run models locally, but I'm still stuck in chat-land.

Of course, if a blog post is in the works, I'll just wait for that :)

Re: Chat is a bad UI pattern for development tools

#87
This is lowkey cope. AI should be like talking to another human, at least that is the promise. Instead we're getting glorified autocomplete with padded language to sound like a human.

In its current form LLMs are pretty much at their limit, barring optimization and chaining them together for more productivity once we have better hardware. Still, it will just be useful for repetitive low level tasks and mediocre art. We need more breakthroughs beyond transformers to approach something that creates like humans instead of using statistical inference.

Re: Chat is a bad UI pattern for development tools

#88
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…

Email threads seem better for documenting and searching correspondence. The last counter argument I read got buried on Discord or Slack somewhere.

Isn't this entirely an implementation detail of slack and discord search? What about email makes it more searchable fundamentally? The meta data if both platforms is essentially the same, no?

Re: Chat is a bad UI pattern for development tools

#89
Just two tips/thoughts:

1) The first thing to improve chats as a genre of interface, is that they should all always be a tree/hierarchy (just like Hacker News is), so that you can go back to ANY precise prior point during a discussion/chat and branch off in a different direction, and the only context the AI sees during the conversation is the "Current Node" (your last post), and all "Parent Nodes" going back to the beginning. So that at any time, it's not even aware of all the prior "bad branches" you decided to abandon.

2) My second tip for designs of Coding Agents is do what mine does. I invented a 'block_begin/block_end' syntax which looks like this, and can be in any source file:

// block_begin MyAddNumbers

var = add(a, b)

return a + b

// block_end

With this syntax you can use English language to explain and reason about extremely specific parts of your code with out expecting the LLM to "just understand". You can also direct the LLM to only edit/update specific "Named Blocks", as I call them.

So a trivial example of a prompt expression related to the above might be "Always put number adding stuff in the MyAddNumbers Block".

To explain entire architectural aspects to the LLM, these code block names are extremely useful.

Re: Chat is a bad UI pattern for development tools

#90
I agree with this and disagree at the same time. It depends what the goal is. If the goal is to have AI write the entire codebase for you, yes chat and human language is quite bad. That's part of the reason formal languages exist. But then only experts can use it. Requirement docs are a decent middle ground. However, I'm not sure it's a good goal for AI to generate the code base.

The mode that I've found most fruitful when using Cursor is treating it almost exactly as I would a pair programming partner. When I start on a new piece of functionality I describe the problem and give it what my thoughts are on a potential solution and invite feedback. Sometimes my solution is the best. Sometimes the LLM had a better idea and frequently we take a modified version of what one of us suggested. Just as you would with a human partner. The result of the discussion is better than what either of us would have done on their own.

I also will do classical ping-pong style tdd with it one we agreed on an approach. I'll write a test; llm makes it pass and write the next test which I'll make pass and so on.

As with a real pair, it's important to notice when they are struggling and help them or take over. You can only do this if you stay fully engaged and understand every line. Just like when pairing. I've found llms get frequently in a loop where something doesn't work and they keep applying the same changes they've tried before and it never works. Understand what they are trying to do and help them out. Don't be a shitty pair for your llm!

Post reply on HN