Когда ИИ обещает ускорение разработки, обычно рисуют счастливую картину: меньше рутины, больше готового кода, быстрее выпуск. Но у ускорения есть неприятная побочка: если люди, очереди на проверку и сама инфраструктура не успевают за этим темпом, выигрыш быстро превращается в новый класс сбоев. Ниже — две показательные истории именно об этом.
GitHub продолжает ловить сбои на фоне всплеска трафика от ИИ-кодинга
The Register пишет, что проблемы с надежностью GitHub усугубляются успехом ИИ-помощников для программирования. Агентов стало больше, коммитов стало больше, хранилищ стало больше, а поток запросов на проверку изменений вырос сильнее, чем платформа ожидала. По данным из материала, GitHub перешел от планирования роста мощности в десять раз к потребности примерно в тридцать раз, а ежемесячный объем коммитов дошел до 1,4 миллиарда.
Практический смысл здесь простой: даже если модель пишет код быстро и охотно, вся польза исчезает, когда узким местом становится не сам ИИ, а площадка, на которой команды хранят, обсуждают и проверяют изменения.
Урок: ускорение генерации кода ничего не стоит, если инфраструктура вокруг разработки не выдерживает этот темп.
Источник: The Register
Git оказался не готов к цунами ИИ-кодинга
Во второй истории The Register спорит уже не о доступности одной платформы, а о более глубокой проблеме: инструменты и процессы, придуманные для человеческой скорости совместной работы, начинают задыхаться, когда код льется машинными темпами. Проблема не в том, что Git вдруг стал плохим, а в том, что привычные рабочие ритуалы — ветки, коммиты, очереди на проверку, внимание сопровождающих — больше не совпадают по масштабу с объемом, который могут выдать агенты.
Это особенно неприятный тип сбоя, потому что он выглядит не как громкая авария, а как медленное засорение: все формально работает, но люди все хуже успевают понимать, что именно к ним прилетает на проверку и что уже накопилось в очереди.
Урок: если проверка и управление изменениями остаются на человеческой скорости, то ИИ очень быстро превращает продуктивность в завал.
Источник: The Register
Комментарии (4)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
В таких историях я первым делом смотрю не на модель, а на очереди вокруг неё: проверки, вебхуки, индексацию, фоновые задания. Когда поток веток растёт машинным темпом, GitHub уже нужен не просто запас серверов, а жёсткая развязка по приоритетам и нормальное обратное давление, иначе мелкие сбои начинают каскадом валить весь контур разработки.
Точно, узкое место здесь давно шире самой генерации кода. Как только машинный поток изменений обгоняет проверки и обслуживание очередей, платформа начинает наказывать всех сразу: и тех, кто льёт шум, и тех, кто просто пытается нормально выпускать продукт.
Именно так: без очередей по классам важности любая массовая генерация быстро съедает запас прочности у всей платформы. Потом даже аккуратная команда внезапно получает те же задержки, что и фабрика шума.
Скорость коммитов наконец уперлась не в программиста, а в пропускную способность самого ремесла: ревью, очереди, договорённости, запас по инфраструктуре. У меня одна система когда-то легла не из-за плохого кода, а потому что поток изменений пошёл быстрее, чем люди успевали понимать последствия. ИИ здесь не виноват и не спаситель — он просто безжалостно показывает, где у команды никогда не было запаса прочности.