DEV Community: Seiji Nakaya

Your AI Agent’s Memory Has No Expiration Date. That’s the Problem.

Seiji Nakaya — Thu, 13 Aug 2026 05:14:49 +0000

We built memory that retrieves the right note every time, then watched it hand us a note that had quietly stopped being true. Retrieval was never the hard part. This is the fix we tried that failed the same afternoon, and the smaller thing we ship instead — one that does not pretend to know whether a note still holds.

The note was correct when we wrote it.

Weeks later, it lied without changing a single word.

I had asked an AI agent for the latest state of our launch work. It did exactly what I had trained it to do: search the team's memory, find a relevant record, and answer confidently. The record said a task was still waiting to be done.

The work had actually been finished weeks earlier.

In the same session, the agent found an old SEO audit and reported its unresolved items as our current problems. That list had been accurate on the day it was written. We measured the live site again; nearly every item had since been fixed.

We found both cases while dogfooding our own product before launch. They were not stories about a database losing data or a model failing to retrieve it. Retrieval worked perfectly. The agent found the right notes and gave the wrong answer.

That distinction changed what I thought an AI memory product needed to solve.

We solved finding the note, not trusting it

Most conversations about AI memory focus on recall: can an agent recover a useful fact after the chat ends? Can another tool or teammate find it later? Can the system rank the relevant note above the noise?

Those are real problems, and the industry has made them much easier.

But recall is only half of memory. The other half is currentness: is the retrieved fact still true?

A stale note does not look broken. Its text is intact. Its embedding still matches the question. Its source may be trustworthy. In fact, the more authoritative and relevant it appears, the more confidently an agent may repeat it.

The dangerous memory is not the one the system cannot find. It is the one the system finds immediately, cites correctly, and should no longer believe.

Our first fix was a label. It failed immediately

Our first design felt obvious: ask the writer to label each record as either a durable rule or a point-in-time observation.

A rule—"API errors use Problem Details"—could be reused without constant warnings. An observation—"the migration is still pending"—would carry a date and invite rechecking.

Then we sampled six of our own records at even intervals. At least four did not fit either box.

One note documented a durable implementation rule, the reason for it, the status of the rollout, and the fact that its commit had not yet reached the main branch. Half of the note could remain useful for a year. One sentence became false a few days later.

Mark it as a rule and the expired sentence escapes scrutiny. Mark it as an observation and the agent warns about a rule we want it to use every day.

The writer was also the worst person to make the distinction. The agent writing that mixed note believed it was documenting a completed fix. It did not know that one small sentence—"this commit is not on the main branch yet"—was a timer with no alarm.

We had tried to attach an expiration policy to the container. The facts inside the container expired at different times.

Age is not evidence

The next tempting fix was simpler: make old memories suspicious.

That fails in both directions. A year-old architecture rule may still be exactly right. A note written today may already be wrong.

We saw the second case in a particularly sharp form. An answer arrived in a review thread. Forty-four seconds later, a separate record said we were still waiting for that answer.

The record was false at birth.

Any rule that asks "did the world change after this was written?" misses that case, because the world changed first. Any rule that treats recent notes as safer gives the wrong note more authority precisely because it is new.

Time matters, but age does not prove truth. A timestamp is evidence for the reader, not a verdict from the system.

What we can show without pretending to know

Once we stopped trying to classify truth, the design became more modest.

When an agent reads a record, we can show two kinds of evidence beside it:

when the record was written;
the current state of any task or question the record explicitly names.

If an old note says a piece of work is pending while the task board says done, the contradiction is visible at the moment of use. If a note says a question is unanswered after a reply has arrived, the reader can see both claims together.

We deliberately do not label the record "current." We have no verification history that would justify that word. We also do not label it "stale," because age alone proves nothing. We do not hide it or silently reorder it.

The system presents the note, its date, and live evidence from named objects. The agent—and ultimately the human responsible for the decision—has to resolve the difference.

That may sound less magical than an automated truth score. It is also much harder to mistake for certainty.

A memory receipt you can use now

You do not need a specialized product to make team memory safer. Start by separating durable rules from observations and giving every observation a receipt.

MEMORY RECEIPT

Durable rule
- Rule:
- Why it exists:
- Scope:

Point-in-time observation
- Observed fact:
- Observed at:
- Verified by: command, URL, person, or source
- Depends on: task, question, branch, deployment, or owner
- Recheck when:

Do not put both sections in one record just because they came from the same conversation. They have different lifetimes. A rule can survive while the rollout status beneath it expires.

When evaluating any memory system, ask whether it preserves this evidence. Does it show when the note was written? Can it show the present state of the things the note names? Does its interface avoid implying that "no warning" means "verified"?

If the answer to all three is no, better recall may only help an agent retrieve obsolete confidence faster.

The part we have not solved

Evidence can still be ignored. An agent may quote the old sentence and skip the status shown beside it. A human may prefer the convenient answer. Notes that mention no structured object have nothing live to compare against.

The stronger solution begins when the record is written: store the subject, the claimed state, and the observation time as structured data instead of asking a later reader to infer them from prose.

We are not there yet. Until then, showing provenance and live contradictions is a guardrail, not a guarantee.

This account is from one team, one codebase, and our pre-launch dogfooding at LOOSEDAYS. It is not a benchmark, and the sample of six records is not a population study. It was enough to disprove our first design for our own work.

What this changed in Vibsync

Vibsync is the shared brain we build at LOOSEDAYS for teams using AI coding agents. After these incidents, we changed the read experience so a retrieved memory carries its recorded date and the live status of tasks or questions it names.

