[deleted]
Developing with GitHub Copilot Agent Mode and MCP
61–70 of 71 posts
Re: Developing with GitHub Copilot Agent Mode and MCP
#62Earlier quoted context omitted.
the answer was "yes, sure" before AI too. the difference is whether you're going to do overtime staying up to 2AM trying to make things work.
Not in my case. But overstaying, at least here in Europe, is not seen as a good thing, while using AI starts to be encouraged by CTOs and CEOs.
as someone from France this has really, really not been my experience when I think of how many times I had to pull on all-nighters for work because of $deadline.
Re: Developing with GitHub Copilot Agent Mode and MCP
#63Earlier quoted context omitted.
> The experiences seem so different, that I'm having a hard time wrapping my mind around it. Because we only see very disjointed descriptions, with no attempt to quantify what we're talking about. For every description of how LLMs work or don't work we know only some, but not all of the following: - Do we know which projects people work on? No - Do we know which codebases (greenfield, mature, proprietary etc.) people…
> And that's before we get into how all these systems and agents are completely non-deterministic, And that is the main issue. For some the value is reproducible results, for others, as long as they got a good result, it's fine. It's like coin tossing. You may want tail all the time, because that's your chosen bet. You may prefer tail, but don't mind losing money if it's head. You may not interested in either, but yo…
> And companies are now pursuing the best coin tossing techniques to get tail.
With the only difference that the techniques for throwing coins can be verified by comparing the results of the tosses. More generally it's known as forcing https://en.wikipedia.org/wiki/Forcing_(magic)
What we have instead is companies (and people) saying they have perfected the toss not just for a specific coin, but for any objects in general. When it's very hard to prove that it's true even for a single coin :)
That said, I really like your comment :)
Re: Developing with GitHub Copilot Agent Mode and MCP
#64Earlier quoted context omitted.
I don't understand the argument, I haven't said humans act like that, what I said is how you have to treat LLMs if you want to use it for things like that. 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.
I interact with tools and with people. When with people, there's a shared understanding of the goal and the context (aka, alignment as some people like to called it). With tools, there's no such context needed. Instead I need reproducible results and clear output. And if it's something that I can automate, that it will follow my instructions closely. LLMs are obviously tools, but their parameters space is so huge tha…
I'm sorry, I'm very lost here, are you responding to the wrong comment or something? Because I don't see how any of that is connected to the conversation from here on up?
Re: Developing with GitHub Copilot Agent Mode and MCP
#65Earlier quoted context omitted.
I interact with tools and with people. When with people, there's a shared understanding of the goal and the context (aka, alignment as some people like to called it). With tools, there's no such context needed. Instead I need reproducible results and clear output. And if it's something that I can automate, that it will follow my instructions closely. LLMs are obviously tools, but their parameters space is so huge tha…
I'm sorry, I'm very lost here, are you responding to the wrong comment or something? Because I don't see how any of that is connected to the conversation from here on up?
>>> But you have to consider the task just like if you handed it over to a person with absolutely zero previous context, and explain what you need from the "requirements gathering", and how it should handle that
The most similar thing is software. Which is a list of instructions we give to a computer alongside the data that forms the context for this particular run. Then it goes to process that data and gives us a result. The basic premise is that these instructions need to be formal so that they became context-free. The whole context is the input to the code, and you can use the code whenever.
Natural language is context dependent. And the final result depends on the participants. So what you want is a shared understanding so that instructions are interpreted the same way by every participant. Someone (or the LLM) coming in with zero context is already a failure scenario. But even with the context baked in every participant, misunderstandings will occur.
So what you want is formal notation which removes ambiguity. It's not as flexible as natural language or as expressive, but it's very good at sharing instructions and information.
Re: Developing with GitHub Copilot Agent Mode and MCP
#66What’s with Copilot “agent mode” anyway, how does it compare to using Claude Code or Gemini CLI?
I haven't used the latter two. The Claude Code experience is very well translatable to Copilot and they are similar in features. There were not many examples of Github Copilot advanced usage like described in the article when Agent mode was just released (around 2 months ago?). But I was able to fully utilize it using Claude Code prompts and examples.
Copilot has a very direct advantage in my eyes - it has a plenty of models available: Sonnet 3.7, 4, GPT, Gemini, etc. That's something you won't get with the latter two.
Re: Developing with GitHub Copilot Agent Mode and MCP
#67Earlier quoted context omitted.
OP's comment also seems to be firmly stuck in 2023 when you'd prompt ChatGPT or whatever. The fact that LLMs today, when strapped into an agentic harness, can do or help with all of these things (ideation, architecture, use linters, validate code, evaluate outputs, and a million other things) seems to elude them.
Dothey do requirement gatherings? Like talking to stakeholder and getting their input of what the feature should, translating business jargon to domain terms? No. Do they do the analysis? Removing specs that conflict with each other, validating what's possible in the technical domain and in the business domain? No. Do they help with design? Helping coming up with the changes that impact the current software the least…
As for a Demo on that front here it is via OpenAI's Codex, see https://openai.com/index/introducing-codex/ Here's the demo https://platform.openai.com/docs/codex/overview and
Re: Developing with GitHub Copilot Agent Mode and MCP
#68Earlier quoted context omitted.
>Artists in residency are not know for being technical. 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 "no…
> The problem was the artists suddenly showing up one day with strange equipment. again, this is not a problem but a basic expectation when you do media arts residencies. Just like it's an expectation when you work in the event industry that you're going to get gigs for making something in the morning for an event happening in the evening.
>again, this is not a problem but a basic expectation when you do media arts residencies
If it isn't a problem, then the AI isn't a solution. You can't have a solution without a problem.
Saying that "this is just a basic expectation" is rather bizarre.
Who's setting that expectation?
And more importantly, why is it there? Who's benefiting from it? Why do you keep it?
FFS, you can proactively reach out to the artists and ask about what equipment they will use.
One doesn't just suddenly get an arts residency. There's an application process, I presume, and plenty of communication between the artist and the venue happening before any work begins.
There's no reason for discussion of the equipment not taking place early on where the entire point is using technology to create art.
And yes, "is just the way things are done in this industry" can be remarkably stupid. Doctors didn't wash hands until mid 19th century, that was just the basic expectation.
More soldiers were dying of disease in military hospitals than from battlefield casualties as a result.
The solution to the high death rate wasn't automating weapons (which did come with the Maxim gun). It was Florence Nightingale challenging the basic expectations.
Or, in modern parlance — calling BS on it.
You're not making a convincing case for that "basic expectation" existing.
>Just like it's an expectation when you work in the event industry that you're going to get gigs for making something in the morning for an event happening in the evening.
I've read this sentence three times, and it still didn't make any sense. Could you perhaps rephrase?
Again, when I gig with bands, I don't bring random gear for someone to set up.
It's my job. And we have a sound check. And if my gear doesn't work, the sound guy isn't fixing it.
Not sure what sort of analogy you meant to make, but it's not coming through.
Re: Developing with GitHub Copilot Agent Mode and MCP
#69All of that to generate crappy code...
Re: Developing with GitHub Copilot Agent Mode and MCP
#70Earlier quoted context omitted.
"Use the cameras you used last time for this gig, we'll work out something for the next one" If uttering a sentence like this is a "theoretical" solution for you, I don't know what to tell you, except that you're not going to have a good time in any job until you learn the practicality of saying "no" the hard way . And if you're living your life where the only "solution" to any problem created by stupidity, miscommun…
> And if you're living your life where the only "solution" to any problem created by stupidity, miscommunication, and bad planning of other people is saying "yes, sir!” and enabling them to do more if it 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 "correc…
>I'm not sure if you've ever worked in a "creative" environment filled with artists
I've played in 4 bands over the past 8 years, paid and unpaid gigs, and helped organize a few events.
So, no, I haven't worked in a "creative" environment (with scare quotes), but I've played live in bars, clubs, concert venues, house parties, So Far Sounds events, art spaces, fairs, park stages, hotels, parties, and so on.
And no, those spaces weren't filled with artists (thankfully). We were the artists; the spaces were filled with the paying audience for which we performed.
Under no circumstances could anyone expect the sounds guy to just make shit work. Nor have whims.
And we've been told "no" a-plenty, because that's the real world. Sometimes you don't get to have a real sound check before going live, and you deal with it.
As a co-organizer: I can recall one person who behaved the way you describe (being clueless about gear and expecting someone else to make it work). I've seen them play in another venue, and — surprise! — their shit didn't work there either. They were a crappy musician, and a bad person. And the sound people at the other venue didn't bend over backwards for that person because why would they.
So, I don't know what artists and what spaces you work with, but the dynamic you describe isn't healthy, isn't the norm, and isn't necessary.
Most importantly: it's not a software issue for Claude to solve.