Technology Explorations in Data & AI

Emil shows how to let his Cursor AI access and manipulate multiple projects at the same time.
He does this by leveraging the Cursor Workspace feature, which enables you to link multiple repositories together. His demo shows how to increase application resources, which also needs a Terraform change in a second project. Along the way, we discover how important human involvement still is...
You'll learn how to:
  • Set up Cursor workspaces with multiple projects
  • Let your agent access and manipulate multiple codebases
  • Leverage best practices from previous projects
  • Be mindful that human involvement is still important
Resources:
  • VSCode Workspace feature: https://code.visualstudio.com/docs/editing/workspaces/workspaces
  • Cursor Rules docs: https://cursor.com/docs/context/rules
  • MCP 101: https://www.youtube.com/watch?v=fIr55-koOJQ
  • Postgres MCP in Cursor: https://www.youtube.com/watch?v=tbrR21I3jJI
  • Click here to watch a video of this episode.
  • Full playlist: https://www.youtube.com/playlist?list=PLJ_da7qdfL80rA7byzC_CmyrfJWjcCTnb

Chapters:
  • (00:00) - Intro & setting up a Cursor Workspace
  • (03:21) - Demo: upgrading application memory
  • (06:46) - Did we cheat?
  • (08:16) - When are Workspaces most useful?
  • (09:37) - Out with monorepos for data products?
  • (10:15) - Best practices + read-only repos
  • (12:17) - Learning & exploring codebases
  • (13:24) - How Emil solved a production incident
  • (14:40) - The future of monorepos?
  • (15:54) - How this works with Cursor Rules
  • (17:21) - Summary & takeaways


Data & AI: Technology Explorations is a biweekly show from Dataminded. Each episode a Dataminded engineer demos a tool or technique worth knowing about -- working code, honest takes, no hype.

Music by Aleksandr Karabanov from Pixabay

Creators and Guests

Host
Jonny Daenen
Head of Knowledge at Dataminded
Guest
Emil Krause
Data Engineer at Dataminded

What is Technology Explorations in Data & AI?

Deep dives and practical demos on the technologies shaping modern data and AI development. Join the Dataminded team as we explore, unbox, and critically review the latest tools, from building AI agents and RAG systems to optimizing cloud costs and accelerating data pipelines. We cut through the hype to show you what actually works in real data engineering practice, complete with demo code!

As developers, when adding new features, we often touch multiple code bases, front-end, backend, data infrastructure. AI can only assist you in limited scopes, right? But today we'll have a look at Cursor Workspaces, a feature that allows AI to assist you across these code bases. Let's have a look. Hi everyone. Welcome to technology explorations at Dataminded.

In this series, we give you an initial look in new or interesting technologies. My name is Jonny, I'm knowledge teacher at Dataminded, and today we'll have look at Cursor Workspaces. For that, I've invited Emil. Hi Emil. Hi, how are you doing? All good here, how are you?

Same here. Okay, perfect. Today we'll be discussing Cursor Workspaces. Maybe a quick introduction on what we're going to cover. Yes, so we're going to cover multi-root workspaces that let you pin various repositories within one workspace. it all enters one AI context window, and you can ask questions that will encompass all of these workspaces.

So you can ask questions across your projects and also let the agent act in these projects. Okay, cool. Okay, I'm ready for the demo. Yeah, let's jump right in. So how do you set up a Cursor Workspace? So it's very simple.

Let's say you start with a blank Cursor page. You start by opening a folder. So I prepared two repositories that I will demo on. First one is demo-infra. You open the folder. this is what most of us work with.

It's just a repository and Cursor and it's a Cursor project. But you can turn it into a repository if you hit file and add folder to workspace. When you do that and you select a second folder. Now this will become a workspace and you will notice this by looking here at the title. have both folders mounted in this Cursor window and the Cursor window is resembling your workspace. Exactly.

So here you see it's an untitled workspace and now we can go ahead and save it. You hit save workspace as. And it's going to create this workspace file, I, by the way, recommend you to save in the Cursor folder right here. And that's it. Now you just created a workspace. Why did you save it in the Cursor folder?

Does it automatically recognize these? I just like to have them all in one place, independent of where the repositories live. Okay, nice. And so now you have an infrastructure repository and your app repository, in this case, your app will probably depend on infrastructure provisioned in the other repository. Exactly, and this is precisely the use case I would like to show. um So the specific use case we have an application a Kubernetes deployment in this case, which is using the infrastructure we provisioned in the infrastructure repository, which runs on the EKS cluster.

