Vibe suddenly returning errors when trying to add new features

Platform discussions
1

I have been building a Vibe application over the course of a week or so. It’s been great. The Vibe console shows me how it’s interpreting my natural language request, then it goes off and builds and in good time adds the code and the features is alive. Suddenly this week things have started acting very differently with the prompt console now not showing me the interpretation of my prompt and instead often just appearing to build. But then I get the error, “I had trouble generating code for your request because the response was too long. Could you try describing what you want in simpler terms or break it into smaller changes?” The prompt i have added is super simple and far less complicated than previous prompts i have added. At times I have persevered and hit retry many times. In some cases this has worked. In others not. I have also then tried to use the Discuss option to reframe my prompt. Often i have got good reasoning back from the discus option. But when i then come out of discuss and hit ‘Start Building’ I get the same error.

2

I am learning there is ALOT of reasons this can happen. Try Rolling back a version and making the last prompt you used simpler. Also, how many files is your app made up of?

3

Hi @matstanley, Welcome to the community!

You’re likely hitting a response length or context limit, especially if the app has grown in size. Even simple prompts can fail if the builder is processing a large codebase behind the scenes.

Break changes into very small, single-purpose updates and avoid combining multiple modifications in one build step.

If it still continues with small prompts, I’d recommend logging a ticket with monday support to check for any platform level issues.

4

Hey @matstanley

The “response too long” error usually means the system is attempting to generate more code than it can return in a single response. Even if the prompt itself is simple, it may trigger changes across multiple parts of the application depending on the current structure of the project.

A few approaches that may help:

Try breaking requests into very small, targeted changes instead of describing a full feature or outcome in one prompt.

Be very specific about scope. For example, asking to modify a single component or function tends to generate smaller responses than broader instructions.

If the Discuss option provides useful reasoning, try converting that explanation into a short, direct instruction before selecting Start Building.

If the application has grown in complexity, it can also help to duplicate the app and test the same prompt in the duplicate to see whether the current project structure is contributing to the issue.

If the same prompt consistently triggers the error, sharing that exact example with support may help them review the behavior more closely.

If you’d like hands-on help or want us to walk through this live, you can book a 1:1 paid 60-minute strategy session with our team here:
:backhand_index_pointing_right: Calendly

5

Hey Mat,

I’ve run into something similar with Vibe before. From my experience, this usually happens when the system hits a length or complexity limit on the generated code, even if your prompt seems simple. A few things that help:

  • Break the feature into smaller steps rather than trying to do everything in one prompt. Even minor changes can help avoid the “response too long” error.
  • Use the Discuss option to clarify logic, but instead of hitting “Start Building” right after, try copying the reasoning into a new prompt in smaller chunks.
  • Retry multiple times; sometimes it’s just a temporary hiccup with the AI backend.
  • Keep prompts as direct and concise as possible—avoid extra context that the AI might try to process unnecessarily.

It’s frustrating, but I’ve noticed that patience and breaking things down usually get it to work. Hopefully, Monday’s team smooths this out in future updates!

6

Hi @matstanley ,

This can sometimes happen when the builder reaches a response or context size limit, especially as the application grows. Even simple prompts may trigger the “response too long” message because the system processes the existing project code as well.

You could try breaking the request into smaller, single-step changes and building them incrementally.

If you need any implementation support kindly contact us

MSquare Support
Visit us here
Youtube Channel

7

So I have rolled back quite a way and got things being more responsive again. I have then asked Vibe to do a health check of the app and this is what it has reported back.

I’ve completed a health check of your application. While the app is functioning well and includes some very sophisticated logic, it has reached a “critical mass” in terms of code organization that will eventually make it difficult for AI to manage.

Health Status: High Risk (Code Density)

The primary concern is the size of your main files. For example, StaffingTable.jsx is currently over 3,700 lines long. My safety guidelines recommend keeping files under 100 lines. When files get this large, future updates become risky because the AI can lose track of the beginning of the file while working on the end, leading to bugs or “code vanishing.”

Top Recommendations for a “Spring Clean”

  1. Fragment the Staffing Table: I recommend splitting the giant StaffingTable.jsx into smaller, focused components like ExpensePolicyCard.jsx, SowSection.jsx, and FinancialSummary.jsx. This makes the code 10x easier for the AI to read and modify.

  2. Extract the “Brain”: Move the complex margin, cost, and rate calculations into a separate “Logic Hook” (e.g., usePricingLogic.js). This ensures that the math stays consistent across the app and is separated from the visual buttons and boxes.

  3. Centralize Data Cleaning: We’ve added several “sanitization” fixes lately (like ensureString). These should be moved to a shared dataUtils.js file so every part of the app can use them without repeating code.

  4. Modularize the Admin Console: Each tab in your Admin settings (Holidays, Service Lines, Consultants) should live in its own independent file to prevent cross-tab bugs.

Why this matters for “Future Vibes”

By refactoring now, you ensure that when you ask for a new feature in a month, I can pinpoint exactly which small file needs to change. This prevents “collateral damage” where adding a feature in one area accidentally breaks a calculation in another.

This refactor will not change how the app looks or operates for you—it simply cleans up the “engine room” to keep it running smoothly.

  1. Priorities: Which area would you like to “slim down” first: the main Pricing Form or the background Calculation Logic?

  2. Safety: Would you like me to start by moving the “Data Cleaning” tools to a shared file first as a low-risk starting point?

When you’re ready to perform this maintenance, just turn off Discuss mode and hit Build to start the refactor!

I am starting by doing step 2.

I think an important feature of Monday vibe should be that the health of the app is constantly reviewed and suggestions made to keep it functional. It is a bad experience for a user to simply stumble into it not working and then have to figure out why. I’ll keep this thread up to date on how i get on with the health restore steps i am trying.

8

You need to limit components to being no more than 300 lines or so each