Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chat is a bad UI pattern for development tools

danieldelaney.net

Post reply on HN
Print view View original

221–230 of 432 posts

Re: Chat is a bad UI pattern for development tools

#221

Post by throwup238 »

ryandrake wrote: post #210
wiremine wrote: post #190

I'm going to take a contrarian view and say it's actually a good UI, but it's all about how you approach it. I just finished a small project where I used o3-mini and o3-mini-high to generate most of the code. I averaged around 200 lines of code an hour, including the business logic and unit tests. Total was around 2200 lines. So, not a big project, but not a throw away script. The code was perfectly fine for what we…

I guess the things I don't like about Chat are the same things I don't like about pair (or team) programming. I've always thought of programming as a solitary activity. You visualize the data structures, algorithms, data paths, calling flow and stack, and so on, in your mind, with very high throughput "discussions" happening entirely in your brain. Your brain is high bandwidth, low latency. Effortlessly and instantly…

At the same time, putting your ideas to words forces you to make them concrete instead of nebulous brain waves. I find that the chat interface gets rid of the downsides of pair programming (that the other person is a human being with their own agency*) while maintaining the “intelligent” pair programmer aspect.

Especially with the new r1 thinking output, I find it useful to iterate on the initial prompt as a way to make my ideas more concrete as much as iterating through the chat interface which is more hit and miss due to context length limits.

* I don’t mean that in a negative way, but in a “I can’t expect another person to respond to me instantly at 10 words per second” way.

Re: Chat is a bad UI pattern for development tools

#222

Post by gnatolf »

shmoogy wrote: post #201
wiremine wrote: post #190

I'm going to take a contrarian view and say it's actually a good UI, but it's all about how you approach it. I just finished a small project where I used o3-mini and o3-mini-high to generate most of the code. I averaged around 200 lines of code an hour, including the business logic and unit tests. Total was around 2200 lines. So, not a big project, but not a throw away script. The code was perfectly fine for what we…

Have you tried cursor? I really like the selecting context -> cmd+l to make a chat with it - explain requirement, hit apply, validate the diff. Works amazingly well for a lot of what I've been working on the past month or two.

I haven't tried cursor yet, but how is this different from the copilot plugin in vscode? Sounds pretty similar.

Re: Chat is a bad UI pattern for development tools

#223

Post by smj-edison »

TeMPOraL wrote: post #188
SoftTalker wrote: post #110

Earlier quoted context omitted.

Yes, agree. Chatting with a computer has all the worst attributes of talking to a person, without any of the intuitive understanding, nonverbal cues, even tone of voice, that all add meaning when two human beings talk to each other.

That comment made sense 3 years ago. LLMs already solved "intuitive understanding", and the realtime multimodal variants (e.g. the thing behind "Advanced Voice" in ChatGPT app) handle tone of voice in both directions. As for nonverbal cues, I don't know yet - I got live video enabled in ChatGPT only few days ago and didn't have time to test it, but I would be surprised if it couldn't read the basics of body language…

This is one reason I love what Bret Victor has been doing with Dynamic Land[1]. He's really been doing in on trying to engage as many senses as possible, and make the whole system understandable. One of his big points is that the future in technology is helping us understand more, not defer our understanding to something else.

[1] https://dynamicland.org/

EDIT: love your analogy to dance!

Re: Chat is a bad UI pattern for development tools

#224

Post by throwup238 »

bongodongobob wrote: post #216
wiremine wrote: post #190

I'm going to take a contrarian view and say it's actually a good UI, but it's all about how you approach it. I just finished a small project where I used o3-mini and o3-mini-high to generate most of the code. I averaged around 200 lines of code an hour, including the business logic and unit tests. Total was around 2200 lines. So, not a big project, but not a throw away script. The code was perfectly fine for what we…

To add to that, I always add some kind of debug function wrapper so I can hand off the state of variables and program flow to the LLM when I need to debug something. Sometimes it's really hard to explain exactly what went wrong so being able to give it a chunk of the program state is more descriptive.

I do the same for my QT desktop app. I’ve got an “Inspector” singleton that allows me to select a component tree via click, similar to browser devtools. It takes a screenshot, dumps the QML source, and serializes the state of the components into the clipboard.

I paste that into Claude and it is surprisingly good at fixing bugs and making visual modifications.

Re: Chat is a bad UI pattern for development tools

#225

Post by [deleted] »

wiremine wrote: post #190

I'm going to take a contrarian view and say it's actually a good UI, but it's all about how you approach it. I just finished a small project where I used o3-mini and o3-mini-high to generate most of the code. I averaged around 200 lines of code an hour, including the business logic and unit tests. Total was around 2200 lines. So, not a big project, but not a throw away script. The code was perfectly fine for what we…

[deleted]

Re: Chat is a bad UI pattern for development tools