And this application has been running out of memory. So I would like to double requests and limits for the memory. but need to be aware if I'm going to create a node request that will not be able to be satisfied. So in this specific situation, I'm going to give a prompt where I'm going to ask to double the requests and limits, but making sure that such a node will be available. Okay, so if I understand correctly, you have your application running. There is some kind of out of memory issue popping up and your infrastructure needs to provision more container resources to run your application.

And this might be hindered by the infrastructure code, which limits the creation of bigger nodes. Okay, got it. So basically I would like to make two changes across two repositories in one shot from a one AI prompt, not having to have two windows open and figuring out where else will it have an implication. Yeah. Can you zoom in one or two steps?

So in this case, you asked it to double the requests and the limits in the deployment and that you get an adequate node so that the actual deployment can happen and that it can be provisioned. Correct. So, and it actually, yeah, it could see that the current node won't be adequate, that it's not gonna satisfy the doubling of requests and limits as we see here. And let's see what change it made in oh main.tf. It actually changed the instance type from small to large, that will exactly...

fit the bill of our double the request in limits. Okay, because otherwise you would actually have a different request of resources that could not be provisioned by this infrastructure code. So it had to change the actual Terraform code. Correct, otherwise it wouldn't find a suitable node and you would risk an outage or a production incident. Correct. That is a change in two repositories in this case.

Correct. This is in the demo infra and our deployment was in the demo app It made this change, which we're going to accept and here as well moving from small to large. did you do anything to signal that or does it just out of the box? No, a, this code is, is indexed and it's available to the context window. I didn't have to point it into any direction because that's the whole point of this is that you don't have to be explicit.

You have all these repositories so it can figure out all the touch points and all the interaction points that maybe you would have missed. And yeah, so it didn't need any, any help to arrive to the solution. I cannot help but wonder, did you cheat a bit by adding to your text like making sure an adequate node is available? If I would be a developer in your application code, I would maybe not even think about saying that in my prompt. you are really right and now I'm also very curious.

Let's undo this. Should we give it a go without any help? So without the last part. And so the YAML file for the deployment that lives in the first repository, the non-infra repository, right? It, deployment lives in the app and EKS in the infra And it didn't do it.

And it didn't do it. so you do need a bit of infrastructure context as an app developer. That's the conclusion, I think. you're right to challenge this. Okay, but if you know what you're doing and you're developing a multiple repositories, this still provides you with an assistant that can touch across your projects, across your repositories.

And it does avoid that you have to work in a monorepository setting or load the entire project in Cursor at once. Yes, although I am disappointed. was hoping it would, it would figure it out. But no, so you still need to know what you're doing it seems. Yeah, this is good, right Emil? So we still need you to handle both sides.

Yeah, yeah, exactly. A little bit more about where I think the value of this is. Even if you don't need to make changes to the code or fix bugs or, develop features. for me, the value lies from the fact that I can add repositories I don't work in and that belong to teams far removed from my team. Maybe networking is provisioned by another team and they create VPCs and subnets you're using. Sometimes you want to dig a bit deeper and understand why certain things were done the way they were done or there are other elements of your product written in other programming languages that you don't understand.

You can still ask just questions and gain an understanding about how things work on a top level for projects that you are not actively contributing in. And I think that's something that I think is quite powerful. Yeah, so that would mean if you get an infra repository from somebody else and you're depending on that, but you're not developing on that, that whatever you're developing can be supported by just linking in that code. Yes, exactly. Or maybe you're making some back-end changes and you want to see where would the front-end impact be ah when you're changing something.

And you can use this feature for exactly that. If I reflect on that for data products, if we build like chains of data products, we often start off with a monorepository where you have all the code together, but that's not always sustainable. I can imagine that if you make a change in a data product and another one depends on it, this could actually help you identify these dependencies and then also collaborating with other teams on that. Or if you're consuming from somebody that has made a change to make it easier to propagate that change.

Exactly. And throw in an MCP server into the mix and you are on top of all... Yeah, we have another video on that, right? Yes. But what I wonder is that suppose you got this extra repository It also brings in like templates potentially or best practices that the system, the AI agent in this case, you can actually mirror in your own code base.

So. I'm thinking you're developing data products. have a few sample repositories. You load them in, you're starting on your own and it can mimic the best practices present in there. Is that also something that would work you think? To get inspired by certain way a product is built to replicate onto a different product in a different maturity stage.

you mean? m structure and I build a third one, I imagine it would be good to automatically carry over the best practices without the need for extra documentation. I don't see why this wouldn't work. If it's just another, if you are very explicit in your prompt to say that take this repository as standard, I don't see what would be standing in way to achieving this. And could you then also lock down these repositories?

Like you loaded both infra and app in here. Suppose you don't want to touch the infra because you're not in control of that. Is that something you can do? So the way I would address this to limit the context a little bit, I would just add Add the folder specifically. and write my prompt here.

