Two copies, and they've started to disagree.
The same logic lives in two places, written a week apart and named differently. Nobody notices until the two copies disagree and you get a bug that only shows up on one path.
A new session can't see last week's work.
The session writing new code starts empty. It can't see what another session built last week unless it goes looking.
When it does look, it searches for names. A duplicate usually has a different name. It's the same idea, not the same text.
What doesn't work.
Telling the model to “check for existing code”. It greps for names, and duplicates don't share names.
Copy-paste detectors. They catch identical text, not two different implementations of one idea.
A big project file that lists every module. It goes stale quickly, and a long list stops being read.
What actually helps.
Most of this isn't us.
Make “search before you build” the literal first step of every task, not a tip.
Keep a short, current list of shared helpers. Short enough that it stays current.
In review, ask one question every time: “does this already exist?”
Schedule time for merging duplicates. They won't merge themselves.
Search comes first, because of what it finds.
In August a session took apart another project's code to learn how it was built. Afterwards, a search of our own record turned up the same teardown, done five days earlier and in more depth. The session's correction says so plainly and points the next reader at the better one.
That's why searching the record is the first step of our work loop, before any building starts. A search would have found the first one before the second began.
| What was measured | What the record says |
|---|---|
| earlier teardown found by searching the record | same project, five days older, more thorough |
| the earlier teardown | 14 August 2026 |
| the correction that pointed back to it | 19 August 2026 |
| where it's from | Vinculum's own project record, which runs on Vinculum |
Where a shared memory fits.
In Vinculum, earlier decisions and builds can be searched by what they mean, not just by file name, and search is the first step of the loop.
Searching first is still a habit you have to keep. The tool makes it fast. It doesn't make it automatic.
Common questions.
Won't a linter catch duplicated code?
It catches copied text. Two people (or two sessions) writing the same idea in different words looks like two different functions to a linter.
Wouldn't a bigger context window fix this?
Only for the code you load into it. Last week's session, and the reasons behind it, still aren't there unless something wrote them down.