The goal is not to declare what is true. It is to stop an old statement from arriving alone, stripped of the evidence needed to question it.

That matters because different agents and sessions inherit the same record. A sentence written as temporary context can become tomorrow's starting point for someone who never saw the surrounding conversation. Shared memory amplifies useful knowledge. It also amplifies outdated assumptions unless current evidence travels with it.

If you want to try the Memory Receipt first, copy the template above into the document your agents already share. If you want agents on different tools and machines to inherit the same dated records, decisions, and live task context, connect them to one Vibsync team.

Vibsync is built by LOOSEDAYS Co., Ltd. This is a first-hand account of one team's pre-release work, not a controlled comparison.

Originally published at https://vibsync.com/blog/ai-memory-has-no-expiration-date.

My AI Said "Fixed" Three Times. It Was Wrong Three Times.

Seiji Nakaya — Tue, 11 Aug 2026 22:31:30 +0000

I nearly shipped three broken fixes in a row because an AI told me they were done and I wanted to believe it. What stopped me was not a better model — it was a second agent that was not allowed to have an opinion until it had run the code. Here is what that loop caught.

“Fixed,” the AI said.

I believed it until another AI wrote a five-line check, ran it, and showed me the same failure.

Then it happened again. And again.

This was not a toy prompt or an interview puzzle. I was trying to finish a feature on the read path of a product we were preparing to release. The code looked plausible. The explanation sounded complete. The tests the author could run were green. I wanted the answer to be true.

It was still wrong.

What finally changed my mind was not a smarter model or a more elaborate prompt. It was a second agent with a separate checkout, permission to distrust the first one, and one rule: do not accept “fixed” without reproducing the failure.

I was the person who wanted to believe it

I run LOOSEDAYS, the company building Vibsync. In this project, Claude Code usually writes a change and Codex reviews it. I decide what matters, settle disagreements, and own the merge.

That sounds disciplined when written after the fact. In the moment, I was a founder trying to get a release out. Every review round added delay. Every “fixed” message offered a reason to move on.

The pull request was meant to solve a real trust problem: a shared note may have been true when it was written and wrong by the time another agent reads it. We wanted each retrieved note to show when it was recorded and the current status of any task or question it mentioned.

The idea was small. The review was not. Across seven rounds, the reviewer raised ten blocking findings.

Three of them were the same humanly familiar mistake in different places: we fixed the decision in one layer and forgot another layer that consumed it.

Two retrieval paths used the new annotation; the fresh-session handoff path did not.
A shared failure path was corrected; another route bypassed it and kept the old behavior.
The analyzer correctly decided which reference mattered; the renderer threw that answer away and re-created the old, wrong one.

After each change, the author could point to code that was now correct. After each change, the product still had a path where the old behavior survived.

That is why “I changed the right function” is not evidence that a bug is fixed.

The reviewer did not read the code better

All ten blocking findings came from running something.

The reviewer pulled the exact commit into a separate checkout, ran the full suite, and then tried realistic inputs around the claimed fix. It also had access to tests the author's environment could not run. That difference between environments turned out to be useful, not inconvenient.

The author knew what the code was intended to do. The reviewer only saw what it did.

That distance mattered more than model intelligence. An author reads an implementation through the story in its own head: this helper is now the source of truth; this condition handles the edge case; this renderer only displays the result. A reviewer can ask the less flattering question: Which route did you not run?

The reviewer also caught the pull request moving after an earlier approval. It did not treat “approved once” as a permanent property of the branch. It pinned the decision to a commit and reviewed the new head again.

The hardest round ended with less code, not a better patch. We had tried to warn when an old note called a finished task “pending.” After four versions, the detector still misread “Task 42 processes pending jobs”: the jobs were pending, not the task. That was a grammar problem, not a word-list problem. The author proposed another fix; the reviewer proposed removing the semantic guess and keeping only reliable evidence—the note's date and the task's current status. We deleted the clever part. Sometimes a second agent's best contribution is making less code survive.

The rule that changed the loop

The early rounds were noisy because the author answered findings too quickly. “I see it” quietly became “fixed.” Reading the report felt close enough to reproducing it.

It is not close enough.

The rule that stopped this was simple:

Before changing the code, reproduce the reviewer's exact failure. After changing it, run the same case again.

That turns a review comment from an opinion into a before-and-after observation. It also prevents a polite but expensive failure mode: two agents debating what the code should do while neither has checked what it does.

The protocol we use now

You do not need Vibsync to try this. You need two agents that can work independently, a branch, and a durable place for the evidence.

THE “FIXED” GATE

Author
1. Show the exact failing input and its output before the change.
2. Make the change. Show the same input passing afterward.
3. State what your environment could not verify.
4. If the branch changes after approval, say so explicitly.

Reviewer
5. Review a commit, not “the latest branch.” Record its SHA.
6. Re-run the reported failure in a separate checkout.
7. Add at least one adjacent, realistic case the author did not choose.
8. Run the broadest suite your environment allows; report the numbers.
9. Separate blocking behavior from non-blocking preference.

Human owner
10. Decide whether the risk justifies another round, and own the merge.

The protocol is intentionally biased toward evidence. “Looks good,” “makes sense,” and “I updated the helper” are not evidence. A failing case that becomes a passing case is.

What this does not prove

This is one team, one codebase, and roughly one month of working this way. It is not a benchmark, and I am not claiming that two agents are always better than one.

The loop is slower than accepting the first plausible answer. For a copy edit or a reversible experiment, the extra round may be waste. For a change that sits on an authentication boundary, a data migration, or a read path people will trust, the cost looks different.

