Trunk-based development

19 апреля 2026

TBD предполагает частую интеграцию небольших изменений в общую ветку. Для этого нужны быстрые проверки, понятное ревью и способы скрывать незавершенную функциональность. При параллельной работе людей и агентов стоит отдельно следить за пересечениями изменений и временем ожидания интеграции.

Что такое TBD и чем он не является

Trunk-based development - практика, при которой все инженеры коммитят в общую ветку (trunk, main) как минимум раз в день. Ветки короткоживущие: обычно несколько часов, максимум 1-2 дня. После merge в trunk ветка удаляется.

Что TBD не:

• Не запрет веток. Короткоживущие feature branches (для быстрой работы, code review через PR) допустимы и в большинстве команд используются.
• Не «одна ветка на все». Release branches существуют: создаются из trunk на момент стабилизации релиза, принимают только bugfixes, не feature-изменения.
• Не «все в один файл». Архитектура не упрощается из-за TBD; модульность и границы доменов (bounded contexts) остаются ключевыми.

Контраст с GitFlow. GitFlow (Vincent Driessen, 2010) - модель с develop, feature, release, hotfix ветками, долгими интеграционными циклами. Создан под контекст, где релизы происходят не ежедневно - в некоторых случаях это 2-4 раза в год, но чаще интервалы заметно короче (недели или месяцы). Packaged software, open-source-проекты с большим фоном внешних contributors - типичные кейсы применения. Для продуктовых команд с daily deploys GitFlow создает постоянные merge-конфликты и замедляет доставку. В 2020 году сам автор GitFlow признал, что модель не подходит для continuous-deployment окружений.

TBD - не про ветки, а про дисциплину интеграции

Смысл TBD - частое слияние кода в общую ветку. Ветки - деталь реализации. Команда может технически использовать короткие feature branches, но если ветки живут часами и сливаются сразу после review - это TBD.

Continuous Integration в оригинальном смысле Martin Fowler - это не «мы купили Jenkins» или «у нас зеленый CI-pipeline». Это практика: каждый разработчик интегрирует свои изменения в trunk как минимум раз в день. Автоматизация CI-сервера помогает поддерживать эту практику, но не заменяет частую интеграцию.

Условия, делающие TBD возможным

TBD не работает декларативно. Нужен фундамент.

Зеленый CI. Быстрый (в пределах 10-15 минут для большинства сценариев), надежный (не флаки), on-demand. Если CI падает часто по посторонним причинам, инженеры перестают доверять сигналу и либо игнорируют, либо откладывают интеграцию. Любая деградация времени или стабильности CI - немедленный приоритет для фикса.

Комплексное тестирование. Unit-тесты покрывают логику, integration-тесты проверяют взаимодействия, end-to-end тесты - критические пользовательские сценарии. Без тестов merge в trunk - это ставка на «вроде работает» без сигнала. Покрытие помогает находить непроверенный код, но целевой уровень нужно выбирать вместе с рисками и качеством тестов.

Feature flags. Архитектурное предусловие. Позволяют мержить неготовую функциональность, скрывая ее от пользователей. Незавершенные изменения нужно интегрировать так, чтобы они не нарушали работу основной ветки. Флаги помогают скрыть новое поведение; иногда достаточно разделить работу на безопасные подготовительные шаги. Разделение deploy и release (следующая секция) - эффект feature flags. Подробнее в статье «Фиче-тогглы».

Дисциплина code review. Ревью не должно задерживать интеграцию изменений. Практики: SLA на review (обычно в пределах 4 часов рабочего дня), pair programming как альтернатива PR-review для некоторых типов задач, четкие правила - что блокирует merge, что оставляется как follow-up. Долго висящий PR - сам по себе антипаттерн TBD.

