Как запустить двух агентов сразу и не смешать правки: git worktree

Что ломается, когда два агента сидят в одном каталоге?#

Коротко: рабочий каталог у git один, и индекс (staging area, куда git add складывает файлы перед коммитом) у него тоже один. Две сессии агента в одной папке пишут в общий индекс, поэтому git commit одной сессии забирает файлы, которые туда положила другая. Ветки от этого не спасают: ветка переключается на весь каталог сразу. Разводит эти состояния git worktree - второй рабочий каталог того же репозитория.

Сценарий выглядит безобидно. Вы открываете второе окно терминала, запускаете там второго агента на соседнюю задачу и уходите смотреть, что делает первый. Через двадцать минут в истории репозитория лежит коммит, в котором рядом с вашей правкой поселились два чужих файла. Отдельный git worktree для агента появляется в вашей жизни примерно здесь.

Дальше начинается разбор, который стоит примерно час. Надо понять, чьи это файлы, дописаны ли они до конца, можно ли их оставить и что будет с соседней сессией, если откатить коммит. Ответ на последний вопрос обычно git reset --soft HEAD~1, но искать его в чужом коммите неприятно.

Причина у этого одна, и агенты тут ни при чём. Git устроен так, что рабочее дерево, индекс и текущая ветка - свойства каталога, а не процесса. Два процесса в одном каталоге делят все три состояния, и ни один из них об этом не знает.

Вторая беда дороже первой. Если сборка релиза берёт файлы прямо из рабочего каталога, вместе с вашими в неё уедут и чужие незакоммиченные правки. Дисциплина тут не помогает, помогает механика: соберите артефакт командой git archive HEAD, и всё, что не в коммите, физически не доедет.

Что такое git worktree и что он делит?#

Коротко: git worktree - это второй рабочий каталог, привязанный к тому же репозиторию. У него свои файлы, своя ветка, свои HEAD и индекс, а история, объекты, ветки и удалённый репозиторий общие с основной рабочей копией. Первый каталог называется main worktree, все следующие - linked worktree, и их число git не ограничивает.

Документация Git описывает механизм прямо:

«A git repository can support multiple working trees, allowing you to check out more than one branch at a time.»

• Документация Git, git-worktree. Перевод: «Репозиторий git может обслуживать несколько рабочих деревьев, позволяя держать выложенными сразу несколько веток».

Ключевая фраза лежит в описании команды add - и это главная причина открыть страницу целиком:

«The new worktree is linked to the current repository, sharing everything except per-worktree files such as HEAD, index, etc.»

• Документация Git, git-worktree. Перевод: «Новый worktree связан с текущим репозиторием и разделяет с ним всё, кроме файлов, приватных для каждого worktree, - таких как HEAD, index и прочие».

Разделяется всё, кроме приватных файлов, и index в этом списке стоит вторым. Именно индекс был общим у двух сессий в сценарии из первого раздела.

Технически внутри git это разведено двумя переменными. $GIT_DIR указывает на приватный каталог конкретного worktree (.git/worktrees/имя), где лежат его HEAD, индекс и приватные ссылки. $GIT_COMMON_DIR указывает на общий .git основного репозитория, куда уезжает всё, что worktree делят между собой. Поэтому операции стейджинга в разных worktree пишут в разные файлы индекса и не дерутся за общий лок.

Одну оговорку стоит знать заранее, и она есть в той же документации:

«Multiple checkout in general is still experimental, and the support for submodules is incomplete.»

• Документация Git, git-worktree. Перевод: «Множественная выкладка в целом всё ещё экспериментальна, а поддержка подмодулей неполна».

На практике механизму больше десяти лет, и на нём построена параллельная работа агентов у Claude Code и Cursor. Но если у вас подмодули, проверьте поведение на кошках до того, как посадите туда агента.

Почему отдельной ветки недостаточно?#

Коротко: ветка не даёт изоляции, потому что переключается на весь рабочий каталог целиком. Пока две сессии живут в одной папке, они стоят на одной ветке и пишут в один индекс, а git checkout в одной из них меняет файлы под ногами у другой. Изоляцию даёт отдельный каталог, и git worktree - способ его получить.

Возражение «я же работаю на своей ветке» звучит убедительно ровно до первого git checkout. Ветка в git - указатель. Смотрит на него HEAD рабочего каталога. Каталог один, значит HEAD один, значит ветка одна для обоих процессов.

