Stacking Features with AI — How to Keep Your Structure from Falling Apart

Now that MCP is connected, it’s time to really start stacking up features. In this post, we’ll look at how to actually add features together with AI, and how to manage the reality that structure gets blurrier as features pile up.

We’ll keep using the bookmark app as our example. In part 4, we built the basic screen, and now we’ll add tagging and search.

How to Ask AI for a New Feature

The single most important principle when adding a feature is one thing at a time.

If you don’t have much experience, you’ll be tempted to ask for everything at once: “Add tags, search, and sorting, all of it.” But this approach is a great way to create problems.

Approach	Pros	Cons
Request several features at once	Feels faster	Code gets tangled and hard to fix later; when an error shows up, it’s hard to tell what caused it
Request features one at a time, step by step	Feels slower	You can check the result at each step; when something breaks, the cause is obvious

In practice, asking for things one at a time is actually faster overall. Since you know exactly where a bug came from, the time you spend fixing it drops dramatically.

The Structure of a Good Feature-Request Prompt

[Describe the current state]
The bookmark app currently saves URLs and titles and shows them in a list.
Data is stored in localStorage, and each bookmark has the shape { id, url, title }.

[Feature to add]
I want to add tags. When saving a bookmark, users should be able to attach
multiple tags, and clicking a tag in the list should filter to only bookmarks
with that tag.

[Data structure change]
Add a tags: [] array to the existing bookmark data.
No migration needed for existing data — if tags is missing, just treat it as an empty array.

[Scope limit]
Just do this for now. Editing or deleting tags will come later.

Writing your prompt in this order — current state → desired feature → data changes → scope limit — lets the AI add the feature without conflicting with your existing code.

The Reality: Structure Gets Harder to Follow as Features Pile Up

Even when you add features one at a time, there’s a reality you can’t avoid: the code keeps getting more complex.

At first it’s fine to have everything in a single App.jsx. But once tags are added, then search, then sorting, at some point App.jsx crosses 300 lines.

Once you’re at this point, requesting a new feature tends to cause problems like:

The AI misunderstands the existing code and recreates a similar function, creating duplication
You ask for a fix and something unrelated changes instead
Fixing one feature breaks another

The root cause of this is that it’s hard for the AI to grasp the entire context of the code all at once when reading it.

Leaving a Trail in the Umtri Tree as Features Pile Up

The way to solve this problem is to leave a record in the Umtri tree every time you add a feature.

The record itself doesn’t need to be complicated. If you created a new component, adding a single leaf node to the Umtri tree is enough.

With MCP connected, ask Claude Code something like this:

I finished adding the tag feature.
Please update the bookmark-app ground tree in Umtri with the following:

- TagFilter component → add as a leaf under the BookmarkList twig
- AddForm now has a tag input, so update the AddForm leaf's description
- localStorage now has a tags array, so update the storage.js leaf's description too

Once you’ve recorded this, the next time you want to add a feature you can do this:

Pull up the bookmark-app tree from Umtri.
I want to add a search feature — suggest where it should go given the current structure.

Claude Code reads the current tree structure, figures out which components the search feature would relate to and where it should live, and then makes a suggestion. It grasps the whole context from the tree structure alone, without needing to open every code file.

Using the Season Concept

Umtri has a concept called Season — a unit for dividing up a project’s growth cycle. Just like the seasons in nature, a project also grows in stages.

How you divide seasons is entirely up to you. For example, you could split it like this:

Season	Content
Season 1	Core features (save/delete bookmarks)
Season 2	Tag and search features added
Season 3	Deployment and sharing features

Dividing things into seasons lets you see a timeline of “this feature existed in Season 1, and here’s how it changed in Season 2.” Later, when you find yourself asking “why did the structure change to this?”, you can look back through the history.

Practical Tip: A Routine for Adding Features

Here’s a routine worth repeating every time you add a feature.

1. Before you start: check the current structure

Pull up the bookmark-app tree from Umtri and summarize the current structure.

2. Write code: request one feature at a time

Break the feature into small pieces and request them in order.

3. Verify it works

Check directly in the browser that the newly added feature works correctly.

4. Record it: update the Umtri tree

Please update the Umtri tree with [what you added].

Repeating this routine keeps the structure from getting blurry no matter how many features you add. Every time you start a new task, you can always start with a clear picture of exactly how far you’ve gotten.

Coming Up Next

In the next post, we’ll cover deployment — how to take an app that only runs locally and publish it on the internet. We’ll also look at setting up GitHub Actions so that every deployment is automatically recorded in Umtri.