Готовность откатывать быстро. TBD подразумевает много мелких релизов. Часть из них будет с проблемами. Инфраструктура должна позволять откатиться за минуты, не за часы - Kubernetes rollback, blue-green deploys, canary с автоматическим откатом при росте ошибок. Это важный слой, но его не стоит путать с продуктовыми ошибками: неверная формула скидки, баг в UI, неверное поведение фичи. Для них откат версии кода - избыточная мера и часто вредная (откатится все, что было в версии, включая исправления других команд). Продуктовые ошибки выключаются через feature flag внутри актуальной версии кода: kill-switch на проблемный функционал, fallback на предыдущее поведение, откат раскатки без отката кода. Два разных механизма для двух разных классов проблем.

Разделение deploy и release

Самая распространенная ошибка - считать, что deploy (доставка кода в production) и release (открытие функционала пользователям) - одно и то же. В мире TBD это разные вещи.

Deploy происходит постоянно: каждый merge в trunk может попадать в production в течение минут или часов. Инженеры видят свой код в проде быстро, получают быстрый feedback на реальные условия.

Release происходит on-demand: функционал скрыт за feature flags, открывается, когда продукт и бизнес готовы. Раскатка может идти по когортам (1% пользователей, потом 10%, потом 100%), A/B-тестам, географии, типу клиентов.

Разделение дает несколько эффектов:

• Снимается страх релиза. Merge кода в prod - рутина, не событие.
• Rollback превращается в выключение флага, не откат деплоя.
• A/B-тесты становятся естественной частью процесса, не специальной активностью.
• Разные команды (продукт, engineering) контролируют свои стороны: engineering контролирует deploy, продукт контролирует release.

Если незавершенное поведение сразу доступно пользователям, интеграция изменений может задерживаться до готовности всей функции. Разделение деплоя и включения помогает этого избежать. Подробнее - в статье «Фиче-тогглы».

Личный опыт: почему «просто мержить в master» не сработало

История из практики.

Декларация. Команда решила перейти на TBD. Объявили: мержим в master, чем меньше живут ветки - тем лучше. Инфраструктурных изменений не сделали - полагались на дисциплину разработчиков.

Что пошло не так. Декларация без инфраструктуры не работает. Через несколько недель выяснилось:

• Большие ветки продолжили висеть. Инженеры мержились в master «когда готово», и «готово» растягивалось на недели.
• В крупные ветки стали подтягивать изменения из master, чтобы ветка не устарела. Это не решало проблему, а маскировало ее: ветка жила дальше, разрастаясь.
• Хуже всего: в одну ветку начали коммитить несколько инженеров параллельно. Получались распределенные длинные ветки с коллективной разработкой вне master.
• К моменту merge в master код был спроектирован так, что закрыть флагами уже ничего нельзя. Feature flag неотделим от функциональности - его надо закладывать с самого начала.
• Merge-конфликты при попытке интегрировать такие ветки в master занимали дни. Некоторые ветки в итоге были переписаны с нуля.

Фикс. Пул тестовых стендов для веток сделали общим явным ресурсом. Завели публичный канал, в котором инженер отмечался при взятии стенда: кто, под какую задачу, почему именно стенд, а не флаг. Сама альтернатива TBD стала видимой команде.

Результат. Через несколько недель в канале всплыли системные паттерны: «взял стенд, потому что не умею работать с флагами в этом модуле», «взял, потому что дизайн не позволяет - слишком много state», «взял для ручного регресса» - и много случаев, где стенд был не нужен. Проблемы перестали быть невидимыми. Инженеры стали замечать, когда их кейс можно было закрыть флагом, и закладывать это в дизайн с самого начала. Использование стендов естественно сместилось на случаи, где они действительно нужны - изменения инфраструктуры или критичные флоу с ручным регрессом. В течение 2-3 месяцев merge в master стал доминирующей практикой.

Следующая проблема. Успех TBD принес свою головную боль: количество feature flags стало расти быстро. Инженеры стали закладывать флаг под каждую нетривиальную задачу, и через полгода их накопились сотни. Часть - давно раскатанные на 100%, но код с if-ветками жил дальше и добавлял шума при чтении. Часть - забытые в проде в выключенном состоянии, никто не помнил, что они делали. Несколько раз столкнулись с ситуацией: баг чиним через флаг, флаг уже существует под другое, включение триггерит поведение из давно забытой фичи.