It also does not remove human responsibility. The agents can generate, challenge, and test. I still decide which risks deserve the loop, when to stop, and whether to merge.

The lesson is narrower: do not use a second AI as another voter. Use it as an independent source of friction. Give it a different checkout, different constraints where possible, the authority to block, and a requirement to bring executable evidence.

Why the record has to outlive the session

By round seven, no single context window held the whole argument. The useful artifact was not the agents' conversation; it was the written trail of findings, reproductions, decisions, and exact commits.

That is where Vibsync enters the story. Vibsync is the shared brain we build at LOOSEDAYS for AI coding teams. Claude Code and Codex used it to leave review findings and decisions for each other across sessions and machines. The agents did not need to be awake together or share one context window. Each round started from the same durable record instead of a summary reconstructed from memory.

The product did not make either model smarter. It made the disagreement survive long enough to be useful.

You can run the protocol above with a shared document today. If you want different agents to inherit the same decisions, open questions, and review trail automatically, connect them to the same Vibsync team.

Vibsync is built by LOOSEDAYS Co., Ltd. This is a first-hand account of one pre-release pull request, not a controlled comparison.

Originally published at https://vibsync.com/blog/ai-said-fixed-three-times.

The AI Coding Team Working Agreement

Seiji Nakaya — Tue, 11 Aug 2026 00:37:58 +0000

Every team I've worked with has unwritten rules — who to ask before touching auth, which decisions are settled, what "in progress" actually means. They used to travel by osmosis. Once everyone on the team is coding with an agent, osmosis stops working, because half the conversation now happens in someone's private session. This is the one-page agreement we ended up writing down, and why each clause is in it.

When every developer on a team codes with an AI agent, one of the first things to break down can be the unwritten rules. Small, shared assumptions that once traveled through everyday conversation ("ask before you touch auth," "we decided on v2 last week") may not reach a teammate's private session — let alone the agent working in it.

The established fix for that is a working agreement: a short, explicit set of norms a team writes for itself. This one is designed for AI-assisted teams — a page you can copy, adapt, and keep somewhere every teammate can access and every agent is configured to read.

What a working agreement is — and isn't

A working agreement is a team norm, written by the team, kept short, and revised as you learn. It is not a tool, and not a policy handed down from above. It doesn't enforce anything — it aligns behavior. That's precisely why it survives across whatever mix of editors and agents your team actually uses: it lives at the human layer, above any one tool.

If you've run agile ceremonies, you've seen these before. What's new is that agents now perform part of the work, so a few assumptions that people may have absorbed implicitly need to be written down. Accountability still stays with people.

The template

Copy this, cut what doesn't fit, and fill in the blanks. Keep it to a page.

# Our AI Coding Working Agreement (v1)

## 1. Shared decisions
- Decisions that affect others live in: ______ (a shared memory, a decisions doc).
- Before a decision affects someone else's work, we record who decided it, what changed, and why.

## 2. Declaring work
- Before starting, we record the intended outcome, owner, and active paths in: ______.
- "In progress" includes the current state, next action, and next check-in — not just a status.

## 3. Handoffs
- When work changes hands — session, machine, person, or tool — we carry four things:
  recent decisions, current state and next action, open questions, and active or unmerged paths.

## 4. Review & merge
- Git is the source of truth for committed code. Every change is reviewed by a human before it merges.
- Agents propose; people approve. A named person owns the change and its follow-up after merge.

## 5. Conflict & escalation
- If active work overlaps, the first current claim gets priority; the later starter coordinates.
- We release claims when work stops and review stale claims after: ______.
- Unresolved disagreements go to: ______ (a person, not a tool).

_Revised: ______. This is v1 — change it as we learn._

That block is the whole deliverable. Everything below is just why each clause is there.

Why each clause earns its place

1. Shared decisions. Re-deciding can be a costly habit on an AI-assisted team. One session concludes "money is integer cents"; another, a day later on another machine, quietly picks floats. Recording decisions somewhere every authorized agent can retrieve turns "we decided" into evidence the next agent can use. (This is one part of the broader coordination cost of AI coding agents.)

2. Declaring work. "Who's on the payments refactor?" should have an answer without a chat poll. Declaring the outcome, owner, and active scope up front helps prevent two people — and two agents — from doing the same thing, or from each assuming the other had it. A next check-in also keeps abandoned work from looking active forever.

3. Handoffs. Work changes hands constantly. Committed code has a durable record; live context is easier to drop. The four items in the clause are worth carrying every time — there is a fuller handoff playbook if you want the detail.

4. Review & merge. Agents make it cheap to generate a lot of plausible change. That raises the value of the human gate rather than lowering it. Naming Git as the source of truth for committed code and a person as the accountable owner helps keep speed from turning into unreviewed risk.

5. Conflict & escalation. Two things collide on a team: edits and opinions. For edits, a simple rule — a current claim gets priority, a later starter coordinates, and stale claims expire — can reduce avoidable merge work. For opinions, the important word is person: an agent can surface a disagreement, but a human resolves it.

Making it real

The agreement is tool-agnostic — you can run v1 on a shared document and a chat channel today. Three clauses especially benefit from being current and machine-readable: the decisions in §1, the who's-on-what in §2, and the claims in §5. A document works only when each client knows to load it and people keep its high-churn state current.

That is the part a shared layer like Vibsync is for. At the start of a session, an authorized agent can call onboard and recall to retrieve current decisions, declare work and claim a path before editing, and ask or answer across sessions. Because the state is exposed over MCP, Claude Code, Cursor, and Codex can access the same team context when each is configured and connected to that team. The shared memory supports §1; claims and the task board make §2 and §5 operational.

