Not That I Couldn’t Fix It, but That I Didn’t Notice It — Cutting Down the Interfaces I Have to Remember#

2026-11-15

More to Keep Track of, Less Will to Start#

Apart from my day job, I run a few personal services and this blog under the name Ted Factory. There’s Code Battle, where you write a strategy as code and pit it against others; I am your AI, a Chrome extension that reads web pages and operates them for you; one service that hasn’t launched yet; and this blog, where I publish an AI news brief every week along with essays. I plan to keep adding apps one at a time.

The problem was the sheer number of them. For each project, I had to carry in my head how far it had come, what to do next, and what only I could take care of. While I held on to one, the context of the others blurred, and whenever I reopened one after a while, I started with “What was I doing here again?” Over time it became hard to decide on my own that “today I’ll do this here and that there.” Once deciding what to work on became a burden in itself, my will to start working shrank along with it.

Back in July, in Context Switching in the Age of AI Agents, I wrote about moving between several agent sessions on a scale of minutes. This problem works on a different scale: a person having to remember the context of several projects that stretch over days and weeks. So this time I decided to rework my personal work environment as a whole.

Two Work Environments#

My work environment is split into a work side and a personal side. On both I mostly use the Claude Code extension in Cursor, but the two were organized differently.

The work side revolves around a single hub repository. I linked repositories such as the backend, frontend, batch pipelines, and agent system into the hub with symbolic links, so the hub looks like a monorepoholding several repositories. I can start any task from the hub, and it’s easy to hand context to the agent when a task spans several repositories. There’s a downside too. Even when a task concerns only one repository, the contents of the others leak into the context the agent reads, and its focus blurs. Still, in practice the upsides outweigh the downside, so I’ve kept this setup.

The personal side was the opposite. I opened a separate Cursor window for each repository and worked inside it. The more repositories I had, the more windows I had, and the more windows I had, the more time I spent finding which window belonged to which repository.

The Difference Was in How the Repositories Relate#

At first I wondered whether I could simply copy the work setup. But when I put the two environments side by side, the relationships between the repositories were different.

The work repositories are tangled together. Change the backend and the frontend changes with it; the agent system uses data that the pipelines produce. It’s natural to treat them as one unit.

The personal repositories have nothing to do with each other. The code duel game and the Chrome extension share no code and no data. When developing, going into each repository separately helps the agent focus on one thing. There was one exception: the blog. The blog carries development notes and introductions for the other services, and after a service launches, it was also more convenient to look at its metrics and analyze them from the blog. Only the blog cares about the other repositories; the other repositories don’t know the blog exists. It’s a one-way relationship.

So I split the personal environment like this: develop in each repository, observe and record from the blog. Instead of imitating the work setup, I decided to match the shape of the relationships.

The Problem Was the Number of Interfaces to Remember#

Before picking concrete methods, I redefined the problem. What wore me out wasn’t the amount of work. It was that there were too many interfaces I had to remember and check just to do the work. I mean “interface” broadly here. The editor windows open for each repository, browser profiles, messengers, planning documents and metrics pages scattered across projects, and the mental note holding on to “what did I decide to do next?” — every one of these is an interface I have to deal with directly.

Each interface on its own is light. But as their number grows, the cost comes not from the work itself but from maintaining a mental map of what is where. No matter how carefully you maintain it, that map goes stale over time. So I settled on a single direction: cut down the number of interfaces I deal with directly. The interfaces don’t disappear. The idea is to keep just a few interfaces that deal with the many others on my behalf. Everything I built afterward applies this principle.

Cut One: Observe From a Single Place, the Blog#

The first cut was moving between repositories. In the blog repository’s Claude Code settings, I registered the other service repositories as additional working directories (additionalDirectories). Now a blog session can read the service repositories’ documents and commit history directly. I look at service metrics from the same place, too. I added one option that takes a property ID to the GA (Google Analytics) query script I was already using for the blog, and the same script produced Code Battle’s metrics.

I didn’t use symbolic links as I do at work, and the reason is focus. A repository connected as an additional working directory doesn’t have its rule file (CLAUDE.md) loaded unless you configure that separately. When I started a fresh session to check, the skills defined in the connected repositories didn’t appear in the blog session’s skill list either. While I write on the blog, other services’ development rules don’t creep in. I avoided, on the personal side, the very downside I put up with on the work side.

I gathered the list of connected services, and where to find each service’s metrics, into a single document in the blog repository. When a service is added, I add one section to that document and one path to the settings.

Cut Two: One Menu Instead of Hunting for Windows#

The second cut was windows. With several windows open, it was hard to tell which window belonged to which repository. Overlapping windows on screen were hard to pick out by name. If I minimized them to the Dock, hovering the mouse showed the repository name, which made them easy to tell apart, but minimizing and restoring them every time was a chore.

The solution came from what I learned building Sleep Guard in Making a MacBook That Never Sleeps. Back then I found that putting an icon in the menu bar and showing a menu when you click it was simpler than I had expected. So I could build a small tool: click the menu bar icon to see a list of repositories I’ve set in advance, and pick one to bring its window to the front if it’s already open, or open it if it isn’t.

While building it, I widened the scope. Once I defined a menu item as “a name and a one-line shell command,” anything that can be run from a terminal could go into the menu. Not just editor windows, but browser profiles, a messenger, and a coding agent’s desktop app all went into one menu. I split the menu into “Personal” and “Work” sections so the interfaces of the two environments don’t mix. You can open the menu with the mouse, or press a hotkey to make it pop up right at the mouse pointer. The menu file looks like this:

HOTKEY=ctrl+cmd+M