Пришлось вводить практику контроля. Каждый флаг заводится с expiration-датой и owner-ом. В CI и дашбордах - список «просроченных» флагов с ответственными. Регулярный cleanup-спринт раз в квартал: раскатанные удаляются, забытые расследуются. Без этой дисциплины флаговое хозяйство превращается в вторую техническую задолженность, которая со временем перевешивает пользу от TBD.

Инженерная польза для разработчика

TBD часто презентуется как выгода для организации (быстрая доставка, меньше рисков). Важная часть, которую не всегда проговаривают - это выгодно самому инженеру.

• Меньше merge conflicts. Чем короче живет ветка, тем меньше шансов, что за это время кто-то изменит пересекающийся код. Перемерживание после нескольких дней - всегда болезненное; перемерживание после 2 часов - обычно тривиальное.
• Быстрый feedback на интеграцию. Когда код в master вместе с изменениями других инженеров, тесты сразу показывают, ломает ли твой код чужое поведение. На feature branch узнаешь только при merge, иногда через недели работы.
• Меньше rework при конфликтующих изменениях. Если две команды делают пересекающиеся изменения, TBD обнаруживает конфликт через день. Feature branches - через недели; к этому моменту одна из команд сильно продвинулась, и возврат стоит дорого.
• Проще debug. Рабочая машина отражает то же состояние, что у коллег и у production. В feature-branch мире разные разработчики работают на разных состояниях кода, и «у меня работает» становится регулярной репликой.
• Маленькие релизы вместо больших. В большой команде «маленький» релиз все равно может содержать десятки коммитов - но это заметно меньше, чем если бы команды жили в параллельных ветках неделями. Каждый merge имеет автора и понятный diff, ревью и откат остаются посильными. Сравнение не с идеальным маленьким, а с альтернативой big-bang-релизом после долгих интеграционных циклов.
• Меньше героизма. «Большой релиз в пятницу после midnight» - явление из мира редких релизов. В TBD каждый релиз рутина, никому не нужно жертвовать выходными на стабилизацию.

Случай из практики - сезонный бизнес с freezes. Есть отрасли, где четыре раза в год вводится freeze на деплой: в пиковые периоды трафика весь production замораживается по изменениям на несколько недель. Во время freeze - только хотфиксы в текущий production-тег, feature flags не используем даже как страховку (риск случайно включить что-то в пиковое окно).

После freeze накопленный в trunk код выпускается одним большим релизом. Даже с TBD этот релиз оказывается настолько рискованным, что часто принимается решение разбивать его на несколько виртуальных релизов и катить по частям - по фичам, доменам или когортам пользователей.

Без TBD эта ситуация была бы неуправляемой. Понадобилась бы отдельная интеграционная команда на полную ставку, занимающаяся мержем команд-ветвлений обратно в trunk после каждого freeze-периода. И даже с ней merge-конфликты копились бы до состояния, которое лечится переписыванием. TBD превращает freeze в управляемую паузу: в trunk продолжает приходить проверенный код от команд в своей дисциплине, после freeze остается свобода батчить релизы с нужной гранулярностью, не переживая про внутреннюю консистентность.

Когда инженеры видят эти эффекты на своей работе, TBD перестает быть «требованием руководства» и становится удобной практикой.

Scaled TBD: большие команды и монолит

Интуиция подсказывает, что в большой команде TBD сложнее: больше людей коммитят в одну ветку, больше конфликтов. На практике ровно наоборот: чем больше команда, тем критичнее TBD, иначе получается merge-hell.

Арифметика конфликтов. Вероятность конфликта между двумя ветками грубо пропорциональна времени их жизни × частоте изменений в пересекающихся файлах × числу активных веток. При 50 инженерах с долгими ветками получается квадратичный рост интеграционных проблем. Сокращение времени жизни ветки до часов снижает вероятность до приемлемой.

Монолит как особый случай. Большая команда, работающая над монолитом (20-50 инженеров в одном артефакте) - классическая ситуация, где TBD обязателен. В микросервисной архитектуре естественная изоляция: разные команды работают над разными сервисами, пересечения редки. В монолите все работают над одной кодовой базой.

