10 ms·

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-mi

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 needed. This is the third time I've done this, and each time I get faster and better at it. 1. I find a "pair programming" mentality is key. I focus on the high-level code, and let the model focus on the lower level code. I code review all the code, and provide feedback. Blindly accepting the code is a terrible approach. 2. Generating unit tests is critical. After I like the gist of some code, I ask for some smoke tests. Again, peer review the code and adjust as needed. 3. Be liberal with starting a new chat: the models can get easily confused with longer context windows. If you start to see things go sideways, start over. 4. Give it code examples. Don't prompt with English only. FWIW, o3-mini was the best model I've seen so far; Sonnet 3.5 New is a close second.

ikety 2y ago
do you use pair programming tools like aider?
shmoogy 2y ago
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.
- gnatolf 2y ago
  I haven't tried cursor yet, but how is this different from the copilot plugin in vscode? Sounds pretty similar.
  - cheema33 2y ago
    > copilot plugin in vscode Copilot, back when I used it, completely ignored context outside of the file I was working in. Copilot, as of a few weeks ago, the absolute dumbest assistant of all the various options available. With cursor, I can ask it to make a change to how the app generates a JWT without even knowing which file or folder the relevant code is in. For very large codebases, this is very very helpful.
  - cruffle_duffle 2y ago
    Similar flow but much better user experience. At least that is how I’d describe it.
  - RugnirViking 2y ago
    ya know what, after a couple times hearing this comment, I downloaded it literally yesterday. It does feel pretty different, at least the composer module and stuff. A bit improvement in ai tooling imo
ryandrake 2y ago
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 move things around and visualize them. Figure everything out. Finally, when it's correct, you send it to the slow output device (your fingers). The minute you have to discuss those things with someone else, your bandwidth decreases by orders of magnitude and now you have to put words to these things and describe them, and physically type them in or vocalize them. Then your counterpart has to input them through his eyes and ears, process that, and re-output his thoughts to you. Slow, slow, slow, and prone to error and specificity problems as you translate technical concepts to English and back. Chat as a UX interface is similarly slow and poorly specific. It has all the shortcomings of discussing your idea with a human and really no upside besides the dictionary-like recall.
- throwup238 2y ago
  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 make my ideas more concrete as much as iterating through the chat interface which is more hit and miss due to context length limits. * I don’t mean that in a negative way, but in a “I can’t expect another person to respond to me instantly at 10 words per second” way.
  - cortesoft 2y ago
    > 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
    - 2y ago
dataviz1000 2y ago
I agree with you. Yesterday, I asked o3-mini to "optimize" a block of code. It produced very clean, functional TypeScript. However, because the code is reducing stock option chains, I then asked o3-mini to "optimize for speed." In the JavaScript world, this is usually done with for loops, and it even considered aspects like array memory allocation. This shows that using the right qualifiers is important for getting the results you want. Today, I use both "optimize for developer experience" and "optimize for speed" when they are appropriate. Although declarative code is just an abstraction, moving from imperative jQuery to declarative React was a major change in my coding experience. My work went from telling the system how to do something to simply telling it what to do. Of course, in React—especially at first—I had to explain how to do things, but only once to create a component. After that, I could just tell the system what to do. Now, I can simply declare the desired outcome, the what. It helps to understand how things work, but that level of detail is becoming less necessary.
deleted 2y ago
[deleted]
bongodongobob 2y ago
To add to that, I always add some kind of debug function wrapper so I can hand off the state of variables and program flow to the LLM when I need to debug something. Sometimes it's really hard to explain exactly what went wrong so being able to give it a chunk of the program state is more descriptive.
- throwup238 2y ago
  I do the same for my QT desktop app. I’ve got an “Inspector” singleton that allows me to select a component tree via click, similar to browser devtools. It takes a screenshot, dumps the QML source, and serializes the state of the components into the clipboard. I paste that into Claude and it is surprisingly good at fixing bugs and making visual modifications.
  - acrophiliac 2y ago
    That sounds cool. I could use that. Care to share your Inspector code?
  - rubymamis 2y ago
    Sounds awesome. I would love to hear more about this. Any chance you can share this or at least more details?
