08

Article 8 of 12 · ARTHA Craft

A Developer Left. The Project Was Live. Nobody Knew Where We Were. Here's What I Built So It Never Happens Again.

Not theoretical. Production system. The institutional memory walked out the door.

Jitander Singh Chauhan

Lead AI & Data Technologist · Haystream

This is not a theoretical problem.

This is a production system. Real users. Live data. A codebase built in the vibe coding era: fast, capable, and entirely undocumented. And one day a developer left for a better opportunity. Completely normal. Completely inevitable.

What wasn't normal was what happened next.

We sat down to continue the project, and realised we didn't know where we were.

Not "what do we build next." We knew what we wanted.

What we didn't have was the answer to the most basic question in software: where are we right now?

What is working. What is partial. What was that developer in the middle of. What decisions had been made that weren't written down anywhere. The institutional memory had walked out the door. [1] And it took everything with it.

Three Beats. One Hard Lesson.

1

The Crisis

Production system. Developer gone. No documentation.

Vibe coding era. Everything built fast, nothing recorded. The team knew the destination, but had completely lost the map of where they currently stood. A paralysing position for any codebase, let alone a live production system.

2

The Recovery

AI helped, but the hard way.

Asked the AI to do a deep codebase review. Reconstruct what existed. Surface what was partial. Map what had been built. It helped, genuinely. But it was painful, slow, and incomplete. The AI could read code. It could not reconstruct intent, half-finished decisions, or the architectural thinking that only existed in one person's head.

3

The Prevention

Asked AI: how do we make sure this never happens again?

The AI's answer was exactly what you'd expect from a system that understands its own limitations. Document context at the end of every session. Capture decisions. Write handoffs. Preserve state. This is standard AI best practice, because the AI knows better than anyone what happens when context disappears.

The AI Told Us What to Build. And Why.

The Moment That Changed Everything

After the painful recovery exercise, after the AI had pieced together what it could from the codebase, I asked it a different question. Not "where are we." But: "How do we make sure this never happens again?"

The AI's answer was immediate, structured, and completely unsurprising to anyone who understands how AI actually works. Document your sessions. Capture decisions before they close. Write a handoff at the end of every working session that tells the next session exactly where to pick up.

This is not a novel insight. This is standard best practice, and the AI recommends it because it knows its own architecture. It knows every session starts from zero. It knows context disappears when the chat closes. It knows the only way to preserve state across sessions is to write it down before the session ends.

The AI didn't just help us recover from the crisis. It told us exactly how to prevent it. And the methodology that came out of that conversation has not changed since.

The context handoff wasn't invented. It was recommended [2], by the AI itself, because the AI understands its own limitations better than most developers who use it.

What Goes in a Context Handoff.

Seven sections. Each one answers a question the next session will need answered before it can do anything useful.

01

Session Date and Participants

When this happened. Who was involved. Which step was active. Simple. Permanent. Traceable. The baseline record that makes every handoff a dated entry in the project's history.

02

Step Status Table

Full snapshot of the step sequence at this moment. DONE, IN PROGRESS, PENDING, BLOCKED. All visible. The next session opens this and knows the full picture in thirty seconds without reading a single line of code.

03

Exact Stop Point

Not "we were working on the API." Surgical. "We stopped at: the E2 prompt recreated. E3 is next. File modified was X. Decision made was Y." The next agent picks up from the exact position, not an approximation of it.

04

Locked Decisions

Every design decision confirmed this session. The next agent reads these and treats them as final. Not up for debate. Not to be revisited without explicit approval. Locked: recorded here so they cannot be unintentionally undone.

05

Open Questions

Anything not resolved. The next agent surfaces these at the start of the session and waits for an answer before proceeding. It does not assume. It does not invent. It asks, because the question is recorded here and cannot be quietly skipped.

06

Standing Reminders

Permanent rules that carry across every session. Frozen modules. Patent considerations. Test coverage expectations. Written in every handoff until resolved, because these are the things that get forgotten in long projects and the forgetting is always expensive.

07

How to Open the Next Session

A paste-ready prompt. The architect pastes it verbatim into a new chat. No typing. No improvising. No "where were we?" The agent reads the handoff, reports position, surfaces open questions, waits for go-ahead. Every session starts from a known, documented state.

The Self-Test That Tells You If the Handoff Is Done.

Before Closing Every Session: Ask This

"If I handed this file to a new agent tomorrow with zero prior context, could it pick up exactly where we stopped?"

Yes, unambiguously: close the session. The handoff is done.
⚠️ Uncertain: open a new chat, paste only the session-open prompt, ask "What is the next action?" If it names the correct step without prompting, done. If it asks or assumes, find what's missing and add it now.
No: the handoff is not done. Write it now, while everything is still in your head. Not tomorrow. Not "in a minute." Now.

What the Handoff Actually Protects You From.

👤

A Developer Leaving

The project survives. A new developer reads the handoffs, the step sequence, the context seed. In one afternoon they know everything, without asking a single question.

🧠

Your Own Memory

You will not remember on Monday what you were thinking on Friday. The handoff does not rely on you remembering. It relies on you writing it down before you close the laptop.

🔄

Switching Tools or Models

You move from one AI model to another. The handoff travels with you. The new model picks up from exactly where the old one stopped, because the state lives in the document, not the session.

⏸️

Any Gap in the Work

Holiday. Illness. Two weeks away. The project is exactly where you left it. No reconstruction. No "now where was I." The handoff is the bridge across any gap, of any length.


The developer who left didn't take the project with them. They took their memory of the project. Those things should never have been stored only in their head. Five minutes. End of every session. That is the entire habit.
The context handoff is not a productivity tool. [3]

It is institutional memory made portable. Write the handoff. Close the session. Trust the system. The project belongs to the documentation, not to any single person's memory.

Research & Further Reading

  • [1] Rigby et al., "Quantifying and Mitigating Turnover-Induced Knowledge Loss", ICSE 2016: Applied financial risk models to software projects: "Projects were susceptible to knowledge losses more than three times larger than expected." Average developer tenure at major tech companies is "only slightly more than one year." Nassif & Robillard (2017) replicated and confirmed: extreme knowledge loss is more common than believed. Academic Paper
  • [2] Anthropic, "Best Practices for Claude Code", Anthropic, 2025: Recommends CLAUDE.md files for persistent context, noting that context is infrastructure that degrades as the window fills. The methodology's session bridge implements this recommendation as a structured, versioned document. Official Docs
  • [3] Hutchins, E., Cognition in the Wild, MIT Press, 1995: Documented how institutional knowledge is distributed across artifacts and people in naval navigation teams. The context handoff document is the artifact that carries distributed knowledge across session boundaries, making the project's cognitive system independent of any individual's memory. Book

← Previous

Article 7

Next →

Article 9: Three Registers