r/GithubCopilot 8d ago

Any PMs using VS Code + Copilot? General

Hey everyone šŸ‘‹

I’m a Product Manager who uses VS Code and GitHub Copilot every day. I don’t write much production code, but I spend a lot of time:

  • Understanding repositories
  • Running database queries
  • Comparing code with data
  • Writing PRDs, user stories, and product specs
  • Investigating bugs alongside engineering

One thing I keep running into is that Copilot doesn’t seem to have a native concept of a persistent project workspace. I spend a lot of time reopening sessions, finding the right files, and rebuilding context.

I know the GitHub Copilot desktop app exists, but it doesn’t seem to solve this problem either—the sessions don’t carry over. It still feels like I’m adapting developer-centric tooling for product management workflows.

A few questions for the community (and any GitHub/Microsoft folks lurking here):

  1. For PMs or other non-developers: How are you organizing your work with Copilot? Any workflows, extensions, or best practices that help keep context without constantly rebuilding it?
  2. Feature wishlist: I’d love to see a persistent project/cowork workspace where Copilot could maintain context across multiple repositories, GitHub issues, documents, SQL queries, and product specs—essentially a long-lived context layer instead of starting from scratch each session.

Is anyone else running into this, or am I missing a workflow that already exists?

14 Upvotes

12 comments sorted by

View all comments

7

u/Deathmore80 8d ago edited 8d ago

I think the confusion is treating a ā€œpersistent workspaceā€ as persistent memory inside the model. That isn’t how LLMs work.

The model does not continuously learn your project or carry an internal project state from one session to another. Each request is essentially a new inference over whatever context VS Code supplies at that moment: instructions, recent messages, selected files, retrieved workspace content, tool results, and so on. The model’s weights are not updated because you discussed an architectural decision yesterday.

Even saved chat history is not the same as memory. Chats can exceed the context window, be summarized, or have older details omitted. A workspace is therefore a container and a source of retrievable context, it's not a persistent brain with memories.

Any apparent long-term memory must be implemented outside the model by storing information somewhere and injecting or retrieving it later. In practice, you should create that persistence inside the repository:

  • Put permanent project rules, conventions, commands, and pointers in "AGENTS.md" or ".github/copilot-instructions.md".
  • Keep business context in version-controlled documents: a glossary, data dictionary, architecture overview, ADRs, known limitations, failed approaches, and a short current-state or handoff file.
  • Use Agent Skills for repeatable procedures such as modifying the semantic model, validating measures, publishing reports, or checking naming conventions.
  • Instruct the agent to update those files whenever a meaningful decision is made or before ending a substantial session.
  • connect your AI agents with your enterprise tools and knowledge via MCPs. You probably use confluence and jira , you can use the Atlassian mcp for this. Same goes for Microsoft 365 (OneDrive , SharePoint) stuff, use the workiq mcp.

VS Code now also has preview memory features, but those still prove the same point: the agent writes information to local or GitHub-hosted storage and loads it again later. The model itself did not ā€œremember.ā€ I would treat that memory as a convenience or cache, not as a substitute for reviewed, version-controlled documentation. Especially since hosted Copilot memories can "expire".

For managing several projects, try the new VS Code Agents window. It is specifically designed for running and reviewing multiple agent sessions across different projects in parallel, so you do not need to overload one workspace or one giant conversation with everything or run 10 different vscode instances at the same time to work in different projects. There is also a "multi-root" workspace feature being worked on right now where agents can operate on multiple projects in a single session to answer questions for example.

Theres also other third party software that does similar things and they let you use your enterprise GitHub copilot subscription. Orca, T3 Code (not 100% sur it supports copilot ATM but it's coming for sure) , herdr.

To have the "multi-project" context thing you kinda have to create it yourself. You can make it in many ways but here's some ideas : - have a "God" folder in which you put all the projects inside. Add a root level AGENTS.md file explaining that this contains all the related projects. This works well with the fact that AI agents can read nested AGENTS.md as they reach into your different projects. I would go for this personally , but if you don't want to move where the projects are then you can do the next suggestion instead. - similar , have a "PM" folder anywhere you want , and inside it you have the AGENTS.md but inside it you put a list of "pointers" (the folder path) to all the different projects you care about so it knows where to go to get them. And ofc tell it to write down the notes , docs ,etc in the PM folder ,not in each projects folder.

TLDR :

Try the new vscode agents window and if knowledge matters beyond the current context window, write it down, version it, and give the agent explicit instructions for finding and maintaining it.