Table of contents
- Cursor as a shared environment for the customer and the developer
- What if you showed the customer how to work with Cursor and use AI agents?
- The first layer of the experiment is not code, but the environment
- SSH: first you need to agree where development actually lives
- Linux users and ACLs. Order should not depend on promises
- Workspace is not just a folder, but the shared context of the project
- GitHub. A shared workspace does not replace branches
- To sum up
Google poured $40 billion into Anthropic, Cursor "built" a browser with GPT-5.2, and I started writing code together with a customer.
Today I want to talk about a new experience in software development. Or rather, this story is more about organizing work and communication. The idea itself is fairly obvious given how quickly development is changing, but I still think it is useful to explain the technical details, describe the problems, and show the ways around them.
What if you showed the customer how to work with Cursor and use AI agents?
A client came to us who, like many people in recent years, is inspired by the AI revolution and wants to get as much value as possible from what neural networks can now offer. He has been building an offline real estate business for several years and is looking for ways to make life easier for his colleagues and counterparties through an online application. Our client had already gone through the classic development flow with a team of developers, and it did not produce the result he wanted. Then he tried no-code tools and AI tools for building an application from scratch. They give you quick prototypes and a strong start. They let a CEO validate a hypothesis very quickly and feel the interface with his own hands. But they have a ceiling. At some point, questions appear that can no longer be solved by dragging blocks around. This is where the engineering part has to enter the process: engineering support and engineering supervision.
One of the main problems in building business applications is that the client always knows how everything should work, but does not know how to implement it. The developer, on the other hand, has the implementation skills, but often has no real idea what the client actually wants. The result of this communication usually ends up scattered across separate documents or stored in someone's memory. Advanced LLMs do not really solve this problem either, because at minimum they are working with different context.
The first layer of the experiment is not code, but the environment
At the very beginning we decided not to take the simple route. The most obvious option would be to suggest that the client use an agent in Cursor to create tasks for developers. But why not go further and build a system that can operate as effectively as possible? The main question became this: how do we build a scalable environment where specialists with different profiles, the client's team, and AI agents work together in one flow without getting in each other's way? A system where every participant complements the work of the others instead of replacing it or breaking it.
Technically, but in plain terms, I built one connected setup: a shared project directory lives on a VDS, Cursor opens it through Remote SSH, each participant logs in as their own Linux user, and code, documentation, tasks, and supporting materials all live in one workspace. Order there is maintained by a combination of OS-level permissions, groups and ACLs, GitHub access boundaries, and the normal branch and pull request cycle.
SSH: first you need to agree where development actually lives
If we want all participants to work in the same context, a local folder on my computer is a poor candidate for the center of the system. So the basic idea is simple. There is a remote server. The project workspace lives there. Cursor connects to that server through Remote SSH. For the user, it feels almost like normal IDE work: you open Cursor, connect to the server, and see files, terminal, git, documentation, and tasks. But in reality, the code and the environment are not on the local machine; they are on the VDS.
There is an important organizational detail here. Cursor, as a product, lives on the user's side: each person has the app, an account, settings, models, and access to agents. In our case, on the client side, one corporate Cursor account (PRO+) is used by him and members of his team. Technically, this is convenient: people can connect from different devices and get a single entry point into the tool. On the development side, the approach is different. Each specialist has their own Cursor account and their own familiar settings. They connect to the project as professional development participants, not as users of the customer's corporate account.
Cursor with AI agents is an editor that can read the project, modify files, run commands, create new artifacts, and sometimes act with too much confidence. If several people connect to one workspace, and each of them can make changes to project files, there is an obvious risk that someone accidentally changes other people's files. That is why SSH access by itself does not solve the problem. After that, you still need to decide exactly where a person is allowed to go, what they can read, what they can edit, and which actions should be impossible for them even by accident.
Linux users and ACLs. Order should not depend on promises
The next layer is ordinary, boring, and very useful Linux mechanics. Every participant gets a separate user on the server. Then permissions are built at the OS level. If a user on the server is allowed to write a file, the agent in Cursor can potentially write it too. If not, the agent cannot magically bypass that.
For this kind of scenario, groups and ACLs are convenient. Groups give you a coarse model: for example, you can separate permissions for the development team and the client team. ACLs give you more precise control at the level of an individual user. In our project, for the most part, each employee got write access to their own repository and to the shared docs repository (.cursor), which contains a set of materials for AI agents. Other people's repositories are read-only. In practice, this is especially important because of agents. A person may not understand which files the agent is about to change. If permissions are configured correctly, some of those mistakes will be stopped not by human attentiveness, but by the file system.
At this design level, the first problem appears. Even if permissions are configured, people and AI still need to live somewhere inside the shared project context. You need a structure where it is clear where code lives, where documents live, where instructions live, where agent rules live, and where personal and shared tasks live. Otherwise, we simply have a server with folders, not a working environment. This is how the need to organize the workspace appears.
Workspace is not just a folder, but the shared context of the project
The concept of a "workspace" is easy to underestimate. It may look like just a directory opened in Cursor. But in this experiment, the workspace becomes a much more important entity. It includes the shared context:
- Cursor commands, skills, and agents
- application repositories
- architecture documents
- meeting materials
- AI instructions and rules
- task directories
- solution drafts
- review artifacts, and so on
This is the place where business context and technical context finally exist next to each other, in one structure available to both a human and an AI agent. In Cursor this is especially interesting, because part of AI behavior can be defined at the workspace level. The project can contain shared rules, commands, skills, subagents, and instructions that apply to everyone who opens that workspace. This starts to look less like a repository with code and more like a project operating system.
It is worth noting that Cursor provides two levels for this kind of configuration. The first is the workspace level, whose role I described above. The second is the user level. A specific person can have their own local Cursor settings, preferences, commands, or extensions. They live on that person's device and do not have to become shared project rules.
Unfortunately, the workspace does not solve all the original problems. In our setup, there is still a physical limitation. If two team members edit the same files on the server at the same time, they will get in each other's way. This is not Figma, where several cursors move around a design. A codebase and Markdown documents in a shared directory do not automatically become a convenient real-time collaborative environment. The same is true for two agents editing one file at the same time. One of them can overwrite the other's work. In other words, the workspace gives us shared context, but it does not remove the need to isolate changes. In other words, we ran into the next problem. And yes, of course, the most correct solution is GitHub.
GitHub. A shared workspace does not replace branches
A shared workspace solves the context problem, but it does not solve the problem of parallel development. In our project, GitHub brings the normal engineering model back, but in a new reading. A separate branch is created for each task, and changes live in isolation. The result is packaged as a pull request. CI and peer review check that it can be merged into the main branch, which remains an integration branch, not a sandbox for everyone at once.
In this model, participants can work in different ways. For example, the customer or someone on the customer's team works on the remote server through Cursor, because most likely this person is hearing about GitHub for the first time and is not required to know how to use it. A backend or frontend developer can work locally in their usual git flow. This is especially important when areas of responsibility overlap. If the customer uses AI to make a small interface change while a frontend developer is refactoring components in parallel, they should not work in the same working tree. One can use the remote workspace as the task and verification environment; the other can use a local branch and their own dev setup. GitHub will then reconcile the changes through a pull request, diff, review, and conflicts if there are any.
To sum up
As a result, we get the following model:
- the workspace is needed for shared context and AI work
- Linux permissions are needed so people and agents do not go where they should not
- GitHub is needed so parallel changes do not turn into a fight over files
- the PR is needed so engineering review remains a required layer before integration
Anticipating the questions of the reader who made it this far, I want to return to the role of the client and the members of his team. Even if he has Cursor, access to the workspace, and an AI agent, that is still not enough. He needs a clear scenario for working in a session with an AI agent. How to start a task, what to ask the agent, how to make the agent write a plan first, where to store the result, how not to work in dev, what to do with a pull request. Otherwise the whole setup will slide back into chaos, only now a more technological kind of chaos.
So the next step became an instruction for the customer to work with the AI agent. Not just a prompt like "do the task", but a full procedure: from checking git state and creating a branch to planning, implementation, tests, preview, and PR. That will be the topic of my next post. Spoiler: there is far more than one way to provide this kind of flow for agent work. Right now I am experimenting with subagents and skills in Cursor.