Cursor tips, Kimi K2 coding

Stop fighting the LLM and start treating it like a junior dev with a memory leak. If you're still just typing "fix this bug" into a chat window, you're wasting 60% of your potential velocity. After three months of swapping between Cursor and Kimi K2 for a TypeScript-based dashboard project, I've realized the secret isn't the model—it's how you constrain the context.

Stop using @Codebase for everything #

The biggest mistake I see is people using @Codebase as a magic wand. In a medium-sized repo, that just floods the context window with noise, leading to "hallucinated" function calls that don't exist in your actual version of the library.

The Fix: Be surgical. Use @Files or @Folders specifically.

| Scenario | Bad Approach | Productive Approach |

| :--- | :--- | :--- | | Adding a new API route | @Codebase add a user route | @api-client.ts @user-schema.ts create a POST route for user registration |

| Refactoring a component | @Codebase fix the CSS | @Component.tsx @theme.css remove the hardcoded margin-top on the header |

I noticed that when I switched to explicit file tagging, the "I forgot you were using Tailwind 3.4" errors dropped from five per session to nearly zero.

Feed Kimi K2 the "Rules" file for better logic #

Kimi K2 is surprisingly aggressive with logic, but it can drift into overly verbose patterns if you don't leash it. I spent four hours last Tuesday fighting a recursive loop in a data-parsing script because the model kept trying to be "helpful" by adding unnecessary try-catch blocks every three lines.

Create a .cursorrules file (or a system prompt equivalent in your Kimi config). Don't write a novel. Write constraints.

Example config for Kimi K2:

• No comments unless the logic is genuinely non-obvious.
• Use Zod for all API validation.
• Prefer functional map/filter over for-loops.
• If a function exceeds 20 lines, suggest a split.

Before this, Kimi would give me 80-line functions that looked clean but were a nightmare to unit test. After implementing these constraints, the code was modular, and my

npm test pass rate on the first run jumped from 40% to 75%.

Use the "Composer" mode for architectural shifts, not line edits #

Using the Composer (Cmd+I / Ctrl+I) for a one-line change is overkill. But for a structural change—like moving from a monolithic state object to a sliced Redux pattern—it's the only way to go. The wild part is that Kimi K2 handles multi-file edits better than some of the older GPT-4 iterations I've used. Try this: instead of asking it to "update the state," give it a specific migration path.

The Workflow:

1. Open Composer.

2. @Folder /store @Folder /components

3. "Migrate the user state from store/index.ts to store/userSlice.ts. Update all imports in the components folder to reflect this change."

It’ll rip through 12 files in about 15 seconds. If you did this manually via chat, you'd be copy-pasting for twenty minutes and probably miss one import in a random utility file. To find more optimized ways to handle these complex shifts, check out the Workflows section of our community.

Stop the "Infinite Loop" of AI corrections #

We've all been there: the AI fixes a bug, introduces another, fixes that one, and suddenly you're back where you started. I hit this hard with a Kimi K2 session while trying to optimize a SQL query.

The moment the AI fails twice on the same logic, stop. Do not ask it to "try again" or "think deeper."

The shortcut:

• Copy the error log.
• Create a new .txt file callederror-context.txt .
• Paste the error and the current state of the function.
• Mention @error-context.txt in a fresh chat.

Clearing the conversation history removes the "bias" the model has toward its previous wrong answer. It sounds tedious, but it saves me at least an hour of frustration per day. For those who want to see how others handle these edge cases, browsing

Prompt Sharingis a goldmine for finding "circuit-breaker" prompts that stop these loops.

When to use Kimi K2 over Cursor's default models #

Kimi K2 is a beast for long-context reasoning and complex logic, but it's not always the right tool for the job.

• Use Kimi K2 when: You need to analyze a 2,000-line legacy file to find a race condition or when you're designing a complex database schema from scratch.

• Use Claude 3.5 Sonnet (via Cursor) when: You need the "aesthetic" of the code to be perfect or you're doing rapid-fire UI iterations. // ... rest of code here) compared to some other models. It actually writes the full implementation.

Dealing with "Hallucinated" Libraries #

Last month, Kimi K2 tried to convince me that a specific method existed in date-fns that simply didn't. I wasted 10 minutes trying to make it work.

To prevent this, I started using a "Verify First" prompt.

Before: "Use date-fns to format this string."After: "Check the latest documentation for date-fns v3. Using only existing methods, format this string."

It's a small tweak, but it forces the model to simulate a documentation check before spitting out code. You can find more refined utility prompts like this in the Resources area of the PromptCube community.

Joining the PromptCube Community #

The reality is that AI coding moves too fast for a single person to keep up. One day a new MCP server drops, the next day Kimi releases a model that makes your previous prompts obsolete.

PromptCube isn't just a place to store prompts; it's where we actually stress-test these tools. Whether you're struggling with context window limits or trying to figure out which model handles Python decorators better, joining the community gives you access to a collective brain of developers who have already hit the bugs you're currently facing.

You can join by signing up on the main site—just look for the community forum. It's the fastest way to stop guessing and start shipping.

Next ToolJet MCP can build a shipment control tower for about $0.17 using the Luna medium →