[ebiester]

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]

"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.

[rustybolt]

> "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.

[scrollaway]

No, it's sometimes just extremely easy to recognize people who have no idea what they're talking about when they make certain claims.

Just like I can recognize a clueless frontend developer when they say "React is basically just a newer jquery". Recognizing clueless engineers when they talk about AI can be pretty easy.

It's a sector that is both old and new: AI has been around forever, but even people who worked in the sector years ago are taken aback by what is suddenly possible, the workflows that are happening... hell, I've even seen cases where it's the very people who have been following GenAI forever that have a bias towards believing it's incapable of what it can do.

For context, I lead an AI R&D lab in Europe (https://ingram.tech/). I've seen some shit.

[SadErn]

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]

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."

[simonw]

As of about three months ago, one of the most important skills in effective LLM coding is coding agent environment design.

If you want to use a tool like Claude Code (or Gemini CLI or Cursor agent mode or Code CLI or Qwen Code) to solve complex problems you need to give them an environment they can operate in where they can solve that problem without causing too much damage if something goes wrong.

You need to think about sandboxing, and what tools to expose to them, and what secrets (if any) they should have access to, and how to control the risk of prompt injection if they might be exposed to potentially malicious sources of tokens.

The other week I wanted to experiment with some optimizations of configurations on my Fly.io hosted containers. I used Claude Code for this by:

- Creating a new Fly organization which I called Scratchpad

- Assigning that a spending limit (in case my coding agent went rogue or made dumb expensive mistakes)

- Creating a Fly API token that could only manipulate that organization - so I could be sure my coding agent couldn't touch any of my production deployments

- Putting together some examples of how to use the Fly CLI tool to deploy an app with a configuration change - just enough information that Claude Code could start running its own deploys

- Running Claude Code such that it had access to the relevant Fly command authenticated with my new Scratchpad API token

With all of the above in place I could run Claude in --dangerously-skip-permissions mode and know that the absolute worse that could happen is it might burn through the spending limit I had set.

This took a while to figure out! But now... any time I want to experiment with new Fly configuration patterns I can outsource much of that work safely to Claude.

[antonvs]

The statement I responded to was, "creating an effective workflow is not trivial".

There are plenty of useful LLM workflows that are possible to create pretty trivially.

The example you gave is not hardly the first thing a beginning LLM user would need. Yes, more sophisticated uses of an advanced tool require more experience. There's nothing different from any other tool here. You can find similar debates about programming languages.

Again, what I said in my original comment applies: people place unrealistic expectations on LLMs.

I suspect that this is at least partly is a psychological game people unconsciously play to try to minimize the competence of LLMs, to reduce the level of threat they feel. A sort of variation of terror management theory.

[donperignon]

Yeah if I want I to develop I need tooling around me. Still trivial to learn. Not a difficult skill. Not an specific skill to llm.

[streb-lo]

The situation you’re outlining is trivial though.

Yea, there’s some grunt work involved but in terms of learned ability all of that is obvious to someone who knew only a little bit about LLMs.

[skydhash]

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]

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.

[jaynetics]

I'm not a native speaker, but to me that quote doesn't necessarily imply an inability of OP to get up the curve. Maybe they just mean that the curve can look flat at the start?

[leptons]

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]

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]

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

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

This is like saying every web app is basically the same fundamental tech - databases.

[trenchpilgrim]

Or that writing Python with notepad.exe and Jupyter are fundamentally the same.

[deadbabe]

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]

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.

[deadbabe]

vim and eMacs are owned by the developer who configures them. LLMs are products, whose capabilities are subject to the whims of their host. These are not the same things.

Everything you mentioned is also fairly trivial, just a couple of one shot prompts needed.