Keep it honest

An agreement is a norm, not an enforcement mechanism, and it works because people choose to follow it. A claim is advisory — it helps well-behaved agents stay out of each other's way; it does not lock a file. Git, review, and CI remain your real safety nets. And responsibility stays with people: an agent can act, but a named person owns the decision and its outcome.

Start with the five clauses above, fill in the blanks with the tools you already use, and put the agreement where teammates and their agents can retrieve it. Try Vibsync free during beta if you want §1, §2, and §5 available to every authorized agent across sessions and tools.

Vibsync is built by LOOSEDAYS Co., Ltd.

Originally published at https://vibsync.com/blog/ai-coding-team-working-agreement.

How to Hand Off AI Coding Work Across Sessions, Machines, and Tools

Seiji Nakaya — Mon, 10 Aug 2026 04:05:06 +0000

Most of us now switch between Claude Code, Cursor, and Codex during a single feature, and move between a laptop, a devcontainer, and a teammate mid-task. The code survives every one of those hops. The reasoning around it usually doesn't. This is what I've found actually needs to travel, and a short checklist for making it travel.

Committed code has a durable record in Git. The context around it often does not: the decision you just made, the task you were halfway through, the question blocking you, and the files you were editing. That context often lives in one session or tool, where it can disappear at the next handoff.

And in AI-assisted teams, those changes happen constantly. This is a practical guide to handing off AI coding work so the next session — whoever, whatever, and wherever it runs — picks up where the last one left off, instead of starting cold.

Three handoffs that happen every day

"Handoff" sounds like a formal ceremony. In practice it's mundane and frequent, and it comes in three flavors:

Tool → tool. You draft with Claude Code, then continue in Codex or Cursor because another tool fits the next step better. Their conversation histories are not shared by default.
Machine → machine. Work moves from your laptop to a CI box, a devcontainer, a second machine, or a teammate's laptop. The committed repository state can travel; local transcripts, uncommitted work, and live decisions may not.
Person → person. A shift ends, someone picks up a stalled PR, an on-call engineer inherits a half-finished migration. The new person's agent has none of the previous one's context.

In all three, the committed repository state can come across intact. The working context is what falls on the floor.

What actually gets dropped

It helps to name exactly what's lost, because it's a short list — four things:

The decision just made. "We're freezing the v1 API for 90 days." Real, agreed, and living only in the session where it was said.
The unfinished task. Not just "this is in progress," but where you were and what's left — context that a code diff rarely captures.
The unanswered question. The thing you were blocked on. If it doesn't travel, the next session either re-discovers the blocker or, worse, guesses past it.
The active file scope. Which paths still have active or unmerged work. Drop this and the next agent may start editing the same file — a collision created at handoff time.

Most handoff failures are variations on losing one of these four.

What repo docs and session resume already cover

You are not starting from nothing — several tools already carry part of the load. It's worth being precise about where each one stops.

A CLAUDE.md or repo docs. Great for stable, repo-scoped instructions — conventions, architecture, "run the tests this way." A committed file travels with the repository. Claude Code loads CLAUDE.md; other clients may use AGENTS.md or their own rules files. These documents are durable, but high-churn live state such as "what we decided twenty minutes ago" is a poor fit.
Git history and pull requests. The canonical record of committed code, and of why when that reasoning is documented. They say little about work with no diff yet: the unfinished task, an open question, or an undocumented decision.
Session resume. Claude Code can continue or resume previous conversations, and other tools have their own history. This provides useful, client-specific conversation continuity. It is not a vendor-neutral record that a teammate or a different tool can reliably inherit.

Put together, these cover your committed code, durable rules, and client-specific continuity. They do not create one team-wide record of the four live items across tools, machines, and people. That's the gap.

Carrying the four across the hop

The way to close it is to put those four items somewhere every authorized agent can retrieve — not in one chat log. That's what Vibsync provides over MCP: a small shared layer agents can read and write, so a handoff carries context, not just code.

Mapped to the four:

Decisions → remember / recall. One agent records "v1 frozen 90 days"; a fresh session on another machine recalls it, attributed and scoped. It's the same shared team memory that outlives any single session.
Unfinished task → a shared task board. The half-done work is visible and claimable, with a title, status, and owner. Put the current state and next action in the title so the next session does not have to reconstruct them.
Unanswered question → async ask / reply. The blocker is posted once and can be answered when a teammate or agent checks the shared state — it survives the session that raised it.
Active file scope → claim. Before editing, a well-behaved agent announces the path; the next agent checks first and stays clear — the same coordinate-before-you-edit approach that helps keep two agents off the same file.

And there is an onboard call that returns the essentials at once — open tasks, unanswered questions, recent team knowledge, and active claims — so a new session can retrieve the team's current picture in one step instead of being briefed by hand.

Because it is vendor-neutral, the same endpoint — https://mcp.vibsync.com/mcp — works with Claude Code, Cursor, and Codex. Each client uses a different configuration format, so follow the client-specific steps in Getting Started. Connect each credential to the same Vibsync team, then call onboard to retrieve the shared state. A task claimed in one client is then visible from another.

A handoff checklist

Keep this somewhere your team can see it. It's short on purpose.

Before you hand off:

Is the decision you just made written down where another agent can read it — not just in this chat?
Does the unfinished task record where you are and what's next, not only "in progress"?
Is the question you were blocked on posted, so it can be answered later?
Is your active file scope released, or clearly marked as still yours?

When you pick up:

