Claude Code workflows & session control

It isn't the model degrading — it's context drift. After an hour of back-and-forth the agent answers a simple question based on a tangent from forty messages ago. It feels like the assistant "forgot" something, but it's the opposite: it remembered too much, including things you already superseded.

Three drift modes look fine inside one turn and compound across forty:

• Style drift. You said "use snake_case." Twenty messages later it's producing camelCase because it picked up your last paste, which happened to be JavaScript.
• Goal drift. You started debugging an auth bug, fixed it, then asked a database question — and the reply still carries auth-related caveats.
• Anchoring drift. You shared a file at the start; it keeps generating against that file after you've moved on, suggesting methods that don't exist on your current one.

Past roughly 70% window saturation, attention degrades non-linearly. The reset triggers are worth memorizing: the agent suggests a change it already made, contradicts a decision you locked in, confuses two files, starts producing smaller and more conservative diffs for no reason, or you find yourself writing longer and longer prompts to fight it.

The fix is not a bigger window — a 200K window with 180K tokens of stale context is more drifty than a 50K window with 5K current tokens. The right axis is curation, not capacity. Three resets, cheapest to nuclear: inline re-anchor ("forget auth.ts, db.ts is the ground truth now"), hard reset (new chat with the same project context but no message history), and session retire (close it, write a two-line note about what you decided, start fresh tomorrow). The note is the part people skip — without it you re-litigate the same decisions the next day.

No. The single most effective change is to split the work across two distinct sessions.

The planner is broad and shallow: it reads the relevant code, talks through architecture, weighs tradeoffs, and writes a plan — on a cheap or fast model. Its job is not to ship code; its job is to produce a document that can be handed off. The implementer is narrow and deep: it receives the plan, reads only the files the plan names, and writes the diff. Its context is never polluted with rejected ideas or architectural debate.

A good plan doc is boring on purpose:

## Goal
Add rate limiting to /api/upload.
## Files to touch
- src/middleware/rate-limit.ts (new)
- src/server.ts (wire middleware)
## Decisions already made
- Token bucket, in-memory, 10 req/min per IP, 429 + Retry-After
## Out of scope
- Distributed / per-user limits
## Open questions
- None. Implementer should not deviate.

Then chunk by what fits, not by what completes the feature. Anything that fits in 30–50% of the window produces reliable output; anything needing 70%+ will not. If a unit of work needs more than half the window to do cleanly, split it — schema first, then API, then UI; migration first, then the code that uses it; tests first, then implementation. Each chunk should be handable to a fresh session with a one-paragraph brief; if it isn't, it's too big. This is not the same as making tasks artificially small: a 200-line diff across three files is fine, a 50-line diff across twelve files is not.

It also helps to budget the prompt explicitly — tell the agent what must stay in context, not to re-read files it already read, not to dump directories, and to stop and ask if it wants to open more than five files. That gives it permission to refuse the expensive, low-value reads it would otherwise default to.

A loop can be genuinely useful: run the test, read the failure, patch the code, run the test again. That's a normal developer rhythm and agents can accelerate it. The problem is a loop with no stop condition. It stops feeling like automation and starts feeling like a slot machine that charges by the spin.

Make the loop explicit before it starts, not after the bill arrives. A controlled loop can answer: what command is being repeated? What changed between attempts? Which failure is still unresolved? How many times has it retried? Is the test output actually improving, or is the agent circling the same error with slightly different patches? Give it a budget and a stop condition up front.

That visibility matters for both ends of the experience spectrum. An experienced engineer wants to know when to intervene. A newer developer wants to avoid accepting a patch just because the assistant sounds certain. In both cases the loop should produce evidence, not just activity — the most dangerous output is not obviously-wrong code, it's plausible code with no proof behind it. A model will happily claim a bug is fixed because one narrow case passed. If the agent can't tell you which failure is still unresolved from the session record, it hasn't converged — it's spinning.

Model choice used to be purely a quality question. Now it's a cost and workflow question too. Route everything through the strongest model and cost becomes unpredictable while feedback slows down. Route everything through the cheapest and quality failures move downstream into debugging. The practical answer is not a universal model choice — it's matching the job to the tool.

