What I Want to Keep from Working with AI

When I finish a task with AI, I want to keep a method I can use again alongside the result. I want the next task to build on the judgment and experience I have accumulated, without repeating the same explanations and checks from the beginning.

I once gave a talk about how I work with AI. What I wanted to convey was less about mastering a particular tool and more about what to entrust to AI and what people should decide. I also wrote about it in “Why I Use AI: People Decide, AI Handles the Repetition”.

Many people are interested in how AI can solve a problem. So am I. But I am more interested in how consistently and effectively I can solve that kind of problem again.

Getting the result I want once is different from getting the quality I expect on the next task. If I have to explain my standards and working methods every time, I do not think using AI more often is enough. The outputs may accumulate while I still begin each new task with the same explanations and checks.

So I find myself thinking about what stays with me through the work, as well as what I have finished.

What sits behind a short request

In the talk, I used daily, a procedure for organizing the morning’s work, as an example.

Before I can begin, I need to find out where I left off yesterday. I read previous notes, check the current state of tickets, and look at code changes and review requests. These materials live in different places. Before deciding what to do today, I first have to gather the information that supports that decision.

The skill-sprint daily procedure I introduced was prepared for this purpose. It draws on previous daily notes, local Git changes, Jira ticket status, and GitHub pull requests and reviews to organize today’s work and the items to leave outside today’s scope. It does not automatically publish the result or send a message. I check and revise the priorities and any missing context, then decide whether to save the record.

What matters to me is what has been prepared behind that short request: what to read, how to organize it, and where a person needs to make a judgment.

The request /skill-sprint daily brings back context and procedures I have already organized. In the talk, I described a skill as a place to keep procedures and standards for repeated use.

Today’s task list is a useful result. But it also matters to me that the method for making that list remains available. The next morning, I can look at what has changed without explaining from scratch what needs to be checked.

Keeping the working method alongside the result

When I talk about turning work with AI into an asset, I include the process that produced the result. I want to retain the materials I consulted, the criteria I considered important, the sequence of work, and the checks that determine whether it is complete. What I missed, and how I discovered it, should be available for the next task too.

In the talk, I explained that context, tools, permissions, and the expected result need to be prepared before handing work to AI. That means deciding what material to consult, where to read it and save the output, how far AI may act, and what must be left behind for the task to count as finished.

I want to keep these conditions in a working environment I can use again, beyond the conversation itself. I can put judgment criteria and procedures into documents and declarative code, and connect repeatable actions and checks to tools. APIs and MCP connections that provide access to the required material, along with the development environment that runs the work, are part of that foundation.

Still, I do not think creating a file immediately makes it an asset. I need to be able to bring it into actual work, run it, and check whether the result meets the standard. I also need to keep examining the gap between a procedure written down and one that actually works.

AI saying “I’m done” is not enough. I need to check what we agreed would count as complete and whether those conditions have been met. When the result falls short, the work needs to be checked and corrected against the original criteria. Changing the explanation to fit the result does not resolve that gap. If the criteria themselves need to change, the reason should be made explicit too.

The consistency I want is the ability to maintain the standards I care about across different tasks. I am interested in making repeatable checks part of the working setup, so that people can judge important exceptions and completion without rechecking every result from the beginning.

What should remain when the model changes

Thinking about this kind of environment also makes me consider my dependence on tools.

I expect to keep using models from the major AI companies. Rather than competing with the performance and scale of the models themselves, I want to use their advances to better solve problems for people I understand.

But I do not want the way I work with those models to exist only inside a particular service. When choosing a new tool, I want to consider what I could take with me if I later switched, as well as how convenient it is now. Would the standards, procedures, and execution records I have built still mean something outside that service?

I want to borrow the model’s intelligence while keeping my judgment criteria, working procedures, execution tools, and verification methods in a form I can manage.

I am not trying to build every tool myself. Sometimes a well-made external service will be the better choice. I just hope that losing access to a service would not also mean losing the way of working I have built around it.

Changing a model or execution environment will mean reconnecting and checking some things. Even so, I want to avoid having to start over on what I am trying to make, which standards I need to maintain, and how to verify the result.

Tools may change. I hope the judgment and experience I gain while using them can inform the next choice.

The services I want to build on that foundation

My interest in this environment is also connected to the kind of services I want to make.

I think it is becoming possible for one person to build a service that deeply satisfies 1,000 to 2,000 people. This is a direction I see potential in and want to pursue, rather than a business result I have already demonstrated.

As the cost of building a service falls, I want to pay more attention to each person’s preferences and circumstances. I imagine something like an omakase service: an experience thoughtfully chosen for the people I understand.

That does not mean I want to provide one tiny feature and stop there. I want to address a person’s need in depth while also meeting some of the related needs around it. A service with depth, and some breadth too.

To keep building and operating such a service on my own, I cannot spend my time starting from scratch on every recurring task. I would like to spend more of that time understanding people and refining their experience, instead of finding materials, explaining the same standards, and correcting mistakes I have already encountered.

This is another reason I care about consistency in my working environment. I think a foundation I can trust with recurring work would let me focus more on people’s different circumstances and on problems I have not yet found an answer to.

Not starting the next task from scratch

In the talk, I called this accumulation “AI compounding.” I meant being able to begin the next task without starting from scratch.

I keep useful requests and corrections, working standards and good examples, and checks I have actually run. The next time, I bring them back and update the conditions that have changed. This does not mean a model automatically learns about me, or that everyone is guaranteed the same results. It takes trying, checking, recording, and revising for anything to accumulate.

Building this foundation takes time at first. I need to decide what to delegate, connect the necessary material, and prepare ways to notice when a result is wrong. For a single task, simply doing it myself may be easier.

So what I want to examine is not the number of skills or documents I have created. Am I explaining the same things less often? Am I spending less time rediscovering mistakes I have already made? Does this actually help once preparation, review, and rework are included?

Each time I finish a task, I want to consider whether I can also leave behind a method for the next one. Which judgments can become written criteria? Which recurring tasks can I turn into tools, and where is human judgment still needed? Distinguishing among them is part of what I am working through now.

Of course, building the environment must not become an end in itself. What I wanted to come back to in the talk was better work and more room in life.

What I want to keep from working with AI is a foundation that lets me begin the next task without starting over. I hope it helps me build the services I want to make, and leaves a little more room in my life.