I disagree with those points. It brought up that monkey patching has downsides with an explanation, and elaborated when asked what they were.
Here's a relevant paragraph
> That said, it's crucial to understand that monkeypatching can make your tests harder to understand and maintain if used excessively or improperly. When you monkeypatch, you're essentially altering the normal behavior of your code. This can lead to situations where tests pass because of the specific setup in the test and not because the actual code is correct, making it less effective at catching real bugs.
More than that, I could instead tell it at the start to tell me the questions I should ask as followups, here's the list when I told it I think I need to use monkeypatching:
1. When is it appropriate to use monkeypatching and when should I avoid it?
2. What are some common pitfalls or mistakes to avoid when using monkeypatching?
3. Can you give me more examples of how to properly use monkeypatching?
4. Are there any other techniques or tools for mocking or stubbing that I should consider?
I could then just say "answer those". No prompting about assuming downsides or problems.
I agree on point one but it's a very easy lesson to learn - try telling it that it's a pirate. It's also not actually required because someone like me can create the persona prompting and then everyone else can just use it. I'm not subtly crafting a weird prompt, it's just telling it who to be for the most part.
> my fear is that one day in the not too distant future, far fewer people will be around with that knowledge, because we’ve slowed the “senior engineer pipeline” down to a trickle through the use of these tools.
On the other side, what we have here is potentially an infinitely patient, always available mentor. You don't have to crash through mistakes on your own to learn, though some lessons are learned harder because of that.
Here's a relevant paragraph
> That said, it's crucial to understand that monkeypatching can make your tests harder to understand and maintain if used excessively or improperly. When you monkeypatch, you're essentially altering the normal behavior of your code. This can lead to situations where tests pass because of the specific setup in the test and not because the actual code is correct, making it less effective at catching real bugs.
More than that, I could instead tell it at the start to tell me the questions I should ask as followups, here's the list when I told it I think I need to use monkeypatching:
1. When is it appropriate to use monkeypatching and when should I avoid it?
2. What are some common pitfalls or mistakes to avoid when using monkeypatching?
3. Can you give me more examples of how to properly use monkeypatching?
4. Are there any other techniques or tools for mocking or stubbing that I should consider?
I could then just say "answer those". No prompting about assuming downsides or problems.
I agree on point one but it's a very easy lesson to learn - try telling it that it's a pirate. It's also not actually required because someone like me can create the persona prompting and then everyone else can just use it. I'm not subtly crafting a weird prompt, it's just telling it who to be for the most part.
> my fear is that one day in the not too distant future, far fewer people will be around with that knowledge, because we’ve slowed the “senior engineer pipeline” down to a trickle through the use of these tools.
On the other side, what we have here is potentially an infinitely patient, always available mentor. You don't have to crash through mistakes on your own to learn, though some lessons are learned harder because of that.