Хуже того, переключение ветки переписывает файлы на диске. Агент, который в этот момент читал файл или запускал сборку, увидит содержимое из другой ветки и сделает выводы по нему.

Отдельная ветка решает вопрос «куда сложить результат». Изоляцию даёт отдельный каталог, и worktree - это способ получить его, не заводя вторую копию истории.

Есть и вторая линия обороны, независимая от worktree. Команда git commit без указания путей коммитит весь индекс целиком, включая то, что добавили не вы. Документация формулирует это через опцию --only, которая включается автоматически, когда пути переданы:

«Make a commit by taking the updated working tree contents of the paths specified on the command line, disregarding any contents that have been staged for other paths.»

• Документация Git, git-commit. Перевод: «Сделать коммит, взяв текущее содержимое рабочего дерева по путям, указанным в командной строке, и не принимая во внимание то, что было проиндексировано по другим путям».

На практике это значит одну привычку:

git commit -- путь/к/файлу другой/файл   # коммитит только названные пути

Стейжить поимённо для этого недостаточно. Между вашим git add и вашим git commit сосед успевает сделать свой git add, и его файлы попадают в индекс, который вы коммитите.

Как завести worktree одной командой?#

Коротко: git worktree add создаёт каталог, ветку и выкладку файлов за один вызов. Каталог кладите рядом с репозиторием, а не внутри него, иначе он засорит git status основной копии сотнями неотслеживаемых файлов. Проверить результат можно командой git worktree list: она печатает главный каталог первым, за ним связанные, с веткой и состоянием каждого.

Порядок такой:

1. Создайте worktree на новой ветке. Имя ветки задаётся флагом -b, путь - первым аргументом.

   bash

   Copy

   git worktree add ../project-feature-a -b feature-a

2. Либо возьмите существующую ветку, если работа уже начата:

   bash

   Copy

   git worktree add ../project-bugfix fix-issue-456

3. Перейдите в каталог и запустите агента там.

   bash

   Copy

   cd ../project-feature-a
   claude

4. Проверьте, что получилось. Команда git worktree list печатает главный worktree первым, за ним - все связанные, с указанием ветки и состояния.

   bash

   Copy

   git worktree list

Если аргумент -b не передавать, git возьмёт имя ветки из последнего сегмента пути. Документация Git называет такую форму удобной для новой темы работы, и для одноразовых задач так действительно быстрее.

Одну и ту же ветку нельзя держать в двух worktree. Документация Git формулирует запрет так:

«By default, add refuses to create a new worktree when commit-ish is a branch name and is already checked out by another worktree.»

• Документация Git, git-worktree. Перевод: «По умолчанию add отказывается создавать новый worktree, если указанная ссылка на коммит - имя ветки, уже выложенной в другом worktree».

Сделано намеренно: два worktree на одной ветке перетирали бы друг другу индекс. Вживую отказ выглядит так:

fatal: 'feature-a' is already used by worktree at '/path/to/project-feature-a'

Что умеют сами агенты - Claude Code и Cursor?#

Коротко: и Claude Code, и Cursor умеют заводить worktree сами. В Claude Code это флаг --worktree, в Cursor - режим worktree в окне агентов плюс файл настроек с командами подготовки окружения. Руками команды git в обоих случаях можно не писать. Обе реализации кладут новый каталог в служебный путь внутри репозитория, поэтому его добавляют в .gitignore.

Claude Code создаёт worktree одним флагом:

claude --worktree feature-auth

Документация описывает поведение по умолчанию точно:

«By default, the worktree is created under .claude/worktrees/<name>/ at your repository root, on a new branch named worktree-<name>.»

• Документация Claude Code, Run parallel sessions with worktrees. Перевод: «По умолчанию worktree создаётся в .claude/worktrees/<имя>/ в корне репозитория, на новой ветке с именем worktree-<имя>».

Там же лежит совет, который избавляет от главного побочного эффекта такого расположения: добавьте .claude/worktrees/ в .gitignore, чтобы содержимое worktree не показывалось неотслеживаемыми файлами в основной копии.

Отдельная возможность, полезная тем, кто гоняет суб-агентов: изоляцию можно сделать постоянной для конкретного суб-агента, добавив в его описание поле isolation: worktree. Тогда каждый запуск такого суб-агента получает временный каталог, который убирается сам, если суб-агент ничего не изменил.

