3 ms·

These all-or-nothing takes on LLMs are getting tiresome. I get the point you’re trying to make, LLMs can be a force multiplier for less experienced devs, but t

These all-or-nothing takes on LLMs are getting tiresome. I get the point you’re trying to make, LLMs can be a force multiplier for less experienced devs, but the sweeping generalizations don’t hold up. If you’re okay with a higher tolerance for bugs or loose guardrails, sure, LLMs can feel magical. But that doesn’t mean they’re less valuable to experienced developers. I’ve been writing Python and Java professionally for 15+ years. I’ve lived through JetBrains IDEs, and switching to VS Code took me days. If you’re coming from a heavily customized Vim setup, the adjustment will be harder. I don’t tolerate flaky output, and I work on a mix of greenfield and legacy systems. Yes, greenfield is more LLM-friendly, but I still get plenty of value from LLMs when navigating and extending mature codebases. What frustrates me is how polarized these conversations are. There are valid insights on both sides, but too many posts frame their take as gospel. The reality is more nuanced: LLMs are a tool, not a revolution, and their value depends on how you integrate them into your workflow, regardless of experience level.

mexicocitinluez 1y ago
> I get the point you’re trying to make, LLMs can be a force multiplier for less experienced devs, but the sweeping generalizations don’t hold up. If you’re okay with a higher tolerance for bugs or loose guardrails, sure, LLMs can feel magical. But that doesn’t mean they’re less valuable to experienced developers. Amen. Seriously. They're tools. Sometimes they work wonderfully. Sometimes, not so much. But I have DEFINITELY found value. And I've been building stuff for over 15 years as well. I'm not "vibe coding", I don't use Cursor or any of the ai-based IDEs. I just use Claude and Copilot since it's integrated.
- voidhorse 1y ago
  > Amen. Seriously. They're tools. Sometimes they work wonderfully. Sometimes, not so much. But I have DEFINITELY found value. And I've been building stuff for over 15 years as well. Yes, but these lax expectation s are what I don't understand. What other tools in software sometimes work and sometimes don't that you find remotely acceptable? Sure all tools have bugs, but if your compiler had the same failure rate and usability issues as an LLM you'd never use it. Yet for some reason the bar is so low for LLMs. It's insane to me how much people have indulged in the hype koolaid around these tools.
  - infecto 1y ago
    My compiler doesn’t write a complete function to visualize a DataFrame based on a vague prompt. It also doesn’t revise that function as I refine the requirements. LLMs can. There’s definitely hype out there, but dismissing all AI use as “koolaid” is as lazy as the Medium posts you’re criticizing. It’s not perfect tech, but some of us are integrating it into real production workflows and seeing tangible gains, more code shipped, less fatigue, same standards. If that’s a “low bar,” maybe your expectations have shifted.
  - mexicocitinluez 1y ago
    > Yes, but these lax expectation s are what I don't understand. It's pretty a really, really simple concept. If I have a crazy Typescript error, for instance, I can throw it in and get a much better idea of what's happening. Just because that's not perfect, doesn't mean it isn't helpful. Even if it works 90% of the time, it's still better than 0% of the time (Which is where I was at before). It's like google search without ads and with the ability to compose different resources together. If that's not useful to you, then I don't know what to tell you.
    - tcfhgj 1y ago
      Google search without ads... uBlock Origin
      - mexicocitinluez 1y ago
        how does that help compose the results?
  - UncleEntity 1y ago
    Hell, AI is probably -1x for me because I refuse to give up and do it myself instead of trying to get the robots to do it. I mean, writing code is for the monkeys, right? Anyhoo... I find that there are times where you have to really get in there and question the robot's assumptions as they will keep making the same mistake over and over until you truly understand what it is they are actually trying to accomplish. A lot of times the desired goal and their goal are different enough to cause extreme frustration as one tends to think the robot's goal should perfectly align with the prompt. Once it fails a couple times then the interrogation begins since we're not making any further progress, obviously. Case in point, I have this "Operational Semantics" document, which is correct, and a peg VM, which is tested to be correct, but if you combine the two one of the operators was being compiled incorrectly due to the way backtracking works in the VM. After Claude's many failed attempts we had a long discussion and finally tracked down the problem to be something outside of its creative boundaries and it needed one of those "why don't you do it this way..." moments. Sure, I shouldn't have to do this but that's the reality of the tools and, like they say, "a good craftsman never blames his tools".