jacob019 2y ago
Totally agree. Chat is a fantastic interface because it stays out of my way. For me it's much more than a coding assistant. I get live examples of how to use tools, and help with boilerplate, which is a time saver and improvement over legacy workflows, but the real benefit is all the spitballing I can do with it to refine ideas and logic and help getting up to speed on tooling way outside of my domain. I spent about 3.5 hours chatting with o1 about RL architecture to solve some business problems. Now I have a crystal clear plan and the confidence to move forward in an optimal way. I feel a little weird now, like I was just talking to myself for a few hours, but it totally helped me work through the planning. For actual code, I find myself being a bit less interactive with LLMs as time goes, sometimes it's easier to just write the logic the way I want rather than trying to explain how I want it but the ability to retrieve code samples for anything with ease is like a superpower. Not to mention all the cool stuff LLMs can do at runtime via API. Yeah, chat is great, and I'll stick with writing code in Vim and pasting as needed.
deleted 2y ago
[deleted]
sdesol 2y ago
> 1. I find a "pair programming" mentality is key. I focus on the high-level code, and let the model focus on the lower level code. I code review all the code, and provide feedback. Blindly accepting the code is a terrible approach. This is what I've found to be key. If I start a new feature, I will work with the LLM to do the following: - Create problem and solution statement - Create requirements and user stories - Create architecture - Create skeleton code. This is critical since it lets me understand what it wants to do. - Generate a summary of the skeleton code Once I have done the above, I will have the LLM generate a reusable prompt that I can use to start LLM conversations with. Below is an example of how I turn everything into a reusable prompt. https://beta.gitsense.com/?chat=b96ce9e0-da19-45e8-bfec-a3ecf408ee71 https://beta.gitsense.com/?chat=b96ce9e0-da19-45e8-bfec-a3ec... As I make changes like add new files, I will need to generate a new prompt but it is worth the effort. And you can see it in action here. https://beta.gitsense.com/?chat=b8c4b221-55e5-4ed6-860e-12f056b682ad https://beta.gitsense.com/?chat=b8c4b221-55e5-4ed6-860e-12f0... The first message is the reusable prompt message. With the first message in place, I can describe the problem or requirements and ask the LLM what files it will need to better understand how to implement things. What I am currently doing highlights how I think LLM is a game changer. VCs are going for moonshots instead of home runs. The ability to gather requirements and talk through a solution before even coding is how I think LLMs will revolutionize things. It is great that it can produce usable code, but what I've found it to be invaluable is it helps you organize your thoughts. In the last link, I am having a conversation with both DeepSeek v3 and Sonnet 3.5 and the LLMs legitimately saved me hours in work, without even writing a single line of code. In the past, I would have just implemented the feature and been done with it, and then I would have to fix something if I didn't think of an edge case. With LLMs, it literally takes minutes to develop a plan that is extremely well documented that can be shared with others. This ability to generate design documents is how I think LLMs will ultimately be used. The bonus is producing code, but the reality is that documentation (which can be tedious and frustrating) is a requirement for software development. In my opinion, this is where LLMs will forever change things.
javier2 2y ago
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
- pc86 2y ago
  Cursor does all of this, and agent chats let you describe a new feature or an existing bug and it will search the entire codebase and add relevant code to its context automatically. You can optionally attach files for the context - code files that you want to add to the context up front, documentation for third-party calls, whatever you want. As a side note, "No, you're wrong" is not a great way to have a conversation.
  - javier2 2y ago
    Yeah, that is right. I'll give Cursor a try, because I believe we can do much better than these hopeless chat windows!
    - pc86 2y ago
      I've tried every LLM+IDE combo that I've heard about and Cursor is by far the best.
- zahlman 2y ago
  >In my tears of working Sometimes typos are eerily appropriate ;) (I almost typed "errily"...)
  - javier2 2y ago
    I’ll leave it!
nonrandomstring 2y ago
> it's actually a good UI Came to vote good too. I mean, why do we all love a nice REPL? That's chat right? Chat with an interpreter.
rpastuszak 2y ago
I've changed my mind on that as well. I think that, generally, chat UIs are a lazy and not very user friendly. However, when coding I keep switching between two modes: 1. I need a smart autocomplete that can work backwards and mimic my coding patterns 2. I need a pair programming buddy (of sorts, this metaphor doesn't completely work, but I don't have a better one) Pair development, even a butchered version of the so called "strong style" (give the driver the highest level of abstraction they can use/understand) works quite well for me. But, the main reason this works is that it forces me to structure my thinking a little bit, allows me to iterate on the definition of the problem. Toss away the sketch with bigger parts of the problem, start again. It also helps me to avoid yak shaving, getting lost in the detail or distracted because the feedback loop between me seeing something working on the screen vs. the idea is so short (even if the code is crap). I'd also add 5.: use prompts to generate (boring) prompts. For instance, I needed a simple #tag formatter for one of my markdown sites. I am aware that there's a not-so-small list of edge cases I'd need to cover. In this case I'd write a prompt with a list of basic requirements and ask the LLM to: a) extend it with good practice, common edge cases b) format it as a spec with concrete input / output examples. This works a bit similar to the point you made about generating unit tests (I do that too, in tandem with this approach). In a sense 1) is autocomplete 2) is a scaffolding tool.
- echelon 2y ago
  I work on GenAI in the media domain, and I think this will hold true with other fields as well: - Text prompts and chat interfaces are great for coarse grained exploration. You can get a rough start that you can refine. "Knight standing in a desert, rusted suit of armor" gets you started, but you'll want to take it much further. - Precision inputs (mouse or structure guided) are best for fine tuning the result and honing in on the solution itself. You can individually plant the cacti and pose the character. You can't get there with text.
