Designing how I work with AI

In my previous article about AI, I put “feed my god complex” in the subtitle. Being able to describe an idea and get something you can actually click does have that effect.

I still love that part. It makes ideas feel possible before I've worked out exactly how to build them. But as AI becomes part of more of my work, I'm getting interested in the arrangement around it. How do we explore together? What should it take care of? What needs my attention? And how much of what we learn can carry over to the next project?

I'm finding myself designing the collaboration as well as the thing we're making.

The help I want changes during the work

Sometimes I know the problem and have a fairly clear direction. Then I want the assistant to read the existing material, find the gaps and prepare something I can review. Having to explain every intermediate step defeats a lot of the appeal.

Other times, figuring out the direction is the work. I'd like help considering alternatives, understanding their consequences and making them concrete enough to compare. Sometimes that means asking for guidance. Sometimes I have an idea I want to follow, even if I can't explain where it leads yet.

A useful AI workflow has to leave room for both. I can want a recommendation in one moment and want to explore in the next. My part is to keep judging whether we're working on the right problem and whether the result makes sense for the people using it.

A small example: while designing group changes for contacts, I asked the assistant how it would handle saving. It recommended letting someone adjust several choices before pressing Save changes. I accepted the direction, and it prepared the sketch states for review.

A recommendation becomes something concrete to review. This is a simplified design example.

That's a useful division of work. I get something to question and develop. The assistant has enough responsibility to contribute a point of view. The next step can still be another sketch.

The workflow should learn something too

A design project leaves more behind than its screens. There are decisions about the product, but also discoveries about how I want to work. Maybe I need the assistant to ask better questions before drawing. Maybe its first proposal is worth exploring, but it needs to check the product's existing patterns.

I'd like those corrections to improve the setup. Otherwise I'm having the same conversation with a very enthusiastic new colleague every time.

This is where skills and project folders come in. A skill is a set of reusable instructions, stored in a folder with a SKILL.md file. My product-design skill describes the different ways we can work together. Project notes hold the current decisions and open questions. The starting instructions tell the assistant where to find them.

Working methods and current project knowledge have different places to live. The names are examples.

Writing style is an easy example. I don't use em dashes, and I normally want existing text reviewed before it's rewritten. Those preferences belong in a skill because they apply wherever I'm writing. A decision about saving group changes belongs with that product.

The setup also gives the assistant somewhere to look beyond our chat. Recently, it asked me questions that had already been discussed in meetings. I sent it to the notes, and it came back with fewer questions. That's the behaviour I'm trying to make routine: use the context we already have, then involve me where something still needs deciding.

These are ordinary files I can inspect and change. If an instruction makes the work too rigid, I can revise it. Writing down a method doesn't make it finished.

I want to own the way I work

I use both Codex and Claude. The effort I put into a workflow should still be useful when I switch tools.

For my work projects, both point to the same original skill files and shared project instructions. Each has the extra setup it needs. When I adjust how I want to approach product design, there's one original to update.

A shared way of working, available from either tool.

That's what “agent-agnostic” means to me here. The tools still need their own source connections, and they won't behave identically. But the accumulated knowledge about my work lives somewhere I control. I can read it, disagree with it and take it with me.

I like the idea that, over time, this becomes a fairly personal working environment. It reflects the products I work on, the kinds of help I ask for and the things I keep correcting. There is no reason your version should look exactly like mine.

Making room to go further

The possibility that interests me is having more room to think through a design. To try an alternative before dismissing it. To ask for a critique, then have something concrete to discuss. To pick up an unfinished idea with its earlier decisions still available.

That asks something of me too. I have to notice when a useful instruction has become a habit that limits the work. I have to keep questioning a convincing proposal. And I have to decide when exploring another option will actually help.

I'm still working out this arrangement. The files and skills will keep changing as I do more with it. I want help through the awkward middle of a project too, when the first version is wrong and I don't yet know what should replace it. That's where having more ways to explore could make a difference to what I end up designing.