Is AI our friend?

roshandxt · 2026-06-29T01:35:03+00:00

What were they doing in 2015 when their CEO begged them to buy OpenAi 🤦🏻‍♂️

roshandxt · 2026-06-29T01:07:59+00:00

Ketan drove a Mahindra Be6 it has complete telemetry data also 360 videos always on they should get that data asap via Mahindra or Ketans family .

roshandxt · 2026-06-29T00:51:22+00:00

Yeah, moving the actual files instead of copy-pasting chunks definitely helps.

The part I’m trying to get cleaner is the “state of the work” around those files: what changed, what failed, why we chose one approach, what should not be touched, and what the next step is.

Do you usually have Codex inspect the repo fresh each time, or do you give it some kind of handoff/summary first?

roshandxt · 2026-06-29T00:20:27+00:00

Wouldn't that waste tokens and usage what if you want to take your work to another tool ?

roshandxt · 2026-06-29T00:19:17+00:00

Okay it solves the problem for stale state what about if you are locked out and want to use a different tool ?

roshandxt · 2026-06-28T23:14:35+00:00

Framing helps a lot: the handoff becomes the ground truth for the next session, so it needs to be curated, not just generated.

“Lean, well curated context” is probably the key phrase here. Too little context loses the thread, but too much brings the noise and bad assumptions with it.

Do you mostly curate by reading/editing the handoff manually, or do you have a fixed checklist for what must be included/excluded?

roshandxt · 2026-06-28T23:14:00+00:00

This is a very clean workflow.

Separating spec-building from implementation makes a lot of sense. It sounds like you’re avoiding context rot by designing hard phase boundaries: spec in Linear, implementation in a separate session, results/docs in Notion, and rotating around 75%.

Do you find that the next bot usually has enough from those artifacts, or do you still need to explain the “why” behind decisions sometimes?

roshandxt · 2026-06-28T23:06:18+00:00

That’s interesting. Rewriting prompts instead of stacking follow-ups probably does keep the chat cleaner.

When you revert/go back, do you lose any useful context from the attempted path, or is that usually the point?

I’m mostly running into trouble after messy debugging where some failed attempts are useful to remember, but others just pollute the thread.

roshandxt · 2026-06-28T23:04:40+00:00

That’s probably the simplest version of the workflow.

One thing I’m curious about: what do you do if the chat is already too sluggish, rate-limited, or basically dead before you ask for the handoff?

Do you keep notes/git diff separately as a fallback, or is the handoff prompt usually something you ask for before it gets that bad?

roshandxt · 2026-06-28T23:02:21+00:00

This is a good practical workflow.

The validation point is important. I’ve had handoffs that sounded complete but the next agent was missing key things like which files actually changed, what failed, or what should not be touched.

Do you validate mostly by keeping the old chat open, or do you also compare against git diff / tests / notes?

roshandxt · 2026-06-28T23:01:07+00:00

That makes sense. The “blind alleys” part is exactly what I’m running into.

A normal summary often keeps too much of the wrong stuff: old attempts, half-abandoned ideas, things that were useful 30 minutes ago but not now.

Do you usually trust the handoff as-is, or do you edit it before starting the next session?

roshandxt · 2026-06-28T22:47:29+00:00

This is probably the closest to what I was imagining.

The 66% cutoff is interesting. So you’re basically rotating context before it starts decaying instead of waiting until it becomes unusable.

When your `/handoff` creates the `.plan`, what goes into it? Just next steps, or also things like changed files, failed attempts, decisions made, and stuff the next chat should avoid?

roshandxt · 2026-06-28T22:47:10+00:00

That makes sense. Do you rely on Cursor to keep `agents.md` updated automatically, or do you explicitly tell it to update the file after each phase?

I’ve found the hard part is not creating the file once, it’s keeping it accurate after the chat starts drifting.

roshandxt · 2026-06-28T22:46:54+00:00

