4 ms·

I don't think that's universally true. We have different humans with different levels of ability to catch errors. I see that with my teams. Some people can debu

I don't think that's universally true. We have different humans with different levels of ability to catch errors. I see that with my teams. Some people can debug. Some can't. Some people can write tests. Some can't. Some people can catch stuff in reviews. Some can't. I asked Sonnet 3.7 in Cursor to fix a failing test. While it made the necessary fix, it also updated a hard-coded expected constant to instead be computed using the same algorithm as the original file, instead of preserving the constant as the test was originally written. Guess what? Guess the number of times I had to correct this from humans doing it in their tests over my career! And guess where the models learned the bad behavior from.

__MatrixMan__ 2y ago
I agree. I've been been struck by how remarkably understandable the errors are. It's quite often something that I'd have done myself if I wasn't paying attention to the right thing.
fn-mote 2y ago
> Some people can debug. Some can't. Some people can write tests. Some can't. Wait… really? No way do I want to work with someone who can’t debug or write tests. I thought those were entry stakes to the profession. People whose skills you use in other ways because they are more productive? Maybe. But still. Clean up after yourself. It’s something that should be learned in the apprentice phase.
- hobs 2y ago
  Keyword want - most people don't control who their peers are, and complaining to your boss doesn't get you that far, especially when said useless boss is fostering said useless person.
- tharkun__ 2y ago
  Like my sibling says, you can't always choose. That's one side of that coin. The other is: Some people are naturally good at writing "green field" (or re-writing everything) and do produce actual good software. But these same people, which you do want to keep around if that's the best you can get, are next to useless when you throw a customer reported bug at them. Takes them ages to figure anything out and they go down endless rabbit holes chasing the wrong path for hours. You also have people that are super awesome at debugging. They have knack for seeing some brokenness and having the right idea or an idea of the right direction to investigate in right away, can apply the scientific method to test their theories and have the bug fixed in the time it take one of these other people to go down even a single of the rabbit holes they will go down. But these same people in some cases are next to useless if you ask them to properly structure a new green field feature or rewrite parts of something to use some new library coz the old one is no longer maintained or something and digging through said new library and how it works. Both of these types of people are not bad in and of themselves. Especially if you can't get the unicorns that can do all of these things well (or well enough), e.g. because your company can't or won't pay for it or only for a few of them, which they might call "Staff level". And you'd be amazed how easy it is to get quite a few review comments in for even Staff level people if you basically ignore their actual code and just jump right into the tests. It's a pet peeve of mine. I start with the tests and go from there when reviewing :) What you really don't want is if someone is not good at any of these of course.
- groby_b 2y ago
  > No way do I want to work with someone who can’t debug or write tests. I thought those were entry stakes to the profession. Those are almost entry stakes at tier-one companies. (There are still people who can't, it's just much less common) In your average CRUD/enterprise automation/one-off shellscript factory, the state of skills is... not fun. There's a reason there's the old saw of "some people have twenty years experience, some have the same year 20 times over". People learn & grow when they are challenged to, and will mostly settle at acquiring the minimum skill level that lets them do their particular work. And since we as an industry decided to pretend we're a "science", not skills based, we don't have a decent apprenticeship system that would force a minimum bar. And whenever we discuss LLMs and how they might replace software engineering, I keep remembering that they'll be prompted by the people who set that hiring bar and thought they did well.
- david422 2y ago
  I worked with a new co-worker that ... had trouble writing code, and tests. He would write a test that tested nothing. At first I thought he might be green and just needed some direction - we all start somewhere. But he had on his bio that he had 10 years of experience in software dev in the language we were working in. I couldn't quite figure out what the disconnect was, he ended up leaving a short time later.
  - nurettin 2y ago
    I've worked with these sorts of people. It is never clear why they don't perform. One of them had clinical depression, another claimed to have low blood values that they simply couldn't fix. And one other just didn't seem to have any working memory beyond one sentence for whatever reason. Do people become like that? Are we going to become like that? It is a scary thought.
- ipsento606 2y ago
  I've been a professional engineer for over a decade, and in that time I've only had one position where I was expected to write any tests. All my other positions, we have no automated testing of any kind.
