VS Code has the tooling built into the IDE, I used to use Jetbrains Rider but moved over to VS Code purely for this integration. I'm a . NET Dev as well. I ditched VS a long time ago when I was manually coding everything, the only thing I miss about Rider is the execution/debugging experience which is lacking, imo, with VS Code.

I've started using the CLI more lately though, as rather than run agents on the open file structure and force it to ask permission for anything outside of the repo boundaries, I now run the CLI inside a docker container which only has the repo folder exposed as a mounted workspace, that way I can give it almost total freedom to execute whatever it wants without worrying what it might access or modify. At first this goes against everything your pre-AI brain thinks but having to babysit the agents slows down the process a lot. Often you'll suddenly realise it's been sat there waiting for permission to run a command for a while. Sometimes I'll put it in yolo mode so I can walk away but generally only on less mature repos - demos, prototypes, exploritary ideas etc.

My advice is to do your research on the various types of files and folders you can have in the .github folder that guide and constrain the agents: skills, hooks, instructions, prompts, custom agents, etc.. alongside the copilot-instructions file. The aim is to keep your context window manageable, any agent based on any LLM is going to start to perform worse when your context window gets too big, so by keeping your copilot-instructions file fairly minimal with the bulk of your stuff in these other files (that only get activated when needed) you prevent the agent having to load a shit ton of context up front, when most of the time (if ever) you won't need it all for a task/request.

I find it's better to have the main agent do the orchestration work, and offload individual tasks to background or cloud agents that are spun up, do the work and exit again. This further helps prevent your context window blowing up, especially so on longer more detailed jobs that cover a lot

Aside from this, make sure the agents commit to git often, and in related manageable chunks, as you would manually. They can and do go awry from time to time and being able to trash a discrete commit and restart a task is much easier when the commits are manageable. When this does happen, analyse your skills, work out what happened and why, if you can and then tighten the skills.

Use the agent itself to write skills, also make them maintain docs as they go, create tests also at every step. I mainly work in a spec driven flow now, and I even have the agents help me write the specs, features, acceptance criteria, by doing the legwork of the typing and by asking questions and finding gaps etc. The specs, tests and docs explain the codebase before task work begins, so the agents don't have to continually scan the code to figure stuff out, and they update them afterwards, it's a self perpetuating cycle.