Live data from Hacker News

Chat is a bad UI pattern for development tools

danieldelaney.net

391–400 of 432 posts

Re: Chat is a bad UI pattern for development tools

#393

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…

This going to sound out of left field, but I would venture to guess you have very high spatial reasoning skills. I operate much this same way and only recently connected these dots that that skill might be what my brain leans on so heavily while programming and debugging.

Pair programming is endlessly frustrating beyond just rubber duckying because I’m having to exit my mental model, communicate it to someone else, and then translate and relate their inputs back into my mental model which is not exactly rooted in language in my head.

Re: Chat is a bad UI pattern for development tools

#394
post #389
post #384

Earlier quoted context omitted.

Programming only needs to make things as explicit as necessary based on the developer's desires and the system's assumptions. Where more detail is necessary, the programmer can add more code. For example, there's no need to tell a browser explicit rules for how users should be able to interact with an input field, since that's the browser's default behavior; you only need to specify different behavior when you want i…

> complex applications can be fully specified in English Of course. We established that at the beginning. The entire discussion is about exactly that. It was confirmed again in the previous comment. However, that is not natural. I expect most native English speakers would be entirely incapable of fully specifying a complex application or anything else of similar complexity. That is not natural use. While the words, b…

> I expect most native English speakers would be entirely incapable of fully specifying a complex application or anything else of similar complexity.

Your original postulation was that it simply wasn't possible, implying nobody could do it. The fact that most native English speakers wouldn't be able to do it doesn't mean nobody can do it.

I agree that most native English speakers wouldn't be able to write a reasonably complete spec in any type of language, not just because they lack the language skill, but because they simply wouldn't have the imagination and knowledge of what to create to begin with, let alone how to express it.

Re: Chat is a bad UI pattern for development tools

#395

Earlier quoted context omitted.

Nah, a Chat is terrible for development. In my tears of working, i have only had the chance to start a new codebase 3-4 times. 90% of the time is spent modifying large existing systems, constantly changing them. The chat interface is terrible for this. It would be much better if it was more integrated with the codebase and editor

>In my tears of working Sometimes typos are eerily appropriate ;) (I almost typed "errily"...)

I’ll leave it!

Re: Chat is a bad UI pattern for development tools

#396
Not just for development tools. It's a bad UI for a lot of use cases. It's merely what made sense for UX challenged researchers when they had to come up with a UI for their LLMs in a hurry. Discord was there and reasonably easy to integrate. Many tools started out as just that. Fast forward and most tools are kind of standalone versions of the same thing.

The challenge is that I haven't seen anything better really.

Lately the innovation comes mainly from deeper integration with tools. Standalone AI editors are mainly popular with people who use relatively simple editors (like VS Code). VS Code has a few party tricks but for me swapping out Intellij for something else on a typical Kotlin project is a complete non starter. Not going to happen. I'd gain AI, but I'd loose everything else that I use all the time. That would be a real productivity killer. I want to keep all the smart tooling I already have and have used for years.

There are a few extensions for intellij but they are pretty much all variations of a sidebar with a chat and autocomplete. Autocomplete competes with normal autocomplete, which I use all the time. And the clippy style "it looks like you are writing a letter" style completions just aren't that useful too me at all. They are just noise and break my flow. And they drown out the completions I use and need all the time. And sidebars just take up space and copying code from there back to your editor is a bit awkward as UX

Lately I've been using chat gpt. It started out pretty dumb but these days I can option+shift+1 in a chat and have it look over my shoulder at my current editor. "how do I do that?" translates into a full context with my current editing window, cursor & selected text, etc. all in the context. Before I was copy pasting everything and the kitchen sync to chat gpt, now it just tells me what I need to do. The next step up from this is that it starts driving the tools itself. They already have a beta for this. This deeper integration is what is needed.

A big challenge is that most of these tools are driven to minimize cost and context size. Tokens cost money. So chat GPT only looks at my active editor and not at the 15 other files I have open. It could. But it doesn't. It's also unaware of my project structure, or the fact that most of my projects are kotlin multiplatform and can't use JVM dependencies. So, in that sense, every chat still is a bit ground hog day. It's promise to "remember" stuff when you ask it too is super flaky. It forgets most things it's supposed to remember pretty quickly.

These are solvable problems of course. But it's useful to me for debugging, analyzing, completing functions, etc.

Re: Chat is a bad UI pattern for development tools

#397
post #368

Earlier quoted context omitted.

LoC per hour seems to me like a terrible metric.

Why? Since you are vetting the code it generates, the rate at which you end up with code you accept seems like a good measure of productivity.

1000 lines of perfectly inoffensive and hard to argue against code that you don't need because it's not the right solution is negative velocity. Granted, I don't think that's much worse with LLMs but I do think it's going to be a growing problem caused by the cost of creating useless taxonomies and abstractions going down.

That is to say: I think LLMs are going to make a problem we already had (much) worse.

Re: Chat is a bad UI pattern for development tools

#398
post #277

Earlier quoted context omitted.

That's such a mechanical way of describing pair programming. I'm guessing you don't do it often (understandable if its not working for you). For me pair programming accelerates development to much more than 2x. Over time the two of you figure out how to use each other's strengths, and as both of you immerse yourself in the same context you begin to understand what's needed without speaking every bit of syntax between…

I think it depends heavily on the people. I've done pair programming at a previous job and I hated it. It wound up being a lot slower overall. For me, there's - Time when I want to discuss the approach and/or code to something (someone being there is a requirement) - Time when I want to rubber duck, and put things to words (someone being there doesn't hurt, but it doesn't help) - Time when I want to write code that i…

You could try setting some quiet hours. Or headphones.

Maybe collaborate the first hour each morning, then the first hour after lunch.

Re: Chat is a bad UI pattern for development tools

#399

Earlier quoted context omitted.

> For any problem there are infinite number of wrong solutions, but only a handful of ones that yield success, why waste time trying all the wrong ones? Devil's advocate: because unless you're working in heavily dysfunctional organization, or are doing a live coding interview, you're not playing "guess the password" with your management. Most of the time, they have even less of a clue about how the right solution loo…

It's just incredibly inefficient if there's any other alternative. Doing 4 sprints over 2 months to make a prototype in order to save 3 60 minute meetings over a week where you do a few requirements analysis/proposal review cycles.

Yeah, that would be stupid. I was thinking one order of magnitude less in terms of effort. If you can make a prototype in a day, it might deliver way more value than 3x 60 minute meetings. If you can make it in a week, where the proper implementation would take more than a month, that could still be a huge win.

I see this not as opposed, but as part of requirements analysis/review - working in the abstract, with imagination and prose and diagrams, it's too easy to make invalid assumptions without anyone realizing it.

Re: Chat is a bad UI pattern for development tools

#400

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]
Post reply on HN