- ryandrake 2y ago
  > I've changed my mind on that as well. I think that, generally, chat UIs are a lazy and not very user friendly. However, when coding I keep switching between two modes: > 1. I need a smart autocomplete that can work backwards and mimic my coding patterns > 2. I need a pair programming buddy (of sorts, this metaphor doesn't completely work, but I don't have a better one) Thanks! This is the first time I've seen it put this clearly. When I first tried out CoPilot, I was unsure of how I was "supposed" to interact with it. Is it (as you put it) a smarter autocomplete, or a programming buddy? Is it both? What was the right input method to use? After a while, I realized that for my personal style I would pretty much entirely use method 1, and never method 2. But, others might really need that "programming buddy" and use that interface instead.
rafaelmn 2y ago
This only works for small self-contained problems with narrow scope/context. Chat sucks for pulling in context, and the only worse thing I've tried is the IDE integrations that supposedly pull the relevant context for you (and I've tried quite a few recently). I don't know if naive fine-tuning with codebase would work, I suspect there are going to be tools that let you train the AI on code in the sense that it can have some references in model, and it knows how you want your project code/structure to look like (which is often quite different from what it looks in most areas)
godelski 2y ago
> 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 don't get 3D space nor temporal movements. It's great for scrolling through Twitter but the longer you look the more surreal they get. This even includes the new ByteDance model also on the front page. But with coding models they ignore context of the codebase and the results feel more like patchwork. They feel like what you'd be annoyed at with a junior dev for writing because not only do you have to go through 10 PRs to make it pass the test cases but the lack of context just builds a lot of tech debt. How they'll build unit tests that technically work but don't capture the actual issues and usually can be highly condensed while having greater coverage. It feels very gluey, like copy pasting from stack overflow when hyper focused on the immediate outcome instead of understanding the goal. It is too "solution" oriented, not understanding the underlying heuristics and is more frustrating than dealing with the human equivalent who says something "works" as evidenced by the output. This is like trying to say a math proof is correct by looking at just the last line. Ironically, I think in part this is why chat interface sucks too. A lot of our job is to do a lot of inference in figuring out what our managers are even asking us to make. And you can't even know the answer until you're part way in.
- lucasmullens 2y ago
  > But with coding models they ignore context of the codebase and the results feel more like patchwork. Have you tried Cursor? It has a great feature that grabs context from the codebase, I use it all the time.
  - pc86 2y ago
    I can't get the prompt because I'm on my work computer but I have about a three-quarter-page instruction set in the settings of cursor, it asks clarifying questions a LOT now, and is pretty liberal with adding in commented pseudo-code for stuff it isn't sure about. You can still trip it up if you try, but it's a lot better than stock. This is with Sonnet 3.5 agent chats (composer I think it's called?) I actually cancelled by Anthropic subscription when I started using cursor because I only ever used Claude for code generation anyway so now I just do it within the IDE.
ic4l 2y ago
For me the o models consistently make more mistakes for me than Claude 3.5 Sonnet.
- pc86 2y ago
  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.
  - kristofferR 2y ago
    o4 doesn't exist (in public at least) yet.
    - esafak 2y ago
      OP means 4o
  - svachalek 2y ago
    I think Claude is incredible on JS/TS coding while GPT is highly python focused.
gamedever 2y ago
What did you create? In my field, so far, I've found the chat bots not doing so well. My guess is the more likely you're making something other people make often, the more likely the bot will help. Even then though, I asked o1-cursor to start a react app. It failed, mostly because it's out of date. It's instructions were for react 2 versions ago. This seems like an issue. If the statistically most likley answer is old, that's not helpful.
- wiremine 2y ago
  The most recent one was a typescript project focused on zod. I might be reading into your comment, but I agree "top-down" development sucks: "Give me a react that does X". I've had much more success going bottom-up. And I've often seen models getting confused on versions. You need to be explicit, and even then then forget.
ls_stats 2y ago
>it's actually a good UI >I just finished a small project >around 2200 lines why the top comments on HN are always people who have not read the article
- pc86 2y ago
  It's not clear to me in the lines you're quoting that the GP didn't read the article.
  - wiremine 2y ago
    Just confirming I did read the article in its entirety. Not reading it is like HN sin #1.
larodi 2y ago
I would actually join you, as my longstanding view on coding is that it is best done in pairs. Sadly humans and programmers in particular are not so ready to work arms-by-arms, and it is even more depressing that it now turns AI is pairing us. Perhaps there's gonna be post-AI programming movement where people actually stare at the same monitor and discuss while one of them is coding. As a sidenote - we've done experiments with FOBsters, and when paired this way, the multiply their output. There's something about psychology of groups and how one can only provide maximum output when teaming. Even for solo activities, and non-IT activities, such as skiing/snowboard, it is better to have a partner to ride with you and discuss the terrain.
bboygravity 2y ago
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.
- RHSeeger 2y ago
  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).