DDD как предусловие для scaled TBD в монолите. Если границы доменов (bounded contexts) не выстроены, инженеры постоянно задевают чужой код. Даже с TBD это дает регулярные конфликты, потому что разные команды пишут в одни и те же модули. Выход - сначала выстроить DDD-границы (подробно в статье «Domain-Driven Design»), потом внедрять TBD. Без DDD масштабированный TBD в монолите дает постоянное взаимное торможение команд.

Release branches для стабилизации. На большом масштабе иногда нужна отдельная ветка для стабилизации кандидата в релиз - несколько дней тестирования, критичных bugfixes, отдельно от основного потока разработки в trunk. Эти release branches короткоживущие (1-2 недели максимум) и принимают только patches, не features. Не путать с feature branches - это разные паттерны с разным назначением.

Scaled TBD - работающая модель для команд в 100-300 инженеров. Google, Facebook, Microsoft - известные примеры использования TBD в крупных монорепозиториях. Требует инвестиций в test infrastructure (быстрые distributed-тесты, selective test execution), но работает.

TBD в эпоху AI-агентов

До 2024 TBD был «лучшей практикой» - рекомендованной, но не обязательной. С 2025-2026 ситуация меняется.

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

Механика ухудшения. В классической модели с feature branches агент генерирует код → появляется PR → review → merge. Если review откладывается, PR висит. В мире агентов PR много (десятки в день от нескольких агентов параллельно). Очередь несмерженных PR растет экспоненциально. Каждый PR, висящий дольше суток, расходится с trunk и требует rebase; rebase генерирует конфликты, которые агент должен разрешить или передать человеку.

Long-lived branches + AI = merge-hell экспоненциально. Если раньше команда могла выжить с «посмотрим на этой неделе PR», теперь накапливается catastrophic backlog. Либо TBD-дисциплина с быстрой интеграцией, либо человеческий review становится несгораемым bottleneck.

Интеграция параллельных изменений. Команды, не практикующие TBD, в 2026 упираются в потолок при попытке интегрировать AI-агентов. Даже корректный код агента может долго ждать интеграции в общую ветку.

Как агент работает в TBD + spec-driven режиме

Появление AI-агентов не отменяет TBD, а заставляет переосмыслить где и когда происходит каждый review. Spec-driven development (Spec Kit, BMAD Method, JetBrains Junie, Amazon Kiro) задает последовательность фаз, где каждая фаза становится контрольной точкой перед следующей. TBD обеспечивает дисциплину интеграции готовых результатов обратно в trunk.

Фазы spec-driven workflow и гейты review

Канонический поток на примере Spec Kit - шесть команд:

1. /speckit.constitution - установить принципы проекта (делается один раз на проект, не на задачу).
2. /speckit.specify. Агент пишет спецификацию на языке бизнеса из короткого prompt. Human review: соответствие требованиям продукта, полнота охвата edge-cases, маркированные unknowns. Гейт: spec.md одобрен перед переходом к plan.
3. /speckit.clarify (опционально, но рекомендуется). Агент задает уточняющие вопросы по недостаточно специфицированным областям, spec.md дополняется.
4. /speckit.plan. Агент пишет план реализации: стек, архитектура, data model, выбор библиотек. Human review: соответствие общей архитектуре, миграционные риски, безопасность, переиспользование. Гейт: plan.md одобрен перед кодом.
5. /speckit.tasks. Агент декомпозирует план на атомарные задачи с учетом зависимостей. Human review: разумность декомпозиции, порядок, маркировка параллельных задач.
6. /speckit.implement. Агент выполняет задачи в правильном порядке, гоняет CI в цикле. Spec Kit не экспонирует стратегию PR - выбор между одним PR на всю фичу или несколькими делается командой/инженером отдельно. TBD-дисциплина здесь подсказывает: при возможности дробить на короткоживущие ветки с частыми merge в trunk.

Verify-фаза в Spec Kit не выделена явной командой - проверка происходит через CI, тесты, AI review и human PR review по стандартной TBD-процедуре.

