"You don’t program by chatting. You program by writing documents.", or long chat prompts as they are also called.
Chat is a bad UI pattern for development tools
281–290 of 432 posts
Re: Chat is a bad UI pattern for development tools
#282I'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…
Ok, but what is a good pattern to leverage AI tools for coding (assuming that they have some value there, which I think most people would agree with now)? I could see two distinct approaches: - "App builders" that use some combination of drag&drop UI builders, and design docs for architecture, workflows,... and let the UI guess what needs to be built "under the hood" (a little bit in the spirit of where UML class dia…
I've yet to see any AI/LLM produce code that withstands even basic scrutiny.
Re: Chat is a bad UI pattern for development tools
#283Natural 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.
Natural language can be precise, but only in context . The struggle is to provide a context that disambiguates the way you want it to. LLMs solve this problem by avoiding it entirely: they stay ambiguous, and just give you the most familiar context, letting you change direction with more prompts. It's a cool approach, but it's often not worth the extra steps, and sometimes your context window can't fit enough steps a…
That’s what programming languages are: You define a context, then you see that you can shorten the notation to symbol character: Like “The symbol a will refer to the value of type string and content ‘abcd’ and cannot refer to anything else for its life time” get you:
const a = “abcd”
Re: Chat is a bad UI pattern for development tools
#284Earlier quoted context omitted.
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.
Similar flow but much better user experience. At least that is how I’d describe it.
Re: Chat is a bad UI pattern for development tools
#285Earlier quoted context omitted.
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…
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 implements things, which may be based on the output of one of the above
That last bucket of time is generally greatly hampered by having someone else there and needing to interact with them. Being able to separate them (having people there for the first one or two, but not the third) is, for me, optimal.
Re: Chat is a bad UI pattern for development tools
#286Earlier quoted context omitted.
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…
You can do that without pair programming, though. Both through actual discussions and through rubber ducking.
Re: Chat is a bad UI pattern for development tools
#287I'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 focus on the high-level code, and let the model focus on the lower level code. Tbh the reason I don't use LLM assistants is because they suck at the "low level". They are okay at mid level and better at high level. I find it's actual coding very mediocre and fraught with errors. I've yet to see any model understand nuance or detail. This is especially apparent in image models. Sure, it can do hands but they still…
> Tbh the reason I don't use LLM assistants is because they suck at the "low level". They are okay at mid level and better at high level. I find it's actual coding very mediocre and fraught with errors.
That's interesting. I found assistants like Copilot fairly good at low level code, assuming you direct it well.
Re: Chat is a bad UI pattern for development tools
#288Earlier quoted context omitted.
For me the o models consistently make more mistakes for me than Claude 3.5 Sonnet.
Same for me. I wonder if Claude is better at some languages than others, and o models are better at those weaker languages. There are some devs I know who insist Claude is garbage for coding and o3-* or o4-* are tier 1.
o4 doesn't exist (in public at least) yet.
Re: Chat is a bad UI pattern for development tools
#289Earlier quoted context omitted.
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 m…
> At the same time, putting your ideas to words forces you to make them concrete instead of nebulous brain waves. I mean, isn’t typing your code also forcing you to make your ideas concrete
Doing it in your native language can add an extra dimension to it, though. In a way, I would consider it like double checking your work on something like a math problem by solving it a different way. By having to express the problem and solution in clear language, it can really help you make sure your solution is a good one, and considers all the angles.
Re: Chat is a bad UI pattern for development tools
#290I'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…
Interesting to see the narrative on here slowly change from "LLM's will forever be useless for programming" to "I'm using it every day" over the course of the past year or so. I'm now bracing for the "oh sht, we're all out of a job next year" narrative.
I think a lot of people have always thought of it as a tool that can help.
I don't want an LLM to generate "the answer" for me in a lot of places, but I do think it's amazing for helping me gather information (and cite where that information came from) and pointers in directions to look. A search engine that generates a concrete answer via LLM is (mostly) useless to me. One that gives me an answer and then links to the facts it used to generate that answer is _very_ useful.
It's the same way with programming. It's great helping you find what you need. But it needs to be in a way that you can verify it's right; or take it's answer and adjust it to what you actually need (based on the context it provides).