Pull the current context first (with Vibsync, one onboard call) before writing anything.
Read the recent decisions before you re-derive them.
Check who's on what, and claim your path before you edit it.

If your team can answer those, a handoff stops being a reset.

Honest limits

A shared layer like this carries context — it is not your code store, and Git stays the source of truth. A claim is an advisory signal that helps well-behaved agents avoid each other; it doesn't physically lock a file, and it's no substitute for branch protection, review, or CI. The goal isn't to replace any of that. It's to make sure that when the session, the machine, or the tool changes, the decision, the task, the question, and the file scope change hands with it.

If your team loses an afternoon every time work crosses a boundary, that's the seam to close. Try Vibsync free during beta — connect an agent at mcp.vibsync.com/mcp, then call onboard to retrieve the team's current context.

For the bigger picture on why individual speed doesn't automatically become team speed, see the coordination cost of AI coding agents. Vibsync is built by LOOSEDAYS Co., Ltd.

Originally published at https://vibsync.com/blog/ai-coding-agent-handoff.

AI Makes Developers Faster. Why Can It Make Teams Slower?

Seiji Nakaya — Sun, 02 Aug 2026 21:33:13 +0000

This was first published on the Vibsync blog. Reposting for the DEV community.

The short version: AI reliably makes each developer faster. Whether it makes the team faster is a separate question — and the gap between the two is where a lot of quiet cost hides. Below: the five coordination costs that eat the difference, a ten-question diagnostic, and five operating principles.

Picture three developers, three AI coding agents, and one repository. Each developer can now produce candidate code, tests, and refactors faster than before. Yet releases move at the same pace, review queues grow, and the same facts keep getting rediscovered.

That's not a paradox, and it isn't a reason to slow anyone down. It's a reminder that individual speed and team speed are different quantities, and AI coding agents scale the first far more easily than the second. Give everyone a faster typewriter and you get more pages — not necessarily a better book, written faster, by a group.

Individual output is not team throughput

It's worth separating two things we tend to blur:

Individual output — how much finished work one developer (plus their agent) produces.
Team throughput — how much shippable, coherent work the group produces together, after review, rework, waiting, and reconciling everyone's changes.

AI agents lift individual output directly. Team throughput is what's left after the coordination overhead is paid, and that overhead doesn't shrink just because each person got faster. A useful way to hold it in your head — not as a formula to compute, just as a shape:

team throughput ≈ the sum of local speed-ups − rework − waiting − reconciliation

When you add agents, the first term grows. If nothing else changes, the last three grow too — because there's now more work in flight, produced faster, by people who can't all see what the others are doing. The interesting question for a team lead isn't "how do I make everyone faster?" It's "which of those subtraction terms is my real ceiling?"

There's some external signal here worth taking seriously. In one 2025 study of experienced open-source developers, participants working on mature codebases they knew well completed the measured tasks more slowly with AI assistance, even though they expected AI to speed them up. The conditions were specific, so this does not generalize to "AI slows you down." The narrower lesson is more useful: perceived speed and measured task time can diverge. And the 2025 DORA report frames AI as an amplifier — it magnifies the strengths and the dysfunctions an organization already has. That suggests weak coordination can become more costly as AI increases the amount of work in flight.

The five coordination costs

When AI raises individual output without improving collective delivery, the gap often comes from some mix of these five costs. None of them are new — AI can raise the volume and the speed at which they hit.

1. Duplicated discovery. One person's agent works out that the staging database resets nightly, or that a module must stay backward-compatible during a migration. That fact is real and hard-won — and it lives in one chat history. The next agent, on another machine, re-derives it from scratch, or worse, derives the opposite. The team keeps paying for the same lesson.

2. Decision drift. Someone decides "we're standardizing on integer cents, never floats." It's correct, it's stated aloud once, and then three agents that never heard it quietly make three different choices. Nobody disagreed; the decision just didn't travel.

3. Ownership ambiguity. With everyone moving fast, "who's on the payments refactor right now?" stops having an obvious answer. Two people pick it up, or nobody does because each assumed the other had it.

4. Handoff loss. Work moves between a morning session and an afternoon one, between a laptop and a CI box, between one developer and the teammate covering for them — or between Claude Code and Codex. Each hop drops context: the decision just made, the task half-finished, the question still open, the files someone was mid-edit on. (This one has its own playbook: handing off AI coding work across sessions, machines, and tools.)

5. Collision and reconciliation. Two agents edit overlapping parts of the same file on two branches. Git faithfully reports the conflict — after both sides did the work. The collision was created hours earlier, when neither side knew the other had started. Now someone spends the afternoon untangling it.

Notice what these have in common: they are not primarily model-capability problems, so a better model or a faster agent does not fix them by itself. They are coordination problems, and they can get worse precisely when individual work gets faster.

This is where an old idea earns a one-paragraph cameo. Fred Brooks observed decades ago that adding people to a late software project can make it later, because communication paths multiply faster than hands. AI agents are not people, and this is not Brooks's Law replayed — but the shape rhymes. Teams now have more fast-moving sources of code, and if the communication paths around them do not scale, coordination can consume the local gains. A related, bounded analogy comes from Conway's Law: when decisions fragment across people who are not communicating, that fragmentation can surface in the system they build.

Five operating principles that cut the cost

The fix isn't to slow anyone down. It's to make the coordination that used to happen implicitly in a small, synchronous team happen explicitly — because you cannot assume that every agent has read your Slack or can see the context in a teammate's private session.

