4 ms·

And after 12 months, most probably no one from your team will understand what the result of half of those bugs is. When devs outsource their thinking to AI, th

And after 12 months, most probably no one from your team will understand what the result of half of those bugs is. When devs outsource their thinking to AI, they lose the mental map, and without it, control over the entire system.

Dig1t 8mo ago
Only if they are supremely lazy. It’s possible to use these tools in a diligent way, where you maintain understanding and control of the system but outsource the implementation of tasks to the LLM. An engineer should be code reviewing every line written by an LLM, in the same way that every line is normally code reviewed when written by a human. Maybe this changes the original argument from software being “free”, but we could just change that to mean “super cheap”.
- collinvandyck76 8mo ago
  There's a pretty big difference between the understanding that comes with reviewing code versus writing it, for most people I think.
  - deleted 8mo ago
    [deleted]
  - macintux 8mo ago
    Definitely true for me. What’s particularly problematic is code I need to review but can’t effectively test due to environmental challenges.
    - mapontosevenths 8mo ago
      Thats a tough situation. How do you handle the testing with human code?
      - macintux 8mo ago
        Just as poorly.
- mapontosevenths 8mo ago
  > An engineer should be code reviewing every line written by an LLM, I disagree. Instead, a human should be reviewing the LLM generated unit tests to ensure that they test for the right thing. Beyond that, YOLO. If your architecture makes testing hard build a better one. If your tests arent good enough make the AI write better ones.
  - jddj 8mo ago
    The venn diagram for "bad things an LLM could decide are a good idea" and "things you'll think to check that it tests for" has very little overlap. The first circle includes, roughly, every possible action. And the second is tiny. Just read the code.
  - kavok 8mo ago
    It’s amazing how often an LLM mocks or stubs some code and then writes a test that only checks the mock, which ends up testing nothing.
    - mapontosevenths 8mo ago
      You really do have to verify and validate the tests. Worse you have to constantly battle the thing trying to cheat at the tests or bypass them completely. But once you figure that out, it's pretty effective.
    - Dig1t 8mo ago
      I have seen junior engineers do this on multiple occasions. This is why all code should be reviewed by experienced engineers, whether written by a human or an LLM.
  - sarchertech 8mo ago
    There’s no way you or the AI wrote tests to cover everything you care about. If you did, the tests would be at least as complicated as the code (almost certainly much more so), so looking at the tests isn’t meaningfully easier than looking at the code. If you didn’t, any functionality you didn’t test is subject to change every time the AI does any work at all. As long as AIs are either non-deterministic or chaotic (suffer from prompt instability, the code is the spec. Non determinism is probably solvable, but prompt instability is a much harder problem.
- vips7L 8mo ago
  The majority of devs I meet are extremely lazy. It’s why so many people are outsourcing their jobs to Claude.
collinvandyck76 8mo ago
I think about this a lot, and do everything I can to avoid having Claude write production code while keeping the expected tempo up. To date, this has mostly ended up having me use it to write project plans, generate walkthroughs, and write unit and integration tests. The terrifying scenario for me is getting paged and then not being able to actually reason about what is happening.
- sixtyj 8mo ago
  Anything bigger in context? Unfortunately - maybe I have bad luck… But I don’t get how they code in Anthropic when they say that almost all their new code is written by LLM. Do they have some internal much smarter model that they keep in secret and don’t sell it to customers? :)
  - ponector 8mo ago
    >> when they say that almost all their new code is written by LLM. Kepping in mind they are trying hard to sell their code assistant what else they can say? Goal is simple: just lie your way forward to the next VC funding round.
- Voultapher 8mo ago
  I find that writing good tests is my ticket to understanding the problem in depth, be careful about outsourcing that part. Plus from what I have seen LLM generated tests are often low quality.
