6 ms·
My take on the issue is that for most use cases where AI is pushed to the general public, a conversational chatbot is not the right tool, and the experience is
by zeumo 4mo ago
My take on the issue is that for most use cases where AI is pushed to the general public, a conversational chatbot is not the right tool, and the experience is bound to be frustrating.
Remember when Copilot was basically a super-smart version of Intellisense? It was awesome. Sure, there was a lot of pushback and concern, mainly about licensing and ethical issues, none of which are solved with the current chatbot model. But now I also have to come up with a prompt and type it out. How is that an improvement over having the LLM use surrounding code as context and figure out how to fill in the blanks? A well integrated tool beats a bolted-on chatbot any time for me. Another example would be translation: in Firefox, I can right click any text or click the 文/A button, and I can translate the text or the whole page from basically any language to any other. The frontier LLM's solution is to prompt their chatbot to do the task, which is a downgrade. Sure, I could also ask Claude to write a poem, but when I need to translate a webpage, it doesn't help much.
I get why all major AI companies push towards this solution, because they can build a single tool and sell it to everyone, and that training their models is very expensive and they can't afford to alienate any part of the potential market. But ultimately they're building Swiss army knives, which are able to do basically anything, but will never be able to allow users to tighten a screw better than a well designed screwdriver. Sure, I won't ever be able to clip my nails with a screwdriver, but if my business is tightening screws, I won't tolerate using a Swiss army knife for long.
Please build actual tools. Not textboxes for me to try and configure a non-deterministic tool. Then frustration will go down.
- berkes 4mo agoMany of the AI companies do train and release models dedicated at one task. I mainly use mistral, so that's my reference, but I know anthropic et.al have similar models around. Codestral is rediculously bad at conversation, but it's -for me- the best model around for "magic autocomplete". It's also pretty good at "one shot" prompt+context generations, e.g. to make "git commit log entries". Document.AI is unusable bad in a conversation style, but really good when wired up to a simple pipeline as "replacement" for OCR or for indexing "meaning" from documents (I'm experimenting with it for my administration, to get invoices, contracts etc into a search tool). I presume there are many others like it. So, what you describe, is already in place. I guess mostly the "interfaces" are missing for you, or hard to discover maybe? For example, a dedicated model with tool I'd like, is some "shell" -a zsh or bash fork or some wrapper- backed with a dedicated model, trained for "commandline interaction". Where instead of "git commit --fixup=[opens another terminal to git log the relevant entry]", we can "git fixup the commit that fixes full names" or "ffmpeg convert some.mov to mp4 without sound but keep quality and ratio etc". Or "run any valid tar command - you have ten seconds". I'm now using the way too heavy "devstral" for these tasks. I don't need it reasoning, conversing, apologising. I need it translating my requests into commands, then showing these to me so I can deny/allow/whitelist/blacklist them and then run them - to interpret *and show me* errors and suggest improvements or fixes etc. Same for - indeed - translation, writing draft mails, reading documents, etc: I don't need to converse with it. I want to have buttons, shortcuts, "tab complete" etc that's "smart" enough to understand what I need and want, preferably tunable by editing "system prompts" or such and then get out of my way. I think the company that figures this out for my IDE will win the competition-race of "AI coding tools". Just today, I found, zed presented a button "git conflict found, resolve with AI" . When pressed, it did start a conversational thread, but its a step in the right direction.
- zeumo 4mo ago> So, what you describe, is already in place. I guess mostly the "interfaces" are missing for you, or hard to discover maybe? That's definitely an issue. Mind you, the general population is not a developer. I'm a mechanical engineer. I can code, use an IDE, but I hate having to figure out tooling the way you describe, and it's not a skill I'm interested in developing. What you are describing sounds to me like someone using vim and a terminal trying to convince me to stop using CLion, because they can make anything CLion can do work with their setup. Sure, I believe it, but for my part I'm going to wait for the features to be well integrated into finely designed software, I'm not going to duct-tape this stuff together to get a workflow that still involves writing out and tweaking prompts. It also sounds to me that the AI/LLM vendors are still in a phase where they are trying to figure what the actual workflow should look like so they let their power users do that work for them. I'm not going to do that either.
- skydhash 4mo agoI strongly believe that if you’re not in the business of predicting text or transforming it, the values of AI tools goes way down. Most people workflows are very routinely and with a constrained set of outputs. That’s why we build software and scripts for those. And for the rest, we need actual human judgment.
- marcuscog 4mo agoI made a tool that’s non-conversational. But I’ll be honest - it’s hard to sell because people default to thinking in conversational terms. My customer set is limited to folks like the author who have genuinely faced an issue. For most, compromising with conversations is fine (at least now)
- ryandrake 4mo agoYea, it really depends on your mode of thinking. Might be why a lot of people struggle with LLM coding while others think it’s great and are productive. When I’m writing code I think in terms of data structures and algorithms. I have the idea fully formed in my head and coding becomes a mere typing exercise. If I have to use a chatbot instead, now I have to do the awkward exercise of translating that code into English text that the chatbot can understand, just so the LLM can convert it back to code. And always a lot is lost in that translation. What is useful are things that speed up data entry, autocorrect formatting, and linting things I forget and so on. Not some awkward thing that makes me round-trip to English as an extra step.
- dnnddidiej 4mo agoMaybe try vibe coding. Seruously. It is a different beast now and so much better than even when the term was coined by Andrej. I do a lot of work editor-free. Just an agent and PR review on web. Occasional peak with `code .` if needed. If. Try it at home first with a low stakes project. And learn it like a game. It will suck less as time goes on. Like skiing or 10 pin bowling.
- ryandrake 4mo agoI tried and just couldn’t accept it. I need to have the code a certain way, and if the prompt doesn’t do it exactly right, I eventually need to open up the editor and fix it. Prompting things like “now move function_foo’s parameter list to the next line” and “remove #include <stdio.h>” is a very expensive (token wise) way to edit text. When I’m writing code, the simplicity, beauty, structure, format, and artistry of the code is what is important to me, not the application.
- da_chicken 4mo agoVibe coding a low-stakes personal project is very different from vibe coding a hospital information system or a kernel patch. Learning you can get away with one doesn't mean you should translate that to the other.
- dnnddidiej 4mo agoIt is like tbe pottery parable. Try 100 times on a low stakes project for tacit experience. Get better at it. Then use in prod. In prod - obviously you will have more guardrails and you would probably review all code.
- zeumo 4mo agoGenuine question: what's the point of vibe-coding a personal, low-stake project? I do work on such projects, but the main goal for me is to learn, not the end result. If the end result is important, then there it's overwhelmingly likely that someone already implemented it better than I ever would, and I should just use that implementation. I have implemented a qoi codec or a gemini client, not because I needed to use either of those, but because I wanted to understand how image codecs or network protocols worked, from bytes to end result. In the end, I learned a bit more about how computers work, how they draw stuff on screen and communicate with each other. I don't believe I would have learned much by letting an LLM do the work for me. Nor do I believe that the LLM could have done a better job than all the existing implementations of those things.
- dse1982 4mo agoAmen. Chatbots are a band-aid on broken UX. <insert bandaid tank meme here> Trying to explain this for a while at the company I work at, but everybody is drunk on the kool-aid. But I get it: good UX takes deep thought and creativity. Tacking on a chatbot does not.
- thewebguyd 4mo ago> good UX takes deep thought and creativity. Tacking on a chatbot does not See: Microsoft Copilot in the Windows settings app. Instead of actually fixing the app and making things discoverable with good design (or at least, functional search), they just slapped the chatbot into the search box. I'm seeing this pattern more and more, and its frustrating. All UX just goes out the window because "well, we'll just make it so the user can ask a chatbot"
- Pay08 4mo ago> Remember when Copilot was basically a super-smart version of Intellisense? It was awesome. I have only used the Copilot completion for C#, but it was absolutely awful and a net negative not just compared to IntelliSense, but compared to the most basic autocomplete algorithm imaginable. I turned it off after a day.
- eddythompson80 4mo agowell you know it kept improving. It got pretty good, though everyone moved to full "agentic" changes over autocomplete.
- Pay08 4mo agoMaybe it shouldn't have been forced on me if it wasn't ready, then.
- eddythompson80 4mo agoI’m sorry you were victimized.