mritchie712 1y ago
my stance is the opposite of all-or-nothing. The note above is one example. How much value you get out of CURSOR specifically is going to vary based on person & problem. The Python dev in my example might immediately get value out of o3 in ChatGPT. It's not all or nothing. What you get value out of immediately will vary based on circumstance.
- infecto 1y ago
  You say your stance isn’t all-or-nothing, but your original comment drew a pretty hard line, junior devs who start from scratch and have a high tolerance for bugs get 10x productivity, while experienced devs with high standards and mature setups will likely be slowed down. That framing is exactly the kind of binary thinking that’s making these conversations so unproductive.
  - ghufran_syed 1y ago
    I wouldn’t classify this as binary thinking - isnt the comment you are replying just defining boundary conditions? Then those two points don’t define the entire space, but the output there does at least let us infer (but not prove) something about the nature of the “function” between those two points? Where the function f is something like f: experience -> productivity increase?
    - infecto 1y ago
      You’re right that it’s possible to read the original comment as just laying out two boundary conditions—but I think we have to acknowledge how narrative framing shapes the takeaway. The way it’s written leads the reader toward a conclusion: “LLMs are great for junior, fast-shipping devs; less so for experienced, meticulous engineers.” Even if that wasn’t the intent, that’s the message most will walk away with. But they drew boundaries with very specific conditions that lead the reader. It’s a common theme in these AI discussions.
      - mritchie712 1y ago
lelandbatey 1y ago
This doesn't seem like an "all or nothing" take. This person is trying to be clear about their claims, but they're not trying to state these are the only possible takes. Add the word "probably" after each "then" and I image their intended tone becomes a little clearer.
motorest 1y ago
> I get the point you’re trying to make, LLMs can be a force multiplier for less experienced devs, but the sweeping generalizations don’t hold up. If you’re okay with a higher tolerance for bugs or loose guardrails, sure, LLMs can feel magical. But that doesn’t mean they’re less valuable to experienced developers. I think you're trying very hard to pin LLMs as a tool for inexperienced developers. There's a hint of paternalism in them. Back in the real world, LLMs are a tool that excels at generating and updating code based on their context and following your prompts. If you realize this fact, you'll understand that there's nothing in the description that makes them helpful exclusively to "inexperienced" developers. Do experience developers need to refactor code or write new software? Do you believe veteran software engineers are barred from writing proofs of concept? Is the job of pushing architecture changes a junior developer gig? What exactly do you think an experienced developer does? > What frustrates me is how polarized these conversations are. There are valid insights on both sides, but too many posts frame their take as gospel. The reality is more nuanced: LLMs are a tool, not a revolution, and their value depends on how you integrate them into your workflow, regardless of experience level. I completely disagree: LLMs have a revolutionary impact on how software engineers do their job. Your workflows changed overnight. You can create new things faster, you can iterate faster, you can even rewrite whole applications and services in another tech stacks and frameworks in a few days. Things like TDD will become of critical importance as automates test suites are now a critical factor in providing feedback to LLMs. Things are no longer the way they were. At least to those who bothered learning.

mexicocitinluez 1y ago

voidhorse 1y ago
> Amen. Seriously. They're tools. Sometimes they work wonderfully. Sometimes, not so much. But I have DEFINITELY found value. And I've been building stuff for over 15 years as well. Yes, but these lax expectation s are what I don't understand. What other tools in software sometimes work and sometimes don't that you find remotely acceptable? Sure all tools have bugs, but if your compiler had the same failure rate and usability issues as an LLM you'd never use it. Yet for some reason the bar is so low for LLMs. It's insane to me how much people have indulged in the hype koolaid around these tools.
- infecto 1y ago
  My compiler doesn’t write a complete function to visualize a DataFrame based on a vague prompt. It also doesn’t revise that function as I refine the requirements. LLMs can. There’s definitely hype out there, but dismissing all AI use as “koolaid” is as lazy as the Medium posts you’re criticizing. It’s not perfect tech, but some of us are integrating it into real production workflows and seeing tangible gains, more code shipped, less fatigue, same standards. If that’s a “low bar,” maybe your expectations have shifted.