- wiremine 2y ago
  > "oh sht, we're all out of a job next year" Maybe. My sense if we'd need to see 3 to 4 orders of magnitude improvements on the current models before we can replace people outright. I do think we'll see a huge productivity boost per developer over the next few years. Some companies will use that to increase their throughput, and some will use it to reduce overhead.
  - hollowturtle 2y ago
    Whenever I read huge productivity boost for developers or companies I shiver. Software sucked more and more even before LLMs, I don't see it getting better just getting out faster maybe. I'm afraid in most cases it will be a disaster
AutistiCoder 2y ago
ChatGPT itself is great for coding. GitHub Copilot is...not. It doesn't seem to understand how to help me as well as ChatGPT does.
knes 2y ago
IMHO, I would agree with you. I think chat is a nice intermediary evolution between the CLI (that we use every day) and whatever comes next. I work at Augment (https://augmentcode.com https://augmentcode.com), which, surprise surprise, is an AI coding assistant. We think about the new modality required to interact with code and AI on a daily basis. Beside increase productivity (and happiness, as you don't have to do mundane tasks like tests, documentations, etc), I personally believe that what AI can open up is actually more of a way for non-coders (think PMs) to interact with a codebase. AI is really good at converting specs, user stories, and so on into tasks—which today still need to be implemented by software engineers (with the help of AI for the more tedious work). Think of what Figma did between designers and developers, but applied to coding. What’s the actual "new UI/UX paradigm"? I don’t know yet. But like with Figma, I believe there’s a happy ending waiting for everyone.
zahlman 2y ago
LoC per hour seems to me like a terrible metric.
- esafak 2y ago
  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.
  - 59nadir 2y ago
    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.
bandushrew 2y ago
Producing 200 lines of usable code an hour is genuinely impressive. My experiments have been nowhere near that successful. I would love, love, love to see a transcript of how that process worked over an hour, if that was something you were willing to share.
protocolture 2y ago
100%. I do all this + rubber ducky the hell out of it. Sometimes I just discuss concepts of the project with the thing and it helps me think. I dont think chat is going to be right for everyone but it absolutely works for me.
Syzygies 2y ago
An environment such as Cursor supports many approaches for working with AI. "Chat" would be the instructions printed on the bottom, perhaps how their developers use it, but far from the only mode it actually supports. It is helpful to frame this in the historical arc described by Yuval Harari in his recent book "Nexus" on the evolution of information systems. We're at the dawn of history for how to work with AI, and actively visualizing the future has an immediate ROI. "Chat" is cave man oral tradition. It is like attempting a complex Ruby project through the periscope of an `irb` session. One needs to use an IDE to manage a complex code base. We all know this, but we haven't connected the dots that we need to approach prompt management the same way. Flip ahead in Harari's book, and he describes rabbis writing texts on how to interpret [texts on how to interpret]* holy scriptures. Like Christopher Nolan's movie "Inception" (his second most relevant work after "Memento"), I've found myself several dreams deep collaborating with AI to develop prompts for [collaborating with AI to develop prompts for]* writing code together. Test the whole setup on multiple fresh AI sessions, as if one is running a business school laboratory on managerial genius, till AI can write correct code in one shot. Duh? Good managers already understand this, working with teams of people. Technical climbers work cliffs this way. And AI was a blithering idiot until we understood how to simulate recursion in multilayer neural nets. AI is a Rorschach inkblot test. Talk to it like a kindergartner, and you see the intelligence of a kindergartner. Use your most talented programmer to collaborate with you in preparing precise and complete specifications for your team, and you see a talented team of mature professionals. We all experience degradation of long AI sessions. This is not inevitable; "life extension" needs to be tackled as a research problem. Just as old people get senile, AI fumbles its own context management over time. Civilization has advanced by developing technologies for passing knowledge forward. We need to engineer similar technologies for providing persistent memory to make each successive AI session smarter than the last. Authoring this knowledge helps each session to survive longer. If we fail to see this, we're condemning ourselves to stay cave men. Compare the history of computing. There was a lot of philosophy and abstract mathematics about the potential for mechanical computation, but our worldview exploded when we could actually plug the machines in. We're at the same inflection point for theories of mind, semantic compression, structured memory. Indeed, philosophy was an untestable intellectual exercise before; now we can plug it in. How do I know this? I'm just an old mathematician, in my first month trying to learn AI for one final burst of productivity before my father's dementia arrives. I don't have time to wait for anyone's version of these visions, so I computed them. In mathematics, the line in the sand between theory and computation keeps moving. Indeed, I helped move it by computerizing my field when I was young. Mathematicians still contribute theory, and the computations help. A similar line in the sand is moving, between visionary creativity and computation. LLMs are association engines of staggering scope, and what some call "hallucinations" can be harnessed to generalize from all human endeavors to project future best practices. Like how to best work with AI. I've tested everything I say here, and it works.
deleted 2y ago
[deleted]
renegat0x0 2y ago
One thing I would keep in mind. There are some parts of the project that you really cannot fill by chat output. I had crucial area with threads. Code generated by chat seemed to be ok, but had one flaw. My initial code written manually was bug free. chat-generated output was not. It was difficult to catch it via inspection.

ikety 2y ago

do you use pair programming tools like aider?

shmoogy 2y ago

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.

gnatolf 2y ago
I haven't tried cursor yet, but how is this different from the copilot plugin in vscode? Sounds pretty similar.
- cheema33 2y ago
  > copilot plugin in vscode Copilot, back when I used it, completely ignored context outside of the file I was working in. Copilot, as of a few weeks ago, the absolute dumbest assistant of all the various options available. With cursor, I can ask it to make a change to how the app generates a JWT without even knowing which file or folder the relevant code is in. For very large codebases, this is very very helpful.
- cruffle_duffle 2y ago
  Similar flow but much better user experience. At least that is how I’d describe it.
- RugnirViking 2y ago
  ya know what, after a couple times hearing this comment, I downloaded it literally yesterday. It does feel pretty different, at least the composer module and stuff. A bit improvement in ai tooling imo

ryandrake 2y ago

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 move things around and visualize them. Figure everything out. Finally, when it's correct, you send it to the slow output device (your fingers). The minute you have to discuss those things with someone else, your bandwidth decreases by orders of magnitude and now you have to put words to these things and describe them, and physically type them in or vocalize them. Then your counterpart has to input them through his eyes and ears, process that, and re-output his thoughts to you. Slow, slow, slow, and prone to error and specificity problems as you translate technical concepts to English and back. Chat as a UX interface is similarly slow and poorly specific. It has all the shortcomings of discussing your idea with a human and really no upside besides the dictionary-like recall.

throwup238 2y ago
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 make my ideas more concrete as much as iterating through the chat interface which is more hit and miss due to context length limits. * I don’t mean that in a negative way, but in a “I can’t expect another person to respond to me instantly at 10 words per second” way.
- cortesoft 2y ago
  > 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
  - 2y ago

dataviz1000 2y ago

I agree with you. Yesterday, I asked o3-mini to "optimize" a block of code. It produced very clean, functional TypeScript. However, because the code is reducing stock option chains, I then asked o3-mini to "optimize for speed." In the JavaScript world, this is usually done with for loops, and it even considered aspects like array memory allocation. This shows that using the right qualifiers is important for getting the results you want. Today, I use both "optimize for developer experience" and "optimize for speed" when they are appropriate. Although declarative code is just an abstraction, moving from imperative jQuery to declarative React was a major change in my coding experience. My work went from telling the system how to do something to simply telling it what to do. Of course, in React—especially at first—I had to explain how to do things, but only once to create a component. After that, I could just tell the system what to do. Now, I can simply declare the desired outcome, the what. It helps to understand how things work, but that level of detail is becoming less necessary.

deleted 2y ago

[deleted]

bongodongobob 2y ago

To add to that, I always add some kind of debug function wrapper so I can hand off the state of variables and program flow to the LLM when I need to debug something. Sometimes it's really hard to explain exactly what went wrong so being able to give it a chunk of the program state is more descriptive.

throwup238 2y ago
I do the same for my QT desktop app. I’ve got an “Inspector” singleton that allows me to select a component tree via click, similar to browser devtools. It takes a screenshot, dumps the QML source, and serializes the state of the components into the clipboard. I paste that into Claude and it is surprisingly good at fixing bugs and making visual modifications.
- acrophiliac 2y ago
  That sounds cool. I could use that. Care to share your Inspector code?
- rubymamis 2y ago
  Sounds awesome. I would love to hear more about this. Any chance you can share this or at least more details?

jacob019 2y ago

Totally agree. Chat is a fantastic interface because it stays out of my way. For me it's much more than a coding assistant. I get live examples of how to use tools, and help with boilerplate, which is a time saver and improvement over legacy workflows, but the real benefit is all the spitballing I can do with it to refine ideas and logic and help getting up to speed on tooling way outside of my domain. I spent about 3.5 hours chatting with o1 about RL architecture to solve some business problems. Now I have a crystal clear plan and the confidence to move forward in an optimal way. I feel a little weird now, like I was just talking to myself for a few hours, but it totally helped me work through the planning. For actual code, I find myself being a bit less interactive with LLMs as time goes, sometimes it's easier to just write the logic the way I want rather than trying to explain how I want it but the ability to retrieve code samples for anything with ease is like a superpower. Not to mention all the cool stuff LLMs can do at runtime via API. Yeah, chat is great, and I'll stick with writing code in Vim and pasting as needed.

deleted 2y ago

[deleted]

sdesol 2y ago

> 1. I find a "pair programming" mentality is key. I focus on the high-level code, and let the model focus on the lower level code. I code review all the code, and provide feedback. Blindly accepting the code is a terrible approach. This is what I've found to be key. If I start a new feature, I will work with the LLM to do the following: - Create problem and solution statement - Create requirements and user stories - Create architecture - Create skeleton code. This is critical since it lets me understand what it wants to do. - Generate a summary of the skeleton code Once I have done the above, I will have the LLM generate a reusable prompt that I can use to start LLM conversations with. Below is an example of how I turn everything into a reusable prompt. https://beta.gitsense.com/?chat=b96ce9e0-da19-45e8-bfec-a3ecf408ee71 https://beta.gitsense.com/?chat=b96ce9e0-da19-45e8-bfec-a3ec... As I make changes like add new files, I will need to generate a new prompt but it is worth the effort. And you can see it in action here. https://beta.gitsense.com/?chat=b8c4b221-55e5-4ed6-860e-12f056b682ad https://beta.gitsense.com/?chat=b8c4b221-55e5-4ed6-860e-12f0... The first message is the reusable prompt message. With the first message in place, I can describe the problem or requirements and ask the LLM what files it will need to better understand how to implement things. What I am currently doing highlights how I think LLM is a game changer. VCs are going for moonshots instead of home runs. The ability to gather requirements and talk through a solution before even coding is how I think LLMs will revolutionize things. It is great that it can produce usable code, but what I've found it to be invaluable is it helps you organize your thoughts. In the last link, I am having a conversation with both DeepSeek v3 and Sonnet 3.5 and the LLMs legitimately saved me hours in work, without even writing a single line of code. In the past, I would have just implemented the feature and been done with it, and then I would have to fix something if I didn't think of an edge case. With LLMs, it literally takes minutes to develop a plan that is extremely well documented that can be shared with others. This ability to generate design documents is how I think LLMs will ultimately be used. The bonus is producing code, but the reality is that documentation (which can be tedious and frustrating) is a requirement for software development. In my opinion, this is where LLMs will forever change things.

javier2 2y ago

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

pc86 2y ago
Cursor does all of this, and agent chats let you describe a new feature or an existing bug and it will search the entire codebase and add relevant code to its context automatically. You can optionally attach files for the context - code files that you want to add to the context up front, documentation for third-party calls, whatever you want. As a side note, "No, you're wrong" is not a great way to have a conversation.
- javier2 2y ago
  Yeah, that is right. I'll give Cursor a try, because I believe we can do much better than these hopeless chat windows!
  - pc86 2y ago
    I've tried every LLM+IDE combo that I've heard about and Cursor is by far the best.
zahlman 2y ago
>In my tears of working Sometimes typos are eerily appropriate ;) (I almost typed "errily"...)
- javier2 2y ago
  I’ll leave it!