Cursor решает ту же задачу через окно агентов и файл .cursor/worktrees.json. Формулировка вендора:

«Worktrees let Agent work in isolated Git checkouts. Each task gets its own files, dependencies, and changes while your main checkout stays untouched.»

• Документация Cursor, Worktrees. Перевод: «Worktree позволяют агенту работать в изолированных выкладках Git. Каждая задача получает свои файлы, свои зависимости и свои изменения, а основная рабочая копия остаётся нетронутой».

В worktrees.json кладутся команды подготовки: установка зависимостей, копирование файла окружения, миграции, сборка. Ключи разведены по операционным системам (setup-worktree-unix, setup-worktree-windows, общий setup-worktree).

Почему .env и зависимости не доезжают?#

Коротко: worktree - это чистая выкладка репозитория, а .env и node_modules лежат в игнор-листе. Git переносит в новый каталог только отслеживаемые файлы, поэтому всё, что игнорируется, там отсутствует по определению, и приложение падает на старте без внятной связи с worktree. Claude Code решает это файлом .worktreeinclude, Cursor - командами подготовки в .cursor/worktrees.json.

Документация Claude Code говорит это прямым текстом:

«A worktree is a fresh checkout, so untracked files like .env or .env.local from your main repository are not present.»

• Документация Claude Code, Run parallel sessions with worktrees. Перевод: «Worktree - это чистая выкладка, поэтому неотслеживаемых файлов вроде .env или .env.local из основного репозитория там нет».

Лечится это файлом .worktreeinclude в корне проекта. Синтаксис - как у .gitignore, а копироваться будут только те файлы, которые и подходят под шаблон, и при этом игнорируются git:

.env
.env.local
config/secrets.json

«Only files that match a pattern and are also gitignored are copied, so tracked files are never duplicated.»

• Документация Claude Code, Run parallel sessions with worktrees. Перевод: «Копируются только файлы, которые подходят под шаблон и при этом игнорируются git, так что отслеживаемые файлы никогда не дублируются».

С зависимостями сложнее: скопировать их мало, нужна установка. Своя копия node_modules в каждом worktree нужна по двум причинам сразу. Первая: разные ветки могут требовать разных версий, и общий каталог зависимостей отдаст версию не от той ветки. Вторая, более коварная: генераторы вроде клиента базы данных пишут внутрь каталога зависимостей, и два таких процесса в одном каталоге перезаписывают результат друг друга.

Вторая причина съедает главный аргумент за экономию. Смысл worktree в том, чтобы разорвать связь между сессиями, а общий каталог зависимостей эту связь возвращает - только на уровень ниже, где её труднее заметить.

Можно ли просто симлинкнуть node_modules?#

Коротко: на современном фронтенд-стеке нельзя. Симлинк - это файл-указатель на каталог в другом месте, и сборщики отказываются идти по нему за пределы корня проекта, а тестовые раннеры путаются в путях. Turbopack на таком симлинке падает с ошибкой о выходе за пределы корня файловой системы, а Cursor прямо не рекомендует приём в документации. Экономить диск надо средствами пакетного менеджера.

Cursor формулирует запрет без оговорок и сразу даёт альтернативу:

«We do not recommend symlinking dependencies into the worktree. This can cause issues in the main worktree. Use a fast package manager such as bun, pnpm, or uv instead.»

• Документация Cursor, Worktrees. Перевод: «Мы не рекомендуем подключать зависимости в worktree симлинком. Это может вызвать проблемы в основной рабочей копии. Используйте вместо этого быстрый пакетный менеджер - bun, pnpm или uv».

Как именно ломается сборщик, видно в баг-трекере Next.js. Turbopack при разрешении модуля поднимается вверх по дереву в поисках package.json, натыкается на симлинк, ведущий за пределы корня файловой системы проекта, и падает:

«Symlink package.json is invalid, it points out of the filesystem root»

• Issue vercel/next.js#91896. Перевод: «Симлинк package.json некорректен, он указывает за пределы корня файловой системы».

Оговорка по этому репорту важна: там симлинком был сам package.json в дереве, собранном инструментами вроде Bazel, а не каталог node_modules в worktree. Механика одна и та же - Turbopack отказывается выходить за корень, - но кейс в репорте другой. Автор репорта ожидал, что Turbopack пойдёт по симлинку так же, как это делает webpack; воспроизводится на next@16.2.1-canary.7, в том числе на next dev при первом запросе страницы.

