DEV Community

pepk
pepk

Posted on

Keeping up with the AI: how one person runs nine Claude Code sessions in parallel

Give each project its own session and Claude Code writes in six of them, or nine, at the same time. The writing is no longer the constraint. The constraint is me, one person, taking in that output and issuing the next instruction.

So what I spend the most time on now is not deciding what to have the AI do. It is the work of keeping up with it. That splits in two.

  1. Perception. Make what just happened, and whether the output is correct, readable by a human.
  2. Instruction. Hand over what I want changed and what I want enforced, without explaining it at length in prose.

Neither is built once and left alone. Fixing skills, tidying CLAUDE.md and memory, keeping the single source of truth honest, maintaining an index: it continues as daily upkeep. This article is a record of where that stands.

A note on the division of labor. The implementation, the git operations, the scripts, and the pane described below were all written by Claude sessions, not by me. What I do is verify the deliverables and maintain the instructions the sessions work under, which live in CLAUDE.md, in skills, and in memory.

I run LLM system development at Cognisant LLC, on contract. I do the engineering myself and I handle all customer communication myself. On a normal weekday six or more sessions run in parallel, and nine is not unusual.

Claude Code is a product of Anthropic. Nothing here is official guidance; it is one practitioner's operating procedure.

1. Perception: put state and output in a readable form

Verify behavior and documents, not code

I moved what I verify off the code. Instead of reading the code myself, I do two things: run it and watch the actual behavior, and have Claude write the overall picture up as a document, then read that. The reason is not only speed. At the current model level, I find this catches more errors than reviewing the code myself, and drift in quality and direction shows up earlier.

The same documents, screenshots and video go straight to customers and teammates. When one person holds the whole engagement, it helps that what I make in order to verify is the same thing I make in order to explain.

Have documents produced in readable archetypes

If the overall picture arrives as a document, the document itself has to be readable. So the archetypes sit as templates inside a skill, and nothing gets built from a blank page.

What I want to see Archetype Where it fits
Who does what at which step Current-state flow, swimlane Process improvement. Shows where load and risk concentrate
How one document moves through approvals Approval flow Sign-off, applications, acceptance
A user's sequence of actions and their results Use-case flow App mockups, manuals, proposals
Something to project and argue over Slide deck Proposals and kickoffs, with an annotation layer and presenter view
Something to read and decide on alone A4 handout Specs, reports, anything distributed

With archetypes, naming one gets the same skeleton back every time, and I can read it knowing the same information sits in the same place. Before anything is built, the session writes a six-line reader-journey brief: who reads it, where they open it from, what they decide on the first screen, where the decision happens, what they do next, and what makes it obsolete.

Excel output works the same way. It is finished so it reads in one pass, with column widths, wrapping, row heights and zoom all set, then exported to PDF and checked on screen for clipping and overlap before it reaches me.

A window for what just changed

With six or nine running at once, a new file appears somewhere every few minutes. Walk the terminals asking each session what it wrote, and finding takes longer than checking.

What I wanted was one screen showing where things just moved, opening on click, outside the terminal. I have used Sublime Text for years, so the pane lives there: Recent Activity. Claude Code designed and implemented it; what I decided was where it sits and what it shows. It is open source (sublime-claude-code, MIT), and it is an unofficial community plugin, not affiliated with or endorsed by Anthropic. "Claude" and "Claude Code" are trademarks of Anthropic, PBC.

Six Claude Code sessions write docs in six projects; the Recent Activity pane lists each file by project and session as it lands

24h  ·  docs & media
▼ data-platform  5 ●2
  ● dataplat-tiles
  * 14:52 STATUS.md
    14:51 …/status_archive/2026-09.md
  ○ dataplat-seo
    14:50 …/snapshots/state.json  ⟨.wt-x⟩  ×3
▶ manufacturing-client  12
Enter fullscreen mode Exit fullscreen mode

Files changed in the last 24 hours, grouped project, then session, then file, newest first, opening on click. Documents and media by default (md, txt, html, pdf, xlsx, docx, pptx, csv, images, video); c adds code files. A project is the directory claude was launched in, and a tool call that changes into a subdirectory does not split it. Projects I do not need to watch are hidden with h.

Underneath, a filesystem watcher supplies what changed and a Claude Code hook supplies which session wrote it, and the two are joined. Scanning modification times across the whole tree was dropped after it took 99 seconds on a project holding 1.58 million files. One weakness remains: when two sessions in the same project run shell commands at the same time, a file cannot be attributed to either.

There is a window in the other direction too. Sessions have a small command-line tool that opens a file in Sublime themselves, and CLAUDE.md tells them to use it whenever they produce something I should look at. Rather than going to find deliverables, I have them brought to me.

2. Instruction: stop explaining fixes in prose

Perception alone does not keep up. Explaining every correction in sentences is its own bottleneck, so the channel changes by domain.

