AI-assisted work patterns

Watch how experienced developers answer a tooling question in a chat channel. One reply is 200 words of "it could be your env vars, or DNS, or a firewall rule, or…"; the other is a single line like nslookup yourapp.com 8.8.8.8. The user reads the essay, runs nothing, and waits. They run the one-liner in five seconds and either have the answer or have output to paste back. For the first turn of a debugging conversation, the copy-paste-able command wins almost every time.

The reason is that the cognitive cost is asymmetric. Long advice makes the reader do four jobs — read, prioritise, plan, execute. One command makes them do one: copy and paste. The bug in most long-form AI answers is that they always dump the entire decision tree instead of the first branch that would actually narrow the problem.

A useful triage rule for the first turn:

• Is there one command that distinguishes your top two hypotheses? Send it and wait for output.
• Is it almost certainly one cause with a one-line fix? Send the fix, skip the diagnosis.
• Are there 5+ possible causes? Send the single diagnostic that eliminates the most of them — not the taxonomy.

Concrete examples: curl -i https://api.example.com/health -H "Authorization: Bearer $TOKEN" tells you in five seconds whether a 500 is network, auth, or server-side. EXPLAIN ANALYZE on a slow query plus \d+ tablename narrows a Postgres problem faster than a paragraph about pooling and indexes ever could.

Longer replies are the right call in three cases: the user already pasted diagnostic output and now needs interpretation; the fix has ordered prerequisites (config, restart) that must happen in sequence; or it's a "should I" design question where the tradeoff genuinely needs explaining. Even then, structure it as direct answer, then one paragraph of why, then the command — not paragraphs of preamble with a command buried at the bottom.

This is now the standard incident workflow, and it's broken. You keep three windows open: an SSH session into the production box, a Claude or Cursor window where you paste log excerpts and ask what they mean, and a notes file tracking what you've tried. Every thirty seconds you copy from the terminal, switch, paste, read, switch back. After an hour the notes are incoherent, the AI's context is full of decontextualised paste fragments, and you still haven't found the problem. You are the slow human bridge between tools that should be one — and the bridge is the bottleneck.

A genuinely unified SSH-plus-AI workflow does five things, in order:

1. A real SSH connection to the actual production box — not a sandbox or a managed shell.
2. A local scrolling log of every command and its output, inspectable without a paste step.
3. An AI that reads that log passively when answering, not only when you feed it manually.
4. The AI can propose commands you approve one at a time — not blanket auto-execute on a prod box.
5. Persistence across reconnects, so a closed laptop doesn't destroy the session and its AI context.

Almost no single tool does all five. SSH clients nail step 1 and nothing else. AI IDEs are strong on step 3 but treat the terminal as a bash subprocess, so real SSH to prod is hit-or-miss and the session lifecycle is fragile. Browser terminals and cloud dev environments each cover a different two or three. The gaps are structural: SSH is forty years old and AI assistants are two; passive log-reading is a non-trivial product to build; and the trust model for letting an AI run commands on production — propose, one-click approve — is uncommon in current tools.

Until one product ships steps 2–4 cleanly, you can stitch a working version together: SSH in, immediately tmux new -s prod and auto-reattach on reconnect; run a sidecar that tmux capture-pane -p -S -200 into a file; point a local agent at that file so it reads recent output before answering; paste-edit-run the AI's suggested commands by hand. It's not pretty, but engineers running incidents a couple of times a month find the setup worth it.

Two engineers spend an hour fixing a flaky deploy over a shared terminal. The next morning a third engineer picks up an adjacent task and opens the session log. She sees every command, in order, with timestamps — but not why any of them were run. That gap is the whole problem with async terminal handoffs. Replay tells you the script; blame tells you the actor; neither tells you the reasoning. And the reasoning is what decides whether tomorrow's engineer reproduces the fix or relitigates the investigation from scratch.

Plain command history isn't insufficient because it lacks data — it captures the output of decisions, not the decisions themselves. A decision-annotated session adds two things on the same timeline: free-form notes pinned to specific moments ("tried this because the 502s were from upstream A, not B"), and explicit branch points ("considered restarting the worker; chose to drain it first because in-flight jobs were billing-critical"). That third one — the considered-X-did-Y-because-Z marker — is the single most valuable note shape and the one almost nothing captures. This is a different artifact from session replay: replay is built for audit and postmortem, decision annotation is built for handoff.

The reason it usually fails is the capture UX. Everyone has tried keeping a notes file next to a long session; it works for about twenty minutes, then the work gets interesting, the cost of leaving the terminal to type into a doc exceeds the perceived value of the note, and the notes stop. The fix isn't discipline — it's putting the capture interface inside the terminal: a keystroke that pauses and prompts for a note attached to the current timestamp, a magic # note: comment prefix the recorder pulls out, or a small branch-point template. On the consuming side, the reader needs a timeline with notes pinned alongside commands, a jump-to-decision affordance that skips the boring ls and cat lines, and searchable rationale rather than just searchable commands.

Multi-agent and AI-assisted sessions raise the stakes: when an agent runs a tool call, its rationale lives in prompt context that evaporates the moment the session ends. Require the agent (or human) to leave a one-line rationale in-flight, on the same timeline, and the handoff problem mostly solves itself. It can't be a documentation step after the session — by then the context is gone.

There's a quiet expectation that bigger context windows end the context-management conversation — "just stuff the whole codebase in." Then you run a long session and the disappointment lands: the model holds the context, it just doesn't use the right parts at the right moments. Important early decisions get diluted by later noise, and at hour three the model confidently contradicts something it agreed to at hour one. Long context is not the same as good retrieval.

This shows up as retrieval drift, and it has recognisable flavours. Style drift: you said the codebase uses tabs, but five hours later a recent code block used spaces, so the model switches. Decision drift: the team decided not to migrate to library v4, and many turns later the model proposes an approach that requires v4. Naming drift: a helper defined at the start gets called by a slightly different name, or reinvented, by the end. Scope drift: you asked it to focus on file X and its attention spreads to Y and Z. In every case the right information is technically in the window — but recency and proximity pull the model away from what should have been load-bearing. Bigger windows tend to make this worse, not better: more tokens mean more competing signal, recency bias pushes the load-bearing decisions further back, abandoned tangents accumulate as noise, and the model's own earlier output starts dominating.

The fix isn't more tokens — it's checkpointing: a deliberate short summary, written mid-session, that captures only what's still load-bearing (the decisions, conventions, and constraints that should govern everything after — not the full history). Dropping that checkpoint back into the conversation re-promotes the important facts to a recent position where the model's attention is naturally higher. Good triggers: right after a decision, after a long debugging detour resolves, before switching scope, and on a regular cadence every 30–50 turns. Write it in plain language, lead with the decision then the reason, include negative constraints ("don't introduce X" is often the most load-bearing line), keep it to the ten most important facts, and date- or turn-stamp it. For a single session, in-conversation checkpoints are enough; for multi-session work, saving the checkpoint to a persistent memory substrate is what makes tomorrow's session — possibly in a different tool — open with the load-bearing facts already in scope. Checkpoints don't raise the model's ceiling; they multiply the useful working time before a session drifts.