nonrandomstring 2y ago

> it's actually a good UI Came to vote good too. I mean, why do we all love a nice REPL? That's chat right? Chat with an interpreter.

rpastuszak 2y ago

I've changed my mind on that as well. I think that, generally, chat UIs are a lazy and not very user friendly. However, when coding I keep switching between two modes: 1. I need a smart autocomplete that can work backwards and mimic my coding patterns 2. I need a pair programming buddy (of sorts, this metaphor doesn't completely work, but I don't have a better one) Pair development, even a butchered version of the so called "strong style" (give the driver the highest level of abstraction they can use/understand) works quite well for me. But, the main reason this works is that it forces me to structure my thinking a little bit, allows me to iterate on the definition of the problem. Toss away the sketch with bigger parts of the problem, start again. It also helps me to avoid yak shaving, getting lost in the detail or distracted because the feedback loop between me seeing something working on the screen vs. the idea is so short (even if the code is crap). I'd also add 5.: use prompts to generate (boring) prompts. For instance, I needed a simple #tag formatter for one of my markdown sites. I am aware that there's a not-so-small list of edge cases I'd need to cover. In this case I'd write a prompt with a list of basic requirements and ask the LLM to: a) extend it with good practice, common edge cases b) format it as a spec with concrete input / output examples. This works a bit similar to the point you made about generating unit tests (I do that too, in tandem with this approach). In a sense 1) is autocomplete 2) is a scaffolding tool.