Shared decisions travel. When someone settles a rule — "v1 API frozen for 90 days" — it should land somewhere every agent can retrieve when it starts, not in one chat. Decide once; make the decision available to every agent.
Ownership is visible. "Who's on what" should be a live, shared picture, not something you reconstruct by asking around after two people already collided.
Handoffs are explicit. Moving work across a session, a machine, a person, or a tool should carry the decision, the unfinished task, the open question, and the active file scope — not just the code.
Coordinate before the edit, not after. The cheapest time to catch a same-file collision is before the second agent starts, when it's a five-second check, not a merge to untangle.
Git stays the source of truth. None of this replaces branches, review, or CI. Coordination sits before those safety nets so they have less to catch. Keep code in Git; keep the fast-moving decisions and coordination beside it.

A ten-question diagnostic

Run this against your own team. Each "no" is a coordination cost you're probably paying without seeing it on any dashboard.

When one person's agent learns something non-obvious about the codebase, can a different teammate's agent get that fact tomorrow without asking a human?
If someone makes a decision at 4pm, will an agent that starts a fresh session at 5pm on another machine follow it?
Can anyone tell, right now, which files or modules a teammate is actively working on?
When work moves between machines or people, does the unfinished part and the open questions travel — or just the committed code?
Before an agent starts editing a module, is there a cheap way for it to learn a teammate already started?
Do your agents re-explain the same context ("money is integer cents," "don't touch auth this week") at the start of every session?
When two people finish, how often do you discover the overlap only at merge time?
Is your "team memory" a document someone has to remember to update and point an agent at — or something agents read and write themselves?
Can a new teammate (or a new agent) get the team's current decisions, open tasks, and who-owns-what in roughly one step?
Does more individual speed currently translate into more shipped-and-reconciled work — or into more rework and review?

If you answered "no" to several, your ceiling isn't how fast anyone codes. It's coordination — and that's a more tractable problem than it looks, because most of it is about making implicit context explicit and shared.

Where a shared coordination layer fits

This is the gap Vibsync is built for. It gives a team's AI coding agents a small shared layer over MCP — durable team memory so a fresh session on another machine can retrieve a decision one agent recorded, async Q&A across teammates and their agents, a shared task board, and file-claim coordination so an agent can check before it edits whether a teammate already holds that path. It's vendor-neutral — Claude Code, Cursor, and Codex connect to the same endpoint — and it deliberately does not ingest your source. Git stays the source of truth; Vibsync carries the decisions and coordination around it.

To be honest about the boundary: a file claim is an advisory signal, not a hard lock — it helps well-behaved agents stay out of each other's way, it doesn't physically prevent an edit, and it's no substitute for review or branch protection. The point isn't magic. It's paying the coordination cost once, up front and in the open, instead of five times over at merge time.

If your team got individually faster with AI but not collectively faster, that's the seam to look at first. Try Vibsync free during beta — connect an agent to mcp.vibsync.com/mcp, then call onboard to retrieve the team's current context in one brief.

Vibsync is built by LOOSEDAYS Co., Ltd.

How to Prevent Multiple AI Coding Agents from Editing the Same Files

Seiji Nakaya — Fri, 31 Jul 2026 14:01:20 +0000

A team of developers, each running their own AI coding agent, is fast — right up until two agents refactor the same file at the same time. One overwrites the other's work, or you discover the collision at merge time and spend the afternoon untangling it.

You can't always prevent this with Git alone: by the time there's a conflicting commit, both agents have already done the work. The goal is to coordinate intent — before the edits happen.

Why this is different from a merge conflict

A merge conflict is detected after both sides changed the code. What you actually want is to know, before you start, that a teammate's agent is already rewriting the module you're about to touch. That's an intent problem, not a diff problem, so branch protection and CI don't solve it — they run too late.

Approaches teams use

Talk in Slack first. "I'm taking the payments client." Works with a small, synchronous team, but it relies on humans remembering to announce, and agents don't read your Slack.

Assign files to people up front. A spreadsheet or a CODEOWNERS-style split. Reduces overlap, but it's coarse and goes stale the moment work shifts.

Feature branches / worktrees. Isolation helps for parallel features, but two agents can still target the same file on different branches and collide at merge. Isolation delays the collision; it doesn't coordinate intent. Git's own workflow documentation is still the right foundation for review and integration — it simply operates at a different layer.

A shared claim/lease. Before editing, an agent announces intent on a shared store — "I'm working on src/payments/**." Another agent checks that store first and sees the path is taken. This is the only approach that coordinates before the edit, across people and machines.

Be honest about what a claim is

A claim is an advisory lock, not a hard lock. It's a shared signal that a path is spoken for, and well-behaved agents check it and stay out of the way. It does not physically prevent someone from editing the file, and it isn't a substitute for code review or branch protection. Any tool that promises literal "zero collisions" is overselling — the honest promise is fewer surprise collisions, caught before the work, when agents check first.

Used that way, advisory claims remove most same-file clobbering: the second agent sees the path is held, reports back instead of editing, and you coordinate or pick different work.

What this looks like with Vibsync

Vibsync gives agents this coordination layer over MCP. Before touching a path, an agent runs check_conflicts and claim:

You: "Refactor the payments client — claim it first."
Agent: "claim came back blocked — carol already holds src/payments/**. I didn't edit anything. Want me to coordinate, wait, or take an unclaimed task instead?"

The agent that would have collided finds out before writing a line, and nothing gets clobbered. Claims sit alongside durable team memory and a shared task board, so "who's on what" is one shared, live picture — not a Slack thread agents can't read.

To be clear about the boundary: Git remains the source of truth and your safety net (review, branch protection, CI). Vibsync's claims coordinate intent before the edit so those safety nets have less to catch.

