1) Auto-complete on steroids. My LLM often auto-completes six or seven lines of code at a time, and can often infer intent from context. Wrong about as often as it is right, but if I had written the code myself, I would have been wrong on the first cut about as often as my coding assistant is. Somewhere between 25% and 60% of all code I write these days is written using TAB auto-complete of LLM suggestions. (Sorry I can't be more precise, but I use TAB auto-complete a LOT).
2) An assistant for writing chunks of code in technologies with which I do not have deep expertise. Provides easy entry into APIs that I'm not familiar with. My LLM will sketch out the framework code required to get some chunk of technology up and working. ("Initialize an ALSA MIDI port. Ctrl+I. "and Make it initialize the port in RAW mode". "and use camel case for the method names". &c). Particularly useful with ancient crusty Linux APIs that are short on documentation and examples. My use of Stack Exchange has gone to zero (and my use of Reddit).
3) Writing code for technologies that I have practically zero experience with. "Write a bash script that takes the output from this program (... format specified...)and use gnuplot to generate a graph."; "And display the results in a QT window"; "And set the title to "cumulative downloads"; "And rotate the x-axis labels by 45 degrees."; "and set all the fonts to 'Roboto'", &c. (I am for all practical purposes bash-script illiterate, and I've never used gnuplot before. I often do programming tasks these days that I would not have done before because the effort would not have been worthwhile without a coding assistant. Making my audio plugins read and write audio files in a variety of file format would have take a week, but with a coding assistant it took me about half a day. Without a coding assistant, I just wouldn't have done it.
4) Difficult debugging problems! "What's wrong with this code?" (That seriously works!) "Why doesn't this code properly recover from ALSA buffer underruns?" Doesn't necessarily get the right answer; but it will often provide a list of extremely useful suggestions. I've encountered several occasions where my coding assistant will help me solve difficult bugs that I've been working for hours on, one of which I had been working on for three or four days.
Of these, I think (2) provides the most productivity boost for me. I've often thought that the vast majority of time spent programming is spent reading documentation for the APIs you're using. Programming is mostly transforming documentation into usefulness. I will often write a one-liner saying what I want to do, and type ^I. My LLM is spookily good at stuff like that. No need to spend 40 minutes reading ffmpeg documenation. No need to google for the least toxicly awful code sample on the internet. Just, "// Write the audio buffer to an MP3 file using ffmpeg" ctrl+I.
Let's be frank; nobody is going to be converting natural language to A-list games. But LLMs are a tool. And tools are good. And LLM coding assistants are extremely good tools. The answer to all of this is: try it, and learn to use the tool, and take away what works for you, and get good at recognizing when your coding assistant will and will not work.
I get that you're asking because you haven't tried it yet. But I guarantee that if you do, you will recognize the traction pretty much instantly. It's immediately obvious that the tool is useful. And as you use it more and more, and adapt to the quirks, it becomes more and more useful.
I'm a professional senior programmer with 40 years of experience. I'm pretty sure it roughly doubles my productivity.
1) Auto-complete on steroids. My LLM often auto-completes six or seven lines of code at a time, and can often infer intent from context. Wrong about as often as it is right, but if I had written the code myself, I would have been wrong on the first cut about as often as my coding assistant is. Somewhere between 25% and 60% of all code I write these days is written using TAB auto-complete of LLM suggestions. (Sorry I can't be more precise, but I use TAB auto-complete a LOT).
2) An assistant for writing chunks of code in technologies with which I do not have deep expertise. Provides easy entry into APIs that I'm not familiar with. My LLM will sketch out the framework code required to get some chunk of technology up and working. ("Initialize an ALSA MIDI port. Ctrl+I. "and Make it initialize the port in RAW mode". "and use camel case for the method names". &c). Particularly useful with ancient crusty Linux APIs that are short on documentation and examples. My use of Stack Exchange has gone to zero (and my use of Reddit).
3) Writing code for technologies that I have practically zero experience with. "Write a bash script that takes the output from this program (... format specified...)and use gnuplot to generate a graph."; "And display the results in a QT window"; "And set the title to "cumulative downloads"; "And rotate the x-axis labels by 45 degrees."; "and set all the fonts to 'Roboto'", &c. (I am for all practical purposes bash-script illiterate, and I've never used gnuplot before. I often do programming tasks these days that I would not have done before because the effort would not have been worthwhile without a coding assistant. Making my audio plugins read and write audio files in a variety of file format would have take a week, but with a coding assistant it took me about half a day. Without a coding assistant, I just wouldn't have done it.
4) Difficult debugging problems! "What's wrong with this code?" (That seriously works!) "Why doesn't this code properly recover from ALSA buffer underruns?" Doesn't necessarily get the right answer; but it will often provide a list of extremely useful suggestions. I've encountered several occasions where my coding assistant will help me solve difficult bugs that I've been working for hours on, one of which I had been working on for three or four days.
Of these, I think (2) provides the most productivity boost for me. I've often thought that the vast majority of time spent programming is spent reading documentation for the APIs you're using. Programming is mostly transforming documentation into usefulness. I will often write a one-liner saying what I want to do, and type ^I. My LLM is spookily good at stuff like that. No need to spend 40 minutes reading ffmpeg documenation. No need to google for the least toxicly awful code sample on the internet. Just, "// Write the audio buffer to an MP3 file using ffmpeg" ctrl+I.
Let's be frank; nobody is going to be converting natural language to A-list games. But LLMs are a tool. And tools are good. And LLM coding assistants are extremely good tools. The answer to all of this is: try it, and learn to use the tool, and take away what works for you, and get good at recognizing when your coding assistant will and will not work.
I get that you're asking because you haven't tried it yet. But I guarantee that if you do, you will recognize the traction pretty much instantly. It's immediately obvious that the tool is useful. And as you use it more and more, and adapt to the quirks, it becomes more and more useful.
I'm a professional senior programmer with 40 years of experience. I'm pretty sure it roughly doubles my productivity.