echelon 2y ago
I work on GenAI in the media domain, and I think this will hold true with other fields as well: - Text prompts and chat interfaces are great for coarse grained exploration. You can get a rough start that you can refine. "Knight standing in a desert, rusted suit of armor" gets you started, but you'll want to take it much further. - Precision inputs (mouse or structure guided) are best for fine tuning the result and honing in on the solution itself. You can individually plant the cacti and pose the character. You can't get there with text.
ryandrake 2y ago
> I've changed my mind on that as well. I think that, generally, chat UIs are a lazy and not very user friendly. However, when coding I keep switching between two modes: > 1. I need a smart autocomplete that can work backwards and mimic my coding patterns > 2. I need a pair programming buddy (of sorts, this metaphor doesn't completely work, but I don't have a better one) Thanks! This is the first time I've seen it put this clearly. When I first tried out CoPilot, I was unsure of how I was "supposed" to interact with it. Is it (as you put it) a smarter autocomplete, or a programming buddy? Is it both? What was the right input method to use? After a while, I realized that for my personal style I would pretty much entirely use method 1, and never method 2. But, others might really need that "programming buddy" and use that interface instead.

rafaelmn 2y ago

This only works for small self-contained problems with narrow scope/context. Chat sucks for pulling in context, and the only worse thing I've tried is the IDE integrations that supposedly pull the relevant context for you (and I've tried quite a few recently). I don't know if naive fine-tuning with codebase would work, I suspect there are going to be tools that let you train the AI on code in the sense that it can have some references in model, and it knows how you want your project code/structure to look like (which is often quite different from what it looks in most areas)

