I started keeping notes on what AI changes in product work

HoursKZ started because I was tired of tracking employee time manually in my coffee shop. It was supposed to be a small Telegram tool: solve one annoying operational problem and move on.

It didn’t stay small.

Somewhere between the first version, the things real use exposed, the changes I made with Codex, the tests, the mistakes, and the things I misunderstood along the way, I realised I had started keeping a second record of the work. Not product documentation. Notes about what AI was changing in the way I worked.

The record I was missing

The product work already left plenty of records behind: requirements, tickets, prompts, commits, test results and deployment notes. I could usually reconstruct what had changed in the software. The observations I kept returning to did not fit neatly into any of those places.

A task that worked much better than I expected. A prompt that looked clear to me but was not clear at all. A moment when the AI produced exactly what I had described and I realised I had left out the part that actually mattered. A change that looked complete in the repository but felt incomplete as soon as it returned to the real workflow.

There were also mistakes that were plainly mine. I have stopped a long-running agent task because I thought it had stalled, only to discover that the work itself was not the problem. It had kept going; only the window I was watching had expired. I have given Codex instructions that made complete sense in my head, then looked at a coherent result and realised I had left out the part that actually mattered to the product.

Those incidents were small. They were usually fixable. That also made them easy to dismiss once the immediate problem was gone. But they kept accumulating. I had records of what changed in the products, but not a reliable record of what changed my mind.

At first I wrote these observations wherever I happened to be working. Some ended up in project chats. Some were buried in retrospective lists. Some sat beside the requirements they had complicated. Others stayed in my head until another project brought them back. Eventually that stopped being enough.

Looking at the same work from different directions

I tend to move across the whole product rather than stay inside one discipline: the business problem, the product decision, architecture, implementation, testing and delivery. That means I often encounter the same decision more than once, from different directions.

Something that seems sensible while defining the requirement can look different when it is being implemented. A technically clean result can become awkward when it reaches the real workflow. A feature that appears useful in isolation can create more work somewhere else. Owning the business where HoursKZ is used makes that last part difficult to ignore. The software eventually has to meet the operation it was meant to improve.

AI agents let me move through much more of this cycle directly, and much faster. That is useful. It also gives my mistakes more room to travel.

A weak assumption made early can become a polished implementation surprisingly quickly. A vague instruction can produce something technically respectable that still misses the point. Sometimes the problem only becomes obvious once the result is concrete enough to use.

None of that means the tools are failing. Sometimes they are. Sometimes I am. Often the more interesting problem is the interaction between the two. That interaction is what kept generating notes.

The interesting part is not only speed

The obvious story about AI-assisted product work is speed. Work that once required several handovers can sometimes happen inside one continuous thread. I can begin with an operational problem, make the expected outcome more precise, ask an agent to implement a substantial change, inspect what came back, follow the checks, revise it, and return it to use without rebuilding the context for a new person at every stage. That changes what is practical for a small team, and sometimes for one person.

But speed is not the part I find myself thinking about most. The distance between a decision and its consequences is getting shorter. That can accelerate learning. It can also accelerate the wrong assumption.

When implementation is expensive, cost creates natural resistance. When a capable agent can build something quickly, saying yes becomes easier. The difficult question shifts from whether something can be built to whether it belongs in the product at all. I have not found a clean rule for that.

Real use helps, but it does not remove the judgment. A repeated request may reveal a genuine need, or it may pull the product toward every nearby inconvenience. Letting an agent continue can preserve useful momentum, or allow a misunderstanding to travel further. These are not questions I solved before starting the work. They appeared because I was doing it.

Why write the notes in public?

Partly because writing forces me to separate what happened from what I now think it meant. A private note can stop at “this went wrong.” A public entry needs enough context for another person to understand what I believed at the time, what happened next, and which part of my interpretation is still uncertain.

It also makes retrospective editing harder. Memory has a way of smoothing out the sequence. The wrong assumption becomes “an early hypothesis.” The missed detail becomes “an iteration.” The moment of confusion disappears completely, and the final lesson starts to sound as though it was obvious from the beginning.

Usually it was not.

I want to preserve more of that progression, including the parts that make me look less certain than the finished product might suggest. I also suspect these observations will be useful beyond my own projects. Someone beginning to work with AI agents may find that the impressive part is easy to notice, while the day-to-day complications arrive later. Someone with more experience may recognise the quieter questions underneath the work: how context degrades, how trust is earned, when intervention helps, when it interrupts, and how human judgment changes when the machine can act rather than merely answer.

I keep coming back to one simple habit: record not only what changed in the product, but what changed your mind. That is what this journal is for.

It is not a universal method, and I am not starting with a settled position on where AI is taking product work. Some entries may age badly. Some questions may turn out to be based on misunderstandings. I may revisit an observation and decide that I was looking at the wrong problem. That is acceptable.

I would rather document the work while the questions are still open than rewrite it later as a neat success story. I have enough observations now to know they are connected. I do not yet know exactly where those connections lead.

The next note starts with one very small operational problem and the decision to solve only that.