Developing with GitHub Copilot Agent Mode and MCP

Why not? This is a translation problem so right up its alley.

Give it tool access to communicate directly with stakeholders (via email or chat) and put it in a loop to work with them until the goal is reached (stakeholders are happy). Same as a human would do.

And of course it will still need some steering by a "manager" to make sure it's building the right things.

They use the technology, they make the decisions about technology (like which cameras to use), and they literally can't do their work without the tech —

— they better be at list a little "technical" for their own sake.

The idea of knowing your gear has nothing to do with artistry. This is my rifle. There are many like it, but this one is mine.

And if they're "not known for being technical", they better consult someone who is (that is, you) before making decisions about technology (like choosing equipment for the job).

The problem here wasn't their lack of technical expertise.

The problem was the artists suddenly showing up one day with strange equipment.

The solution here is asking the artists to check in with you about gear as soon as they are signed up, and talking to you BEFORE getting new gear.

That's it. They don't have to be more technical. They need to help you help them.

You said it yourself that this would not have been a problem for you without Claude if you had more time to deal with it.

The problem was a lack of advance warning. And it's a solvable problem.

These artists might not have been divas before that residency.

But the policy of not having to consult the tech before bringing in gear and expecting it to just work, on zero notice, while remaining "not technical" — that turns them into divas.

If they are not making these demands, who does?

If that's you, that sounds rather masochistic. In which case using Claude to dull the pain seems rather counterproductive in the short term.

Seriously though, Claude isn't a solution for setting expectations and communication, which is the real problem here.

You could've still used Claude to write that driver. But you could have also had the several days to do it, and it wouldn't be an example of Claude saves the day any more.

Or — better yet — you could've given the artists a chance to reconsider their gear choices.

There might not have been a reason why they picked that gear in the first place instead of one you could've worked with easily (did you ask?).

You didn't enable the artists to do their job. You enabled them to make uninformed gear decisions.

That's not helping them in the long term; it's just setting them up for failure. Claude can't code around an API that isn't there, or a hardware incompatibility.

And that's before we get to the most important aspect of art: limitation breeds creativity. This sort of babysitting isn't helping the art either.

If the goal is to help them develop as artists, then it seems you're accomplishing the opposite.

Have you at least told them that they've created a problem for you? They'd want to know that. People usually don't want to create problems for others.

As for me — I'm chill AF in the first place; and I'm not against using chatbots to solve problems — it's just that I'm not convinced that Claude is the right LLM to use here.

Perhaps asking ChatGPT about this situation, and how to talk to artists (and shape the equipment policy for your space) would do much more impact on the problem you said is recurring on a weekly basis than using Claude to put more bandaids on a pile of bandaids.

If you're somehow under the belief that LLMs will (or should) magically replace a person, I think you've built the wrong understanding of what LLMs are and what they can do.

When you read the manual page for a program, or the documentation for a library, the things described always (99.99999...%) exist. So I can take it as objective truth. The description may be lacking, so I don't have a complete picture, but it's not pure fantasy. And if it turns out that it is, the solution is to drop it and turn back.

So when I act upon it, and the result comes back, I question my approach, not the information. And often I find the flaw quickly. It's slower initially, but the final result is something I have good confidence in.

I'm not sure if you've ever worked in a "creative" environment filled with artists, either professionally or not, but the goal is almost never to come up with a solution that is technological superior or even "correct", it just have to work for the session, maybe two.

If you're a technical contributor to such an environment, then your "job" is basically to support their whims, that's how the project moves forward. Saying "no" when an artist approaches you isn't really in the job requirements, but of course you can steer them into a different direction, but ultimately they steer the ship, and they have to.

But ultimately your job in those cases are to support the vision of someone else, often by any means necessary and fast too.