Domain How instruction is delivered What that means
Frontend Tweak Select elements in the browser and adjust type size, spacing, position and wording by hand, then hand the diff over as JSON. The session converts it into Tailwind classes or design tokens, applies it to the source, and verifies with before and after screenshots
Documents and slides Annotation Click anywhere on the document to attach a note, export the notes as JSON, and that is the correction request. No writing out "the top right of the figure on slide 3"
Backend Engineering judgment No tool removes this one. Design, boundaries and contracts get settled first, tests get written first, and fixes go one layer and one variable at a time with before and after differences measured across every category. The judgment stays on the human side
Infrastructure Monitoring and logs Behavior is only visible through monitoring and logs. Log design, failure-rate visibility, and a cost checkpoint go into operations: requests divided by human page views above 100 means the structure is wrong

Frontend and documents move toward not explaining in words at all. Backend and infrastructure move toward applying human judgment and observation. The word "instruction" covers both, but the instrument that works differs by domain.

Confirmations are multiple choice

When a session is unsure, it does not send back an open question. It forms a hypothesis, offers options with the recommended one first, and where the answer could branch, answers both branches in advance. The point is to get my reply down to one tap.

Rules live where they will actually be read

Where a rule sits determines whether it works.

  • Cross-cutting rules go in CLAUDE.md, which applies to every project
  • Rules tied to an action go in that action's skill self-check, read immediately before creating a pull request or sending something outside the company
  • Memory is for handover between sessions, not for rules. A rule there is not consulted at the moment of action
  • Project design decisions stay in that project's design docs, decision records and status file, and are not promoted to global

That split was decided after the same defect recurred three times in one day: screenshot links in pull requests lost their ?raw=true and rendered as broken images. The rule existed. It was in memory, and memory was not consulted at the moment the pull request was created.

Instructions get written down the moment they are given

When I say "from now on", "always" or "never" in conversation, the session does not treat having said it as the record. Within the same turn it decides where the rule belongs, writes it, and ends its reply with the path it wrote to. At the end of a session, a script cross-checks the instruction words in the conversation log against the files that were actually updated. It stops instructions from evaporating into chat.

3. The parallel foundation

Adding sessions produces defects in three places: identity, git, and shared machine state. These are fixed as instructions, and six or nine sessions now run without trouble.

  • Naming. Launch with claude --name <project>-<task>, and never run parallel on auto-generated names. The name is also the address for messages between sessions.
  • Isolate git with worktrees. In any project where parallel sessions can run, git worktree add first, then edit and commit inside the worktree. Since isolation became the default, defects on the git side have essentially stopped. It is the single most effective rule in the whole setup. Commits are chained to a branch check inside the same command, and git add takes explicit paths only.
  • Switch shared machine state inside one command. Write it as gh auth switch --user … && gh pr create …. Split across two commands, another session may switch the account in the gap, and the pull request opens under the wrong identity. Nothing raises an error.
  • Let sessions talk to each other. Claude Code sessions can message each other directly. I use it for declaring intent before touching a shared worktree, announcing what landed on main, and getting a single notification when another session goes idle.

One example of that last channel. The session that drafted this article took over open-source work from another session. My part was one sentence telling it to request the handoff. The handoff itself went between the sessions: the repository HEAD, whether anything was uncommitted, prioritized next actions, and the task-tracker ID.

4. Daily maintenance

None of this is a fixed installation. It gets repaired on roughly this cadence.

  • Skill and CLAUDE.md audit. Twice a year, against a written rubric, across every skill and agent definition. Is any canonical location now duplicated? Does each front-matter description still match what the skill actually does?
  • Memory audit. Take stock of memory across all projects, promote anything cross-cutting to global, and send project-specific design decisions back to the project they belong to.
  • Index upkeep. One hub page maps every asset, covering the config directory, business documents and development work, updated whenever a project is added or moved. Knowing where things are pays off more as projects accumulate.
  • A terminology ledger. When a session reaches for an unnatural literal translation, one line gets added: the term to avoid, and what to say instead.

Every one of these was added after a session got something wrong. The individual diffs are small. Stacked up, they are what keeps "able to keep up" true.

Closing

"More sessions, more throughput" is a common claim. In my case, running more only got easier once the human side, perception and instruction, was in place first. Without that, time spent searching and time spent explaining cancel the gain.

The important question is not how to make the AI faster. It is how one person keeps up with that speed. What is written here is today's answer, and tomorrow I will be fixing another line of it. If you are doing the same thing, I would like to hear in the comments where you have put your effort on perception and on instruction.

Resources

Read this elsewhere

About the Author

Daichi Kudo

  • Cognisant LLC CEO - Building the future where humans and AI create together
  • M16 LLC CTO - AI, Creative, and Engineering

Top comments (0)