Дэйв Шумейкер разбирал ту же задачу на монорепозитории, где в node_modules больше 750 000 файлов и yarn install занимает десять с лишним минут. Симлинк отвалился на Vitest и Vite. Режим hardlinks-global у yarn не спас: он экономит байты, а время съедает само количество файловых операций. Копирование при записи на APFS упёрлось в то же самое.

«This is the part that none of the "git worktrees for AI agents!" articles I've read seem to mention.»

• Дэйв Шумейкер, «"Use git worktrees," they said. "It'll be fun!" they said.», 13.03.2026. Перевод: «Вот про эту часть ни одна из прочитанных мной статей про git worktree для ИИ-агентов, кажется, не упоминает».

Его вывод про узкое место такой: сам worktree создаётся мгновенно, время съедает установка зависимостей.

Легальный способ сэкономить диск существует, и он идёт от пакетного менеджера. Pnpm предлагает включить глобальное виртуальное хранилище одной строкой в pnpm-workspace.yaml:

enableGlobalVirtualStore: true

Что это даёт, вендор описывает так:

«each worktree's node_modules contains only symlinks into a single content-addressable store on disk»

• Документация pnpm, Git worktrees. Перевод: «node_modules каждого worktree содержит только симлинки в единое хранилище на диске, где пакеты лежат с адресацией по содержимому».

Разница с ручным симлинком принципиальная: симлинки кладёт пакетный менеджер, он же отвечает за их корректность, и структура каталога остаётся той, которую ожидают сборщики. Численных замеров pnpm при этом не приводит, поэтому проверять экономию придётся на своём проекте.

Что worktree не изолирует?#

Коротко: worktree изолирует файлы, HEAD и индекс. Порты, базы данных, кэши, глобальные сервисы и сам каталог .git остаются общими. Два dev-сервера в двух worktree подерутся за порт 3000 так же, как дрались бы в одной папке. Сохранённые ответы на запросы разрешений тоже общие: выданные в одном worktree, они действуют во всех и переживают удаление каталога.

Это ограничение вытекает прямо из определения: git разделяет рабочее дерево и приватные файлы worktree, а всё остальное на машине его не касается. Практические следствия такие.

• Порты. Dev-серверы по умолчанию берут один и тот же порт. Разводить придётся руками, через переменные окружения в каждом worktree.
• База данных. Один хост, одна база, одна схема. Миграции из одного worktree видит второй.
• Кэши сборки и временные каталоги, если они заданы абсолютным путём.
• Каталог .git. Общий по построению.
• Сохранённые ответы на запросы разрешений. В Claude Code ответ «Yes, don't ask again» на конкретную Bash-команду пишется в .claude/settings.local.json основной копии.

Про общий .git документация Claude Code говорит прямо:

«git commands in a worktree write to the main repository's shared .git directory»

• Документация Claude Code, Run parallel sessions with worktrees. Перевод: «Команды git внутри worktree пишут в общий каталог .git основного репозитория».

Про разрешения там же:

«choosing "Yes, don't ask again" for a Bash command in a worktree session saves the rule to the main checkout's .claude/settings.local.json, so it applies in the main checkout and in every other worktree of the repository, and it survives the worktree's removal»

• Документация Claude Code, Run parallel sessions with worktrees. Перевод: «Выбор "Yes, don't ask again" для Bash-команды в сессии внутри worktree сохраняет правило в .claude/settings.local.json основной копии, поэтому оно действует и в основной копии, и во всех остальных worktree репозитория, и переживает удаление worktree».

У последнего пункта есть неочевидное следствие: разрешение, выданное агенту в изолированном каталоге, изоляцией не ограничивается. Про то, какие права давать агенту, а какие закрывать, есть отдельный разбор: права агента в Claude Code. А проверить, что он вообще достаёт на машине за пределами репозитория, можно за десять минут: проверка песочницы агента.

Как вернуть работу и убрать за собой?#

Коротко: закоммитьте в worktree, влейте ветку в основную командой git merge --ff-only, затем удалите каталог через git worktree remove. Удалять каталог командой rm -rf нельзя: git оставит запись о worktree и продолжит считать ветку занятой. Осиротевшую запись убирает git worktree prune, а сам remove работает только на чистом каталоге - без незакоммиченных правок и неотслеживаемых файлов.