And I would expect this. Yeah. on that folder, but it will also not use the information from the other one, I suppose. I think there's no guarantee because as long as this is indexed and it is, it just enters, it's, know, all of this is indexed. So I don't think you can explicitly exclude what's already been indexed, but by adding the folder, you probably narrow the solution space here. And do you think you can also use this for exploratory reasons?

You mentioned before you sometimes use AI to learn about code bases. Yeah, I did it a lot in my current project where I work with a frontend team and I learned quite a lot about their code base using AI prompting that otherwise I wouldn't be able to do because I have no knowledge of frontend or the languages they use. it helped me understand what they do, follow in meetings a little bit better just by asking natural language questions about how their systems are structured without jumping into implementation. Yeah.

And do you then ask questions or do you just say, give me a summary what this code repository is all about? I do ask questions, for sure. Okay, so it's targeted questions that you do. this in a real life setting, you said you had a front end developers. What is the effect ultimately? Did you actually manage to speed yourself up or to learn more or to be more effective?

So one situation we had, we had a production incident and I wasn't sure why it's happening and it took quite a while to figure out and it was happening only in one environment. And even though the code was seemingly the same. So I used this to ask questions about the front end repositories and asked it to tell me what is exactly the difference between all of these environments? Is there any setting that makes environment X much more resource heavy than other environments and actually told me that there is this process that runs only in this environment for this and this reason and then it helped me narrow in on the actual production ah incident and the cause of it that was something very useful for me to just figure out what was the root cause.

even with lack of TypeScript knowledge or whatever. knowledge. could, and then with this information, I just gave it to front end and then they knew what to do. But I helped as an enabler for them and to figure this out. Cause we thought it comes from the backend, turns out it didn't. So.

Okay, nice. how do you see this evolve? Do you see this getting bigger or more effective? Uh, for sure. first of all, I think a lot of people don't know this exists just because it's relatively recent. what got me interested in exploring this was a podcast when someone was having an issue and AI helped him fix the issue.

And he said that, luckily it was all in a monorepo. So the AI agent could. Yeah. do everything at the same time and it got me thinking. So first step is for people to know and use it and then they will, the use base will drive the development and the features of this. For sure, what you mentioned to include or exclude certain repository from any given chat that could be done more explicitly and with more control.

Indeed, my reflex is also often to keep things in the same repository in the beginning to avoid confusion. And the effect is also then if you split across repositories, my thoughts are like, okay, but then an LLM or an AI agent like this one cannot really help you, but this removes that barrier, right? Yes, it's no longer an argument or a reason pro or contra Cursor also has these Cursor rules that you can embed. Have you experimented in any way with these?

And if so, how would this behave across these folders? So it is supported. you need to drop these rules in this dot Cursor folder that I uh saw previously. And they should be available to all the projects pinned under the workspace. And I'm actually opening the page with the release notes for this. and there we go Okay, so in the backend and in the front end, you can have your own Cursor rules defined if I understand it correctly.

Cause it says in all folders added. So you can probably have a system level rule set I can imagine. But so in every project, in every folder that we see here, there can be a dot Cursor folder with rules in there. Yes, or you can have one global set of rules that will be available to any folder you pin under the workspace. Okay, nice. There's still some side questions that pop up to be invested.

Like what if these rules conflict in multiple projects and things, but this is nice that this is still supported on the workspace level. Cool. Alright, How would you summarize Emil? Multiroot's workspaces are a relatively new feature that for me have too main use cases. They'll, helped me develop better code by taking into account interdependencies with other projects or other repositories that I don't actively work in that are easy to overlook And also helps me gain a top level understanding of other projects where I'm not a contributor or maybe they're written using a technology I don't know.

And it doesn't prevent me from following in discussions better and by understanding, yeah, what's the logic? What are the touch points? What's the input? What's the output? This you can understand no matter the technology. So that's for me where the strength lies in these two points.

Okay, indeed. My personal takeaway is essentially, the Cursor Workspaces removes the barrier between repositories. And so my arguments for having a monorepo, I'm a big fan of monorepo, is not that great anymore, at least in these terms. So it removes the barriers between the different projects and it allows you to go across many code bases. Yeah. Okay, very nice.

All right, thanks a lot Emil. Very interesting view on these new tools. Any concluding words? Try it out and see how it works for you. There might be some, value behind these three, four clicks. Yeah.

Any links we can add to the comments, maybe the documentation page we can add for the workspaces that people can start exploring. of the feature which is on the VS Code website. Alright, good. Thanks a lot, Emil. And thanks everybody for watching. We'll see you again in one of our next videos.

If you want to learn more about what we mentioned like MCP, checkout our other videos and we'll see you next time. Bye bye.