XenophileJKO 8mo ago
I find this such a weird stance to take. Every system I work on and bug I fix has broad sets of code that I didn't write in it. Often I didn't write any of the code I am debugging. You have to be able to build a mental map as you go even without ai.
- whynotminot 8mo ago
  Yeah. Everyone sort of assumes that not having personally written the code means they can’t debug it. When is the last time you had an on call blow up that was actually your code? Not that I’m some savant of code writing — but for me, pretty much never. It’s always something I’ve never touched that blows up on my Saturday night when I’m on call. Turns out it doesn’t really change much if it’s Sam who wrote it … or Claude.
  - croes 8mo ago
    The problem is you lose abilities if stop writing code completely. There is a difference between a lector and an author
  - geetee 8mo ago
    "hey coworker, I know your team wrote this, can you help?" Except there is no coworker, just Claude
    - crazygringo 8mo ago
      "Yeah our team wrote it but everyone who built that part of it has moved to different teams or companies since."
      - geetee 8mo ago
        Yeah it happens, and it's not ideal, and now instead of a risk, it's a guarantee.
        crazygringo 8mo ago
zarzavat 8mo ago
I agree, but you don't have to outsource your thinking to AI in order to benefit from AI. Use AI as a sanity check on your thinking. Use it to search for bugs. Use it to fill in the holes in your knowledge. Use it to automate grunt work, free your mind and increase your focus. There are so many ways that AI can be beneficial while staying in full control. I went through an experimental period of using Claude for everything. It's fun but ultimately the code it generates is garbage. I'm back to hand writing 90% of code (not including autocomplete). You can still find effective ways to use this technology while keeping in mind its limitations.
- deleted 8mo ago
  [deleted]
deleted 8mo ago
[deleted]
jimmaswell 8mo ago
The better the code is, the less detailed a mental map is required. It's a bad sign if you need too much deep knowledge of multiple subsystems and their implementation details to fix one bug without breaking everything. Conversely, if drive-by contributors can quickly figure out a bug they're facing and write a fix by only examining the place it happens with minimal global context, you've succeeded at keeping your code loosely-coupled with clear naming and minimal surprises.
broast 8mo ago
Don't they eventually become managers and tech leads anyway and outsource to their staff?
qudat 8mo ago
100% agree. I’ve seen it with my own sessions with code agents. You gain speed in the beginning but lose all context on the implementation which forces you to use agents more. It’s easy to see the immediate speed boost, it’s much harder to see how much worse maintaining this code will be over time. What happens when everyone in a meeting about implementing a feature has to say “I don’t know we need to consult CC”. That has a negative impact on planning and coordination.

Dig1t 8mo ago

Only if they are supremely lazy. It’s possible to use these tools in a diligent way, where you maintain understanding and control of the system but outsource the implementation of tasks to the LLM. An engineer should be code reviewing every line written by an LLM, in the same way that every line is normally code reviewed when written by a human. Maybe this changes the original argument from software being “free”, but we could just change that to mean “super cheap”.

collinvandyck76 8mo ago
There's a pretty big difference between the understanding that comes with reviewing code versus writing it, for most people I think.
- deleted 8mo ago
  [deleted]
- macintux 8mo ago
  Definitely true for me. What’s particularly problematic is code I need to review but can’t effectively test due to environmental challenges.
  - mapontosevenths 8mo ago
    Thats a tough situation. How do you handle the testing with human code?
    - macintux 8mo ago
      Just as poorly.
mapontosevenths 8mo ago
> An engineer should be code reviewing every line written by an LLM, I disagree. Instead, a human should be reviewing the LLM generated unit tests to ensure that they test for the right thing. Beyond that, YOLO. If your architecture makes testing hard build a better one. If your tests arent good enough make the AI write better ones.
- jddj 8mo ago
  The venn diagram for "bad things an LLM could decide are a good idea" and "things you'll think to check that it tests for" has very little overlap. The first circle includes, roughly, every possible action. And the second is tiny. Just read the code.
- kavok 8mo ago
  It’s amazing how often an LLM mocks or stubs some code and then writes a test that only checks the mock, which ends up testing nothing.
  - mapontosevenths 8mo ago
    You really do have to verify and validate the tests. Worse you have to constantly battle the thing trying to cheat at the tests or bypass them completely. But once you figure that out, it's pretty effective.
  - Dig1t 8mo ago
    I have seen junior engineers do this on multiple occasions. This is why all code should be reviewed by experienced engineers, whether written by a human or an LLM.