Когда агент открывает PR после implement-фазы, reviewer видит структурированные артефакты: spec.md (что сделано и почему), plan.md (как выбран подход), task-лист с выполненными пунктами, diff кода и тестов. Assumptions агента представлены как structured data в артефактах, а не закопаны в freeform commit messages.

Git worktrees для параллельной работы агентов

Агенты генерируют PR со скоростью, которая требует соответствующей git-стратегии. Стандартная практика 2026:

• Worktree на агента. Каждый агент работает в отдельном worktree - shared .git, но изолированные файлы и ветки. Claude Code создает worktrees в .claude/worktrees/<n> с веткой worktree-<n>. Параллельные агенты не конфликтуют по файлам, shared история остается консистентной.
• Префикс веток для агентов. Claude Code по умолчанию разрешает push только в ветки с префиксом claude/. Safety barrier: даже при ошибке агент не сможет напрямую писать в main или release. Снимается только при зрелом downstream review.
• Overnight PR queues. Распространенный паттерн: ночью агенты обрабатывают очередь issues - каждый issue получает worktree, ветку, попытку фикса, тесты, draft PR. Утром разработчик получает очередь draft PR для review. TBD-дисциплина обеспечивает, что после review эти PR быстро мержатся, не накапливаются.

Split-and-merge: multi-agent + TBD

Для крупной задачи агенты работают параллельно:

• Мастер-агент (обычно orchestrator) декомпозирует работу на независимые части по явным границам (bounded contexts, модули, фичи).
• Каждая часть - отдельный worktree, отдельный sub-agent.
• Sub-agents коммитят в свои worktree-ветки параллельно.
• Мастер-агент или человек объединяет результаты через последовательные merge в trunk в правильном порядке зависимостей.

При декомпозиции стоит уменьшать число файлов, которые приходится менять одновременно в разных задачах. DDD-границы и модульность критичны - без них sub-agents задевают друг друга, merge-конфликты возвращаются. Это еще один аргумент за предварительную работу над границами (см. «Domain-Driven Design»).

Где человек остается в цикле

Несмотря на автоматизацию, human review остается в нескольких точках:

• После spec.md - соответствие бизнес-требованиям. AI не знает бизнес-контекста за пределами предоставленного промпта.
• После plan.md - архитектурные решения: выбор библиотек, стратегия миграции, риски на production. Плюс проверка: не дублируется ли с уже существующим.
• После implement - PR review с фокусом на архитектуру и доменную логику (подробнее - следующая секция).
• Merge-gate в trunk. Финальное human approval. Даже при полной автоматизации всех предыдущих стадий merge-gate остается человеческим - особенно на main и release-ветках. Инфраструктурно это реализуется через branch protection rules в GitHub/GitLab.

Тулинг 2026 уже поддерживает эту модель: Spec Kit с intake-фазами и структурированными артефактами, Amazon Kiro, JetBrains Junie, Claude Code с AGENTS.md. Разбор экосистемы - в статье «SDLC для AI-агентов».

Code review в мире TBD + AI

Это, пожалуй, самая перестраиваемая часть процесса. Стандартная модель review (человек ревьюит весь diff line-by-line перед merge) перестает масштабироваться при росте количества PR.

Новая модель 2026

1. AI review первым. Когда PR открыт, AI-tool (CodeRabbit, Qodo, встроенные GitHub/GitLab AI-reviewers) автоматически анализирует код за секунды. Находит типовые проблемы: security, performance, coding standards, bugs. Разработчик исправляет AI-найденные issues до человеческого review.
2. Человек фокусируется на высокоуровневом. Архитектурные решения, business logic correctness, user experience implications. Не тратит время на catch'инг того, что ловит AI.
3. Plan-first / spec-first подход. Для больших изменений - сначала план или спека, которую человек ревьюит. Если план OK, агент пишет код по нему. Review кода становится проверкой соответствия плану, не свободным чтением. У Anthropic в Claude Code это /plan mode.
4. Agentic quality control. AI reviewing AI output становится стандартом. Один агент пишет код, другой проверяет с учетом codebase conventions, security policies, performance patterns. Человек подключается на последнем этапе.