Порядок закрытия:

1. Закоммитьте всё в worktree. Пока изменения не в коммите, git worktree remove откажется работать.

2. Перейдите в основной каталог и влейте ветку.

   bash

   Copy

   cd ../project
   git merge --ff-only feature-a

   Флаг --ff-only тут несёт смысл. Он падает, если основная ветка ушла вперёд, - и заставляет заметить, что кто-то уже влил своё, вместо тихого merge-коммита поверх.

3. Удалите worktree.

   bash

   Copy

   git worktree remove ../project-feature-a

4. Если каталог всё же удалили руками, подчистите записи:

   bash

   Copy

   git worktree prune

Условие удаления в документации сформулировано жёстко:

«Only clean worktrees (no untracked files and no modification in tracked files) can be removed. Unclean worktrees or ones with submodules can be removed with --force. The main worktree cannot be removed.»

• Документация Git, git-worktree. Перевод: «Удалить можно только чистые worktree - без неотслеживаемых файлов и без изменений в отслеживаемых. Грязные worktree и те, где есть подмодули, удаляются с --force. Главный worktree удалить нельзя».

Вторая по частоте ошибка новичка растёт отсюда же. Каталог снесли через rm -rf, а git продолжает держать запись в .git/worktrees и отказывается выдавать ветку под новый worktree:

fatal: 'feature-a' is already used by worktree at '/path/to/project-feature-a'

Каталога по этому пути уже нет, а запись осталась. Команда git worktree prune убирает такие осиротевшие записи.

Claude Code часть уборки берёт на себя: при выходе из интерактивной сессии он смотрит, есть ли в worktree изменения, неотслеживаемые файлы или новые коммиты, и либо убирает каталог сам, либо спрашивает. Запуски в неинтерактивном режиме с флагом -p такого шага не имеют, и их worktree остаются на диске до ручного git worktree remove.

Worktree или свежий клон?#

Коротко: worktree дешевле по диску и держит одну общую историю, свежий клон проще по механике и изолирует полностью. Оба варианта решают исходную задачу - развести сессии по разным каталогам. Выбор зависит от размера репозитория и от того, насколько вам важна общая история. Опытные практики пользуются обоими подходами, и клон в этом споре не проигрышный.

Свежий клон - рабочий вариант. Саймон Уиллисон описывал свою схему так:

«I haven't adopted git worktrees yet: if I want to run two agents in isolation against the same repo I do a fresh checkout, often into /tmp.»

• Саймон Уиллисон, «Embracing the parallel coding agent lifestyle», 05.10.2025. Перевод: «Я пока не перешёл на git worktree: если мне нужно запустить двух агентов изолированно на одном репозитории, я делаю свежую выкладку, часто прямо в /tmp».

Общая история у worktree работает в обе стороны. Плюс: коммит из одного каталога сразу виден в другом без сети. Минус: повредить общий .git можно из любого worktree.

Пять ошибок, которые ловят всех#

Коротко: чаще всего ломаются на симлинке зависимостей, на git add . в общем каталоге, на удалении worktree через rm -rf, на размещении worktree внутри дерева репозитория и на убеждении, что worktree изолирует вообще всё. Четыре из пяти стоят потерянного часа, вторая - чужих файлов в вашем коммите.

1. Симлинк node_modules вместо установки. Cursor не рекомендует этот приём в документации, а Turbopack на симлинке, ведущем за корень проекта, падает при сборке. Экономьте диск через глобальное хранилище пакетного менеджера.

2. git add . и git add -A в общем рабочем каталоге. Забирают файлы соседней сессии. Правило «добавляю только своё» не помогает, потому что git commit без путей коммитит весь индекс. Помогает форма git commit -- путь.

3. rm -rf вместо git worktree remove. Оставляет запись в .git/worktrees и занятую ветку. Лечится через git worktree prune, но проще сразу пользоваться remove.

4. Worktree внутри дерева репозитория. Формально это работает, практически - основной git status заполняется неотслеживаемыми файлами, а линтеры и сборщики начинают обходить копию проекта внутри проекта. Держите каталог рядом с репозиторием либо добавьте служебный путь в .gitignore, как советует документация Claude Code.