- sarchertech 8mo ago
  There’s no way you or the AI wrote tests to cover everything you care about. If you did, the tests would be at least as complicated as the code (almost certainly much more so), so looking at the tests isn’t meaningfully easier than looking at the code. If you didn’t, any functionality you didn’t test is subject to change every time the AI does any work at all. As long as AIs are either non-deterministic or chaotic (suffer from prompt instability, the code is the spec. Non determinism is probably solvable, but prompt instability is a much harder problem.
vips7L 8mo ago
The majority of devs I meet are extremely lazy. It’s why so many people are outsourcing their jobs to Claude.

collinvandyck76 8mo ago

I think about this a lot, and do everything I can to avoid having Claude write production code while keeping the expected tempo up. To date, this has mostly ended up having me use it to write project plans, generate walkthroughs, and write unit and integration tests. The terrifying scenario for me is getting paged and then not being able to actually reason about what is happening.

sixtyj 8mo ago
Anything bigger in context? Unfortunately - maybe I have bad luck… But I don’t get how they code in Anthropic when they say that almost all their new code is written by LLM. Do they have some internal much smarter model that they keep in secret and don’t sell it to customers? :)
- ponector 8mo ago
  >> when they say that almost all their new code is written by LLM. Kepping in mind they are trying hard to sell their code assistant what else they can say? Goal is simple: just lie your way forward to the next VC funding round.
Voultapher 8mo ago
I find that writing good tests is my ticket to understanding the problem in depth, be careful about outsourcing that part. Plus from what I have seen LLM generated tests are often low quality.

XenophileJKO 8mo ago

I find this such a weird stance to take. Every system I work on and bug I fix has broad sets of code that I didn't write in it. Often I didn't write any of the code I am debugging. You have to be able to build a mental map as you go even without ai.

whynotminot 8mo ago
Yeah. Everyone sort of assumes that not having personally written the code means they can’t debug it. When is the last time you had an on call blow up that was actually your code? Not that I’m some savant of code writing — but for me, pretty much never. It’s always something I’ve never touched that blows up on my Saturday night when I’m on call. Turns out it doesn’t really change much if it’s Sam who wrote it … or Claude.
- croes 8mo ago
  The problem is you lose abilities if stop writing code completely. There is a difference between a lector and an author
- geetee 8mo ago
  "hey coworker, I know your team wrote this, can you help?" Except there is no coworker, just Claude
  - crazygringo 8mo ago
    "Yeah our team wrote it but everyone who built that part of it has moved to different teams or companies since."
    - geetee 8mo ago
      Yeah it happens, and it's not ideal, and now instead of a risk, it's a guarantee.
      - crazygringo 8mo ago

zarzavat 8mo ago

I agree, but you don't have to outsource your thinking to AI in order to benefit from AI. Use AI as a sanity check on your thinking. Use it to search for bugs. Use it to fill in the holes in your knowledge. Use it to automate grunt work, free your mind and increase your focus. There are so many ways that AI can be beneficial while staying in full control. I went through an experimental period of using Claude for everything. It's fun but ultimately the code it generates is garbage. I'm back to hand writing 90% of code (not including autocomplete). You can still find effective ways to use this technology while keeping in mind its limitations.

deleted 8mo ago
[deleted]

deleted 8mo ago

[deleted]

jimmaswell 8mo ago

The better the code is, the less detailed a mental map is required. It's a bad sign if you need too much deep knowledge of multiple subsystems and their implementation details to fix one bug without breaking everything. Conversely, if drive-by contributors can quickly figure out a bug they're facing and write a fix by only examining the place it happens with minimal global context, you've succeeded at keeping your code loosely-coupled with clear naming and minimal surprises.

broast 8mo ago

Don't they eventually become managers and tech leads anyway and outsource to their staff?

qudat 8mo ago

100% agree. I’ve seen it with my own sessions with code agents. You gain speed in the beginning but lose all context on the implementation which forces you to use agents more. It’s easy to see the immediate speed boost, it’s much harder to see how much worse maintaining this code will be over time. What happens when everyone in a meeting about implementing a feature has to say “I don’t know we need to consult CC”. That has a negative impact on planning and coordination.