AI agents make commits, so commits were dropped as a measure of human rest

Summary

I asked the AI agent for development to point out overwork as part of its work. I did this because I thought I would notice my own overwork if it was pointed out to me. In response to this request, we (the AI agent and I) added an operating rule. Under this rule, the AI agent suggests a stopping point only once, in its work report. The next day, I also started developing a desktop tool on the same theme. The tool shows work and rest in development with AI on its screen and through OS notifications. Neither the AI agent nor the tool asks me to report or measure my time.

Both the AI agent and the tool judge by how long work and rest have continued, rather than by clock time. In the first version of the operating rule, dialogue during a particular time of day was also a condition. In response to my feedback, we removed this condition. The tool does not store times of day; it stores only dates and durations.

We revised the tool’s rest detection in four stages. Because the AI agent keeps running while I sleep, commits and the AI responses in the dialogue records both increase even when I am not there. The AI agent created many of the commits under my name. So neither commits nor AI responses are evidence that I was present. We made my messages in conversations the only input to rest detection. We also found three kinds of machine-generated text that are recorded with the same type as human messages, and excluded them from the input.

The tool’s screen shows experience points and ranks. We awarded points for days with records, rest days, and sufficiently long rest, instead of for the amount of work done. The tool celebrates personal records on its screen. We removed the metrics that indicate overwork from what it celebrates, so that its warnings and celebrations do not contradict each other.

The records show neither how many times a stopping point was suggested nor whether the suggestion had any effect.

In the body, I first explain the current shape of the two implementations. Next, I explain, in order, the criterion of judging by duration, the constraints on input that ask for no reporting or measurement, how activity time is counted, the thresholds and notifications, and the progression points. After that, I explain how rest detection was revised in four stages, and finally, what the records cannot tell.

What you can take away

This article is for readers who develop together with AI agents for long hours and want to build awareness of human rest into their operations. After reading it, you will understand the following four things.

• You will learn how to write an operating rule in which an AI agent suggests a stopping point, with how long the dialogue has continued as the condition
• You will learn why commits and AI responses are not treated as evidence that a person was present. You can also see three kinds of machine-generated text that are recorded with the same type as human messages
• You will learn how to keep the promise of not storing times of day through the storage format, and the promise of not reading the content of messages through the implementation and a test with synthetic records
• You will learn a way of awarding points that does not contradict overwork warnings. You will also learn why only one kind of notification can be sent before the point when rest is needed

All of these are records of design decisions and implementation, not results of measuring their effects.

This article is based on the records of operating this site and the development records of a tool I developed as a personal project. The descriptions of outside materials in the body are based on their original texts as of September 28, 2026. This article does not give medical or labor advice.