Live data from Hacker News

Chat is a bad UI pattern for development tools

danieldelaney.net

51–60 of 432 posts

Re: Chat is a bad UI pattern for development tools

#51

Earlier quoted context omitted.

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…

idk if you think all those jira tickets and meetings are precise enough (IMO sometimes the opposite) By the way, remind me why you need design meetings in that ideal world?:) > Real projects don't require an infinitely detailed specification either, you usually stop where it no longer meaningfully moves you towards the goal. The point was that specification is not detailed enough in practice. Precise enough specifica…

That's a fair point, I'd love to see Copilot come to a conclusion that they can't resolve a particular conundrum and communicates with other people so everyone makes a decision together.

Re: Chat is a bad UI pattern for development tools

#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 terrible way to build things. It can be a great way to communicate them, but being a separate entity, it is not necessarily good at making any artifacts.

Re: Chat is a bad UI pattern for development tools

#53
You may have challenges using chat for development (Specifically, I mean text prompting, not necessary using a langchain session with a LLM, although that is my most common mode), but I do not. I have found chat to be, by far, the most productive interface with LLMs for coding.

Everything else, is just putting layers, that are not nearly as capable at an LLM, between me and the raw power of the LLM.

The core realization I made to truly unlock LLM code assistance as a 10x + productivity gain, is that I am not writing code anymore, I am writing requirements. It means being less an engineer, and more a manager, or perhaps an architect. It's not your job to write tax code anymore, it's your job to describe what the tax code needs to accomplish and how it's success can be defined and validated.

Also, it's never even close to true that nobody uses LLMs for production software, here's a write-up by Google talking about using LLMs to drastically accelerate the migration of complex enterprise production systems: https://arxiv.org/pdf/2501.06972

Re: Chat is a bad UI pattern for development tools

#54

Earlier quoted context omitted.

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…

We are kind of actually there already. With a 200k token window like Claude has you can already dump a lot of design docs / transcripts / etc. at it.

And Gemini has 2m token window. Which is about 10 minutes of video for example.

Re: Chat is a bad UI pattern for development tools

#55
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.

> and that’s just programming with extra steps.

If you know how to program, then I agree and part of why I don't see the point. If you don't know how to program, than the prompt isn't much different than providing the specs/requirements to a programmer.

Re: Chat is a bad UI pattern for development tools

#56
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.

Yes, let's devise a more precise way to give AI instructions. Let's call it pAIthon. This will allow powers that be, like Zuckerberg to save face and claim that AI has replaced mid-level developers and enable developers to rebrand themselves as pAIthon programmers. Joking aside, this is likely where we will end up, just with a slightly higher programming interface, making developers more productive.

man, pAIthon was just sitting right there for the taking

Re: Chat is a bad UI pattern for development tools

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

As a written form of "stream of consciousness", it seems to have a lot of value to me. It's noisy, inefficient & meandering -- all the things those polished artifacts are not -- but it's also where you can explore new avenues without worrying about succinctness or completeness. It's like the first draft of a manuscript.

Re: Chat is a bad UI pattern for development tools

#58
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 to generate an image, which is a ridiculous amount of friction.

Re: Chat is a bad UI pattern for development tools

#59
post #7

There is a black box effect between when you press enter and it starts updating code in multiple places. Like wtf just happened, I have to find these changes, which code broke dependencies. It should be more step wise visually

The next couple of years will be dedicated to working that out.

rather months than years

Re: Chat is a bad UI pattern for development tools

#60
This puts me in mind of something I read years ago and am having trouble finding that basically had the same premise but went about proving it a different way. The idea was that natural language programming is always going to mean dealing with a certain background level of ambiguity, and the article cited contracts and contract law as proof. Basically, a contract is an agreement to define a system with a series of states and a response for each state defined, and the vast and difficult-to-navigate body of contract law is proof that even when purposefully being as unambiguous as possible with two entities that fully grasp the intricacies of the language being used there is so much ambiguity that there has to be an entire separate group of people (the civil court system) whose only job it is to mediate and interpret that ambiguity. You might point to bad-faith actors but a contract where every possible state and the appropriate response are defined without ambiguity would be proof against both misinterpretations and bad faith actors.
Post reply on HN