Оценка AI-ревью. Измеряйте время проверки, долю полезных замечаний, пропущенные дефекты и нагрузку на человека. Без этих данных нельзя обещать сокращение времени ревью.

Soft gates vs hard gates

• Soft gate: AI findings показываются как guidance, не блокируют merge. Команда учится доверять AI через observation.
• Hard gate: AI findings блокируют merge, пока не исправлены или явно подтверждены как false positive.

Индустриальная практика: начинать с soft gates (2-3 недели на адаптацию), отслеживать acceptance rate (доля AI findings, которые разработчики принимают как валидные). Когда acceptance rate > 80% - переход на hard gates.

Опасности

• Переоценка AI-надежности. AI review хорошо ловит типовые паттерны, плохо ловит архитектурные ошибки и нарушения доменной логики. Без human review системные проблемы проскакивают.
• Ложные зеленые метки. Команда, увидев green pipeline от AI reviewer, перестает думать. Это снимает когнитивный контроль, который раньше давал человеческий review.
• Shifting cognitive burden. Как отмечает Stack Overflow в статье о guidelines 2026: с ростом количества AI-сгенерированного кода first look at the code для разработчика - это code review, потому что сам он этот код не писал. Когнитивная нагрузка на review возрастает.

Что AI не убрал: роль человека в review

В 2026 году, несмотря на рост AI-tooling, human review не исчез. Изменилось то, что проверяет человек. Классы проблем, которые AI стабильно пропускает и на которых сохраняется человеческий контроль:

• Архитектурные решения. Выбор между добавить метод в существующий сервис или создать новый; расширить агрегат или вынести в отдельный bounded context; использовать синхронный вызов или событие. AI видит код, но не видит архитектурных компромиссы, которые инженер держит в голове.
• Доменная логика и бизнес-правила. Соответствует ли реализация актуальным требованиям продукта. AI проверит синтаксис и типы, но не поймет, что «скидка 5% для premium-клиентов» в этом конкретном контексте должна применяться до налога, а не после. Эти правила часто живут в головах product-owners и инженеров, не в коде.
• Бизнес-контекст, не представленный в коде. Регуляторные ограничения, договоренности с партнерами, исторические компромиссы, которые невозможно вывести из diff-а.
• Security-решения с доменной компонентой. Кому можно видеть эти данные, каким образом, в каких сценариях. AI поймает SQL-injection, но не увидит, что этот endpoint не должен быть доступен B2B-клиентам без enterprise-плана.
• Координация между командами. PR затрагивает контракт, используемый другой командой. AI заметит изменение в public API, но не знает, что владелец соседнего сервиса сейчас в отпуске и координацию надо сдвинуть.
• Эдж-кейсы, требующие суждения. «Работает ли этот код при нулевом balance, при отрицательном balance, при missing data?» Часть AI ловит из тестовых паттернов, но суждение о том, должны ли мы обрабатывать конкретный edge case как ошибку или тихо fallback - все еще человеческое.

Примеры из индустрии (2026)

Даже AI-first компании и вендоры AI-инструментов сохраняют human-in-the-loop в code review. Примеры позиционирования:

• GitHub Copilot Review (встроенный в GitHub PR workflow) позиционируется как first pass: автоматические комментарии в PR, но merge требует человеческого approval. GitHub явно указывает, что Copilot Review дополняет, не заменяет человеческий review.
• Anthropic Claude Code - флагманский инструмент для агентской разработки. Режим /plan выносит план на human review до генерации кода; финальный merge остается человеческим решением. В публичных материалах Anthropic 2026 прямо формулирует: human-in-the-loop для высокорискованных операций.
• CodeRabbit, Qodo (бывший Codium), Greptile, PR-Agent - специализированные AI code review-инструменты. Все явно позиционируются как дополнение к человеческому review, не замена. Маркетинговый фокус - «экономия времени reviewers на типовых проблемах, больше времени на архитектуру».
• Google - исторически имеет внутренние AI-инструменты для code review (Tricorder, ML Code Review), но merge всегда требует human LGTM от owner-а кода. Правило сохранилось при введении новых AI-tools.
• Meta, Stripe, Shopify - публично обсуждали внедрение AI-review в СЕО-выступлениях и engineering blogs 2025-2026. Общее сообщение: AI review снижает нагрузку на reviewers, но не отменяет человеческий merge-gate.
• Shopify CEO Tobi Lütke в внутреннем меморандуме 2025 ввел правило: AI-использование обязательно, но артефакты проходят human review. Стало industry benchmark для AI-mandate компаний.

