A rubber duck that evolves with usage, not time

For a while, the rubber duck was one of the better metaphors I had for working with AI. The useful part of rubber-duck debugging has never really been the duck. You explain the problem out loud, and the act of explaining forces you to make things explicit. Something that felt perfectly clear in your head becomes less clear once you have to describe it properly. Sometimes the answer appears before you have finished explaining the question.

I still get that effect with AI. There are plenty of times when I start describing a product problem, a strange piece of behaviour or an architectural question and realise halfway through that I have already found the thing I was missing. But there is one important difference: the duck never changes.

If I explain the same kind of problem to it six months later, it knows exactly as much about me, the product and the previous discussion as it did the first time. It does not know that I tried one approach already. It does not know that I changed my mind about a decision. It does not know what I meant the last five times I used a particular term, or which part of its imaginary answer I would probably reject.

With an AI assistant, repeated use can make that interaction quite different. I do not mean that the underlying model is quietly retraining itself on me every time I use it. I do not need that claim for the observation to hold. A model can stay the same while my experience of working with it changes substantially. What changes is the working context around it when relevant previous discussions, corrections, decisions and conventions are available to the current work. That distinction has become much more important to me than I expected.

A surprising amount of collaboration is reconstruction. Why did we make this decision? What have we already tried? Which constraint matters here? What does this term mean in this project? Which option did we reject last time, and why? Has anything changed since then?

With another person, some of that context comes naturally through working together. Some gets written down. Some has to be reconstructed in meetings, messages, tickets and documents. If enough time passes, even people who were part of the original decision can remember it differently.

When I first started using AI heavily, I treated re-explanation as normal. A new task meant rebuilding the relevant world around the task. I would explain the product, the current state, the constraints and what I wanted. If the conversation moved somewhere else, I would rebuild enough of it again. That still happens. Context is never complete, and sometimes starting clean is exactly what I want. But it happens much less than it used to.

HoursKZ is an easy example because I have been working on it long enough for the difference to be obvious. I do not want to spend the first part of every discussion explaining that it began as a small Telegram tool for employee time tracking in my coffee shop, that Telegram was already part of the operating environment, or that real use gradually exposed connections to the work around the original workflow. Those things matter when we make a new decision, but they are rarely the new decision themselves.

Even something as simple as the choice of interaction channel illustrates the point. Once Telegram had proved to be a natural place for the employee workflow, I did not need every later product discussion to reopen the question of why Telegram was there. That decision could remain part of the working context while the conversation moved on to the new problem.

If the relevant context is already available, I can begin much closer to the actual problem.

The same thing happens in less visible ways. A particular approach may already have been considered and rejected. A term may have a project-specific meaning. A constraint that looks arbitrary in isolation may exist because something went wrong previously. If that history carries forward, I do not have to compress it into every new instruction.

This Journal has made the effect particularly obvious to me because writing exposes small preferences very quickly. I have corrected AI-generated drafts for fragmenting paragraphs, turning observations into frameworks, over-polishing language and making something I actually experienced sound like generic thought leadership. I have corrected title conventions, repeated wording and the tendency to make a conclusion sound more settled than it really was.

None of those corrections is profound. They are also exactly the kind of thing I do not want to repeat indefinitely. When they carry into later work, I spend less time correcting the same surface problems and more time looking at the actual argument. The assistant has not become a better writer in some universal sense. It has become easier for me to work with because more of the context about how I work is already present. That is a different kind of improvement.

It also shows up in product and technical work. I tend to care about certain questions repeatedly. What else does this change affect? Are we solving the actual operational problem? Did we already try something similar? Has a requirement changed since the last implementation? Is this a local issue or something that appears elsewhere? After enough repeated work, those questions stop being isolated instructions and start becoming part of the surrounding context of the work.

I still have to ask them. I still have to review the answer. But I am no longer always starting the conversation from a blank page.