godelski 2y ago

> 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 don't get 3D space nor temporal movements. It's great for scrolling through Twitter but the longer you look the more surreal they get. This even includes the new ByteDance model also on the front page. But with coding models they ignore context of the codebase and the results feel more like patchwork. They feel like what you'd be annoyed at with a junior dev for writing because not only do you have to go through 10 PRs to make it pass the test cases but the lack of context just builds a lot of tech debt. How they'll build unit tests that technically work but don't capture the actual issues and usually can be highly condensed while having greater coverage. It feels very gluey, like copy pasting from stack overflow when hyper focused on the immediate outcome instead of understanding the goal. It is too "solution" oriented, not understanding the underlying heuristics and is more frustrating than dealing with the human equivalent who says something "works" as evidenced by the output. This is like trying to say a math proof is correct by looking at just the last line. Ironically, I think in part this is why chat interface sucks too. A lot of our job is to do a lot of inference in figuring out what our managers are even asking us to make. And you can't even know the answer until you're part way in.

lucasmullens 2y ago
> But with coding models they ignore context of the codebase and the results feel more like patchwork. Have you tried Cursor? It has a great feature that grabs context from the codebase, I use it all the time.
- pc86 2y ago
  I can't get the prompt because I'm on my work computer but I have about a three-quarter-page instruction set in the settings of cursor, it asks clarifying questions a LOT now, and is pretty liberal with adding in commented pseudo-code for stuff it isn't sure about. You can still trip it up if you try, but it's a lot better than stock. This is with Sonnet 3.5 agent chats (composer I think it's called?) I actually cancelled by Anthropic subscription when I started using cursor because I only ever used Claude for code generation anyway so now I just do it within the IDE.

ic4l 2y ago

For me the o models consistently make more mistakes for me than Claude 3.5 Sonnet.

pc86 2y ago
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.
- kristofferR 2y ago
  o4 doesn't exist (in public at least) yet.
  - esafak 2y ago
    OP means 4o
- svachalek 2y ago
  I think Claude is incredible on JS/TS coding while GPT is highly python focused.

gamedever 2y ago

What did you create? In my field, so far, I've found the chat bots not doing so well. My guess is the more likely you're making something other people make often, the more likely the bot will help. Even then though, I asked o1-cursor to start a react app. It failed, mostly because it's out of date. It's instructions were for react 2 versions ago. This seems like an issue. If the statistically most likley answer is old, that's not helpful.

wiremine 2y ago
The most recent one was a typescript project focused on zod. I might be reading into your comment, but I agree "top-down" development sucks: "Give me a react that does X". I've had much more success going bottom-up. And I've often seen models getting confused on versions. You need to be explicit, and even then then forget.

ls_stats 2y ago

>it's actually a good UI >I just finished a small project >around 2200 lines why the top comments on HN are always people who have not read the article

pc86 2y ago
It's not clear to me in the lines you're quoting that the GP didn't read the article.
- wiremine 2y ago
  Just confirming I did read the article in its entirety. Not reading it is like HN sin #1.

larodi 2y ago

I would actually join you, as my longstanding view on coding is that it is best done in pairs. Sadly humans and programmers in particular are not so ready to work arms-by-arms, and it is even more depressing that it now turns AI is pairing us. Perhaps there's gonna be post-AI programming movement where people actually stare at the same monitor and discuss while one of them is coding. As a sidenote - we've done experiments with FOBsters, and when paired this way, the multiply their output. There's something about psychology of groups and how one can only provide maximum output when teaming. Even for solo activities, and non-IT activities, such as skiing/snowboard, it is better to have a partner to ride with you and discuss the terrain.

bboygravity 2y ago

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.

RHSeeger 2y ago
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).
wiremine 2y ago
> "oh sht, we're all out of a job next year" Maybe. My sense if we'd need to see 3 to 4 orders of magnitude improvements on the current models before we can replace people outright. I do think we'll see a huge productivity boost per developer over the next few years. Some companies will use that to increase their throughput, and some will use it to reduce overhead.
- hollowturtle 2y ago
  Whenever I read huge productivity boost for developers or companies I shiver. Software sucked more and more even before LLMs, I don't see it getting better just getting out faster maybe. I'm afraid in most cases it will be a disaster

