4 ms·

I disagree from almost the first sentence: > Learning how to use LLMs in a coding workflow is trivial. There is no learning curve. You can safely ignore them i

I disagree from almost the first sentence: > Learning how to use LLMs in a coding workflow is trivial. There is no learning curve. You can safely ignore them if they don’t fit your workflows at the moment. Learning how to use LLMs in a coding workflow is trivial to start, but you find you get a bad taste early if you don't learn how to adapt both your workflow and its workflow. It is easy to get a trivially good result and then be disappointed in the followup. It is easy to try to start on something it's not good at and think it's worthless. The pure dismissal of cursor, for example, means that the author didn't learn how to work with it. Now, it's certainly limited and some people just prefer Claude code. I'm not saying that's unfair. However, it requires a process adaptation.

mkozlows 1y ago
"There's no learning curve" just means this guy didn't get very far up, which is definitely backed up by thinking that Copilot and other tools are all basically the same.
- leptons 1y ago
  Basically, they are the same, they are all LLMs. They all have similar limitations. They all produce "hallucinations". They can also sometimes be useful. And they are all way overhyped.
  - trenchpilgrim 1y ago
    The amount of misconceptions in this comment are quite profound. Copilot isn't an LLM, for a start. You _combine_ it wil a selection of LLMs. And it absolutely has severe limitations compared to something like Claude Code in how it can interact with the programming environment. "Hallucinations" are far less of a problem with software that grounds the AI to the truth in your compiler, diagnostics, static analysis, a running copy of your project, runnning your tests, executing dev tools in your shell, etc.
    - leptons 1y ago
      >Copilot isn't an LLM, for a start You're being overly pedantic here and moving goalposts. Copilot (for coding) without an LLM is pretty useless. I stand by my assertion that these tools are all basically the same fundamental tech - LLMs.
      - noidesto 1y ago
        > I stand by my assertion that these tools are all basically the same fundamental tech - LLMs. Over generalizing. The synergy between the LLM and the client (cursor, Claude code, copilot, etc) make a huge difference in results.
      - phillipcarter 1y ago
        This is like saying every web app is basically the same fundamental tech - databases.
        trenchpilgrim 1y ago
        Or that writing Python with notepad.exe and Jupyter are fundamentally the same.
- rustybolt 1y ago
  > "There's no learning curve" just means this guy didn't get very far up Not everyone with a different opinion is dumber than you.
  - SadErn 1y ago
    This is all just ignorance. We've all worked with LLMs and know that creating an effective workflow is not trivial and it varies based on the tool.
    - antonvs 1y ago
      Define "not trivial". Obviously, experience helps, as with any tool. But it's hardly rocket science. It seems to me the biggest barrier is that the person driving the tool needs to be experienced enough to recognize and assist when it runs into issues. But that's little different from any sophisticated tool. It seems to me a lot of the criticism comes from placing completely unrealistic expectations on an LLM. "It's not perfect, therefore it sucks."
      - skydhash 1y ago
        I don’t think anyone expects perfection. Programs crash, drives die, and computers can break anytime. But we expect our tools to be reliable and not fight with it everyday to get it to work. I don’t have to debug Emacs every day to write code. My CI workflow just runs every time a PR is created. When I type ‘make tests’, I get a report back. None of those things are perfect, but they are reliable.
        antonvs 1y ago
        If you work in a team, you work with other people, whose reliability is more akin to LLMs than to the deterministic processes you're describing. What you're describing is a case of mismatched expectations.
        skydhash 1y ago
deadbabe 1y ago
If it’s not trivial, it’s worthless, because writing things out manually yourself is usually trivial, but tedious. With LLMs, the point is to eliminate tedious work in a trivial way. If it’s tedious to get an LLM to do tedious work, you have not accomplished anything. If the work is not trivial enough for you to do yourself, then using an LLM will probably be a disaster, as you will not be able to judge the final output yourself without spending nearly the same amount of time it takes for you to develop the code on your own. So again, nothing is gained, only the illusion of gain. The reason people think they are more productive using LLMs to tackle non-trivial problems is because LLMs are pretty good at producing “office theatre”. You look like you’re busy more often because you are in a tight feedback loop of prompting and reading LLM output, vs staring off into space thinking deeply about a problem and occasionally scribbling or typing something out.
- ebiester 1y ago
  So, I'd like you to talk to a fair number of emacs and vim users. They have spent hours and hours learning their tools, tweaking their configurations, and learning efficiencies. They adapt their tool to them and themselves to the tool. We are learning that this is not going to be magic. There are some cases where it shines. If I spend the time, I can put out prototypes that are magic and I can test with users in a fraction of the time. That doesn't mean I can use that for production. I can try three or four things during a meeting where I am generally paying attention, and look afterwards to see if it's pursuing. I can have it work through drudgery if I provide it an example. I can have it propose a solution to a problem that is escaping me, and I can use it as a conversational partner for the best rubber duck I've ever seen. But I'm adapting myself to the tool and I'm adapting the tool to me through learning how to prompt and how to develop guardrails. Outside of coding, I can write chicken scratch and provide an example of what I want, and have it write a proposal for a PRD. I can have it break down a task, generate a list of proposed tickets, and after I've went through them have it generate them in jira (or anything else with an API). But the more I invest into learning how to use the tool, the less I have to clean up after. Maybe one day in the future it will be better. However, the time invested into the tool means that 40 bucks of investment (20 into cursor, 20 into gpt) can add 10-15% boost in productivity. Putting 200 into claude might get you another 10% and it can get you 75% in greenfield and prototyping work. I bet that agency work can be sped up as much as 40% for that 200 bucks investment into claude. That's a pretty good ROI. And maybe some workloads can do even better. I haven't seen it yet but some people are further ahead than me.

