How to learn your coding preferences from your own corrections

Ahmet Karaca · 31 October 2026

Why start from corrections?

People tend to describe how they would like to work, which is not always how they do work. A correction is different, because it was made during real work, in response to a real result. It also shows the case in which the preference applies, which a general statement usually leaves out.

How do you do it by hand?

• Save the sessions first. Claude Code deletes transcripts after 30 days by default, as the sessions guide explains, and /export writes a session as readable text.
• Start with your longest sessions. In the data below, corrections were concentrated in a few of them.
• Mark each message that pushes back on the reply before it. A message that only continues the work is not a correction.
• Group the marked messages by the behaviour they object to, not by their wording.
• Keep what appears in at least two separate sessions. A single correction may only describe that one task.
• Write each as an instruction that can be verified, with the reason next to it, and add it to CLAUDE.md, AGENTS.md or the file your tool reads.

What counts as a correction?

The examples below are illustrative, and the instruction is what remains after several such corrections.

What did the data show?

These figures come from one database, read on 31 October 2026: that of the person who builds Coredence. They describe one person working mostly in Turkish, measured with this product's own detector, and nobody outside has audited them. They are an example of what such a record contains, not a benchmark.

The gap between Claude Code and chat cannot be read as a difference in behaviour. The two sources contain different kinds of work, and the detector may not perform equally on both. The share of memories citing a correction is also not independent evidence, because the engine reads flagged messages first and is more likely to cite them.

How reliable is automatic detection?

The detector combines a list of pushback phrases, applied to messages that follow an assistant reply, with messages the model marks while reading. To test it, Claude read two random samples of Claude Code messages once. Of 40 flagged messages, 33 were real corrections. Of 40 unflagged messages of 10 to 400 characters, 5 could reasonably be called corrections.

The samples are small and were judged by a model rather than a person, so these are rough figures. They still suggest two practical points: a flagged message should be read before it becomes an instruction, and a list of phrases alone misses corrections written politely or indirectly.

Do preferences stay the same?

Not always, which is why a written instruction needs review. In this record, 72 memories were replaced by a later version. Another 121 conflicts were raised where behaviour contradicted a memory, and 99 of those have been answered. An instruction that was true six months ago can be followed exactly and still be wrong, and the guide on ignored instructions covers what else makes a file stop working.

Sources, checked on 31 October 2026

• Claude Code docs: Manage sessions
• Claude Code docs: Write effective instructions