- 30minAdayHN 2y ago
  Little tangent: I realized that currently LLMs can't debug because they only have access to the compile time (just code). Many bugs happen due to run time complex state. If I can make LLMs think like a productive Dev who can debug, then would they become more efficient? I started hacking a small prototype along those lines: https://github.com/hyperdrive-eng/mcp-nodejs-debugger https://github.com/hyperdrive-eng/mcp-nodejs-debugger Hoping I can avoid debug death loop where I get into this bad loop of copy pasting the error and hoping LLM would get it right this one time :)
  - _ea1k 2y ago
    Yeah, IMO this is also why they can be so terrible at UI. They don't really have a feedback loop for a lot of code related issues yet. This is changing and I really expect everything to be different 12 months from now.
    - 30minAdayHN 2y ago
      In general, the theme I'm seeing is that we are providing the old tools to a new way of software engineering. Similar to you, I think the abstractions and tools we will work with will be radically different. Some things I am thinking about: * Does git make sense if the code is not the abstraction you work with? For example, when I'm vibe coding, my friend is spending 3hrs trying to understand what I did by reading code. Instead, he should be reading all my chat interactions. So I wonder if there is a new version control paradigm * Logging: Can we auto instrument logging into frameworks that will be fed to LLMs * Architecture: Should we just view code as bunch of blocks and interactions instead of reading actual LOC. What if, all I care is block diagrams. And I tell tools like cursor, implement X by adding Y module.
      - tharkun__ 2y ago
        Regarding reading all your chat interactions I'd find that a really tedious way to understand what the code will actually be doing. You might have "vibe coded" for 3 hours, resulting in a bunch of code I can read and understand in a half hour just as well. And I'm not interested in all the "in between" where you're correcting the LLM misunderstanding etc. I only care about the result and whether it does the right thing(s) and whether the code is readable. If the use of an LLM results in hard to understand spaghetti code that hides intent then I think that's a really bad thing and is why the code should still go through code review. If you, with or without the help of an LLM create bad code, that's still bad code. And without the code and just the chat history we have no idea what we even actually get in the end.
skerit 2y ago
Claude Sonnet 3.7 really, really loves to rewrite tests so they'll pass. I've had it happen many times in a claude-code session, I had to add this to each request (though it did not fix it 100%) - Never disable, skip, or comment out failing unit tests. If a unit test fails, fix the root cause of the exception. - Never change the unit test in such a way that it avoids testing the failing feature (e.g., by removing assertions, adding empty try/catch blocks, or making tests trivial). - Do not mark tests with @Ignore or equivalent annotations. - Do not introduce conditional logic that skips test cases under certain conditions. - Always ensure the unit test continues to properly validate the intended functionality.
- _ea1k 2y ago
  I'm guessing this is a side effect of mistakes in the reinforcement learning face. It'd be really easy to build a reward model that favors passing tests, without properly measuring the quality of those tests.

__MatrixMan__ 2y ago

I agree. I've been been struck by how remarkably understandable the errors are. It's quite often something that I'd have done myself if I wasn't paying attention to the right thing.

fn-mote 2y ago

> Some people can debug. Some can't. Some people can write tests. Some can't. Wait… really? No way do I want to work with someone who can’t debug or write tests. I thought those were entry stakes to the profession. People whose skills you use in other ways because they are more productive? Maybe. But still. Clean up after yourself. It’s something that should be learned in the apprentice phase.