This is where the phrase *it evolves with usage, not time* started making sense to me.

Elapsed time by itself does not build shared working context. I could stop using an assistant for months and, whatever else changed in the product, that time alone would not create a history of decisions, corrections or working patterns between us. A much shorter period of intensive work can produce dozens of corrections, decisions, conventions, rejected approaches and examples of what did or did not work.

The difference comes from interaction. A correction matters because there was something to correct. A preference becomes useful because it appears repeatedly in actual work. Project terminology becomes meaningful because it is attached to decisions and consequences. Even the way I ask questions changes when I know I do not need to explain every surrounding detail first.

That last part is easy to underestimate. A long instruction often contains several different jobs. Part of it explains the problem. Part of it reconstructs history. Part defines terminology. Part warns against something that went wrong previously. Somewhere inside all of that is the thing I actually want to work on now.

When enough relevant context is already there, the proportion changes. More of the conversation can be about the current problem.

I notice this most when switching between very different kinds of work. One moment I may be reviewing an article. Later I am discussing architecture, debugging an implementation or working through a product decision. Earlier, each transition felt more like opening a different tool and configuring it for the task. Increasingly, I can continue from an existing body of context instead.

That does not mean one giant conversation should contain everything I have ever done. That would create its own problems. Different projects need boundaries, and irrelevant history is still irrelevant. The useful part is not the quantity of accumulated context. It is having the right context available when it matters.

More usage does not automatically make the collaboration better. It can just as easily create more material to misunderstand.

One of the least useful forms of continuity is when an assistant carries forward something I said when I was wrong.

I can make a correction based on a misunderstanding. I can establish a convention that made sense for an earlier version of a product and no longer makes sense now. A decision can be superseded. A constraint can disappear. Something I rejected six months ago may become reasonable because the surrounding conditions changed.

If old context keeps being treated as current, the assistant can become efficiently wrong in a very familiar way.

I have seen smaller versions of this often enough to pay attention to it. A previous decision appears in a new discussion as though it were permanent. An earlier assumption quietly shapes a recommendation even though the product has moved on. A wording preference that was useful for one type of document starts appearing somewhere it does not belong.

This is the other side of reducing re-explanation. When I had to reconstruct everything manually, I was also forced to decide what was still relevant. That was inefficient, but the reconstruction itself created a natural review point. If context carries forward more easily, I have to notice when something should stop carrying forward.

Sometimes that means explicitly replacing an old decision with a new one. Sometimes I want the previous context preserved as history but no longer treated as an instruction. Sometimes the cleanest answer is to start with less context rather than more.

That has changed the responsibility involved for me. I am not only giving AI the information it needs to do the current task. I am also shaping the context that future work may inherit. A bad instruction can affect one result. A bad assumption that becomes part of the ongoing working context can influence several later results before I notice what happened.

The reverse is also true. A useful correction does not have to disappear when the immediate task ends. A decision can remain available along with the reason behind it. A mistake can become context for recognising the same pattern later instead of becoming something I rediscover from scratch.

That is where the ongoing value starts to feel different from a normal tool. The rubber-duck metaphor still works for the act of explaining. I still benefit from having to articulate the problem, and I would not want AI to remove that part. Thinking becomes clearer when I have to put it into words.

But the thing on the other side is no longer necessarily identical every time I return. When the relevant previous context is available, it can know that we discussed something before. It can connect the current question to a previous decision. It can know that I rejected an earlier approach, that I use a particular term in a particular way, or that the last attempt failed for a reason that might matter again. It can also inherit the wrong lesson from any of those things.

That is what I mean when I say it evolves with usage, not time.

The interesting change is not that the model somehow knows me in a mystical sense. It is that less of the relevant past has to be reconstructed before useful work can continue. The working relationship changes because the context around the work has history.

And once enough of that re-explanation disappears, another kind of friction starts disappearing with it.

I am not yet sure all of that friction was useless.