Nobody really knows how to product-ize any of these LLM interfaces beyond just chat.
They don't want a traditional UI with buttons and forms and labels because they want the interface to be "chat". The problem is that "chat" is tedious. And the turn-based, linear nature of the chat interaction model makes it even more tedious and unproductive.
> The moment someone figures out a new modality for LLMs is when we’ll see the next hockey stick.
Honestly, that fills me with fear. LLMs exist to make money to their companies, and said companies are not gonna turn around and say, "you know what, go are going to make an android for each elderly person, that can not only help them with their medications, but that can actually make their medications, tailored to their biologies." Instead, they are going to go for the low-handing fruit of "you know Bob, the guy who makes jokes in meetings but who is grumpy about delivery timelines? Well, we are going to make an android to replace Bob. MetalBob will make even better jokes. The blue model will be able to explain in excruciating level of detail why timelines aren't reasonable. The red model will walk through the cubicles with a whip to ensure everybody keeps working all the time, and nobody goes to pee."
The great confusion for Anthropic and OAI is how to break out from pure chat without signalling you in fact intend to eat all of your customer's business too.
One thing I would like is a tree-like chat structure like reddit / HN. Many times I abandon the direction things have gone but would like to resume at some ancestor or sibling response.
I solved this with task management and got work trees.
The downside of course is branching in got, but I usually don’t go of course more then a handful of tasks.
I had to engineer my own ticket management to keep opus on target. It’s been great for managing work, history, audit trails and commits are tagged with the task id.
I implemented subtasks to deal with the way Claude likes to stage its own objectives.
Then I made enforcement logic in the task manager so tasks can’t be closed out until reviewers have consensus on the same sha.
The adhd that is Anthropic demanded I build it and now I’m knocking out issues faster than Batman.
I'm not affiliated, and did not actually try it, but your comment reminded me of the juggler coding agent, discussed here: <a href="https://news.ycombinator.com/item?id=48883305">https://news.ycombinator.com/item?id=48883305
>Each conversation is a Yjs CRDT tree. It can branch into sub-threads (recursively), and you can drill down, backtrack, edit, undo/redo, and inspect everything: tool calls, approvals, and the raw context JSON going to the model, etc.
Gemini has something kind of like this. In a chat, click on the "..." icon next to one of Gemini's responses and select "Branch in new chat".
It creates a new chat which has the conversation up to that point and a link to the conversation you branched it from.
The UI isn't tree-like, though. It's more like Git where each branch name is just mixed in with the rest of the soup of references.
I don't think it's that anyone wants the interface to be chat. I think it's that the underlying technology is inherently words in and words out. It's similar to how devices with capacitive screens are most naturally going to support tapping, dragging, and pinching.
It's funny to me that instead of moving existing tech to a word in word out paradigm, people are dropping millions getting the chat to work with the existing paradigm.
Probably inevitable, but seems like a lot of disruption could happen there.
I mean, that's the first adoption phase where you don't start from scratch but keep using the old tech with the bolted on LLMs. It would take some time for devs to build the primitives around the new tech.
My personal hot take is that the product people (engineers too probably) at these companies are just straight up lazy. Yes, a new UI paradigm is hard, but it's been painfully obvious that chat just absolutely sucks. It's also obvious that some DSL-ish thing is possible, something that just does token juggling and the end-user sees some UI behavior.
I know this all sounds abstract. I've been mulling over it for the past year and it's very hard; and LLMs are super janky and inconsistent so it's 100% not trivial. So in some sense I understand why a lazy bottom-of-the-barrel "chat interface" has become the de facto standard.
For the abstract "you can do anything" product, you want an open ended interface, but if I'm, eg, renting a car, is a free form text box really the way to go? The rental company knows exactly what information they need from me before they'll rent me a car, so a free form text box so the computer can ask me questions one by one vs a traditional form, seems suboptimal.
> How in the world would I interface with claude other than sending it messages?
The protocol will of course be `text -> text` for the typical LLM (though some new models are structured, as we saw yesterday with Jev). Even so, the user doesn't need to be exposed to the protocol (almost ever). It's not like I'm crafting a POST request to send this form.
There's a lot of room for window dressing, and I look at AI like I look at the touch-screen. It was a fun technical toy until people (mostly Apple) poured in a lot of serious effort into "ok, how do we make this pleasant to use, intuitive, and genuinely useful?"
Before OpenAI dropped ChatGPT, nobody knew chat would be such a hit. Several labs had versions of these things, Google engineers were getting finessed by a rudimentary model just like in the movie Ex Machina that came out 10 years prior which was satirizing Google
But I don't agree that they aren't product-ized. There are many applications doing calls to LLMs behind the scenes and are hits, leveraging structured data very heavily and not having conversations with users at all. I would say that there is a predictable scope creep from executives to surface a conversational aspect though. We need to bring representation to that so we can point to some other best practice to push back
API calls are expensive and slow, so I’ve shied away from integrating them into my personal projects. And of course there’s always the risk of hallucination.
IMO no one knows what LLMs are capable of yet and the goal post keeping moving every few months that building any specific UIs right now risks rendering them obsolete or too slow.
e.g. We went from somewhat smarter code autocomplete, to asking chatgpt copy paste, to cli agent running inside your project, managing session, to GUI to manage that, to projects where you talk to a "Chief of Staff" agent that manages other sessions, to who knows what's next.
I think the right interfaces for LLMs right now need to be very simple and easy to change/evolve. And chat still seems to be the best default solution.
I wouldn't call copy & paste code from a webui of chatgpt either traditional or boring. I'd call it tedious, error prone and guaranteed to get poor results. There is much better tooling and harnesses to leverage now.
Technology folks don’t really understand people and what they need.
This always happens. This is why woz needed Steve.
Steve Jobs is sorely missed tbh. For all the shit he got - he was a true visionary. He lived at the intersection of technology and the humanities… he kept preaching this. And now we are seeing why.
We’re working on this problem at my company. All of our competitors have churned out a bunch of generic chat based agents (basic harness with a few tools connected and different system prompts) to do basic stuff you’d used to do from a wizard or even just a couple of buttons in a form. We’re steering away from this by building full ‘surface’ agents with A2UI and an initial surface message. The users just see a normal looking web application but under the hood it’s all driven by a harness. UI updates are effectively just new events received by the client. Events are either generated by an LLM directly, or deterministically - it’s up to the dev.
petcat · · focus · HN ↗
They don't want a traditional UI with buttons and forms and labels because they want the interface to be "chat". The problem is that "chat" is tedious. And the turn-based, linear nature of the chat interaction model makes it even more tedious and unproductive.
threwaway555999 · · focus · HN ↗
[dead]
jeromechoo · · focus · HN ↗
The moment someone figures out a new modality for LLMs is when we’ll see the next hockey stick.
dsign · · focus · HN ↗
Honestly, that fills me with fear. LLMs exist to make money to their companies, and said companies are not gonna turn around and say, "you know what, go are going to make an android for each elderly person, that can not only help them with their medications, but that can actually make their medications, tailored to their biologies." Instead, they are going to go for the low-handing fruit of "you know Bob, the guy who makes jokes in meetings but who is grumpy about delivery timelines? Well, we are going to make an android to replace Bob. MetalBob will make even better jokes. The blue model will be able to explain in excruciating level of detail why timelines aren't reasonable. The red model will walk through the cubicles with a whip to ensure everybody keeps working all the time, and nobody goes to pee."
dpkirchner · · focus · HN ↗
varispeed · · focus · HN ↗
petcat · · focus · HN ↗
fidotron · · focus · HN ↗
clumsysmurf · · focus · HN ↗
BikiniPrince · · focus · HN ↗
The downside of course is branching in got, but I usually don’t go of course more then a handful of tasks.
I had to engineer my own ticket management to keep opus on target. It’s been great for managing work, history, audit trails and commits are tagged with the task id.
I implemented subtasks to deal with the way Claude likes to stage its own objectives.
Then I made enforcement logic in the task manager so tasks can’t be closed out until reviewers have consensus on the same sha.
The adhd that is Anthropic demanded I build it and now I’m knocking out issues faster than Batman.
drivebyhooting · · focus · HN ↗
Often times I just sort of wish to undo.
whythismatters · · focus · HN ↗
>Each conversation is a Yjs CRDT tree. It can branch into sub-threads (recursively), and you can drill down, backtrack, edit, undo/redo, and inspect everything: tool calls, approvals, and the raw context JSON going to the model, etc.
jobigoud · · focus · HN ↗
adrianmonk · · focus · HN ↗
It creates a new chat which has the conversation up to that point and a link to the conversation you branched it from.
The UI isn't tree-like, though. It's more like Git where each branch name is just mixed in with the rest of the soup of references.
AshleyGrant · · focus · HN ↗
jonathanberger · · focus · HN ↗
sroerick · · focus · HN ↗
Probably inevitable, but seems like a lot of disruption could happen there.
nonethewiser · · focus · HN ↗
gessha · · focus · HN ↗
dvt · · focus · HN ↗
I know this all sounds abstract. I've been mulling over it for the past year and it's very hard; and LLMs are super janky and inconsistent so it's 100% not trivial. So in some sense I understand why a lazy bottom-of-the-barrel "chat interface" has become the de facto standard.
nonethewiser · · focus · HN ↗
fragmede · · focus · HN ↗
nonethewiser · · focus · HN ↗
dvt · · focus · HN ↗
The protocol will of course be `text -> text` for the typical LLM (though some new models are structured, as we saw yesterday with Jev). Even so, the user doesn't need to be exposed to the protocol (almost ever). It's not like I'm crafting a POST request to send this form.
There's a lot of room for window dressing, and I look at AI like I look at the touch-screen. It was a fun technical toy until people (mostly Apple) poured in a lot of serious effort into "ok, how do we make this pleasant to use, intuitive, and genuinely useful?"
nonethewiser · · focus · HN ↗
Dictation? Neuralink thought-to-text?
ieie · · focus · HN ↗
[dead]
gitaarik · · focus · HN ↗
yieldcrv · · focus · HN ↗
But I don't agree that they aren't product-ized. There are many applications doing calls to LLMs behind the scenes and are hits, leveraging structured data very heavily and not having conversations with users at all. I would say that there is a predictable scope creep from executives to surface a conversational aspect though. We need to bring representation to that so we can point to some other best practice to push back
drivebyhooting · · focus · HN ↗
API calls are expensive and slow, so I’ve shied away from integrating them into my personal projects. And of course there’s always the risk of hallucination.
disgruntledphd2 · · focus · HN ↗
Yes, they are expensive, but flexibility has a lot of value.
yieldcrv · · focus · HN ↗
emadabdulrahim · · focus · HN ↗
e.g. We went from somewhat smarter code autocomplete, to asking chatgpt copy paste, to cli agent running inside your project, managing session, to GUI to manage that, to projects where you talk to a "Chief of Staff" agent that manages other sessions, to who knows what's next.
I think the right interfaces for LLMs right now need to be very simple and easy to change/evolve. And chat still seems to be the best default solution.
doublerabbit · · focus · HN ↗
Traditional and boring works for me.
cruffle_duffle · · focus · HN ↗
I wouldn't call copy & paste code from a webui of chatgpt either traditional or boring. I'd call it tedious, error prone and guaranteed to get poor results. There is much better tooling and harnesses to leverage now.
eieiei1 · · focus · HN ↗
Technology folks don’t really understand people and what they need.
This always happens. This is why woz needed Steve.
Steve Jobs is sorely missed tbh. For all the shit he got - he was a true visionary. He lived at the intersection of technology and the humanities… he kept preaching this. And now we are seeing why.
frnz · · focus · HN ↗
drivebyhooting · · focus · HN ↗
jamiegregz · · focus · HN ↗
paulhebert · · focus · HN ↗
It sounds painful to debug
tencentshill · · focus · HN ↗