How to add a feature to an existing AI-built app without redesigning everything

Start with what changes and what does not

A request to add teams, notifications, a subscription tier, or an AI assistant can quietly change more than the new screen. Explain the difference the user should experience and the promises that must remain intact. Adding team sharing, for example, raises ownership questions that changing a button color does not. Do not ask an agent to modernize the whole application simply because it needs to inspect the affected area.

Inspect the boundary that the feature actually touches

Trace the current user action, its saved records, access checks, and downstream consumers. Inspect enough code or behavior to understand the consequence, not every file by default. If repository access is unavailable, distinguish the user's description from implementation evidence. A useful screenshot can explain a workflow; it cannot establish that a server rejects unauthorized writes. Carry the unproven check explicitly rather than pretending it happened.

Example: sharing a project changes authority, not just navigation

In an illustrative single-owner app, only the creator can change a project. Adding a share button raises concrete questions: can another person view, edit, invite others, or delete? Does the original owner remain responsible? What happens to existing projects? The architecture should settle those rules before an implementation spreads a different answer across UI, API, and database permissions. Not every sharing feature needs a full enterprise organization system. Build the authority required by the actual sharing promise.

Give implementation one outcome with preservation duties

Ask for the complete change, not a separate human mission for each file. The agent should inspect, implement, run appropriate checks, view the relevant UI, and repair ordinary defects within the agreed boundary. Name the decisions it cannot make silently. A migration that discards customer information is different from a local refactor that preserves behavior.

• New journey: the intended user completes the new action.
• Old journey: existing users can still do what already worked.
• State: old records remain readable or are migrated deliberately.
• Access: the right actor can perform each consequential action.
• Failure: interruption or retry does not leave a misleading partial result.

Architecture can support continuation, not just recovery

You do not need to wait until the app is broken. An architecture pass can establish how the next phase fits the product already being built. The Terraria-in-Minecraft case is an existing implementation example: the delivered package connected the builder's larger roadmap with a bounded next playable milestone and the evidence needed around it. The published case does not establish that those implementation steps were subsequently completed.

Read the approved existing-build case study

How Driftbreak handles consequential product changes

When not to stop for a larger planning pass

If the feature is isolated, the intended behavior is clear, and the owner can be identified, implement it proportionately. The purpose of architecture is to expose consequential relationships, not to make ordinary development slower. Step back when the change alters ownership, persistence, protected behavior, or what the product actually promises, or when the available evidence does not support a safe choice.