DORA 2025 фиксирует интересный сигнал: при adoption AI-tooling 90%+ время review выросло на 91%. Интерпретации разные, но факт - AI не устранил потребность в human review, а часто ее увеличил (больше кода производится, больше нужно смотреть).

Практический вывод. AI review сместил что делает человек - с поиска typo и security-lint в сторону архитектурных и доменных решений - но не убрал человека из цикла. TBD-дисциплина + AI review первым слоем + быстрый human review для архитектурных моментов - работающая модель 2026. Полная автоматизация без human discipline - путь к накоплению скрытых системных проблем.

Антипаттерны

• Декларация TBD без CI/тестов/флагов. Команда объявляет «мержим в master», не изменив инфраструктуру. Старые привычки побеждают через несколько недель; инженеры возвращаются к длинным веткам. История из секции 5 - типичный сценарий.
• Long-lived branches с коллективной разработкой. Несколько инженеров коммитят в одну feature branch неделями. Худшая из возможных моделей: все недостатки feature branches + внутренние merge-конфликты в ветке.
• Feature flags без lifecycle management. Флаги накапливаются десятками, мертвые не удаляются, код покрыт флаговой логикой, которую никто не помнит. Через 2 года - кладбище флагов, которое тормозит разработку. Решение - процесс регулярной cleanup и expiration-меток.
• Отложенный review. PR висит 3+ дней. Автор переключается на другую задачу, контекст теряется, review через неделю превращается в переписку. Ломает TBD даже при формальном соблюдении остальных условий.
• Review-heavy культура. Команда компенсирует отсутствие автоматизации и тестов через тяжелый человеческий review (4-5 ревьюеров на PR, обязательные архитектурные обсуждения, блокирующие обсуждения стиля). Ревью становится очередью и затрудняет частую интеграцию. Стоит проверить, какие вопросы можно закрыть автоматическими проверками, а где действительно нужно обсуждение.
• GitFlow «по привычке». Команда продолжает использовать GitFlow, потому что «так делали» или «нашел хороший tutorial». Не задается вопросом, подходит ли эта модель под текущий контекст (daily deploys, SaaS, не open-source).
• Hard gates на AI review с низким acceptance rate. Блокирование merge на AI findings, которые команда в 40-50% случаев считает неверными. Результат - frustration, обход правил, потеря доверия к инструменту.

Источники и смежные статьи

Первоисточники

• trunkbaseddevelopment.com - Paul Hammant. Канонический ресурс по TBD с паттернами, историей, scaled-вариантами.
• Dave Farley. Continuous Delivery (2010) - фундаментальная книга, TBD как ключевая практика.
• Nicole Forsgren, Jez Humble, Gene Kim. Accelerate (2018) - DORA research, TBD как одна из 24 capabilities, связанных с performance.
• Martin Fowler. Feature Branch - статья-критика feature-branch workflow.
• Anthropic Agentic Coding Trends Report 2026 - обзор агентной разработки; универсальная доля AI-коммитов в статье не утверждается.
• Stack Overflow: Coding guidelines for AI agents and people too - shifting cognitive burden в эпоху агентов.

Смежные статьи блога

• Фиче-тогглы - feature flags как enabler TBD и разделение deploy/release.
• Domain-Driven Design - как bounded contexts снижают interference между командами.
• Монолит vs Микросервисы - когда TBD в монолите работает.
• Паттерны распределённых систем - deploy vs release, observability.
• SDLC для AI-агентов - процессная трансформация.
• Стратегия внедрения Claude в команде - AI adoption с учётом TBD.