mkozlows 1y ago

"There's no learning curve" just means this guy didn't get very far up, which is definitely backed up by thinking that Copilot and other tools are all basically the same.

leptons 1y ago
Basically, they are the same, they are all LLMs. They all have similar limitations. They all produce "hallucinations". They can also sometimes be useful. And they are all way overhyped.
- trenchpilgrim 1y ago
  The amount of misconceptions in this comment are quite profound. Copilot isn't an LLM, for a start. You _combine_ it wil a selection of LLMs. And it absolutely has severe limitations compared to something like Claude Code in how it can interact with the programming environment. "Hallucinations" are far less of a problem with software that grounds the AI to the truth in your compiler, diagnostics, static analysis, a running copy of your project, runnning your tests, executing dev tools in your shell, etc.
  - leptons 1y ago
    >Copilot isn't an LLM, for a start You're being overly pedantic here and moving goalposts. Copilot (for coding) without an LLM is pretty useless. I stand by my assertion that these tools are all basically the same fundamental tech - LLMs.
    - noidesto 1y ago
      > I stand by my assertion that these tools are all basically the same fundamental tech - LLMs. Over generalizing. The synergy between the LLM and the client (cursor, Claude code, copilot, etc) make a huge difference in results.
    - phillipcarter 1y ago
      This is like saying every web app is basically the same fundamental tech - databases.
      - trenchpilgrim 1y ago
        Or that writing Python with notepad.exe and Jupyter are fundamentally the same.
rustybolt 1y ago
> "There's no learning curve" just means this guy didn't get very far up Not everyone with a different opinion is dumber than you.
- SadErn 1y ago
  This is all just ignorance. We've all worked with LLMs and know that creating an effective workflow is not trivial and it varies based on the tool.
  - antonvs 1y ago
    Define "not trivial". Obviously, experience helps, as with any tool. But it's hardly rocket science. It seems to me the biggest barrier is that the person driving the tool needs to be experienced enough to recognize and assist when it runs into issues. But that's little different from any sophisticated tool. It seems to me a lot of the criticism comes from placing completely unrealistic expectations on an LLM. "It's not perfect, therefore it sucks."
    - skydhash 1y ago
      I don’t think anyone expects perfection. Programs crash, drives die, and computers can break anytime. But we expect our tools to be reliable and not fight with it everyday to get it to work. I don’t have to debug Emacs every day to write code. My CI workflow just runs every time a PR is created. When I type ‘make tests’, I get a report back. None of those things are perfect, but they are reliable.
      - antonvs 1y ago
        If you work in a team, you work with other people, whose reliability is more akin to LLMs than to the deterministic processes you're describing. What you're describing is a case of mismatched expectations.
        skydhash 1y ago

deadbabe 1y ago

If it’s not trivial, it’s worthless, because writing things out manually yourself is usually trivial, but tedious. With LLMs, the point is to eliminate tedious work in a trivial way. If it’s tedious to get an LLM to do tedious work, you have not accomplished anything. If the work is not trivial enough for you to do yourself, then using an LLM will probably be a disaster, as you will not be able to judge the final output yourself without spending nearly the same amount of time it takes for you to develop the code on your own. So again, nothing is gained, only the illusion of gain. The reason people think they are more productive using LLMs to tackle non-trivial problems is because LLMs are pretty good at producing “office theatre”. You look like you’re busy more often because you are in a tight feedback loop of prompting and reading LLM output, vs staring off into space thinking deeply about a problem and occasionally scribbling or typing something out.

ebiester 1y ago
So, I'd like you to talk to a fair number of emacs and vim users. They have spent hours and hours learning their tools, tweaking their configurations, and learning efficiencies. They adapt their tool to them and themselves to the tool. We are learning that this is not going to be magic. There are some cases where it shines. If I spend the time, I can put out prototypes that are magic and I can test with users in a fraction of the time. That doesn't mean I can use that for production. I can try three or four things during a meeting where I am generally paying attention, and look afterwards to see if it's pursuing. I can have it work through drudgery if I provide it an example. I can have it propose a solution to a problem that is escaping me, and I can use it as a conversational partner for the best rubber duck I've ever seen. But I'm adapting myself to the tool and I'm adapting the tool to me through learning how to prompt and how to develop guardrails. Outside of coding, I can write chicken scratch and provide an example of what I want, and have it write a proposal for a PRD. I can have it break down a task, generate a list of proposed tickets, and after I've went through them have it generate them in jira (or anything else with an API). But the more I invest into learning how to use the tool, the less I have to clean up after. Maybe one day in the future it will be better. However, the time invested into the tool means that 40 bucks of investment (20 into cursor, 20 into gpt) can add 10-15% boost in productivity. Putting 200 into claude might get you another 10% and it can get you 75% in greenfield and prototyping work. I bet that agency work can be sped up as much as 40% for that 200 bucks investment into claude. That's a pretty good ROI. And maybe some workloads can do even better. I haven't seen it yet but some people are further ahead than me.