A rough routing policy that holds up in practice:

• Cheap-first for low-risk exploration — summarizing logs, drafting a test, inspecting a small file.
• Stronger model for high-risk reasoning — architecture, an unfamiliar bug, careful review of a risky change.
• Local search before long-context prompting, so you're not paying to re-read the repo every turn.
• Explicit review before merging generated code.

Token budgets become engineering inputs the moment you decide which task deserves expensive reasoning and where the proof of completion has to appear. The mistake is treating every task as if it deserves the same model and the same amount of context — that's what makes usage feel unpredictable and turns the most expensive tool into the default. And the best routing decision is usually made after you can see the current state — the diff, the test output, the terminal history in one place — not guessed before the task starts. One team was ready to leave Anthropic because cost no longer matched their confidence, but provider loyalty was never the fix; a layer that lets you change engines per task is.

Sub-agents make coding feel less like a chat window and more like an operating system — and that changes the failure mode. When one assistant delegates to another, calls MCP tools, burns quota, edits files, and returns a clean summary, you can no longer judge the work from the final paragraph.

When several agents touch the same repository, context fragmentation becomes real: one agent solves a problem another already handled, a second edits a file without knowing it's been claimed, a third follows the plan superficially and skips the helper tests that would have proven the change. Coordination needs four things that become necessary the moment agent work goes parallel: shared memory, file ownership, explicit task boundaries, and a record of verification.

The cleanest time to define a boundary is before the run begins. A reviewer should be able to see the planned roles, the file scope, the tool access, and the stopping conditions. If an agent is only supposed to inspect logs, it should not silently edit source. And because MCP expands the surface area of every run, packaging should be visible rather than folklore: which servers are enabled, which agent can call them, what credentials or environment are assumed, and what log proves the call happened. Without that, one developer knows the right local setup, another copies half of it, and a third agent fails because a schema changed. If the only durable artifact of a nested run is a success summary, you're reconstructing responsibility from side effects.

Writing a rule once is easy. The hard part is proving the rule shaped the work every time an agent ran. A repo with AGENTS.md, CLAUDE.md, MCP configuration, and team conventions is just a pile of instruction files unless you have a visible way to confirm which rules each agent actually received. Otherwise you have documentation without enforcement.

This is a real gating concern, not a nicety. One developer wanted chat-level Skills and rule adherence in Claude Code before they'd trust parallel agents on something as consequential as legal drafting — because a coding agent can sound completely confident while skipping tests, ignoring style rules, duplicating another agent's work, or carrying hidden context the user never meant to include. The answer to that is not a stronger model and not a sharper one-off prompt; it's a workflow that exposes state.

Concretely, you want to be able to see which conventions were loaded into a given run, which Skills were available to it, and whether the agent that edited a file inherited the same rules as the agent that planned the change. Standardize the setup, then make it inspectable instead of tribal knowledge. That's the difference between a rule you wrote and a rule that actually governed the run.

The most dangerous AI coding output is not obviously-wrong code. It's plausible code with no evidence. A model can produce a clean explanation for a patch that was never run, claim a bug is fixed because one narrow case passes, or review its own work and miss the exact assumption that caused the mistake. A confident answer is not evidence, and a working screen is not evidence by itself.

Evidence is the reviewable trail that connects the task to the patch: scope, the files that changed, the commands that ran, the test output, what failed before it passed, and what still needs human judgment. The key is to ask for those receipts while the session is still active, not to reconstruct them at review time. Which files changed? What commands ran? What did the tests actually print? Was the failing case reproduced before the fix? A claim dies at the end of the session; evidence compounds, because it's reusable in PR review, incident debugging, onboarding, and the next agent's run.

This is also where a human belongs in the loop — but human-in-the-loop does not mean stopping every action. It means placing review where the cost of being wrong is high: destructive commands, secret handling, production deploys, and unclear tests. Let an approval gate slow down those, not routine edits. Sub-agent runs raise the stakes further: if the only durable artifact is a success summary, the reviewer is reduced to reconstructing the whole run from its side effects.