If overlapping AI edits are costing your team time, try Vibsync free during beta — connect your agent at mcp.vibsync.com/mcp and have it claim a path before it starts.

Vibsync is built by LOOSEDAYS Co., Ltd.

Originally published on the Vibsync blog.

#### HASHNODE

You can't always prevent this with Git alone: by the time there's a conflicting commit, both agents have already done the work. The goal is to coordinate intent — before the edits happen.

Why this is different from a merge conflict

Approaches teams use

Talk in Slack first. "I'm taking the payments client." Works with a small, synchronous team, but it relies on humans remembering to announce, and agents don't read your Slack.

Assign files to people up front. A spreadsheet or a CODEOWNERS-style split. Reduces overlap, but it's coarse and goes stale the moment work shifts.

Be honest about what a claim is

Used that way, advisory claims remove most same-file clobbering: the second agent sees the path is held, reports back instead of editing, and you coordinate or pick different work.

What this looks like with Vibsync

Vibsync gives agents this coordination layer over MCP. Before touching a path, an agent runs check_conflicts and claim:

You: "Refactor the payments client — claim it first."
Agent: "claim came back blocked — carol already holds src/payments/**. I didn't edit anything. Want me to coordinate, wait, or take an unclaimed task instead?"

If overlapping AI edits are costing your team time, try Vibsync free during beta — connect your agent at mcp.vibsync.com/mcp and have it claim a path before it starts.

Vibsync is built by LOOSEDAYS Co., Ltd.

Originally published on the Vibsync blog.

Claude Code Team Memory: CLAUDE.md, Git, or MCP?

Seiji Nakaya — Thu, 30 Jul 2026 07:24:53 +0000

If a team wants its Claude Code agents to remember decisions and context, three tools come up: a CLAUDE.md file, Git itself, and an MCP memory server. They're often framed as competitors. They're not — they cover different layers. Here's the boundary.

`CLAUDE.md`: standing instructions, per repo

CLAUDE.md is a file Claude Code reads automatically. It's the right home for stable, repo-scoped conventions: coding style, architecture notes, "run the tests with this command," "money is integer cents."

Good at: durable rules that rarely change; zero setup; versioned with the code.

Where it stops: it's static and per-repo. It's a poor fit for "what did we decide this morning," which changes daily, and it doesn't cross repos or capture a decision at the moment an agent makes one. It also doesn't help two agents avoid editing the same file right now.

Git: the source of truth for code

Git already stores your code and its history, and commit messages/PRs explain why a change happened. Some teams try to extend this into a shared "memory" — a Markdown vault or changelog committed to a repo.

Good at: it is, and should remain, the canonical record of the code itself. Attribution and history come for free.

Where it stops: most coordination context has no diff to attach to — "don't touch this module yet," "we're standardizing on X," "who's working on payments." Pushing that into Git turns coordination into a file that has to be pulled, merged, and resolved. Merge conflicts are exactly the thing you're trying to avoid, and a committed vault reintroduces them. Git is also poll-based: an agent only sees an update after a fetch, not the moment it's written.

MCP memory: the working context around the code

An MCP memory server gives agents a small shared store they read and write through tools, live, across sessions and machines. MCP is an open standard for connecting AI applications to external systems. This is the layer for the decisions and context that never make it into a commit — and, in some tools, for coordination primitives like file claims and a task board.

Good at: capturing a decision the instant an agent makes it; serving it to a different agent on a different machine on connect; staying vendor-neutral (any MCP client — Claude Code, Cursor, Codex).

Where it stops: it is not your code store. It shouldn't try to be Git, and a good one won't fetch or clone your repositories.

The boundary, in one line

Git is the source of truth for code.
CLAUDE.md holds stable, per-repo instructions.
MCP memory holds the live, cross-machine decisions and coordination around the code.

They compose. Keep code in Git, keep conventions in CLAUDE.md, and put the fast-moving team context — "we decided v2," "carol holds payments," "is the API frozen?" — in a shared MCP layer where every agent can read and write it.

How Vibsync fits

Vibsync is that MCP layer: durable team memory (remember / recall), async agent-to-agent Q&A (ask / reply), and file-claim + task coordination — one endpoint, vendor-neutral, bring your own model. It deliberately does not ingest your source; Git stays the source of truth. A decision one agent records is inherited by a fresh session on another machine, without anyone copy-pasting context.

If your team keeps re-explaining the same decisions to new Claude Code sessions, that's the gap this layer fills. Try it free during beta — point your agent at mcp.vibsync.com/mcp.

Disclosure: this comparison is written by the Vibsync team. Vibsync is built by LOOSEDAYS Co., Ltd.

Originally published on the Vibsync blog.

#### HASHNODE BODY (below; set fields from the comment)

`CLAUDE.md`: standing instructions, per repo

Good at: durable rules that rarely change; zero setup; versioned with the code.

Git: the source of truth for code

Good at: it is, and should remain, the canonical record of the code itself. Attribution and history come for free.

MCP memory: the working context around the code

Where it stops: it is not your code store. It shouldn't try to be Git, and a good one won't fetch or clone your repositories.

The boundary, in one line

Git is the source of truth for code.
CLAUDE.md holds stable, per-repo instructions.
MCP memory holds the live, cross-machine decisions and coordination around the code.

How Vibsync fits

If your team keeps re-explaining the same decisions to new Claude Code sessions, that's the gap this layer fills. Try it free during beta — point your agent at mcp.vibsync.com/mcp.

Disclosure: this comparison is written by the Vibsync team. Vibsync is built by LOOSEDAYS Co., Ltd.

Originally published on the Vibsync blog.

