Если вы гоняете несколько сессий Claude Code по одному и тому же репозиторию, то рано или поздно две из них полезут в один и тот же файл и перетрут работу друг друга, и обнаружите вы это не сразу, а когда упадут тесты с каким-нибудь «unexpected keyword argument». Лечится это просто: либо вы паузите параллельную сессию, пока первая не закоммитит, либо разводите каждого агента по отдельному git worktree, чтобы у каждого было своё рабочее дерево и они физически не могли наступить друг другу на ноги. Я в итоге выбрал первое и просто остановил параллельную, потому что в моменте так было быстрее. Но историю стоит разобрать, потому что грабли тут не про код, а про то, как вообще организован параллельный вайбкодинг.
Что вообще произошло
Был обычный рабочий день по Картаре, и я держал не одну сессию Claude, а несколько штук разом по одному репо. Одна сессия делала рефакторинг чата — большую правку, которую я ещё не закоммитил, она просто лежала в рабочем дереве. И параллельно у меня крутилась вторая сессия, которая занималась своим, чинила что-то по LLM-части. И вот эта вторая взяла и закоммитила свой фикс в тот же самый service.py, что правила первая. А коммит, как известно, фиксирует то состояние файла, которое видит git прямо сейчас, и моя незакоммиченная правка первой сессии при этом просто растворилась.
То есть никакого «бага» в классическом смысле тут не было, никто ничего не сломал в логике. Просто два агента работали с одним физическим файлом в одном дереве, и тот, кто закоммитил последним, переписал реальность под себя. И самое противное в этой ситуации, что ты не видишь этого в момент, когда оно происходит. Ты сидишь, думаешь что обе сессии тащат своё, всё идёт по плану, а на деле одна уже молча затёрла полдня работы другой.
Как я это поймал
Поймал я это классически, на тестах. Запустились тесты и упали с «unexpected keyword argument». Вот это и был симптом: код первой сессии вызывал функцию с новым аргументом, который она же и добавляла в своей незакоммиченной правке, а в файле этого аргумента уже не было, потому что параллельная сессия перетёрла его своим коммитом. И ты сначала минут пять тупишь, потому что аргумент-то ты помнишь как добавлял, вот он, всё было, а его нет. А его нет, потому что его действительно нет, git хранит ту версию, которую закоммитил последний.
И это, кстати, был уже не первый звоночек на той ветке. Чуть раньше я заметил, что между двумя моими шагами на ветке вдруг появился чужой коммит, фикс, который я в этой сессии точно не делал. Стало понятно, что на ветке оказалось несколько коммиттеров, то есть несколько моих же сессий пишут в одно место, и я тогда ещё подумал что надо бы их развести. А руки дошли только когда оно реально стрельнуло.
Почему параллельные AI-агенты — это отдельная дисциплина
Тут вся соль вот в чём. Когда вы пишете код руками, вы физически один, у вас одна голова и одни руки, и вы просто не можете одновременно редактировать один файл в двух местах. А когда у вас несколько AI-агентов, каждый из которых сам читает, думает и пишет в файлы, вы внезапно становитесь не одним разработчиком, а маленькой командой, где у каждого свои руки. И вся та боль, которую обычные команды решали мерж-конфликтами, ветками и прочей дисциплиной годами, прилетает к вам разом, только команда эта — это вы сами, размноженный на четыре терминала.
Я свою позицию по этому поводу тогда сформулировал прямо в сессии: мы не можем вдвоём редактировать общие файлы вроде service.py в одном дереве, иначе будем терять работу. Звучит как очевидность, но осознаёшь ты это обычно постфактум, когда уже потерял. И ведь признак был заранее, я же сам до этого просил вынести разработку админки на отдельную ветку, чтобы сессии не путались между собой. Чуйка была, а инфраструктуру под неё я не подложил, вот и получил.
Два варианта решения
Когда я разбирался, на столе лежало ровно два варианта, и оба рабочие.
Первый — тупо пауза. Параллельную сессию останавливаешь, ждёшь пока первая докоммитит свою правку, и только потом снова запускаешь вторую, уже на свежем дереве. Это то, что я и сделал в моменте, потому что мне нужно было разгрести затор быстро, а не строить инфраструктуру. Минус очевиден: вы перестаёте быть параллельными, то есть теряете весь смысл гонять несколько агентов сразу, и просто работаете по очереди.
Второй вариант — git worktree, и вот это уже взрослое решение. Worktree — это механизм самого git, который позволяет иметь несколько рабочих деревьев из одного репозитория. То есть у вас один общий .git, одна история, но физически разные папки, каждая на своей ветке, и в каждой свой набор файлов на диске. Вы заводите по worktree на каждую AI-сессию, и тогда первая сессия правит service.py в своей папке, вторая в своей, и они просто не видят файлов друг друга до тех пор, пока вы сознательно не смержите ветки. Никакого «кто последний закоммитил, тот и прав», потому что коммитят они в разные деревья.
Я не стал перестраиваться на worktree прямо в тот день, выбрал быстрый путь и остановил параллельную. Но для постоянной работы с несколькими агентами это, конечно, единственный нормальный способ, потому что иначе вы будете ловить эти затирания снова и снова, и каждый раз тратить полдня на «куда делся мой аргумент».
Что я из этого вынес
Главный вывод простой: количество параллельных сессий Claude Code упирается не в то, сколько вы потянете по голове или по деньгам, а в то, как у вас разведён git. Один репозиторий, одно рабочее дерево, и сколько бы агентов вы туда ни запустили, они дерутся за одни и те же файлы, и работа теряется молча, без ошибок и предупреждений. И ловите вы это потом на тестах, в самый неудобный момент, когда уже не помните что именно затёрлось.
Поэтому если вы только начинаете гонять несколько агентов разом, заранее решите, как они будут изолированы. Либо честная пауза и работа по очереди, что проще, но медленнее, либо git worktree на каждого, что чуть сложнее настроить, зато потом параллелитесь сколько угодно и не теряете куски кода. А если у вас на ветке вдруг появился коммит, которого вы не делали, то это не мистика, это вторая ваша же сессия, и пора их разводить, пока она не съела чего-нибудь поважнее. Похожую историю про то, как параллельная работа агентов вскрывает границы между проектами, я уже разбирал в посте про настройку чужого бота, там тоже всё упёрлось в то, кто где работает. А о том, как эти же агенты по той же Картаре наплодили два разных продукта из одного — веб и Telegram Mini App, которые я потом неделю сводил обратно, — у меня есть отдельный разбор.
Так что вот вам мой опыт и набитая шишка бесплатно. Несколько AI-агентов — это не про мощность модели, это про то, чтобы каждый из них копал в своей яме, а не все в одной.