- mexicocitinluez 1y ago
  > Yes, but these lax expectation s are what I don't understand. It's pretty a really, really simple concept. If I have a crazy Typescript error, for instance, I can throw it in and get a much better idea of what's happening. Just because that's not perfect, doesn't mean it isn't helpful. Even if it works 90% of the time, it's still better than 0% of the time (Which is where I was at before). It's like google search without ads and with the ability to compose different resources together. If that's not useful to you, then I don't know what to tell you.
  - tcfhgj 1y ago
    Google search without ads... uBlock Origin
    - mexicocitinluez 1y ago
      how does that help compose the results?
- UncleEntity 1y ago
  Hell, AI is probably -1x for me because I refuse to give up and do it myself instead of trying to get the robots to do it. I mean, writing code is for the monkeys, right? Anyhoo... I find that there are times where you have to really get in there and question the robot's assumptions as they will keep making the same mistake over and over until you truly understand what it is they are actually trying to accomplish. A lot of times the desired goal and their goal are different enough to cause extreme frustration as one tends to think the robot's goal should perfectly align with the prompt. Once it fails a couple times then the interrogation begins since we're not making any further progress, obviously. Case in point, I have this "Operational Semantics" document, which is correct, and a peg VM, which is tested to be correct, but if you combine the two one of the operators was being compiled incorrectly due to the way backtracking works in the VM. After Claude's many failed attempts we had a long discussion and finally tracked down the problem to be something outside of its creative boundaries and it needed one of those "why don't you do it this way..." moments. Sure, I shouldn't have to do this but that's the reality of the tools and, like they say, "a good craftsman never blames his tools".

mritchie712 1y ago

my stance is the opposite of all-or-nothing. The note above is one example. How much value you get out of CURSOR specifically is going to vary based on person & problem. The Python dev in my example might immediately get value out of o3 in ChatGPT. It's not all or nothing. What you get value out of immediately will vary based on circumstance.

infecto 1y ago
You say your stance isn’t all-or-nothing, but your original comment drew a pretty hard line, junior devs who start from scratch and have a high tolerance for bugs get 10x productivity, while experienced devs with high standards and mature setups will likely be slowed down. That framing is exactly the kind of binary thinking that’s making these conversations so unproductive.
- ghufran_syed 1y ago
  I wouldn’t classify this as binary thinking - isnt the comment you are replying just defining boundary conditions? Then those two points don’t define the entire space, but the output there does at least let us infer (but not prove) something about the nature of the “function” between those two points? Where the function f is something like f: experience -> productivity increase?
  - infecto 1y ago
    You’re right that it’s possible to read the original comment as just laying out two boundary conditions—but I think we have to acknowledge how narrative framing shapes the takeaway. The way it’s written leads the reader toward a conclusion: “LLMs are great for junior, fast-shipping devs; less so for experienced, meticulous engineers.” Even if that wasn’t the intent, that’s the message most will walk away with. But they drew boundaries with very specific conditions that lead the reader. It’s a common theme in these AI discussions.
    - mritchie712 1y ago

lelandbatey 1y ago

This doesn't seem like an "all or nothing" take. This person is trying to be clear about their claims, but they're not trying to state these are the only possible takes. Add the word "probably" after each "then" and I image their intended tone becomes a little clearer.

motorest 1y ago

> I get the point you’re trying to make, LLMs can be a force multiplier for less experienced devs, but the sweeping generalizations don’t hold up. If you’re okay with a higher tolerance for bugs or loose guardrails, sure, LLMs can feel magical. But that doesn’t mean they’re less valuable to experienced developers. I think you're trying very hard to pin LLMs as a tool for inexperienced developers. There's a hint of paternalism in them. Back in the real world, LLMs are a tool that excels at generating and updating code based on their context and following your prompts. If you realize this fact, you'll understand that there's nothing in the description that makes them helpful exclusively to "inexperienced" developers. Do experience developers need to refactor code or write new software? Do you believe veteran software engineers are barred from writing proofs of concept? Is the job of pushing architecture changes a junior developer gig? What exactly do you think an experienced developer does? > What frustrates me is how polarized these conversations are. There are valid insights on both sides, but too many posts frame their take as gospel. The reality is more nuanced: LLMs are a tool, not a revolution, and their value depends on how you integrate them into your workflow, regardless of experience level. I completely disagree: LLMs have a revolutionary impact on how software engineers do their job. Your workflows changed overnight. You can create new things faster, you can iterate faster, you can even rewrite whole applications and services in another tech stacks and frameworks in a few days. Things like TDD will become of critical importance as automates test suites are now a critical factor in providing feedback to LLMs. Things are no longer the way they were. At least to those who bothered learning.