hobs 2y ago
Keyword want - most people don't control who their peers are, and complaining to your boss doesn't get you that far, especially when said useless boss is fostering said useless person.
tharkun__ 2y ago
Like my sibling says, you can't always choose. That's one side of that coin. The other is: Some people are naturally good at writing "green field" (or re-writing everything) and do produce actual good software. But these same people, which you do want to keep around if that's the best you can get, are next to useless when you throw a customer reported bug at them. Takes them ages to figure anything out and they go down endless rabbit holes chasing the wrong path for hours. You also have people that are super awesome at debugging. They have knack for seeing some brokenness and having the right idea or an idea of the right direction to investigate in right away, can apply the scientific method to test their theories and have the bug fixed in the time it take one of these other people to go down even a single of the rabbit holes they will go down. But these same people in some cases are next to useless if you ask them to properly structure a new green field feature or rewrite parts of something to use some new library coz the old one is no longer maintained or something and digging through said new library and how it works. Both of these types of people are not bad in and of themselves. Especially if you can't get the unicorns that can do all of these things well (or well enough), e.g. because your company can't or won't pay for it or only for a few of them, which they might call "Staff level". And you'd be amazed how easy it is to get quite a few review comments in for even Staff level people if you basically ignore their actual code and just jump right into the tests. It's a pet peeve of mine. I start with the tests and go from there when reviewing :) What you really don't want is if someone is not good at any of these of course.
groby_b 2y ago
> No way do I want to work with someone who can’t debug or write tests. I thought those were entry stakes to the profession. Those are almost entry stakes at tier-one companies. (There are still people who can't, it's just much less common) In your average CRUD/enterprise automation/one-off shellscript factory, the state of skills is... not fun. There's a reason there's the old saw of "some people have twenty years experience, some have the same year 20 times over". People learn & grow when they are challenged to, and will mostly settle at acquiring the minimum skill level that lets them do their particular work. And since we as an industry decided to pretend we're a "science", not skills based, we don't have a decent apprenticeship system that would force a minimum bar. And whenever we discuss LLMs and how they might replace software engineering, I keep remembering that they'll be prompted by the people who set that hiring bar and thought they did well.
david422 2y ago
I worked with a new co-worker that ... had trouble writing code, and tests. He would write a test that tested nothing. At first I thought he might be green and just needed some direction - we all start somewhere. But he had on his bio that he had 10 years of experience in software dev in the language we were working in. I couldn't quite figure out what the disconnect was, he ended up leaving a short time later.
- nurettin 2y ago
  I've worked with these sorts of people. It is never clear why they don't perform. One of them had clinical depression, another claimed to have low blood values that they simply couldn't fix. And one other just didn't seem to have any working memory beyond one sentence for whatever reason. Do people become like that? Are we going to become like that? It is a scary thought.
ipsento606 2y ago
I've been a professional engineer for over a decade, and in that time I've only had one position where I was expected to write any tests. All my other positions, we have no automated testing of any kind.
30minAdayHN 2y ago
Little tangent: I realized that currently LLMs can't debug because they only have access to the compile time (just code). Many bugs happen due to run time complex state. If I can make LLMs think like a productive Dev who can debug, then would they become more efficient? I started hacking a small prototype along those lines: https://github.com/hyperdrive-eng/mcp-nodejs-debugger https://github.com/hyperdrive-eng/mcp-nodejs-debugger Hoping I can avoid debug death loop where I get into this bad loop of copy pasting the error and hoping LLM would get it right this one time :)
- _ea1k 2y ago
  Yeah, IMO this is also why they can be so terrible at UI. They don't really have a feedback loop for a lot of code related issues yet. This is changing and I really expect everything to be different 12 months from now.
  - 30minAdayHN 2y ago
    In general, the theme I'm seeing is that we are providing the old tools to a new way of software engineering. Similar to you, I think the abstractions and tools we will work with will be radically different. Some things I am thinking about: * Does git make sense if the code is not the abstraction you work with? For example, when I'm vibe coding, my friend is spending 3hrs trying to understand what I did by reading code. Instead, he should be reading all my chat interactions. So I wonder if there is a new version control paradigm * Logging: Can we auto instrument logging into frameworks that will be fed to LLMs * Architecture: Should we just view code as bunch of blocks and interactions instead of reading actual LOC. What if, all I care is block diagrams. And I tell tools like cursor, implement X by adding Y module.
    - tharkun__ 2y ago
      Regarding reading all your chat interactions I'd find that a really tedious way to understand what the code will actually be doing. You might have "vibe coded" for 3 hours, resulting in a bunch of code I can read and understand in a half hour just as well. And I'm not interested in all the "in between" where you're correcting the LLM misunderstanding etc. I only care about the result and whether it does the right thing(s) and whether the code is readable. If the use of an LLM results in hard to understand spaghetti code that hides intent then I think that's a really bad thing and is why the code should still go through code review. If you, with or without the help of an LLM create bad code, that's still bad code. And without the code and just the chat history we have no idea what we even actually get in the end.

skerit 2y ago

Claude Sonnet 3.7 really, really loves to rewrite tests so they'll pass. I've had it happen many times in a claude-code session, I had to add this to each request (though it did not fix it 100%) - Never disable, skip, or comment out failing unit tests. If a unit test fails, fix the root cause of the exception. - Never change the unit test in such a way that it avoids testing the failing feature (e.g., by removing assertions, adding empty try/catch blocks, or making tests trivial). - Do not mark tests with @Ignore or equivalent annotations. - Do not introduce conditional logic that skips test cases under certain conditions. - Always ensure the unit test continues to properly validate the intended functionality.

_ea1k 2y ago
I'm guessing this is a side effect of mistakes in the reinforcement learning face. It'd be really easy to build a reward model that favors passing tests, without properly measuring the quality of those tests.