Cursor for Professional Services
Learn how professional services teams use Cursor to deliver implementations and accelerate customer success.
Terms in this video
Transcript
All right. So the first thing I want to show kind of like a high level um oh sorry first before starting I'm Hugo from the field engineering team at cursor and so essentially I interact with clients every day um you know rolling out cursor best practice at scale across engineering organizations and so a big part of my work is actually talking to professional services and consulting firms and understanding their needs when it comes to uh you know bring
a POV around AI agentic engineering and also helping them around both internal work and client facing work. So really just wanted to preface this session by saying uh that cursor has some really good adoption in that industry. I wanted to kind of go over today how we think about this and how we're we can like give you a very quick demo as to uh this process of like delivering client facing work. So the first step of this is really going at a high level over the
vision behind cursor when it comes to the SCLC. And what we're trying to achieve here is come to a state where every engineer and every um professional services engineer can essentially expand the role by bringing different parts of the SDLC within the same space with cursor. So initially cursor was really focused on this phase which is development and essentially code generation. And as we move forward towards like a new vision for software engineering and for proserve we're trying to bring in other parts of that
CLC to make the context switching as low as possible. So what this means in practice is that when you're in a situation where you're doing some internal facing work or client facing work, uh there are most likely some um you know requirements, a spec requirements document, some context that's coming from different stakeholders across the organization, whether it be your PMs, your designers, the client themselves, uh the consulting team, all these different stakeholders come with their context. And so it's
very important to be able to reconcile that context with your existing engineering space. The way we do this is by essentially using things like MCPs to bridge the gap and bringing things like for example proc requirements document from notion uh or from confluence maybe a an issue or ticket from Jira. It could also be a frame from your from your design team or any kind of documentation whatsoever that you can incorporate into cursor and then reconciling that with
their automated indexing. And so where this helps is like this idea of fusing both the codebased context and that external context. Uh a cursor is used across a wide variety of use cases. Today we have people who are working on like brownfield projects who are using uh essentially cursor to migrate legacy code bases for clients. We also have users who are focusing mainly on green field topics. So things like uh building PC's, building prototypes and more of
like a PM focused approach or even things like uh building entire full stack applications both for internal purposes but also for client facing deliverables. We're noticing in general as a trend that uh with things like cursor and like these like newer agentic engineering tools uh the uh the onus on productivity is very strong. So these days you're able to ship fully functional applications uh even before you have your first call with the client
and so the uh landscape has changed a lot as compared to a few years ago where initial technical planning would take weeks and it would take a while to get to a stage where you could have an MVP that would be showable to a client. Now today you're able to whip this up uh in a few days at most with cursor and again taking into account all these steps both the technical planning but also the actual implementation and even things that are downstream of implementation
like testing monitoring deployment and change management. All right so with that in mind uh just wanted to move over to a separate piece which was uh how we see you know this uh you know rolling out in practice. So we're seeing of course a lot of like vibe cutting in the industry uh especially when it comes to client facing work. This idea that we were trying to get to uh uh tangible outcome really fast. Sometimes that can come with some compromises including issues around cleanup and compliance uh
security issues especially if that MVP is bound to make it to production to some extent and we're trying to ship this code to the customer. sometimes it can cause issues and so we're taking a different approach where essentially we are helping you uh make incremental uh changes around legacy migrations or even around building new apps where the AI code generation is intertwined with things like rules, commands, compliance toolkits that are meant to increase the
overall quality of the code and make it shippable and make it production ready. So that's kind of like the big emphasis there. And finally, one thing I want to mention before we move on to the demo is how we think about the context engine of cursor. So, cursor operates with a very specific context engine. As mentioned before, we have this automated indexing piece which is meant to understand at a at a deeper level, you know, what the codebase means. Like what's the semantic meaning of the codebase, which is useful
when you're coming into a project, you're not necessarily knowledgeable about what's going on. You want to ask questions to cursor about the codebase. You can do this with indexing very easily. So kind of like the discovery step. Separately, if you're trying to enforce guard rails or essentially build an application that respects a few norms, a spec uh that is mindful of best practices for that specific customer and the way they've implemented their their
specific stack. That's when you would want to use things like rules, commands, and hooks. And roles, commands, and hooks are these primitives within cursor that are meant to help you structure uh your code generation and give you very reliable high quality outputs that are shippable to production.
And so just to kind of go at a high level, this is what typically our context session looks like. So a rule could be always use this dependency. A [snorts] command could be something like uh a checklist of steps to go through like for example migrating a coobo application to Java or even onboarding a new developer or helping with change management. Uh and then separately I'll just skip hooks for now but things like MCPs which are very useful for again
bridging that context gap and bringing in external vendor information into the system. So a spec from a client, a PRD from a product manager, a Figma frame from a designer. All right, that's it for the slides portion. I'm going to switch over to the demo now and show you this in practice.
So this is my cursor. As you can see, I have a certain number of MCPS installed in my cursor settings. And the one I'm going to go with today is notion uh notion with this idea of like bringing that PRD from notion directly into cursor using MCP. So typically you'll be able to go to uh our MCP directory online and I'm going to put the uh URL in chat. You'll be able to install any MCP with one click similar to notion could be any other existing project
management system or knowledge management system and from there use that to query information directly uh in that system. So one way of thinking about this is I'm going to go to the agent panel here and start by asking uh for the agent to bring in that PRD directly. So I'm going to say um bring in the lamp store PRD from notion. And so from that the agent will be able to extrapolate the ask and run some tool calls directly against my notional workspace to find the relevant document. And again just reiterating that this is
possible for notion. It's also possible for other uh knowledge management systems that you may have. Things like the elastin MCP are also supported which helps you bring documentation from Jura and from places like Confluence as well. And so you'll see here my uh lamp store prd was immediately brought in to cursor in my workspace and printed to a file that's very easily readable. You can see I have my markdown file with my prd. No context switching needed. I am just
bringing this directly uh from my notion workspace. So a proc manager could have written this. Uh maybe somebody who's on the the client facing team could have written this and I can bring this in directly into my workspace to start working on it. Now, this is again a pretty high level PRD. It's not super like spec driven. We're really focused on the highle uh features that we want to build out uh that were highlighted by the customer. And so, what I'm going to
do here is I'm going to start building out a plan that's going to go step by step into each implementation detail to go with like a specd driven approach. I'm going to go back into the agent pane over here and I'm going to switch over to plan. So, plan mode in this little drop down. And in plan mode, I'm going to say write a spec uh that uh implements the aforementioned uh products document. And you can see I can even mention that PRD directly with the ad symbol. And from there in plan mode, this is
actually going to generate an actual spec, an implementation plan. Uh going through all the implementation details. Notice how it's searching the codebase to find context about the existing code. So again, in the case where you're not knowledgeable about a codebase, indexing will reconcile that codebase meaning with your spec generation automatically for you. So this spec that's being generated in front of me, this plan is all in the context of the current
codebase and of the ask from the product manager. And so you can see I have a complete architecture with a file structure, the ideal files to create these different components. breaking these down by implementation details and by section you'll see this is a e-commerce website and I'm trying to implement some cart functionality so here we have some information about the cart management among other things uh even business logic right things that are very important to present a customer facing deliverable shipping step
shipping form Google places integration payment step these are all things that usually would have um you know been kept in the technical planning phase and not have made it to the MVP but now I have the ability to implement this directly with cursor much faster and shortening that feedback loop. So with that in mind, I'm going to go at the very bottom. You'll see that I have um you know all my success metrics for tracking all these things, all my features. And
if I'm satisfied with this plan, uh I'm good to go. Otherwise, what I can do is edit the plan directly if I have any nits or I can even resteere it again. For example, I can receive the plan by reprompting and saying, "I want this to have a bigger focus on unit testing." If the client's asking for more of like a unit testing focused approach, again, you can make the plan your own. Uh, it's spec driven, but you have this intermediary step in plan mode to
essentially help you do your architectural work and design systems planning. Once I'm satisfied with this outcome, uh, I can click on the build button and you'll be able to start building out this plan. And from there after having planned all the next moves it will start to generate the code for me and going through all those todos one by one you'll see it's installing all the required dependencies including integrations that are useful to show uh in the end deliverable so things like stripe zod uh mill with
recent like Google maps creating type definitions so again we're taking a sustainable approach to this we're not trying to ship code that is will not be usable in production and finally things like you know utility functions and an example to be able to generate mock data and look at the actual uh browser outcome. You'll see it was able to install all those dependencies for me automatically again with that codebase context in mind and build out all this
functionality for me as well including uh the ability to select the cart uh navigate to the cart and add cart items. There we go. Notice also the speed at which we're generating this. This is using cursors composer one model which is our frontier model that we just released in our 2.0 release. Composer one is about 80 to 90% the quality of the best Frontier model today but with four times the speed which means that you really have this ability to increase
the interact interactivity of uh your interactions with the agent. So the feedback loop is much tighter. The back and forth is also much quicker which means you can quickly give feedback on what cursor is generating and adjust depending on customer expectations. So that really helps with being token efficient as well because instead of like using a very complicated model and essentially running this for two hours and having to revert back after a bad
quality outcome, I can almost like fail faster, which is something I want to do in this use case. And so again, that helps me interact with the model in a way that is more efficient and clearly specifying my intent. All right, so it's fairing pretty good against the todd. Uh we're creating a stripe integration. We're creating a checkout payment page. Now, what does this actually look like in practice? So, what I'm going to do in parallel is I'm going to run a dev server and I'll look at the output of this code and what the
agent is actually generating. Now, where it starts to get interesting is this is the classic editor layout. But in 2.0, we released a different layout called agents layout that you can look at by uh going into the top left of the screen here and then clicking on agents. And so, notice how the layout is completely different here. uh we actually have um you know like the agent directory in the middle and we can look at our agents on the left here. You'll
notice that I'm actually orchestrating multiple agents at the same time here. I'm focusing on like implementing this PR but in the background I also had a backend agent building out my backend. So really this idea of like being able to orchestrate multiple tasks at the same time on the same codebase with cursor especially relevant when you're trying to quickly prototype and build MVPs. You want to be able to paralyze that prototyping effort. So things like
building out a mock backend while you're building building out the front end or maybe something like building out the entire MVP with one agent and perhaps having a second agent document all this for you in a way that is digestible. So an executive summary or something that you can commit back to a knowledge management or project management system like notion.
And so again you can see it's again running through all these different uh implementations here. And now to look at the actual output of what I'm building. You'll see the agent is done. Now I can actually go in the bottom right. Again another feature that we ship with 2.0 is the ability for you to connect to a browser. So I'm going to click on the globe and then in the dropown I'm going to click on browser tab. And you'll see that from there I'm able to immediately
see the output of my generation uh with the complete MVP for this e-commerce store. This functionality with the cart uh pieces here is something that was implemented brand new from the output of this agent. So I'm able to see this live. Now where this gets interesting is like if you combine all these workflows together uh I showed a more simplified workflow where I get a PR from notion but you can imagine a world where use MCPS across your entire SDLC to bring in even more context. So for example, a
Figma frame and from the Figma frame you replicate uh what your designer has built directly in cursor with the context from your product manager and their PRD in notion and so that really helps like again recombining all that context and then end to end building that full stack application that front-end render that you can show as a deliverable and even better downstream of this test out the code do end to end testing unit testing uh instrument the
browser with the agent and um check if there's any visual regression. So one way of doing this with browser use which is one of our new features in 2.0 is the ability for you to mention the browser directly using this add browser functionality or separately you can go in the top right of the browser window here click on select element and then uh select a specific element to modify. So here I can select this uh you know header and I can say uh modify this to
match uh the client branding and I'm going to call it home company. I'm also going to say make it more uh interactive and you'll see that I actually directly mention that home component uh in the input window using that select tool. So, I'm being very prescriptive about the feedback that I want to give back to the agent, which again helps with those back and forths to the client because it's really easy for me to select the right piece to modify instead of just giving very vague instructions to the agent.
And this layout with the browser on the right helps me focus on what's important, which is steering the agent towards the right outcomes with that feedback. And so you'll see here it's able to modify all my code live and essentially rerender my front end directly in the browser window.
There we go. So we have some edits here. So really easy to kind of get started with this and build a full stack implementation framework. Uh you can do even more things like for example end toend testing with playright. Uh you can instrument the agent to look at the console logs. For example, here I can say look at the console logs and check for errors and from there have the agent uh take action on your behalf directly in uh you know in the browser. So really it's the ability to leverage all these tools
together in unison. Later on in the deployment process, you can also use MCPs like the Versol MCP to deploy this application to a manage hosting provider and then have it be hosted there to then give it as like a previewable URL to the client. And this is all into it. So I can go from PRD to spec to planning to implementation to uh rendering and feedback directly within cursor with no context switching. And so that severely increases my velocity [snorts] and gets
me to a point where uh those iteration loops are very short. I'm able to compress the entire PRD life cycle in SDLC. Um and building demos PC's and MVPs for clients has never been easier. >> I have question for you. Did you use any project rules during this demo? And if not, like which ones would you have added? >> Yeah, for this one there are no project rules so far. I believe if I check my doc cursor folder you'll see my doc cursor folder is empty so there are no rules u typically when you are trying to
build out that context so with rules commands hooks u the way I would do it is to try and set constraints that match the customer environment so things like for example being prescriptive in the rule about the text stack that you want to use or being prescriptive for example around the design system guidelines of a customer or things like their component library the way you would kind of like use your tech stack and use our guidines lines to then reinject into a PC so that
it matches what the customer expects as close as possible. >> Awesome. Thank you. >> Perfect. Um, are there any other questions in chat that I'm missing? >> Uh, no other questions, but yeah, if folks had stuff, feel free to drop them in the Q&A section.
Yeah, well free to I don't know if you can raise your hand on the webinar, but we're happy also to answer questions uh live as is. >> I do see another question. Um can this solution get completely imported to let's say Visual Studio? Can you maybe talk a bit more about how what you're seeing in cursor interacts with other ids?
>> Yes. So something to keep in mind is that cursor is a VS code fork. So typically we'll see users replace uh Visual Studio Code uh with cursor directly. When it comes to Visual Studio specifically for uh you know specific like programming language, we do see a lot of users who migrate over from Visual Studio to um cursor directly because of the AI capabilities. If you still want to keep your existing ID, keep in mind that we do have a CLI which
I'll put the link for directly in chat and you can leverage that in your existing setup if you don't necessarily want to move over to a new ID. Uh but usually we try to make the user interface as welcoming as possible so it's easy to get started without feeling like you're missing some debugging tools. >> And then we have another question of how do you trigger and coordinate multiple agents?
>> Yes. So that's a good question. Uh that ties back to that initial 2.0 layout that I was referring to. So if you go back into the agents layout here and then you uh look at the left portion of my screen, you'll see that these agents are actually stacked. So I can see multiple agents running in parallel.
You'll see that my front-end uh agent that was building out this front end here is done, but my cloud agent that was running the backend work is still running. So you're able to orchestrate these on the left side here. One thing that we typically do that is a good use case is having one agent working on the front end and one agent working on the back end and having these agents reconcile uh any API changes so that they're reflected on the front end. So
that's a big example. One way you would do this is that you go into the drop down here. You switch over to work tree mode which will use get work trees under the hood to separate it out with different mirrors of the codebase to avoid any u destructive changes any conflicts. And from there you're going to just select one model for example composer one and you're going to use plan mode to plan out with one agent right and then you can also plan out
with the other agents. So, typically what I'll do in a in a very common workflow is plan out my front-end changes first in one work tree. And then I'll open a new agent and plan out my backend changes in a separate agent. So, I'll say uh improve the accessibility of my front end. That's one example. And I'll create a new agent. Same thing. Plan mode workree composer one model with cursor. and I'll say uh improve my backend uh mock API. And from there, we're going to see that
I have technically three models, but if you just take the first two that I built here, front end accessibility, back and mock API, these are both running in parallel generating their own plans. And so in some capacity, you are delegating to both of these agents at the same time. And then you can go on to implement those plans after having um you know answered the follow-up questions and have both of those agents writing code in parallel >> and then I think now we're starting to get into the admin security question
side of things. Um I guess in Daniel's company the infosc team is very picky about the tools information access. Um can you maybe like talk about restricting MCPS on a team company level and maybe some of the other admin tools we have? >> Yeah, absolutely. So we do have the ability for you to restrict which MCPs you allow with an allow list directly in the admin panel. Uh keep in mind as well that typical patterns we see is enterprises allow listing us through a number of critical MCPS that are useful
for the entire org. So things like project and knowledge management systems, DevOps MCPs, um you know MCPs for like uh connecting to Figma for example, those are all critical MCPs that are used very commonly in most workflows. So we recommend allow listing them. separately you also have the possibility to allow list only certain MCP tool calls. So um definitely some controls there in the on the admin side. >> Yeah. And building on that we have additional controls to control like different models that your teams can
access. Um and then also like potentially controlling auto run mode which commands can be executed automatically in the terminal as well as for the browser control which websites can be run automatically. >> Exactly. And then another question on what are the steps for implementing APIs to handle live financial data retrieval and how would you incorporate that in the PRD?
>> Yeah, so typically the approach I would take there is to um you can mention this at a high level in the PRD. It doesn't have to be necessary super specific and like with implementation details and then when you're writing that plan I was referring to uh you can actually let's go back to the plan here. You can actually in the plan be very prescriptive about the approach that you want to take. So you can rest steer the plan and edit directly to uh account for
that like API with financial data. You can for example specify the endpoints, specify the way that that spec needs to follow like maybe a certain data structure. Uh you can even paste artifacts like a sample data structure from that API directly into cursor and have it incorporate that in the plan automatically for you. So there's a lot of different approaches there to like essentially building out entire APIs. uh you can build out the APIs, you can
build out the SP for them, you can even deploy those APIs to like a hosting provider all within Cursor. And so that really helps like building out those MVPs that feel real. >> And I did want to call out that like cursor kind of moves responsibility of PII to the companies themselves. And so we've seen a lot of orgs maybe allow connecting to the data structures. So knowing what fields are available for kind of writing those APIs, but actually calling and fetching the financial data and is typically like has separate
policies that the company governs. So did want to call out that that's something that you might need to talk to your team about. >> Yes. And you can of course keep it at a high level and not honestly have to fetch that API. You can always replicate at a high level what the API does and then have it be simulated within your environment within cursor totally within the capabilities of the agent there. And then another question I think how does cursor work with other IDs for instance Xcode um for iOS Apple
projects. >> Yeah. So typically in that scenario you would use your command line interface. Uh so I'll just open a separate window here that has a terminal in it right here. And you'll see that from there I can launch a cursor agent CLI which has very similar capabilities to the ID with the same ability to plan to execute to search and to build anything and with support for MCBs. So that's typically where we see some value for folks who are trying to stay on like a more of a native ID for things like Xcode iOS
development. Uh you can still use Xcode and essentially have the CLI be injected in your terminal to write files to the file system inject agent capability while keeping the native debugging tools of Xcode. >> I'm not seeing any more questions but we have a few more minutes as for them to trickle in. Okay. >> Amazing.
What what would you recommend next steps be for teams looking to try out cursor? >> Yeah, I would say if you want to try out cursor, please reach out to um you know the enterprise team. We're happy to set up a discussion and we have also some very strong POVs on the way that we think cursor should be used to do client facing work. We work with a lot of like large consulting firms today and professional service organizations who leverage curse every day to be more
productive and to um essentially increase the potential of their engineering work. >> Awesome. Seeing one more question. Um I think if two agents are triggered at the same time let's say one is writing code and another is updating notion. How does like parallel timing work or they're in completely isolated environments? And then second question is if we want to implement kind of shared coding guidelines is the best practice using the cursor rules um kind of how do you combine front and back end? Do you
recommend having multiple or just one mega one? Um let me know if you forgot what the first question is because I know that's >> uh I got it. So basically the the way we think about this is that when you're in the multi- aent setup I'm going to increase this window here. When you are in a multi- aent setup uh you want to use work trees. So this ability to use work trees here to have independent copies of the codebase for each agent.
And so this really helps with avoiding conflicts. Uh ideally you also want to scope out your plans in a way that makes overlapping u you know not at risk. So you would scope out your plans to work on specific files and implementation details and you would use work trees to then uh avoid any conflicting changes.
And finally you would reconcile those changes in the work trees with your existing branches. You can do this automatically with carer today. So it's not as much so as like sub agents. rather just like this idea of like delegating to the you know for the right task at the right scope and clearly specifying what the implementation details should be on sharing code guidelines. So this is where rules commands and MCPS will uh become very important. Uh just coming back to kind of like the uh different like levels for
each I'll just go back to this slide. You'll see that for each different primitive we have a user project and team level. Uh we are in the process of like thinking about things like sub team. So being able to divide rules, commands and hooks uh depending on each like sub team like DevOps, security, etc. This is something you can technically do right now already since you can like scope these to projects and so everybody who is in that project will
have access to cursor rules commands. Note that these are more advanced than simple markdown files because cursor can help you inject these in the context window or apply them intelligently. So it's a little bit more advanced than say just like a pure agent.mmd.
>> Awesome. Well, I know we are at time. >> Thank you everyone for joining us. Um really engaged, thoughtful questions and yeah, we loved having you here with us. >> Thank you so much. Take care.