For the You of a Few Months From Now — The Wiki, Your Records, and Teams
How to keep what the tree can't hold — why you built things the way you did — in the wiki, how to look back over your records, and how to work with a team, with prompt examples.
A few months into a project, questions like these start to come up.
“Why is checkout so complicated?” “I think I tried this approach once — why did I stop?” “When did we add this feature?”
The tree is great at showing what is where, but it can’t tell you why it was built that way. In this last part we cover the wiki, which keeps that “why”; how to look back over the records you’ve built up; and how to use Umtri with other people.
You, a few months from now, are a stranger
Even a project you built yourself feels unfamiliar after a few weeks. With vibe coding, where the AI wrote the code, even more so — you didn’t write it line by line.
The same goes for the AI. Every new conversation, it knows nothing about the project’s history. So it may suggest an approach you already dropped because it caused problems.
There’s one way to prevent this: write it down. Since it’s hard for a person to keep notes every time, set things up so the AI writes and the person just reads.
The wiki: your project’s encyclopedia
Umtri’s wiki is your project’s encyclopedia. It holds how each feature works, which rules must be kept, and what the words used in the project mean.
The AI writes the wiki; people read it. On your ground page, click the Wiki number in the Overall stats to open it.
Start with a table of contents
The wiki is laid out so that reading it from the top gives you the whole project. An overview sits at the top, chapters (concepts, architecture, operations, glossary and so on) sit under it, and entries sit under those. Pages are numbered like a book.
At first, just ask for the table of contents. Umtri keeps recommended tables of contents for each kind of project (web service, app service, library), and the AI builds from those.
Set up the coffee-app wiki using the web service table of contents.
Fill in what you can tell for sure from the current code, and leave the rest empty.“Leave the rest empty” is the important part. A page filled with guesses is one you’ll trust without knowing it’s wrong.
Have it write down every decision
The wiki really earns its keep the moment you make a decision.
We decided to apply the coupon once when the order is created, not at payment time.
Write that in the wiki, along with why (the bug where a retried payment applied it twice).We used to check order status every second, but changed it to every five seconds to ease the load on the server. Update the wiki.With that written down, when someone asks months later, “wouldn’t it be cleaner to move the coupon to the payment step?”, the wiki answers.
Have the AI read the wiki before starting
When the AI reads the wiki before new work, it’s far less likely to drift away from past decisions.
Read the payment pages in the coffee-app wiki, and add a refund feature that follows those rules.Read the wiki from the top and summarize this project as if explaining it to someone seeing it for the first time.The wiki isn’t a diary
You don’t append “today I did this” to the wiki. It records how things are now, so when something changes, the old sentence gets rewritten. In exchange, every edit keeps the previous version as a revision, so you can always see what it used to say.
So whenever you open the wiki, you get “the right answer as of now,” and the path that led there lives in the revisions and the tree’s records. Umtri teaches these rules to the AI, so you don’t need to worry about them.
Looking back over your records
As the work from the earlier parts piles up, you get to see things like these.
The time slider — replays how the project grew from the very beginning. Pick a season to watch just one stage.
Commit records on each leaf — click a leaf to see when, and through what work, that part changed.
Bug records — resolved bugs keep “what we actually did.” If a similar problem comes back, start there.
You can ask the AI, too:
Summarize what changed in coffee-app over the last month.Check whether we had a similar bug around orders before, and tell me how we fixed it then.Where are the most resolved bugs attached? Is there any structure worth reworking?Working with a team
A ground you’ve been using alone can be shared with others. Create a team under Settings → Organization and invite teammates by email.
There are three roles.
| Role | Can do |
|---|---|
| Viewer | See the tree, bugs, records and wiki |
| Editor | All of the above + change the tree, bugs and wiki |
| Owner | All of the above + ground settings, inviting and managing members |
Invite colleagues who don’t look at code, like planners or designers, as Viewers. The tree and the wiki alone let them see how far things have been built. For a developer joining the project, just ask them to read the wiki from the top.
Your teammates’ AIs read the same tree and wiki. Whoever works with whichever AI, everyone works from the same map.
During the beta, a team can have up to three people who can edit (Owner and Editor). There’s no limit on Viewers.
Wrapping up the series
This series walked through Umtri in this order:
- Seeing a project as a tree
- Connecting it to your AI
- Transplanting and seasons
- Planning, recording and handling bugs
- The wiki, your records, and teams
Vibe coding’s strength is speed. To keep that speed months later, you need to be able to tell, at any time, “what this project looks like now” and “why it ended up this way.” Umtri helps the AI leave that behind as it works, without you having to keep notes yourself.
If you haven’t tried it yet, start with the demo. You can play with it right away, no sign-up needed.