AutistiCoder 2y ago

ChatGPT itself is great for coding. GitHub Copilot is...not. It doesn't seem to understand how to help me as well as ChatGPT does.

knes 2y ago

IMHO, I would agree with you. I think chat is a nice intermediary evolution between the CLI (that we use every day) and whatever comes next. I work at Augment (https://augmentcode.com https://augmentcode.com), which, surprise surprise, is an AI coding assistant. We think about the new modality required to interact with code and AI on a daily basis. Beside increase productivity (and happiness, as you don't have to do mundane tasks like tests, documentations, etc), I personally believe that what AI can open up is actually more of a way for non-coders (think PMs) to interact with a codebase. AI is really good at converting specs, user stories, and so on into tasks—which today still need to be implemented by software engineers (with the help of AI for the more tedious work). Think of what Figma did between designers and developers, but applied to coding. What’s the actual "new UI/UX paradigm"? I don’t know yet. But like with Figma, I believe there’s a happy ending waiting for everyone.

zahlman 2y ago

LoC per hour seems to me like a terrible metric.

esafak 2y ago
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.
- 59nadir 2y ago
  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.

bandushrew 2y ago

Producing 200 lines of usable code an hour is genuinely impressive. My experiments have been nowhere near that successful. I would love, love, love to see a transcript of how that process worked over an hour, if that was something you were willing to share.

protocolture 2y ago

100%. I do all this + rubber ducky the hell out of it. Sometimes I just discuss concepts of the project with the thing and it helps me think. I dont think chat is going to be right for everyone but it absolutely works for me.

Syzygies 2y ago

An environment such as Cursor supports many approaches for working with AI. "Chat" would be the instructions printed on the bottom, perhaps how their developers use it, but far from the only mode it actually supports. It is helpful to frame this in the historical arc described by Yuval Harari in his recent book "Nexus" on the evolution of information systems. We're at the dawn of history for how to work with AI, and actively visualizing the future has an immediate ROI. "Chat" is cave man oral tradition. It is like attempting a complex Ruby project through the periscope of an `irb` session. One needs to use an IDE to manage a complex code base. We all know this, but we haven't connected the dots that we need to approach prompt management the same way. Flip ahead in Harari's book, and he describes rabbis writing texts on how to interpret [texts on how to interpret]* holy scriptures. Like Christopher Nolan's movie "Inception" (his second most relevant work after "Memento"), I've found myself several dreams deep collaborating with AI to develop prompts for [collaborating with AI to develop prompts for]* writing code together. Test the whole setup on multiple fresh AI sessions, as if one is running a business school laboratory on managerial genius, till AI can write correct code in one shot. Duh? Good managers already understand this, working with teams of people. Technical climbers work cliffs this way. And AI was a blithering idiot until we understood how to simulate recursion in multilayer neural nets. AI is a Rorschach inkblot test. Talk to it like a kindergartner, and you see the intelligence of a kindergartner. Use your most talented programmer to collaborate with you in preparing precise and complete specifications for your team, and you see a talented team of mature professionals. We all experience degradation of long AI sessions. This is not inevitable; "life extension" needs to be tackled as a research problem. Just as old people get senile, AI fumbles its own context management over time. Civilization has advanced by developing technologies for passing knowledge forward. We need to engineer similar technologies for providing persistent memory to make each successive AI session smarter than the last. Authoring this knowledge helps each session to survive longer. If we fail to see this, we're condemning ourselves to stay cave men. Compare the history of computing. There was a lot of philosophy and abstract mathematics about the potential for mechanical computation, but our worldview exploded when we could actually plug the machines in. We're at the same inflection point for theories of mind, semantic compression, structured memory. Indeed, philosophy was an untestable intellectual exercise before; now we can plug it in. How do I know this? I'm just an old mathematician, in my first month trying to learn AI for one final burst of productivity before my father's dementia arrives. I don't have time to wait for anyone's version of these visions, so I computed them. In mathematics, the line in the sand between theory and computation keeps moving. Indeed, I helped move it by computerizing my field when I was young. Mathematicians still contribute theory, and the computations help. A similar line in the sand is moving, between visionary creativity and computation. LLMs are association engines of staggering scope, and what some call "hallucinations" can be harnessed to generalize from all human endeavors to project future best practices. Like how to best work with AI. I've tested everything I say here, and it works.

deleted 2y ago

[deleted]

renegat0x0 2y ago

One thing I would keep in mind. There are some parts of the project that you really cannot fill by chat output. I had crucial area with threads. Code generated by chat seemed to be ok, but had one flaw. My initial code written manually was bug free. chat-generated output was not. It was difficult to catch it via inspection.