How to Share Claude Code Learnings Across Your Team

Seiji Nakaya — Tue, 28 Jul 2026 21:58:36 +0000

Your team adopted AI coding agents, and productivity went up. But something quieter also happened: every developer's agent now learns in isolation.

One teammate's Claude Code session works out that the API must stay backward-compatible, that a flaky test needs a retry, or that a certain module is off-limits during a migration. That knowledge is real and useful — and it stays trapped in one person's chat history. The next agent, on the next machine, starts from zero and sometimes re-derives the opposite conclusion.

This post is about the practical ways teams share those learnings, where each one breaks down, and what a shared layer looks like.

What counts as a "learning"

It helps to be concrete. The things worth sharing are rarely code — they're the decisions and context around it:

Decisions: "We're migrating the public API to v2; keep v1 frozen for 90 days."
Gotchas: "The staging DB resets nightly, so don't rely on seeded rows."
Conventions: "Money is always integer cents, never floats."
Ownership: "Carol is refactoring the payments module this week — coordinate first."

These are exactly the things that never make it into a commit, and exactly the things a fresh agent needs to not repeat someone's mistake.

The usual approaches — and where they stop

Copy-paste in chat. The most common one: a developer pastes context into their agent at the start of each session. It works for a single person, but it doesn't scale to teammates or survive a new session. You become the integration layer, relaying decisions by hand.

A shared doc or wiki. Better, because it's written down. But docs are static and drift. Nobody updates them mid-task, and an agent has to be explicitly pointed at them. The decision made at 4pm Tuesday rarely lands in the doc before it matters.

Commit messages and PR descriptions. Great for why a change happened, but they're tied to code that changed. Most coordination context — "don't touch this yet," "we decided X" — has no diff to attach to.

A CLAUDE.md file. A real improvement: it gives one agent standing instructions per repo. But it's per-repo and mostly static — a good place for conventions, a poor place for "what did we decide this morning" that changes daily. (We compare CLAUDE.md, Git, and MCP directly in Claude Code Team Memory: CLAUDE.md, Git, or MCP?.)

The common thread: each approach either doesn't cross people and machines, or doesn't capture decisions as they happen.

A shared memory the agents read and write themselves

The alternative is to give the agents a small shared memory over MCP — one that any agent can write to when it makes a decision, and read from when it starts work.

Concretely, when one agent settles something, it records it:

remember — "Public API moves to v2 under /api/v2; v1 frozen for 90 days." scope: src/api, by alice.

Later, a different agent on a different machine, in a session that was never told anything, asks "what did we decide about the API?" and gets it back — attributed and scoped — because it was written to the team's memory, not to one chat. No re-explaining, no contradiction.

This is what Vibsync does: durable team memory, plus async agent-to-agent Q&A and file-claim coordination, exposed as one MCP endpoint that Claude Code, Cursor, Codex, and other clients connect to. Git stays the source of truth for your code; Vibsync holds the decisions and context around it.

Where to start

You don't need to boil the ocean. Start by writing down the three or four decisions your team keeps re-explaining to new sessions, and make them readable by every agent. Whether you use a shared doc, a CLAUDE.md, or a shared MCP memory, the win is the same: decide it once, and every agent inherits it.

If you want that to work across people and machines without anyone playing relay, try Vibsync free during beta — point your agent at mcp.vibsync.com/mcp and it inherits the team's memory on connect.

Vibsync is built by LOOSEDAYS Co., Ltd.

Originally published on the Vibsync blog.

DEV Community: Seiji Nakaya

Your AI Agent’s Memory Has No Expiration Date. That’s the Problem.

We solved finding the note, not trusting it

Our first fix was a label. It failed immediately

Age is not evidence

What we can show without pretending to know

A memory receipt you can use now

The part we have not solved

What this changed in Vibsync

My AI Said "Fixed" Three Times. It Was Wrong Three Times.

I was the person who wanted to believe it

The reviewer did not read the code better

The rule that changed the loop

The protocol we use now

What this does not prove

Why the record has to outlive the session

The AI Coding Team Working Agreement

What a working agreement is — and isn't

The template

Why each clause earns its place

Making it real

Keep it honest

How to Hand Off AI Coding Work Across Sessions, Machines, and Tools

Three handoffs that happen every day

What actually gets dropped

What repo docs and session resume already cover

Carrying the four across the hop

A handoff checklist

Honest limits

AI Makes Developers Faster. Why Can It Make Teams Slower?

Individual output is not team throughput

The five coordination costs

Five operating principles that cut the cost

A ten-question diagnostic

Where a shared coordination layer fits

How to Prevent Multiple AI Coding Agents from Editing the Same Files

Why this is different from a merge conflict

Approaches teams use

Be honest about what a claim is

What this looks like with Vibsync

#### HASHNODE

Why this is different from a merge conflict

Approaches teams use

Be honest about what a claim is

What this looks like with Vibsync

Claude Code Team Memory: CLAUDE.md, Git, or MCP?

CLAUDE.md: standing instructions, per repo

Git: the source of truth for code

MCP memory: the working context around the code

The boundary, in one line

How Vibsync fits

#### HASHNODE BODY (below; set fields from the comment)

CLAUDE.md: standing instructions, per repo

Git: the source of truth for code

MCP memory: the working context around the code

The boundary, in one line

How Vibsync fits

How to Share Claude Code Learnings Across Your Team

What counts as a "learning"

The usual approaches — and where they stop

A shared memory the agents read and write themselves

Where to start

`CLAUDE.md`: standing instructions, per repo

`CLAUDE.md`: standing instructions, per repo