Composer continuously breaking existing code/functionality

Bug Report
1

I have 3 files:

  1. 2 files are under 230 lines and 1 around 1.2k long. All are very well commented.
  2. I use composer for changes and speak to the entire codebase.
  3. I explicitly tell it not break any existing functionality or amend anything nothing directly requested in my changes (e.g. front end design). I also ask it to ensure all functions are defined, scripts and syntax are complete and accurate. I’ll provide it with code snippets to help it (as it often fails to do itself).
  4. I ask one change at a time.

However, Im going around in circles. By the time Ive got one thing working, its broken something else.

I only code in python.

Is this a bug?

I’m sure others are making much more complex programs than I with far more code and complex file structure. What am I doing wrong here?

2 Likes
2

Maybe a long shot, but what happens if instead of chat with entire codebase you just attach all your files in composer? Is the outcome any different?

3

Same issue since the update!

4

I am having exactly the same issue.

Tried using Cursor Rules and Composer Project to tell the prompt to not remove any existing functionality, but it keeps doing so, mainly when debugging in circles whether a specific thing does not work.

I wouldn’t mind it removing it temporarily, but it should be able to add it back. I understand that it can’t “recall” what was there before, because context length, of course, but still, regarding productivity it is a lot of back and forth.

I will be trying maybe to have a @draft file where I try to instruct the prompt to write to it the current code before changing it, and whenever it gets the given feature working to merge with the @draft file and will see if it somehow helps.

5

I have been working with Claude (3.5 Sonnet) projects and had some success talking to the entire code base (and having multiple files changed in response to a task given. With firm instructions not to remove existing functionality (even if at the time its purpose seems irrelevant) Claude appears to behave somewhat responsibly. But using Claude in Cursor, I don’t get the same context window. Cursor seems to limit the size of the context to a few files only and lets Claude assume the rest remains unchanged (and does as a consequence not feed the content of those files back to Claude). Claude then reacts by saying in order for these files to be changed it would need access to them (eventhough they are part of the files provided to the Cursor context). Cursor should take advantage of the Claude project concept where the context files are uploaded once and then implicitly resubmitted with every prompt (and therefore make part of the context window.