# How to design personal software

By Eduardo Martínez, 2026-11-01

Rethink your priors.

Software has been built for the average user for a long time, because building one product for millions of people was the only way to pay for it. You got the same menus as everyone else and learned to work around the parts that didn't fit you. Agents change that math. When an agent can build and change tools for you, the software can fit the one person using it, and I think that changes how you should design it.

I'll use one build of mine as the example, because it shows the steps better than a theory would.

## I didn't ask for a clone

I wanted a stronger creative studio for my agents. I make short videos with drawings made by code, and I wanted my agents to edit images, lay out a poster, fix a photo and hand me something I could check.

The easy request would have been "build me Photoshop." You can tell an agent to do that, and it will try. Photoshop was designed with a human driving it, though: a mouse, a stack of menus, and a pair of eyes on the screen deciding when an edit looks right. My agent has none of those. Copying an interface built around human hands gives the agent a tool shaped for someone else.

![Two paths from "I want a creative studio": clone the app leads to menus built for a human; start from the outcome leads to what experts deliver, then tools an agent can check.](https://rethinkyourpriors.com/assets/articles/how-to-design-personal-software/1-clone-vs-outcome.png)

## Start from the outcome

I started from the outcome instead and worked backwards. I had my agents research what an expert video editor, a photographer and a photo editor are responsible for delivering. Those outcomes are easier to find than a clear answer on which tools are right for which jobs. Ask ten editors which app to use and you get ten answers. Ask what a finished cutout needs and you get close to one: the hair stays, the background goes, and nothing else in the picture moves.

Next I had them look at the techniques and processes those experts use today to get there. I did this because the techniques hold patterns that carry over to an agent, even when the tools don't.

Then I asked them to build the tools that let an agent reach those same outcomes. The result is the Agent Drawing Studio. Its outcome library has twelve entries, written the way a person would ask, like "Remove that sign behind me" and "Make this narrower without squashing the person." Each run states which parts of the image must stay untouched. The runner refuses to declare success if a protected region changes, and failed attempts stay on disk with a failed receipt, so I can see what went wrong.

I did keep a Photoshop reference in the repo. It is a feature map the agents use to check for gaps, and the README says plainly that the studio is not Adobe Photoshop. The checklist helps. It didn't decide what to build.

## Track what you ask for

The part I'm turning on next closes the loop. My requests to my agents get tracked, and the studio's capabilities get improved based on what I ask them to do. Today that tracking does not exist in the repo yet, so treat this section as the plan.

My agents already ran a first pass over my requests from the last two weeks of October, and it found something I would have missed. On October 22 I asked my agents for a feature in Handgrown, my own product: let a brand hold approved applicants until launch day, then release them in one reviewed batch. That change ended up with 15 comments before it merged, more than any other change in that repo over those two weeks. The same week, I filed separate requests so an agent could do things a person could already do in the Handgrown console: manage member invitations, draft applicant emails, read and reply to member messages, and save notes back. Those sat next to a rule I had written down the same day, that a feature counts as done only when an agent can use it too.

The pattern was plain once the requests sat in one list. We kept building features for the console first and for agents second, then went back to fill the gap. Handgrown's automated checks already fail a change when an agent can use a feature but has no way to save what it learned back. The next step the pass proposed is to check agent access while a feature is being designed, before anyone builds the console screen. I would not have seen that from any single request.

![Requests from two weeks show features built for the console first, then a later request for agent access, then going back to fill the gap. Proposed: check agent access at design time.](https://rethinkyourpriors.com/assets/articles/how-to-design-personal-software/3-console-first-pattern.png)

If I ask for color matching every week and never ask for print plates, the agents should get better at color matching and leave the plates alone. They keep asking which capabilities I need, then build those. I stop building things I don't need, which is most of what a general product carries around for other people.

The full loop has five steps. You start from the outcome. You research what the experts who own that outcome deliver and how they do it. You build tools that let an agent reach the same result, with checks that prove it. You track what you ask for. Then you improve the capabilities you use and ignore the rest, and you go around again.

![Five steps in a loop: start from the outcome, research what experts own, build tools an agent can drive, track what you ask for, improve what you use, then go around again.](https://rethinkyourpriors.com/assets/articles/how-to-design-personal-software/2-five-step-loop.png)

## Systems thinking holds it together

None of this works if you think in single features. A loop is a system: inputs, outputs, checks, and feedback that changes the next round. If you skip the checks, the agent ships edits nobody verified. If you skip the tracking, you build for an imaginary user again, except now that user is a guess about yourself.

Two outside projects shape how my agents change this code. The first is pstack, a set of agent skills published in Cursor's plugins repo, with a portable mirror on GitHub. My repos use its refactoring and skill-authoring playbooks, its formal verification skills, which check state machines with TLA+ and the TLC model checker, and its statechart skill, which turns those results into Mermaid diagrams. The second is Ponytail, an open-source project by Dietrich Gebert, whose rules for making a complete change my repos follow.

My engineering loop combines the two. Before an agent changes code it maps every caller and test the change touches. It picks the smallest change that covers the whole task. It tests failure cases as well as success, looks at the rendered image instead of trusting an exit code, and gets a review from an agent that didn't write the patch. After a merge, it reads the merged revision back from GitHub before telling me it's done.

That discipline is what makes a personal loop safe to leave running. Agents that keep adding capabilities need a process that catches what breaks.

## Where this goes

I think the smart platforms will move this way: software that watches what you ask for and reshapes itself around it, instead of shipping the same release to everyone. You don't have to wait for them. You can build this for yourself now with an agent, a repo and a habit of writing down what you asked for.

It doesn't have to start big. Pick one area where you keep asking your agents for help. Write down the outcomes an expert in that area owns. Have your agent build toward those, with a check for each. Keep a plain log of your requests, and once a month look at what you asked for most and improve that.

Start from the outcome, then work backwards.

---
Rethink your priors by Eduardo Martínez. AI implementation. Outcomes over tools. And everything else.
YouTube: https://www.youtube.com/@rethinkyourpriors · Instagram: https://www.instagram.com/rethinkyourpriors/ · Work with Eduardo: https://edumartinez.ai/