#226

Post by jerjerjer »

layer8 wrote: post #121
jayd16 wrote: post #88

Earlier quoted context omitted.

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?

What makes email more useful in general is that each email is a separate object that you can organize in any way you want, i.e. move, copy, rename, sort into folders, attach as a file to any calendar entry, todo item, etc., or indeed to any other email. You can forward them to any other recipient, you can add and remove any recipient to and from the conversation at any time. It is conceptually powerful and flexible i…

Accessing Thunderbird via JDBC from my favorite SQL client was so convenient. No messaging app search is even remotely close to what a simple SELECT/WHERE can do. Old Skype versions also stored chat info in an SQLite db. I wish I'd still have SQL access to my messages.

Re: Chat is a bad UI pattern for development tools

#228

Post by jerjerjer »

65 wrote: post #127
dapperdrake wrote: post #76

Earlier quoted context omitted.

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

Oh, how nice it must be to complain about Slack. Try using Teams and you will never want to complain about Slack again.

Slack is way worse than Teams. I honestly rather dislike both and rather use email only, but will pick Teams over Slack any time.

Re: Chat is a bad UI pattern for development tools

#229

Post by sdesol »

wiremine wrote: post #190

I'm going to take a contrarian view and say it's actually a good UI, but it's all about how you approach it. I just finished a small project where I used o3-mini and o3-mini-high to generate most of the code. I averaged around 200 lines of code an hour, including the business logic and unit tests. Total was around 2200 lines. So, not a big project, but not a throw away script. The code was perfectly fine for what we…

> 1. I find a "pair programming" mentality is key. I focus on the high-level code, and let the model focus on the lower level code. I code review all the code, and provide feedback. Blindly accepting the code is a terrible approach.

This is what I've found to be key. If I start a new feature, I will work with the LLM to do the following:

- Create problem and solution statement

- Create requirements and user stories

- Create architecture

- Create skeleton code. This is critical since it lets me understand what it wants to do.

- Generate a summary of the skeleton code

Once I have done the above, I will have the LLM generate a reusable prompt that I can use to start LLM conversations with. Below is an example of how I turn everything into a reusable prompt.

https://beta.gitsense.com/?chat=b96ce9e0-da19-45e8-bfec-a3ec...

As I make changes like add new files, I will need to generate a new prompt but it is worth the effort. And you can see it in action here.

https://beta.gitsense.com/?chat=b8c4b221-55e5-4ed6-860e-12f0...

The first message is the reusable prompt message. With the first message in place, I can describe the problem or requirements and ask the LLM what files it will need to better understand how to implement things.

What I am currently doing highlights how I think LLM is a game changer. VCs are going for moonshots instead of home runs. The ability to gather requirements and talk through a solution before even coding is how I think LLMs will revolutionize things. It is great that it can produce usable code, but what I've found it to be invaluable is it helps you organize your thoughts.

In the last link, I am having a conversation with both DeepSeek v3 and Sonnet 3.5 and the LLMs legitimately saved me hours in work, without even writing a single line of code. In the past, I would have just implemented the feature and been done with it, and then I would have to fix something if I didn't think of an edge case. With LLMs, it literally takes minutes to develop a plan that is extremely well documented that can be shared with others.

This ability to generate design documents is how I think LLMs will ultimately be used. The bonus is producing code, but the reality is that documentation (which can be tedious and frustrating) is a requirement for software development. In my opinion, this is where LLMs will forever change things.

Re: Chat is a bad UI pattern for development tools

#230

Post by frocodillo »

ryandrake wrote: post #210
wiremine wrote: post #190

I'm going to take a contrarian view and say it's actually a good UI, but it's all about how you approach it. I just finished a small project where I used o3-mini and o3-mini-high to generate most of the code. I averaged around 200 lines of code an hour, including the business logic and unit tests. Total was around 2200 lines. So, not a big project, but not a throw away script. The code was perfectly fine for what we…

I guess the things I don't like about Chat are the same things I don't like about pair (or team) programming. I've always thought of programming as a solitary activity. You visualize the data structures, algorithms, data paths, calling flow and stack, and so on, in your mind, with very high throughput "discussions" happening entirely in your brain. Your brain is high bandwidth, low latency. Effortlessly and instantly…

I would argue that is a feature of pair programming, not a bug. By forcing you to use the slower I/O parts of your brain (and that of your partner) the process becomes more deliberate, allowing you to catch edge cases, bad design patterns, and would-be bugs before even putting pen to paper so to speak. Not to mention that it immediately reduces the bus factor by having two people with a good understanding of the code.

I’m not saying pair programming is a silver bullet, and I tend to agree that working on your own can be vastly more efficient. I do however think that it’s a very useful tool for critical functionality and hard problems and shouldn’t be dismissed.

Post reply on HN