4 ms·

I'm firmly in the LLM fanbase. Not because I can't type code (was doing it for over 17 years, everywhere from low level hardware drivers in C to web frontend to

I'm firmly in the LLM fanbase. Not because I can't type code (was doing it for over 17 years, everywhere from low level hardware drivers in C to web frontend to robot development at home as a hobby - coding is fun!), but because in my profession it allows me to focus more on the abstraction layer where "it matters". I'm not saying that I'm no longer dealing with code at all though. The way I work is interactively with the LLM and pretty much tell it exactly what to do and how to do it. Sometimes all the way down to "don't copy the reference like that, grab a deep copy of the object instead". Just like with any other type of programming, the only way to achieve valuable and correct results is by knowing exactly what you want and express that exactly and without ambiguity. But I no longer need to remember most of the syntax for the language I happen to work with at the moment, and can instead spend time thinking about the high level architecture. To make sure each involved component does one thing and one thing well, with its complexities hidden behind clear interfaces. Engineers who refuse to, or can't, or won't utilize the benefits that LLMs bring will be left behind. It's just the way it is. I'm already seeing it happening.

deleted 5mo ago
[deleted]
ap99 5mo ago
This mindset is fine (it's mine essentially too). But it absolutely has to be combined with verification/testing at the same speed as code production.
- dgellow 5mo ago
  I generally do have that mindset, but over the past 1y of Claude code I do notice that I’m clearly losing my understanding of the internals of projects. I do review LLM generated code, understand it, no problem reading/following through. But then someone asks me a question, and I’m like… wait, I actually don’t know. I remember the instructions I gave and reviewing the code but don’t actually have a fine-details model of the actual implementation crystallized in my mind, I need to check, was that thing implemented the way I thought it was or not? Wait, it’s actually wrong/not matching at all what I thought! It’s definitely becoming uncomfortable and makes me reconsider my use of Claude code pretty significantly
  - vehemenz 5mo ago
    I've had this issue too, and I feel it was an important lesson—kind of like the first time getting a hangover. On the other hand, LLM-generated code comments better than I do, so given a long enough time horizon, it could be more understandable at a later time than code I've written myself (we've all had the experience of forgetting how things work).
    - ori_b 5mo ago
      It's not. Invariably, the code is locally fine and globally nonsense.
      - deleted 5mo ago
        [deleted]
    - thesz 5mo ago
      > On the other hand, LLM-generated code comments better than I do, so given a long enough time horizon, it could be more understandable at a later time than code I've written myself (we've all had the experience of forgetting how things work). Writing and rewriting piece of software performs what is called "spaced repetition" [1]. [1] https://en.wikipedia.org/wiki/Spaced_repetition https://en.wikipedia.org/wiki/Spaced_repetition You ask questions about code when you implement something and if you cannot answer these questions, you go to code to find answers out and refresh your understanding of it. For this to work you have to be interested in the understanding of the code and code should be created at the pace you can keep up. Software engineers usually do create code economically because they need to remember and understand it. Vibe coders do not have this particular constraint, they just do not aim for most understandable code possible. Even if there are more comments in code.
  - toddmerrill 5mo ago
    Same experience. I've been writing code for many decades, but that experience doesn't mean I can remember what I read when reviewing generated code. I write small, focused commits, but I have to take a day off each week to make changes by hand just to mentally keep up with my own codeset knowledge, and I still find structures that surprise me. It's not necessarily that the code quality is poor, but it's not like I (thought) I had designed it. It's lead to a weakening of my confidence when adding to or changing existing architecture.
- vehemenz 5mo ago
  One-off tasks and parts of the stack that already have lots of disposable code do not need the same scrutiny as everything else. Just as there is a broad continuum of code importance, there is a broad continuum of testing requirements, and this was the case before AI. Keeping this in mind, AIs can also do some verification and testing, too.
- onlyrealcuzzo 5mo ago
  I've found that for non-trivial features, I typically benefit from 3-4 rounds of: are you sure this isn't tech debt, are you sure this is thoroughly tested for (manually insert the applicable cases, because they aren't great at this, even if explicitly asked), are you sure this isn't re-inventing wheels, adding unnecessary complexity by not using existing infrastructure it should or that other existing code would not benefit from moving to this, are you sure you can't find any bugs, in hind sight, are you sure this is the best design? Then, after it says, yes I'm sure this is production ready and we're good to move on, you have Codex and Gemini both review it one last time, and ask it to address their feedback if it's valuable or not. After all this, it's the only time I'll look at the code and review it and make sure it's coherent. Until then, I assume it's garbage. I'd estimate this still improves velocity by 10x, and more importantly, allows me to operate at a pace I couldn't without burning out.
  - em-bee 5mo ago
    working this way would drive me nuts
    - onlyrealcuzzo 5mo ago
      Why? It's not that different from managing engineers. You're just getting less work done on a slower cadence and asking the questions in design review and in code reviews...
      - em-bee 5mo ago
        it's very different. LLMs don't behave like people. they don't learn. i don't mind managing people, but i don't want to manage machines unless i can control them with the precise languages that the commandline and programming languages use. prompting a LLM is to vague an interface for me, the outcome is to unreliable, to unpredictable.
0xpgm 5mo ago
> Engineers who refuse to, or can't, or won't utilize the benefits that LLMs bring will be left behind. It's just the way it is. I'm already seeing it happening. Any examples how you see some engineers being left behind?
- xyzal 5mo ago
  Probably in cognitive surrender. I have one such colleague and he is driving me crazy. "Claude sad that ..."
- ZaoLahma 5mo ago
  I'm starting to notice how those who don't use AI end up having to hand tasks over to people who can get them done quicker. It is anecdotal for sure, but it's a pattern that seems to be emerging around me that expectations of velocity increases, and those who don't use AI can't keep up.
  - ericjmorey 5mo ago
    Why is velocity the overriding goal?
    - Bridged7756 5mo ago
      Shit processes. I don't know what places most of those people work at that crap is being merged into production at insane pace. You would expect any serious piece of software would be important enough to have the code be reviewed by at least one human. Kind of.... I don't know. To get placed such requirements from the top down and not fight back, just take it head on, not even maliciously, don't even oppose it on a technical basis, just be like "yeah, you've now gotta ship faster or you're left behind, so therefore LLMs must be the future!", no critical thought attached. Is this shit coming from experienced engineers? Preposterous we're relying on "it's better because I feel like", "dudes who don't use it are falling behind at work", "they ask for it in job interviews".
- Quothling 5mo ago
  > Any examples how you see some engineers being left behind? I don't know where you live, but around where I live in Denmark you'd fail for not using AI at a senior interview in a lot of places. Even places which aren't exactly AI fans use AI to some extend. The biggest challenge we face right now is figuring out how you create developers who have enough experience to know how to use the AI tools in a critical manner. Especially because you're typically given agents for various taks, which are already configured to know how we want things to be written.
archagon 5mo ago
Again, I have to point out that AI is not an abstraction layer. It blows my mind that engineers with years of experience somehow don’t understand this. It would be an honor to be “left behind” by people who practice their craft with such carelessness. (Frankly, I should probably stop replying to self-professed LLM boosters entirely since there’s a good chance I’m just chatting with an LLM.)

deleted 5mo ago

[deleted]

ap99 5mo ago

This mindset is fine (it's mine essentially too). But it absolutely has to be combined with verification/testing at the same speed as code production.

dgellow 5mo ago
I generally do have that mindset, but over the past 1y of Claude code I do notice that I’m clearly losing my understanding of the internals of projects. I do review LLM generated code, understand it, no problem reading/following through. But then someone asks me a question, and I’m like… wait, I actually don’t know. I remember the instructions I gave and reviewing the code but don’t actually have a fine-details model of the actual implementation crystallized in my mind, I need to check, was that thing implemented the way I thought it was or not? Wait, it’s actually wrong/not matching at all what I thought! It’s definitely becoming uncomfortable and makes me reconsider my use of Claude code pretty significantly
- vehemenz 5mo ago
  I've had this issue too, and I feel it was an important lesson—kind of like the first time getting a hangover. On the other hand, LLM-generated code comments better than I do, so given a long enough time horizon, it could be more understandable at a later time than code I've written myself (we've all had the experience of forgetting how things work).
  - ori_b 5mo ago
    It's not. Invariably, the code is locally fine and globally nonsense.
    - deleted 5mo ago
      [deleted]
  - thesz 5mo ago
    > On the other hand, LLM-generated code comments better than I do, so given a long enough time horizon, it could be more understandable at a later time than code I've written myself (we've all had the experience of forgetting how things work). Writing and rewriting piece of software performs what is called "spaced repetition" [1]. [1] https://en.wikipedia.org/wiki/Spaced_repetition https://en.wikipedia.org/wiki/Spaced_repetition You ask questions about code when you implement something and if you cannot answer these questions, you go to code to find answers out and refresh your understanding of it. For this to work you have to be interested in the understanding of the code and code should be created at the pace you can keep up. Software engineers usually do create code economically because they need to remember and understand it. Vibe coders do not have this particular constraint, they just do not aim for most understandable code possible. Even if there are more comments in code.
- toddmerrill 5mo ago
  Same experience. I've been writing code for many decades, but that experience doesn't mean I can remember what I read when reviewing generated code. I write small, focused commits, but I have to take a day off each week to make changes by hand just to mentally keep up with my own codeset knowledge, and I still find structures that surprise me. It's not necessarily that the code quality is poor, but it's not like I (thought) I had designed it. It's lead to a weakening of my confidence when adding to or changing existing architecture.
vehemenz 5mo ago
One-off tasks and parts of the stack that already have lots of disposable code do not need the same scrutiny as everything else. Just as there is a broad continuum of code importance, there is a broad continuum of testing requirements, and this was the case before AI. Keeping this in mind, AIs can also do some verification and testing, too.
onlyrealcuzzo 5mo ago
I've found that for non-trivial features, I typically benefit from 3-4 rounds of: are you sure this isn't tech debt, are you sure this is thoroughly tested for (manually insert the applicable cases, because they aren't great at this, even if explicitly asked), are you sure this isn't re-inventing wheels, adding unnecessary complexity by not using existing infrastructure it should or that other existing code would not benefit from moving to this, are you sure you can't find any bugs, in hind sight, are you sure this is the best design? Then, after it says, yes I'm sure this is production ready and we're good to move on, you have Codex and Gemini both review it one last time, and ask it to address their feedback if it's valuable or not. After all this, it's the only time I'll look at the code and review it and make sure it's coherent. Until then, I assume it's garbage. I'd estimate this still improves velocity by 10x, and more importantly, allows me to operate at a pace I couldn't without burning out.
- em-bee 5mo ago
  working this way would drive me nuts
  - onlyrealcuzzo 5mo ago
    Why? It's not that different from managing engineers. You're just getting less work done on a slower cadence and asking the questions in design review and in code reviews...
    - em-bee 5mo ago
      it's very different. LLMs don't behave like people. they don't learn. i don't mind managing people, but i don't want to manage machines unless i can control them with the precise languages that the commandline and programming languages use. prompting a LLM is to vague an interface for me, the outcome is to unreliable, to unpredictable.

0xpgm 5mo ago

> Engineers who refuse to, or can't, or won't utilize the benefits that LLMs bring will be left behind. It's just the way it is. I'm already seeing it happening. Any examples how you see some engineers being left behind?

xyzal 5mo ago
Probably in cognitive surrender. I have one such colleague and he is driving me crazy. "Claude sad that ..."
ZaoLahma 5mo ago
I'm starting to notice how those who don't use AI end up having to hand tasks over to people who can get them done quicker. It is anecdotal for sure, but it's a pattern that seems to be emerging around me that expectations of velocity increases, and those who don't use AI can't keep up.
- ericjmorey 5mo ago
  Why is velocity the overriding goal?
  - Bridged7756 5mo ago
    Shit processes. I don't know what places most of those people work at that crap is being merged into production at insane pace. You would expect any serious piece of software would be important enough to have the code be reviewed by at least one human. Kind of.... I don't know. To get placed such requirements from the top down and not fight back, just take it head on, not even maliciously, don't even oppose it on a technical basis, just be like "yeah, you've now gotta ship faster or you're left behind, so therefore LLMs must be the future!", no critical thought attached. Is this shit coming from experienced engineers? Preposterous we're relying on "it's better because I feel like", "dudes who don't use it are falling behind at work", "they ask for it in job interviews".
Quothling 5mo ago
> Any examples how you see some engineers being left behind? I don't know where you live, but around where I live in Denmark you'd fail for not using AI at a senior interview in a lot of places. Even places which aren't exactly AI fans use AI to some extend. The biggest challenge we face right now is figuring out how you create developers who have enough experience to know how to use the AI tools in a critical manner. Especially because you're typically given agents for various taks, which are already configured to know how we want things to be written.

archagon 5mo ago

Again, I have to point out that AI is not an abstraction layer. It blows my mind that engineers with years of experience somehow don’t understand this. It would be an honor to be “left behind” by people who practice their craft with such carelessness. (Frankly, I should probably stop replying to self-professed LLM boosters entirely since there’s a good chance I’m just chatting with an LLM.)