Editing existing apps

Use Buzzy Builder MCP to help an agent inspect and change an app that already exists. This workflow is best for focused improvements, screen refinements, data-model adjustments, bug fixes, and follow-on features.

If you have not connected and bootstrapped your agent yet, start with Getting Started with Builder MCP.

Editing an existing app is an Adapt workflow. Direct artifact edits made through your connected agentic tool do not require Buzzy AI generation credits; the tool's own subscription or usage allowance still applies. If you explicitly invoke a Buzzy generation tool for new artifacts, sample data, or screens, you need separately purchased Buzzy AI credits or a supported bring-your-own OpenAI API key for those steps. See Builder MCP: Create vs Adapt.

Recommended Workflow

1. Connect the agent to Buzzy MCP and bootstrap the local repo if needed.

2. Identify the existing app by name, workspace URL, editor URL, or app ID.

3. Ask the agent to inspect the current app before changing anything.

4. Have the agent summarize the relevant data model, flows, blueprint, screens, and runtime behavior.

5. Review a short implementation plan for broad changes.

6. Apply changes in staged passes.

7. Verify the result in preview or runtime, using screenshots for visual changes.

Good Editing Prompts

For inspection:

Connect to Buzzy MCP and inspect this existing app: [app name or URL]. Summarize the current data model, main screens, navigation, and anything that looks risky before making changes.

For a focused change:

Update the [screen or flow] so that [specific outcome]. Keep the change scoped to this behavior and verify it in preview before reporting back.

For broader product feedback:

Make a plan before editing. I want [screen or workflow] to change from [current issue] to [desired outcome]. Inspect the current app first, then propose the smallest staged set of changes.

Review Gates

Use review gates when the change can affect multiple parts of the app:

• data model changes that may affect screens or sample data

• auth, public/private access, or user-owned content

• navigation, modal, or multi-screen workflow changes

• code-widget changes

• visual refinements across several screens

For small copy or layout fixes, it is reasonable for the agent to apply the change directly and then verify it.

Verification

Ask the agent to verify the specific path that changed. For UI work, screenshots are usually the clearest proof. For data or permission-sensitive work, check both allowed and denied user states where relevant.

Avoid broad rewrites while editing an existing app. The safest MCP editing loop is: inspect, plan, change one coherent area, verify, then continue.