This is a real failure, not a hypothetical: a developer lost two weeks of Cursor agent chat and file changes after editing an old message, with no Git history or clear local checkpoint to fall back on. The lesson isn't "be more careful" — it's that AI-assisted work needs durable state that lives outside the chat window. Conversation is volatile; files are durable.

Anything important the agent figures out should be written to disk, not held in conversation the next session will never see. Decisions ("we chose X over Y because Z") belong in a DECISIONS.md. Intermediate state — a complex mapping, a non-obvious pattern the agent derived — belongs in a scratchpad you can throw away when the feature ships. Don't lean on /compact for this either: compaction is a lossy summary of a lossy summary and tends to discard exactly the architectural decisions you needed to keep.

When you end a productive session, write a structured handoff first: current state (what's done, in progress, untouched), the decisions made this session and why, the files changed, the next three concrete steps, open questions, and anything the next session should not redo. You read it, correct it, and save it. The next session opens cold, reads the handoff as its first action, and primes from a clean 500-token summary instead of a 50,000-token chat replay — it inherits the old session's conclusions, not its confusion. And the cheapest insurance is the oldest one: commit to Git at checkpoints, so a bad edit is a revert instead of a loss.

Two beginner-but-high-intent questions keep surfacing together.

First, setup clarity. A new MacBook Pro owner who wants to build an iOS app doesn't know whether Claude Code runs locally or in the cloud, how it performs on 16GB of RAM, or what else to install. The short version: the Claude Code CLI runs on your own machine and talks to a hosted model over the API, so the heavy computation happens remotely and 16GB is plenty for the tool itself — the real constraints are your API usage limits and whatever else you're running alongside it (simulators, builds, a browser). The tool is light; the model is elsewhere.

Second, provider trust. A team was leaving Anthropic because their confidence in high-stakes output no longer matched the cost. That pressure shows up from several directions at once — speed changes, billing changes, quota limits, setup confusion. None of it is solved by loyalty to a single provider. The durable move is a layer above the provider that remembers your project rules and records what happened, so you can change engines without changing your whole operating model. Framed that way, "which provider" stops being an identity and becomes a routing decision. A new developer shouldn't have to reverse-engineer the last twenty prompts to understand why an agent made a change, and a lead shouldn't have to ask which model was used or whether the tests ran.

The shift showing up in r/ClaudeAI threads is exactly this: experienced users have stopped asking "what prompt gets better code" and started asking for a repeatable engineering system around the agent. The pieces that keep coming up form a pipeline, not a prompt list:

• Codebase understanding first. Before any feature work, have the agent build (and persist) a map of the repo — architecture, conventions, where the bodies are buried — instead of re-discovering it every session.
• Plan before implement. Separate the planning conversation from the implementing one, and review the plan yourself. Most runaway diffs trace back to skipping this.
• Token discipline as a budget, not a vibe. Decide per task what model tier it deserves and how many tokens it may burn. One thread had a user about to buy a second Claude Pro subscription because limits kept interrupting work — that's a routing-and-budget problem, not a capacity problem (see model routing & costs).
• Tests and review as gates. Generated code doesn't merge until tests ran and a review pass (human or second agent) happened — "it runs" and "it's solid" are different claims.
• Decision docs / memory files. Write down what was decided and why, in files the agent reads next session. One builder's Claude Code Blender pipeline grew structured memory files so load-bearing they had to be extracted from the game code into their own layer — that's the point where a workflow has become real infrastructure worth maintaining.
• Multi-agent flows where they pay. Split planner/executor roles once the single-session ceiling hurts (see multi-agent control).

Adopt these one at a time — each is useful alone, and together they're the "engineering control system" people keep asking for.

The pain here isn't the model, it's the clock. Claude Code runs on a rolling usage window (the widely-hit "5-hour" limit), and when it trips in the middle of a task people reach for hacks that are worse than the problem. One developer built a key scheduler that presses Enter in VS Code so Claude auto-continues the moment the window resets — but it only works if the machine stays unlocked, focused, and unattended. That's an overnight run where nobody is watching what an agent is doing to the repo: not a resume, just an unsupervised agent with the safety rails removed. The other common move is handing the task to Codex, opencode, or Cline when Claude runs out — which works, except the new agent starts cold and loses the decisions, the file scope, and the why from the first half of the work.

The durable fix is to plan around the window instead of fighting it. Checkpoint often (commit to Git), and when you feel the limit approaching, write a short handoff note — current state, decisions made, next three steps, what not to redo — so any agent, or you tomorrow, resumes from a 500-token brief instead of a blind keystroke. Never leave a machine unlocked to fake continuity: a paused task with a good handoff resumes cleanly, while an overnight auto-continue produces work no one reviewed. And if you're constantly slamming into the ceiling, that's a routing-and-budget signal, not a reason to buy a second subscription — spend the cheap models where they're good enough and save the window for work that needs it (see model routing & costs).

It's a real and increasingly common worry: one developer described losing their core coding confidence after over-relying on AI and wanting a way back to trustworthy developer work. The failure mode isn't that the code is wrong — it's that you stop understanding your own codebase because you accept diffs you never read and fixes you never verified. Skill doesn't atrophy from using AI; it atrophies from using it as an oracle instead of a tool you supervise.

The way back is workflow, not willpower. Stay in the loop at the points that actually build understanding: read the diff before you accept it, and make the agent explain why it chose that approach, not just what it changed. Treat "it's fixed" as a claim that needs receipts — which files changed, what command ran, what the test actually printed — because the most dangerous output is plausible code with no proof behind it, the same instinct behind confirming an agent really ran the tests before you believe it. Write the decisions down yourself so you're steering the architecture rather than discovering it later. And deliberately keep some work manual: do the occasional fix by hand, review generated code as if a junior wrote it, and stay the person who can tell a solid patch from a confident-sounding one. Used that way, the agent handles the typing while you keep the judgment — which was the part that was actually your job. Proof trails and review gates aren't only for catching the agent; they're what keeps you engaged enough that your own skills stay sharp.

The prompt that finally got the agent to review code the way your team reviews code is worth more than the code it produced, and most people throw it away by accident. It lives in scrollback, gets buried under the next fifty messages, and is gone the moment the session closes. So the same instructions get reinvented — slightly differently — every week, and the quality of your AI work swings with how well you happened to phrase things that day.

The shift is to stop treating prompts and policies as conversation and start treating them as code. A prompt you rely on should have a name, a place it lives, and a version history — something you can open, edit, and invoke deliberately rather than retype from memory. A review checklist, a refactor procedure, a house style for commits: these are reusable skills, not chat messages. Once they're assets, improving one improves every future run instead of a single conversation.

Two things make a library actually get used. First, invocation has to be cheaper than retyping — if pulling up the right skill is one action, you'll reach for it; if it means digging through old chats, you won't. Second, the text should be clean and consistent, because a prompt that's been formatted and normalized behaves more predictably across models and sessions than a wall of hurried instructions. Do that, and the policy you worked out once survives past the chat that produced it, and every agent you run starts from your best work instead of a blank line.

This failure is more frustrating than buggy output because there is nothing to point at. The code compiles, the tests it wrote pass, the structure is reasonable — and it solves a problem you did not ask about. The gap is not model capability; it is that "what done looks like" lived in your head and never made it into the task. An agent optimizes for a plausible interpretation of the words you gave it, and a vague prompt has many plausible interpretations, most of which are not the one you meant.

The fix is to specify the target before the agent writes code, in the terms a reviewer would use to reject the wrong answer:

• Outcome, not topic. "Return 400 with password_required when the password is missing" is checkable; "improve the login flow" authorizes anything.
• Acceptance criteria. Two or three observable conditions that must hold when it is done. These double as the definition the agent builds toward and the checklist you review against.
• Explicitly out of scope. Name what not to build, so the agent does not helpfully add the adjacent feature it imagines you want.
• Force a plan first. Make the agent restate the goal and outline its approach in a few lines before it touches code. A wrong interpretation is cheap to catch in a five-line plan and expensive to catch in a finished diff. If the plan describes the wrong feature, you saved the whole build.

Then review against the criteria, not the vibe: a green test suite the agent wrote itself only proves internal consistency, not that the feature is the right one. The habit that compounds is turning each "that's not what I meant" into a written acceptance criterion for next time, so the specification sharpens instead of the corrections repeating. The point is to move the decision about what to build from after the diff to before it.

Yes — and the deletion is the part that makes it work. Agents made prototypes nearly free, and that changes what a spec is. The old economics forced you to guess requirements up front because building was expensive; now you can buy information instead of guessing: an hour of tokens produces a running sketch that reveals the wrong requirements, the missing constraints, the real shape of the data, and the workflow that looked fine on paper but feels wrong under your hands. People using this deliberately report the same thing — the throwaway pass kills bad requirements earlier than any planning session would have.

The discipline has three rules. Declare it disposable before you start: no cleanup, no tests, no naming debates, no refactoring — polish spent on a prototype is information budget wasted. Harvest before you delete: the deliverable is not the code, it's the written spec you extract — constraints discovered, decisions made, what turned out to be wrong about the original ask. Then actually delete it, because the failure mode of this pattern is well known: the demo that works gets promoted into production, and now untested, unowned scaffolding is load-bearing. Deleting is what forces the second build to happen against the spec, with real standards, instead of accreting onto the sketch.

Keep the two passes separated — different session, ideally a different project — so the sloppy pass's context doesn't leak into the real build. The prototype taught you; it shouldn't be teaching the agent shortcuts. The second build is where plan-then-implement, tests, and review apply. The first build's only job was to make that spec true instead of hopeful.

The confusion is understandable, because Claude Code is a different shape than the tools you're coming from. Cursor and Copilot are editors (or editor plugins) with AI bolted in. Claude Code is an agent that runs in a terminal against a working directory — a folder of code on your disk. It doesn't replace your IDE; it works alongside whatever editor you like, driving the same files from the command line. Plenty of people keep VS Code open to read and review while the agent does the editing. So the mental model isn't "which editor wins," it's "an agent operating on a project directory, and an editor for looking at the result."

Where does it run? Locally, on your machine, against your local clone. Private repos aren't special — you clone them with your own git credentials the same way you always have, and because the agent runs on your box, the code stays on your box. There's no separate upload step that puts your proprietary repo somewhere new.

The two-Macs-and-iCloud problem is the one that actually bites, and it's not a Claude Code problem — it's a project-isolation problem. A repo living inside a syncing folder (iCloud Drive, Dropbox) means the sync engine and the agent are both mutating files, git state included, and you get half-uploaded, conflicted, half-local projects. Give each project a fixed home outside any sync folder, let git — not the file-sync service — be how it moves between machines, and the "where does my project actually live" anxiety goes away.

The syntax-break trick is a genuinely clever hack and a clear signal of a missing feature: people need an asynchronous channel to a running agent, and the only one available is the filesystem the agent is already watching.

The reason interruption hurts is that a hard stop discards working state — the plan, what's been tried, what's been ruled out. The reason waiting hurts is that a wrong direction compounds into a diff too large to review, so you end up reverting good work along with bad.

What works better:

• Correct at a boundary, not mid-thought. After a file write, after a test run, at the end of a plan step — the agent's state is clean and your correction lands as the next instruction rather than as a lost turn.
• Leave the correction where it will be read. A NOTES.md the agent is told to check between steps, or a comment at the exact line, gives you an inbox rather than an interrupt. This is the sanctioned version of the syntax-break hack.
• Ask for a plan before a long run. Most mid-run corrections are plan disagreements that surfaced late. Thirty seconds reading a plan saves the twenty-minute wrong turn.
• Bound the run. "Do step one, then stop and show me" makes correction a scheduled event instead of an emergency.
• Queue new ideas instead of injecting them. A new thought mid-run is the most common derailment. Write it to a list; let the agent pull it when it's free. Interrupting to add scope is how a focused run becomes an unreviewable one.

The general principle: a running agent should have an inbox, not a panic button.

The fear is reasonable and the framing is wrong. What's on offer isn't a replacement for your judgment — it's a very fast, very literal junior who has read everything and remembers nothing. Your framework knowledge is what makes that useful instead of dangerous.

A staged adoption that doesn't cost you your standards:

• Start read-only. Point an agent at a repo you already know and ask it to explain a module. You can grade the answer instantly, which is exactly what you need while calibrating how much it actually understands.
• Then plans, no edits. Ask for an approach and a list of files it would touch. You'll catch the misunderstandings before any code exists, and you'll learn how to spec for it.
• Then one bounded change. One file, one behaviour, tests must pass. Read the whole diff. This is the step where most people discover their prompts were ambiguous.
• Expand permissions only after the loop is boring. Multi-file work, then terminal access, then longer autonomous runs — each step only when the previous one stopped surprising you.
• Ignore the tooling discourse for a month. MCP servers, skills, orchestration frameworks — nearly all of it is optimisation of a loop you haven't run yet. One agent, one repo, one reviewed diff teaches you more than any setup guide.

The developers getting the most out of this aren't the ones who trust it most. They're the ones who can tell quickly when it's wrong — which is a skill you already have.

You've spotted the thing leaderboards miss. Hold the model constant and the results still diverge widely, because most of what determines the outcome isn't the weights — it's the system prompt, which files get into context, how edits are applied, whether tests actually run, and what happens on failure.

To compare harnesses honestly, make the model the control variable:

• Use one real repo and three fixed tasks. A small bug fix, a cross-file feature, and a refactor with a test suite. Toy tasks flatter every harness equally.
• Same model, same prompt, everywhere. Word for word. Most "X is smarter" claims dissolve at this step.
• Score what you actually care about: did it pass the existing tests without editing them; how many turns to a correct diff; how much of the repo it read to get there; token cost; and how easy it was to redirect when wrong.
• Log the failure mode, not just pass/fail. A harness that fails by asking is far better than one that fails by inventing.
• Re-run after upgrades. These systems change monthly; a benchmark from March is history, not evidence.

One thing shows up consistently in field reports: on large projects the harness and the verification layer dominate the model choice. Isolated worktrees, deterministic CI gates, and a real click-through before deploy make an average model productive, and their absence makes a great one unreliable.

The instinct once agentic coding starts working is to add more: another MCP server, another plugin, another memory layer. Most of it is motion, not control. A brand-new setup needs a control model, not a bigger toolbox — a small number of surfaces you actually look at, arranged so the agent can't quietly go off the rails.

The stack that holds up is boring and short:

• Repo rules the agent re-reads, not rules it drifts from. One rules file, checked in, that states the architecture and what's off-limits. If it lives in five places it's already stale.
• A plan before a diff. Spec or test first, then bounded tasks with a file budget. "Change only X, don't touch shared code" is worth more than any plugin.
• A test gate the agent can't soften. Done means the suite is green on a run you can see, not a sentence claiming it passed.
• A diff you read before you accept. The single highest-leverage habit; a one-section request that produced a twelve-file diff has already failed.
• Evidence for anything visual or runtime — the rendered page, the real query result — not the agent's description of them.

Everything past that is a plugin you added because it existed. Add the sixth tool when a specific failure demands it, not on day one. A minimal stack you understand beats a maximal one you're hoping works.

Impressive demos are usually true and rarely reproducible, and the gap between those two things is where people make bad tooling decisions.

"One prompt built this" is doing a lot of hidden work. What gets omitted isn't usually dishonest — it's invisible to the person posting:

• The prompt itself, verbatim. "One prompt" and "one 900-word prompt with a spec, a file layout, and three constraints" are different claims, and only one of them generalizes to your work.
• The harness and its configuration. Same model, different scaffolding — instruction files, skills, MCP servers, retry behavior — produces wildly different outcomes. A result credited to a model is usually a result produced by a system.
• Turn count and human interventions. "One shot" often means one goal and forty steering messages. Still a good outcome; not the advertised one.
• What was already there. A template, a starter repo, or a project shape the model has seen thousands of times does much of the structural work.
• Whether it does more than render. The demo shows a screen. The questions are whether state persists, whether error paths exist, whether anything is tested, and what happens on the second input it wasn't demoed with.

The useful test is behavioral, not aesthetic: publish the prompt and the config, run it twice from a clean checkout, and show both runs passing the same acceptance checks. A demo that survives that is evidence about a workflow you could adopt. One that can't is evidence that a single run went well — worth watching, not worth restructuring your setup around.

Hold your own reports to the same standard, especially internal ones. "The agent built it in an afternoon" sets an expectation someone will be held to next quarter.

Starting a new chat is half the answer, and on its own it's a loss — you throw away the drift and the accumulated understanding together. The other half is deciding what deserves to survive the reset, and that list is much shorter than people expect.

A protocol worth running whenever you notice the symptoms you described:

• Write down the current invariants first. Not history — what is true now. The decisions still in force, the parts that are finished and shouldn't be touched, the constraint the last three sessions kept violating. Half a page. If it's running longer, most of what you're writing is history.
• Capture the acceptance check for the current piece of work, in a form that can fail. "Undoing something we already fixed" is the one symptom you can catch mechanically — it's a test that used to pass.
• Start the new session from that document, not from a summary of the old chat. A summary carries the drift forward, because it was written by the drifted context.
• Scope the first prompt narrowly. Unrelated-refactor behaviour reappears almost immediately if the opening request is broad.

Two of your symptoms deserve separate treatment. Random refactoring of untouched code is an unbounded edit scope — worth fixing directly by saying what may change and reviewing the diff per file, rather than hoping a fresh session behaves. And "technically correct but nowhere near what I had in mind" isn't a memory failure at all; it's a specification gap that a long session was quietly papering over with context you'd built up conversationally, and it will survive the reset unless you write the intent down.

Long projects don't need one long session. They need a durable document and a series of short ones.

Split it, but split on a real boundary rather than by habit. The one that holds up: what the tool needs to touch.

• Conversational chat is for work whose output is a document. Architecture, the data model, the ordering flow's edge cases, how Stripe objects map onto your domain. Having no repository access is a feature here — you're trying to think, and an agent that can start editing will start editing.
• A repository agent is for work whose evidence is a diff. Implementation, refactors, tests, debugging. It should start from the document rather than from a re-explanation, and its output should be reviewable file by file.
• Computer-use surfaces are for work that isn't in the repo at all — clicking through the Stripe dashboard, checking a deployed page, admin tasks against a running system. Powerful, and the least reversible of the three, which is a reason to keep it separate rather than a reason to avoid it.

The thing that decides whether this works is the handoff artifact between stages. Planning should end with something written — decisions, constraints, acceptance criteria — that the implementation stage reads directly. If the handoff is you re-typing the plan into the next tool, you've split the work without splitting the context, and you'll pay for that at every boundary.

For your build specifically, Stripe and deployment are where the boundary earns its keep, because those are the stages where an agent acting on a live system can do something you can't undo. Plan them conversationally, implement them as reviewable diffs, and keep the live-system steps explicit and supervised. The catalog and admin dashboard are ordinary repository work and don't need the ceremony.

No — and it is worth separating the two things you are being asked to trade. The agent's execution model, a terminal process with shell access running against real files, is what you trust. Diff rendering is a display concern. Bundling them is a product packaging decision rather than a technical requirement, and switching harnesses for better colours means changing the part that works to fix the part that does not.

What review actually needs, roughly in order of how much it matters:

• Change grouped by intent, not by file. The expensive question is "what did this run do", and a flat alphabetical diff answers it worst.
• Both sides visible at the point of change. Terminal diffs read fine for three lines and badly for thirty; that is a viewport problem more than a formatting one.
• Hunk-level granularity. Accepting most of a change while rejecting one part is the normal case with agents, and all-or-nothing review pushes people into accepting things they have not read.
• Proof attached to the diff. What ran, what passed, what was not covered. A beautifully rendered diff with no test result is still a guess.

The lightweight-workspace instinct behind the question is also right. The loop needs a file tree, a fast editor for Markdown, CSV, JSON and config, a real terminal, a diff surface, and the ability to move between project folders without rebuilding everything. Full IDE surface area is orthogonal to that loop — much of it exists to support a way of writing code you have partly stopped doing.

Judge a workspace by the loop — inspect, run, review, move on — rather than by feature count. The agent stays in the terminal where you trust it, and review gets a surface built for reading.