An assistant that remembers
In the stretches when I work alone, I learned to use Claude as an assistant and not only as the one who writes code.
Tuesday, 18:40
Let's find out why booking confirmations are not arriving.
I found the cause. The provider rejects emails that bounce.
I wrote the decision in the work log and in the ticket.
The session was cut off
Wednesday, 09:05
Where did we leave off?
I read the latest summary. We decided to validate the address before sending.
The change to the form is still pending, and it depends on product.
I checked the ticket and nothing has changed since yesterday.
Shall we go on with the form?
This entry is not about GATE. It is about how I work with Claude when I am alone with a problem, which in a role like mine happens often.
Almost everything written about AI assistants is about code: how much faster you program or how good the tests they generate are. But much of the time I work with Claude I am not programming. I diagnose incidents, prepare documents, review the team's work and follow topics that last for weeks. For that I need the assistant to know where we left off last time and what is still pending.
The practices I set up for this have little to do with the development cycle. I learned them over years of working with people, and they help anyone who uses an assistant seriously.
A log per topic
Each topic has a short summary: what was asked, what was decided, where each thing ended up and what is left. Claude writes it on its own, every time something moves forward, without waiting for the end of the session. I do it this way because a session can be cut off or summarised to free up space, and whatever was not written down is lost. Once a session was cut off in the middle of a change, and since the progress was written down, picking it up again took minutes.
The summary does not copy what is already somewhere else: if something is in the code or in a ticket, it links to it. And so that it does not depend on the assistant remembering, a hook reminds it with every message.
Picking a topic back up
When I come back to a topic, Claude first reads its latest summary. Then it checks the source for what may have changed, because a summary from a week ago can be out of date. If I open a session without asking for anything, it tells me in a few lines what is still open and where it makes sense to start.
That way I do not have to explain the context every morning, and in busy weeks that is a relief.
Decisions, with their reason
A decision written down without its reason is of little use. That is why each summary keeps what was decided and why, and also the options that were discarded and the reason for each. Weeks later, when someone proposes something that had already been discarded, the answer is written down and there is no need to argue it again.
Correcting only once
Claude has a memory that lasts between sessions, and I use it for what I do not want to repeat: how I like it to write, who should review each type of change or which is the only reliable source for diagnosing production. Every time I correct it on something that will come up again, the correction is saved with its reason and when it applies. It is the same as with someone new on the team: you correct them once.
Separate projects
I work on projects that must not mix: my company's, my personal ones and others with their own access. Each one lives in its own folder, with its identity and its credentials, and Claude does not leave the session's project unless I authorise it for that task.
Permissions work in a similar way. Reading, analysing and preparing need no approval. Writing to a shared system does, and the most sensitive things, such as production or a merge, always ask. That way the assistant moves on its own where it is safe and stops when a person has to decide.
Work on a board
Daily work goes into tickets and not only into the conversation. Before starting a topic, Claude looks for its ticket and, if there is none, creates it with the context, what needs to be done and how to know it is finished. Every step forward, blocker or decision is noted there right away, and the ticket changes status.
That makes visible work that used to live only on my computer, and it also helps me feel less alone, because others can see what I am working on. If someone else needs to know or do something, I ask with a comment on their ticket, mentioning them, and not over chat, where it gets lost. The log still exists, but it points to the ticket.
Check before claiming
The most important rule is that nothing is claimed without checking it against the code, the data or the real system. If Claude could not verify something, it has to say so. An assistant that sounds sure and is wrong does more harm than one that says what it does not know.
What changes
None of these practices is new. They are the same ones I expect from anyone I work with. The difference is that an assistant needs them written down, because it does not come with them. With that in place, Claude stops being only the one who writes code and follows the work with me from one day to the next.
It does not replace a team, and I do not want it to. But on long days it helps to know that the progress will not be lost when I close the window.