Short answer

An AI assistant that writes code is only as reliable as the context it receives. If the project's rules and status live in the repository, versioned alongside the code, any assistant or person can start where the previous one left off, and every change leaves a trail. The method fits in a handful of files: a document of binding rules, a lightweight memory folder, three session prompts (start, close and handover) and a guard that runs before every commit.

Key points

  • If the project's rules and status live in the repository, versioned alongside the code, any assistant or person can continue where the previous one left off.
  • There should be a single document of binding rules, with each tool's instructions file simply pointing to it, so that there are never two versions of the truth.
  • Shared memory should be deliberately lightweight and size-limited, because a memory that grows unchecked stops being read.
  • A handover note with the task, the work done, the work half-finished, the exact next step and what was not verified lets anyone resume without reconstructing anything.
  • A guard before every commit checks that private material is still ignored and that nothing looks like a secret; if it fails, there is no commit.

A single source of rules

Every tool has its own instructions file, and it is tempting to maintain several versions. It is better to have a single rules document and for each tool’s file simply to point to it. That way there are never two versions of the truth about what may and may not be done.

Useful rules are concrete: where work happens and where it does not, which data is never opened, which actions require a person’s approval (deploying, changing a secret, touching DNS, writing to someone), how status is reported and which checks come before a commit.

Deliberately lightweight memory

Shared memory needs a few files with clear purposes: the current objective and status, the system as it stands today, procedures, outstanding work, lasting decisions with their dates and a log of what was done in each session. Anything superseded is archived so that each session starts by reading very little.

Setting size limits on those files, and having the guard fail when they are exceeded, forces summarising and archiving. A memory that grows unchecked stops being read, and a memory that is not read does not exist.

Starting, closing and handing over

At the start, the assistant reads the rules and the status, reports on the state of the repository and changes nothing until a person confirms. At the close, it updates the log, the outstanding work and the decisions, runs the checks and prepares the commit. Both routines are written once and shared across tools.

The handover is the piece that is usually missing: a dated note with the task, what has been done, what is half-finished (with the files), the exact next step and what was not verified. With that note and a commit marked as work in progress, another assistant, from another vendor, or the same person the next day, can pick up the work without reconstructing anything.

A guard before every commit and honest status words

A script that checks that private material is still ignored and that the staged change contains nothing that looks like a secret costs little and prevents the most expensive mistake. If it fails, there is no commit, and it states only the name of the problem, never the value.

Finally, vocabulary: ‘ready’ means it works locally with the tests passing; ‘deployed’ means it is published and checked with real requests; ‘validated’ means the responsible person has walked through it on their own computer. Using three different words stops a prototype from being counted as a delivery.

Frequently asked questions

How do we stop a project's context getting lost when working with AI coding assistants?

Keep the project's rules and status in the repository, versioned alongside the code, rather than in a tool's chat, which is lost when the tool is closed. Any assistant or person can then start where the previous one left off, and every change leaves a trail. The method fits in a handful of files: a document of binding rules, a lightweight memory folder, three session prompts (start, close and handover) and a guard that runs before every commit.

What rules should we give an AI assistant that writes code in our repository?

Concrete rules, gathered in a single document that each tool's instructions file points to. They should state where work happens and where it does not, which data is never opened, which actions require a person's approval (deploying, changing a secret, touching DNS or writing to someone), how status is reported and which checks come before a commit. Keeping a single source avoids two versions of the truth about what may and may not be done.

How can another AI assistant or another person pick up a half-finished task?

With a dated handover note recording the task, what has been done, what is half-finished (with the files), the exact next step and what was not verified. Together with a commit marked as work in progress, it lets another assistant, even one from another vendor, or the same person the next day, carry on without reconstructing anything. It is the piece that is usually missing.

What is the difference between work that is ready, deployed and validated?

‘Ready’ means it works locally with the tests passing; ‘deployed’ means it is published and checked with real requests; ‘validated’ means the responsible person has walked through it on their own computer. Using three different words stops a prototype from being counted as a delivery.