5. Вера в полную изоляцию. Порты, база, кэши и сохранённые разрешения общие. Тест в worktree падает не только потому, что код неверный: порт мог быть занят соседом.

Сколько агентов держать параллельно?#

Коротко: технический потолок высокий. Cursor в changelog версии 2.0 заявляет запуск до восьми агентов параллельно на один промпт. Практический потолок ниже и упирается в человека: ревьюить и вливать результаты приходится вам. Ruben Broekx в Towards Data Science говорит про трёх агентов и смену роли, Саймон Уиллисон - про одну значимую задачу за раз.

Уиллисон описывает ограничение честнее всего:

«I can only focus on reviewing and landing one significant change at a time, but I'm finding an increasing number of tasks that can still be fired off in parallel without adding too much cognitive overhead to my primary work.»

• Саймон Уиллисон, «Embracing the parallel coding agent lifestyle», 05.10.2025. Перевод: «Я могу сосредоточенно ревьюить и вливать только одно значимое изменение за раз, но нахожу всё больше задач, которые можно запустить параллельно, не добавляя слишком много когнитивной нагрузки к основной работе».

Вторая половина фразы тут важнее первой: потолок стоит на значимых изменениях, а мелочь параллелится свободно.

Смена роли тут реальная:

«When three Agents are running in parallel, your job stops being "write the code" and starts being "decompose the work, assign it, review what comes back".»

• Ruben Broekx, «AI Agents Need Their Own Desk, and Git Worktrees Give Them One», Towards Data Science, 18.04.2026. Перевод: «Когда параллельно работают три агента, ваша работа перестаёт быть "написать код" и становится "разложить задачу, раздать, проверить, что вернулось"».

Верхнюю границу называет сам Cursor: changelog версии 2.0 обещает «Run up to eight agents in parallel on a single prompt» - запуск до восьми агентов параллельно на один промпт, каждый в своём worktree.

Второе ограничение - контекст. Чем больше параллельных задач, тем чаще вы переключаетесь между ними, и тем больше шансов, что агент потеряет нить в своём окне: почему агент забывает контекст.

С чего начать?#

Коротко: заведите один worktree под следующую задачу, положите каталог рядом с репозиторием, поставьте в нём зависимости и скопируйте файл окружения. Дальше добавьте .worktreeinclude или скрипт подготовки, чтобы второй раз это не делать руками. Весь цикл - четыре команды: add, установка зависимостей, merge --ff-only, remove; на первый прогон уходит около десяти минут.

Четыре шага на десять минут:

1. git worktree add ../project-next -b next-task
2. В новом каталоге поставьте зависимости своим пакетным менеджером и скопируйте .env.
3. Запустите там агента и убедитесь, что git status в основном каталоге чист.
4. Закончив: git merge --ff-only next-task в основном каталоге, затем git worktree remove ../project-next.

Когда это войдёт в привычку, автоматизируйте подготовку окружения: .worktreeinclude для Claude Code, .cursor/worktrees.json для Cursor, обычный shell-скрипт для всего остального.

Источники#

• Документация Git, git-worktree - определение linked worktree, что разделяется, ограничения remove и prune, оговорка про подмодули
• Документация Git, git-commit - поведение --only и коммит по списку путей
• Документация Claude Code, Run parallel sessions with worktrees - флаг --worktree, .worktreeinclude, isolation: worktree, уборка, общий .git и разрешения
• Документация Cursor, Worktrees - worktrees.json, рекомендация против симлинка зависимостей
• Cursor, changelog версии 2.0, 29.10.2025 - до восьми агентов параллельно на один промпт
• Документация pnpm, Git worktrees - глобальное виртуальное хранилище для нескольких worktree
• Баг-трекер Next.js, issue #91896 - отказ Turbopack идти по симлинку за пределы корня
• Саймон Уиллисон, «Embracing the parallel coding agent lifestyle», 05.10.2025 - свежий клон вместо worktree, потолок ревью
• Дэйв Шумейкер, «"Use git worktrees," they said. "It'll be fun!" they said.», 13.03.2026 - замеры на монорепозитории, три обходных пути, которые не сработали
• Ruben Broekx, «AI Agents Need Their Own Desk, and Git Worktrees Give Them One», Towards Data Science, 18.04.2026 - смена роли человека при параллельных агентах