[IanCal]

I told it that it was a senior engineer and I was a random client and asked the same thing. It explained what monkey patching was for, creates an example where a function pulls from an API and we patch it. Depending on runs or prompts you can see more or less explanation. I like getting it to first reason about its role and task, then it has that in its context when replying.

Have you tried telling it who it is? You're coming at it with context about how it should act without telling it - it can role play a lot of things. I spoke to a teacher dealing with kids doing their homework too well with it, and showed you can just say "write X as a student with middling English" and get realistic mistakes.

[__loam]

I hate that every time someone adds a nuanced view to these discussions, someone comes in to ask if they're "using it right" and asks them if they're typing words right as if that actually stops this thing from hallucinating bullshit all the time.

[IanCal]

It's fine to not want to learn to use a tool, but it doesn't really add much to the conversation to get angry about people talking about how to use it.

> as if that actually stops this thing from hallucinating bullshit all the time.

This has nothing to do with hallucinations though. It's about giving something a poorly specified problem and then complaining that it gives a valid answer but doesn't act like a particular persona when that persona was not explained. This is a very general problem with a general approach to fixing it. Want it to challenge you on what you're asking it to do? Tell it that.

[__loam]

He never asked you to explain how to use the tool. You're assuming he doesn't know how to use a tool that requires approximately 10 minutes to learn. It's completely patronizing to ignore his point and continue with "Well have you tried.." in a way that fundamentally does not address the issue he's bringing up at all. Your tips and tricks add nothing to the conversation.

[IanCal]

> . You're assuming he doesn't know how to use a tool that requires approximately 10 minutes to learn

That raises the question of why they used it ineffectively in the first place then. They asked it to do something, it did, but they say it misses the point that a senior engineer would spot. My point is that if you want to judge how well it operates in replacing someone you have to actually specify who it's supposed to be imitating. It's not idle speculation, as I said I did this and it worked. Asking it for an example of monkeypatching gave back a proper example, along with a warning about maintainability.

Telling it I was a junior engineer and wanted to use monkeypatching did the same thing. Asking a followup of why I should be so careful with it and what I could do instead it gives explanations about several problems and then a few other approaches. Telling it simply to be a senior and I'm a junior, and that it should come up with followup questions for me it not only explains those problems but gives me the kind of followups a junior should ask but may not know to. Exactly the kind of intuitions about what's going on that are said to be missed here.

So I think the example used is significantly weaker than it appears, and the argument hinges on what GPT4 is lacking.

Now, a very solid response to the problem posed is that if it can approximate a more senior role for discussions it can make junior engineers more effective and teach them those skills.

[Ancapistani]

FYI: I’ve read the whole comment chain under this post before replying

> I told it that it was a senior engineer and I was a random client and asked the same thing.

I’m aware that ChatGPT is capable of performing the task I chose. I agree that it’s a relatively weak example, especially if it was my goal to show that AI can’t do this.

That’s not really what I was trying to show, though. My point is that you knew two things that many/most people probably wouldn’t:

1) That crafting your prompts to get the LLM to adopt a “persona” impacts the results significantly

2) That monkey patching has downsides, and that understanding when it is appropriate is important

I strongly suspect that you knew both of those things because you are a senior engineer yourself. My point is that some level of domain knowledge is necessary to get good results from it; 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.

[IanCal]

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.