🦾 Preparing a project to be vibe-coded

If you are an IT specialist, you have probably heard about tools like Cursor, Windsurf, Cline, and Roo Code. These tools can create entire projects for you even if you don’t know programming. You just need to download an IDE (or VS Code with some extensions), give it instructions, and wait for the result. If you’re lucky, it will even work.

I have spent some time using these AI tools, and today I want to share my experience about how to prepare a project for “vibe-coding”.

I used Cursor the most, but it doesn’t matter much because all these tools use the same AI models. The main difference is usually the UI. What I’m going to talk about applies to all these kinds of tools.

• Using .cursorrules file
• Using .cursor/rules/ directory
• Make your memory self-manageable
• “Memory bank” prompts
• Graphiti
• Conclusion

As I said, we’ll discuss how to prepare a project for AI coding. I believe you always need a “preparation stage” for both existing and new projects. Of course, you can just let AI work on your project without guidance, but this often breaks things. AI doesn’t know your preferences, your project and doesn’t know what you want. It can understand some requirements from your code, but this doesn’t always work well. Sometimes it also can make unexpected changes, like “Hey, I also migrated your project from Vue to React.”

That’s why you need to prepare your project for AI: to make it more predictable and make it do what you need without unwanted changes. Preparation means documenting your preferences, requirements, agreements, tech stack, and so on. It’s like CONTRIBUTING.md and README.md, but for AI.

You could just fill in those .md files and things would be better, but it’s better to separate human and AI documentation.

Using .cursorrules file

The simplest way to store your AI documentation is using a .cursorrules file. This file can contain any instructions in free format, and it will be loaded by default in every new chat. For example, you can write something like this and Cursor will remember it:

- Use only Tailwind classes and minimize the amount of custom CSS.

This approach works fine, but requires you to manually manage the .cursorrules file, and also as for now it’s deprecated in favor of the newer approach.

Using .cursor/rules/ directory

Since recently, you can split your rules into files like architecture.mdc, stack.mdc, styling.mdc and place them in the .cursor/rules/ directory. This helps keep your rules organized. Look at a good example of such rules: eyaltoledano/claude-task-master.

You can also use an instruction like:

- Read your context from all `*.md` files from `context/` folder.

This lets you store your rules in the context/ directory. This approach works well if you use not only Cursor as your AI assistant.

Make your memory self-manageable

Instead of manually editing your rules, you can ask Cursor to manage them for you. A basic instruction for .cursorrules is:

- Read context from all files from `context/` folder.
- Whenever you learn new knowledge, requirements or preferences about the project,
  summarize it and put it into the `context/` folder. Choose a suitable existing `.md`
  file or create a new one.

This works, but you must review carefully what it writes. Often it adds unnecessary information, so don’t let your context/ become a mess of AI-generated shit.

docs/
├── ai-assistant-integration.md
├── architecture-plan.md
├── build-with-bun.md
├── bun-migration.md
├── cline-integration.md
├── code-improvements.md
├── cursor-integration.md
├── custom-folder-name.md
├── debug-mcp-config.md
├── documentation-structure.md
├── file-naming-convention-update.md
├── file-naming-convention.md
├── implementation-plan-rule-formats.md
├── integration-testing-guide.md
├── logging-system.md
├── mcp-protocol-specification.md
├── memory-bank-bug-fixes.md
├── memory-bank-mcp-startup.md
├── memory-bank-path-changes.md
├── memory-bank-status-fix.md
├── memory-bank-status-prefix.md
├── migration-guide.md
├── modular-architecture-proposal.md
├── npx-usage.md
├── README.md
├── requirements.md
├── roo-code-integration.md
├── rule-examples.md
├── rule-formats.md
├── test-coverage.md
├── testing-clinerules.md
├── testing-guide.md
├── testing-strategy.md
├── testing.md
└── usage-modes.md

“Memory bank” prompts

Another way to solve this problem is using “memory bank” prompts. These are instructions that filter unnecessary information, organize it between existing *.md files, and help keep your context clean.

The idea came from Cline memory bank prompt and then spread around. Now you can find many different variations: cursor-memory-bank, cursor-bank, rules_template, memory-bank-mcp memory-bank-mcp (another), roocode-memorybank-optimized, roo-code-memory-bank, RooFlow and others.

You can try these yourself, but I didn’t find them very useful. Things still don’t “just work” and you often need to manage something manually. But manual management becomes even harder because you don’t fully understand the prompts. When something doesn’t work as expected, you have to debug and edit these prompts, which takes extra time. And this happens quite often because these approaches aren’t much solid and not enough battle-tested.

Graphiti

During my attempts to improve my workflow, I found another promising solution: Graphiti. It’s a kind of AI-powered database that stores knowledge about whatever you put into it. It wasn’t originally meant to be used as memory for AI assistant, but recently they published an article called “Cursor IDE: Adding Memory With Graphiti MCP”.

I checked this out carefully and right now it’s not much usable:

• It requires you to run a separate service and database on your computer.
• The MCP integration doesn’t work well. Usually, the AI ignores it unless you directly ask it “to store memory.”
• Managing memory manually is difficult. The best way to remove something from memory is probably to remove it directly from the database.
• It requires API keys for OpenAI. Other providers are available too, but only if you code them yourself.
• The installation is complicated and the documentation is incomplete (the MCP part has no documentation at all). If you need to do something, you’ll have to look through the code.

They published this MCP about a month ago, so things might not be polished yet. They might improve in the future.

Conclusion

As you can see, there are many approaches to try. Which one should you use? After everything I’ve tried, I think the best choice is using the .cursor/rules/ directory with manually created rules (or AI-generated rules that you carefully review). In my opinion, everything else is a waste of time as for now, but things might change in the future. There’s still room for a good memory management tool, which might appear soon given how fast the AI market is changing 🙂

Thank you for reading this little article, I hope it will be useful to someone. Feel free to reach me if you have something to say.

And also take a look on the posts on similar topics:

• ⚙️ Managing dotfiles with Nix
• 🌇 Civilization 5 multiplayer modding
• 🌉 Migration from Jekyll to Bridgetown