Нельзя игнорировать, что AI coding, особенно с появлением таких инструментов, как Claude Code или Codex, резко увеличил объём коммитов и качество кода. Но многие не замечают, что с этим растёт и нагрузка на CI/CD, который начинает реально тормозить разработку. В линейке проектов, где я участвую, мы столкнулись с этим bottleneck’ом и решили проблему не просто апгрейдом железа, а переосмыслением самого процесса.
Почему AI coding превратил CI в узкое место
AI coding — это не только ускорение написания кода, но и увеличение количества мелких коммитов, PR и экспериментов. Раньше разработчик мог за час написать пару коммитов, сейчас за тот же час приходит десяток, и все хотят, чтобы CI это проверил и прогнал тесты.
В классическом CI pipeline каждый коммит запускает полный набор тестов, билдов и проверок. Это хорошо, когда коммитов мало и они крупные. Но когда поток коммитов увеличился в разы, CI начинает просто очередь набивать. В итоге разработчики ждут по 20–30 минут, чтобы получить фидбек, а иногда и больше. Это убивает flow и vibe coding — когда хочется быстро проверить гипотезу и сразу увидеть результат.
На Hacker News недавно обсуждали, что многие похожие проблемы ощущают разные команды. И Linear, как компания с мощным CI, поделилась, как они переосмыслили процесс.
Что мы взяли из опыта Linear: reworked CI под AI coding
В их статье ключевые моменты сводятся к таким наблюдениям:
-
Переход от запуска всех тестов на каждый коммит к умной селекции — запускается только то, что потенциально затронуто изменениями. Это снижает время ожидания и нагрузку на CI.
-
Параллелизация и оркестрация — не просто запускать все параллельно, а распределять задачи так, чтобы минимизировать блокировки и ожидания.
-
Использование incremental builds и кэширования — чтобы не пересобирать и не тестировать заново то, что не изменилось.
-
RAG (Retrieval-Augmented Generation) и agentic workflows для triage тестов — AI помогает понять, какие тесты критичны, а какие можно отложить или запускать отдельными батчами.
-
Интеграция с AI coding tools — например, автоматический запуск тестов на основе анализа сгенерированного кода, чтобы ловить ошибки на ранних этапах.
-
Мониторинг и метрики с фокусом на узкие места — чтобы определить, где CI тормозит, и быстро реагировать.
-
Гибкие правила запуска pipeline в зависимости от ветки и типа изменений — не всегда нужно прогонять полный pipeline на багфиксах.
На практике мы взяли эти идеи и адаптировали под наши сценарии. Например, для наших фронтенд-проектов с большим количеством мелких UI-коммитов мы настроили smart test runner, который запускает только affected tests. Это сэкономило нам до 40% времени в pipeline.
Пример: smart test runner на практике
Допустим, у вас есть монорепо с несколькими пакетами и много тестов. Вместо того, чтобы запускать все тесты на каждый коммит, вы можете определить, какие пакеты изменились, и прогонять тесты только для них:
changed_dirs=$(git diff --name-only HEAD~1 HEAD | awk -F/ '{print $1}' | sort | uniq)
for dir in $changed_dirs; do
echo "Running tests in $dir"
npm run test --workspace=$dir
done
Дальше можно интегрировать этот скрипт в pipeline, чтобы уменьшить время сборки.
Мы также внедрили кэширование node_modules и билд-артефактов с помощью MCP (Managed Cache Protocol) — это помогло избежать пересборки неизменных частей.
Честный вывод
AI coding круто ускоряет разработку, но если не прокачивать CI, то он станет узким местом. Перебор с количеством коммитов и PR без оптимизации pipeline — прямой путь к ожиданиям и снижению продуктивности.
Если у вас команда больше 5-7 человек и вы активно пользуетесь AI coding, рекомендую посмотреть в сторону:
- smart test runners и selective test execution,
- кэширование и incremental builds,
- мониторинг pipeline с фокусом на задержки,
- интеграция AI для triage и автоматизации запуска тестов.
Риски? Если переусердствовать с селективностью, можно пропустить баги. Поэтому важно тщательно настраивать покрытие и иметь fallback полного прогона на важных ветках.
Следующий шаг — пробовать agentic workflows, где AI не просто пишет код, а управляет pipeline, выбирает, когда и какие тесты запускать, основываясь на метриках и опыте. Linear уже в этом направлении, и это стоит мониторить.
В итоге, CI перестал быть просто «фоном» и превратился в активного участника процесса разработки, который надо прокачивать вместе с AI coding. Иначе вся скорость просто улетит в ожидание.
Попробуй сам: Cursor — AI-редактор для разработчиков.