[Personal]
blog              = open -a Cursor ~/src/blog
code-battle       = open -a Cursor ~/src/code-battle
Chrome (personal) = ~/.local/bin/chrome-profile "Profile 1"
---
[Work]
work-hub          = open -a Cursor ~/work/hub
Chrome (work)     = ~/.local/bin/chrome-profile "Default"
Slack             = open -a Slack

The launcher doesn’t implement “bring the window to the front if it’s already open” itself; it leaves that to each command. When I checked, though, each command behaved differently. Cursor’s cursor <folder> command switched to the right window only when Cursor was already in front; if another app was in front, it couldn’t bring Cursor forward. Switching to macOS’s open -a Cursor <folder> brought the right window to the very front even when another app was in front. Chrome opened a new window every time when launched with a specific profile. So I wrote a separate small command (chrome-profile) that finds that profile’s window from the session records Chrome keeps in the profile folder, brings it to the front, and opens a new window only when there isn’t one.

I’ve published the tool as menubar-launcher. Edit the menu file and the change shows up the next time you open the menu, without restarting the app.

Cut Three: One Interface That Asks “What Should I Do Today?”#

The third cut was the biggest. Now I could find windows through the menu, but I still had to remember which window to open and what to do there. I moved that memory into documents and a skill.

First, I put a short document in each repository (.memory/goals.md) for its goals and to-dos. It has only a few sections: why I’m doing this project, the goal for the current stage and how to judge it, to-dos split into “now, next, and someday,” things only I can do, and recurring tasks. The detailed plans stay in each repository’s planning documents; this document holds only one-line summaries and links.

The key design decision was to keep this document inside each repository, not in the blog. If they were gathered in the blog, the development sessions wouldn’t know about them, and they’d go stale quickly. So I added a one-line rule to each repository’s agent instructions: “When you finish a task or the direction changes, update goals.md.” The documents get updated where the work happens, and the blog only reads them. The one-way relationship I set earlier stays intact.

Documents can’t decide which of the to-dos across repositories comes first. So I wrote down the business priorities in one place and decided that I alone would set that order.

Then I built a skill, /today, that pulls all of this together and makes suggestions. When I run /today in a blog session, a small script first gathers the facts: recent commits in each repository, uncommitted changes and how long they’ve been sitting, when each goals document was last updated, and whether recurring tasks like the Saturday AI news brief or the monthly checkup are due. The agent checks those facts against the priorities and the goals documents and picks up to three things to do now. Each suggestion comes with a prompt I can paste straight into that repository’s window, and I open that window with the menu bar launcher. The context I used to have to recall is inside that prompt.

The effect showed up even before the first run. When I gathered my existing notes and planning documents to draft the goals docs, I found that the project listed as priority number one in my business documents had been stalled for a month, with dozens of uncommitted changes piled up. My attention had already moved on to other projects, but the documents hadn’t caught up with that change. With the drafts in front of me, I reset the priorities from scratch. If I hadn’t pulled all this out into documents, that project would have kept lingering as a vague burden of “I really should get to that.”

On the first run, what /today put at the top was Code Battle’s weekly marketing round, which had been skipped for two weeks. It was something I had committed to doing every week and had forgotten.

From “Can I Fix It?” to “Do I Notice It?”#

The time I actually spent paying attention to all this was only an hour or two. Linking the repositories, organizing the goals docs, implementing the menu bar launcher, writing the /today skill — the agents did most of the hands-on work, while I said what bothered me, chose the direction, and checked the results. For the menu bar launcher, I handed the requirements to a separate Claude Code session and ran it in parallel with this work.

It used to be that to improve something, you had to know how to improve it. To build a menu bar app, you needed to know macOS app development; to collect the state of several repositories, you needed to know how to write scripts. Learning those things cost a lot, so I simply put up with most minor annoyances. That’s no longer the case. Finding a solution and actually building it can be handed to an agent. The bottleneck that remains is noticing that something needs improving.

And that noticing is harder than it sounds. Most of what I fixed this time were things that had bothered me for a long time without my ever calling them annoyances. Opening a separate window for each repository, minimizing and restoring windows in the Dock to find the right one, recalling how far I’d gotten on each project — these were so familiar that they felt like part of the work itself. People adapt to friction quickly. Friction you’ve adapted to stops looking like friction, and friction you can’t see doesn’t get fixed. I think there are still a great many things we put up with even though they could be fixed.

So I intend to pay deliberate attention to finding friction. It’s hard to call it a settled method yet, but this experience gave me a few clues.

• If you keep repeating the same motions. Minimizing and restoring windows, typing the same command again, opening the same screen every day to check on it.
• If you hear yourself say “that’s just how it is.” Much of what I fixed this time was what I used to brush off that way.
• If you’re relying on memory. Information that lives only in your head, like “I need to do this next” or “where was that again?”, eventually gets forgotten. The effort of trying not to forget is itself a cost.
• If your motivation has dropped. This time, losing motivation was the starting point. Behind not wanting to do something, there may be a structural friction hiding.

Once you’ve found the friction, the next step isn’t hard. Just tell an agent plainly what’s bothering you. You don’t need to bring a solution with you. This time, too, the first thing I said was little more than “it’s a bit inconvenient to go into each repository and open a session there separately,” and as the conversation went on, the menu bar launcher and /today emerged as solutions. Being able to put the friction into words came before knowing the solution.

Closing Thoughts#

What I built this time isn’t finished. Whether the goals docs keep getting updated where the work happens, and whether /today’s suggestions actually help me shape my day, I’ll only know by continuing to use them. When something feels off along the way, I plan to fix it then and there. I set things up so that each new app needs just one more goals doc and one more line in the menu, so even as the number of projects grows, the number of interfaces I have to face stays the same.

References#

• menubar-launcher (GitHub)
• sleep-guard-for-mac (GitHub)
• Claude Code docs: Settings (additionalDirectories)