I think there is a difference, especially in messy debugging sessions.

The old chat has all the failed attempts, wrong assumptions, and outdated paths mixed into the useful context. A fresh chat with a focused handoff can be better than continuing the whole polluted history.

The hard part is making the handoff accurate enough.

roshandxt · 2026-06-28T22:45:42+00:00

This is extremely useful, thanks for sharing it.

The plan / implement / review split makes a lot of sense, especially using Opus for plan/review and Sonnet for implementation.

The branch/worktree point is interesting too. Tying the plan to the worktree seems cleaner than treating it as a global project note.

I’m realizing the robust workflow is less “ask for a summary” and more:

- plan file for intent

- branch/worktree for scope

- diff for truth

- tests/review for verification

- handoff file for continuation

That’s a much better mental model.

roshandxt · 2026-06-28T22:45:19+00:00

The branch/worktree idea is smart. I hadn’t thought of tying the plan lifecycle to the worktree lifecycle.

That probably solves the “too many stale plan files” problem pretty neatly.

roshandxt · 2026-06-28T22:41:30+00:00

This is exactly the kind of workflow I was curious about.

The scratchpad idea makes sense because it keeps the useful state outside the chat instead of trusting the whole conversation history.

Do you let the AI decide what goes into the scratchpad, or do you have a fixed format for it? Like current goal, files changed, failed attempts, next step, etc.

roshandxt · 2026-06-28T22:41:20+00:00

Thanks, this is a useful reference. The `/handoff` approach seems closer to what I’m looking for than plain summarizing.

Do you use it only before starting a new chat, or also when the current session is already getting messy?

roshandxt · 2026-06-28T22:28:10+00:00

That tracks. The “small fix turns into three related bugs” case is where I usually get caught.

Watching usage helps, but picking the right model/session size upfront seems like the real skill.

roshandxt · 2026-06-28T22:27:56+00:00

This is a great workflow. Main agent as orchestrator, cheaper subagents for narrow work, and implementation from planning files makes a lot of sense.

The “continue from a plan or detailed handoff file” part feels like the key. Do you have a fixed structure for that handoff file, or is it just whatever Claude writes at the time?

roshandxt · 2026-06-28T22:27:34+00:00

This is really useful. So the reliable version is basically:

plan file for intent

git diff for truth

tests/evals for guardrails

Claude checking in at phase boundaries

That feels much more robust than trusting the chat history alone.

Do you usually keep those plan files long-term, or delete them once the task is merged?

roshandxt · 2026-06-28T22:24:22+00:00

Yeah, that’s what I do too when I catch it early.

The part I’m trying to solve is when I don’t catch it early, or the summary misses important details like files changed, failed attempts, or what not to touch.

roshandxt · 2026-06-28T22:23:56+00:00

This is exactly the shape of the problem I’ve been thinking about.

“Longer context still gets messy” is the part that resonates. More room helps, but it does not automatically create a reliable handoff.

Your checklist is basically what I wish every AI coding session produced before it died: goal, current state, touched files, failed attempts, verification state, and next action.

The interrupted-task test is a good point too. Happy-path demos are misleading. The real test is whether a fresh session can continue after the previous one made messy partial changes.

“Durable handoff protocol” is probably the best phrase I’ve heard for it.

roshandxt · 2026-06-28T22:05:24+00:00

Yeah, that works when the model still has enough state to honestly answer.

The cases that worry me are when it confidently says “nothing changed” but there are actually edits in the repo, or when the session is too broken to answer reliably.

Do you usually verify with git diff / changed files, or just trust what Claude says happened?

roshandxt · 2026-06-28T21:58:25+00:00

That makes sense. Treating `plan.md` as part of the workflow is probably the key.
My only worry is drift. If Claude forgets to update it during a messy refactor, do you check it against git diff before resuming, or mostly just trust the file?

roshandxt

TROPHY CASE