How to Stop Worrying About Requests and Start Coding

If you use Cursor, Windsurf or other coding assistants, you've probably encountered how they tend to rewrite the same pieces of code multiple times, tend to suddenly change variable names, and generally, when you're debugging a bug, on the fifth iteration you realize that the bug still isn't fixed, but you've gotten three new ones in the process.

Cursor/Windsurf handle simple changes quite well. But when it comes to making complex changes that affect multiple files at once, context and logic start to get lost, and you might find yourself at the dead end.

Sadly, when you're going in circles trying to debug something, you spend a lot of requests out of your limit and eventually run out of your plan.

I want to share some approaches that seem to help me and my team deal with these problems, get the necessary changes faster, more reliably, and with fewer requests.

Why do problems arise when making large changes?

Code assistants are wrappers around LLMs. When code generation affects only one file everything works great, since Cursor, simply put, just sends that file to the LLM and asks for changes. When a change involves multiple files, it's important to send all the necessary files to the LLM while maintaining the context of the task, i.e., why certain pieces of code exist in your project. We don't know exactly how Cursor or Windsurf, and other assistants do this. Apparently, this process differs noticeably among them. What unites them is that all of them start to stumble once changes reach a certain complexity, which leads to running in circles, wasting time, and hitting request limits.

What can be done?

Here are several practical tips that might prove useful:

Approach design as modularly as possible: This approach requires some system architect skills and isn't always easy for those who haven't developed many complex products or who just entered the industry through vibe coding. However, try to break down all your functionality into small blocks, each responsible for a small subset of the functionality. For example, user registration, document parsing, etc. In this case, parts of code that will be changed are isolated from other parts, and there's less chance that something unnecessary will be affected or something important will be left out of the change context. Btw, within this logical division, large files actually work better than several small ones. Large files are less readable for humans, but for LLMs, they're just fine.

Use micro-commits and continuous rapid testing: A micro-commit is when we commit even the smallest changes to Git, unlike how it was done before, when a developer could work on their branch for quite a while and merge branches after completing some functionality entirely.Why do this? This way you can simply roll back your changes when you discover that your assistant has made some changes that you can't track down but which broke your product.

Add as much context manually as possible: Cursor handles context in a somewhat unclear way. To be more precise, it tends to forget it. Even if you specify certain files to use, it might ignore them.What helps? Explicitly indicate the code fragments we consider important. Use requests like "Fix this function [code], taking into account this function [code], so that it works considering this code [code] and passes these tests [code]".Strictly speaking, this isn't vibe coding anymore, since it requires a lot of attention from your side. But this way there's a much better chance that all necessary context won't fall out of Cursor/Windsurf's attention, and you won't lose touch with your code so quickly.

"First analyze, then implement": This point somewhat contradicts the goal of minimizing the number of requests, but overall, it proves worthwhile. Instead of one request like "Implement functionality X" you can first ask "Analyze how to implement functionality X, indicate what changes will be needed, and verify that these changes will not break other functionality".Why do this? Modern LLMs usually work better if you first let them analyze the task and then ask them to solve it. Accordingly, with this two-step approach, when we ask to analyze the task and then implement it, there's a chance to get higher quality changes in the second phase.

Remember that a prompt can be long or short, but it's one request: Don't be afraid to add as much context as you can. Directory structure, documents, code examples. You'll spend just one request but will pass to Cursor/Windsurf the amount of context that you would otherwise communicate over several requests. Moreover, all this context won't be forgotten and will be taken into account (at least in theory).