Последнее узкое место

Код теперь создаётся быстрее, чем когда-либо, но ревью остаётся человеческим узким местом. Что произойдёт, когда машины будут генерировать код быстрее, чем мы способны его понять?

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Последнее узкое место

The Final Bottleneck Автор: Armin Ronacher Оригинальный текст:

Исторически написание кода было медленнее, чем его ревью.

Может казаться иначе, потому что код-ревью томились в очередях, пока кто-то не добирался до них. Но если сравнить сами процессы, создание обычно обходилось дороже. В командах, где люди и писали, и проверяли код, никогда не возникало ощущения «может, нам стоит программировать помедленнее».

Поэтому, когда всё больше людей говорят мне, что уже не знают, какой код находится в их собственной кодовой базе, я чувствую, что здесь что-то очень не так, и пора задуматься.

Вы находитесь здесь

Инженеры часто верят, что если сделать ванну побольше, переполнение исчезнет. Не исчезнет. В OpenClaw сейчас открыто более 2500 пулл-реквестов. Это очень большая ванна.

Любой, кто работал с очередями, знает: если входной поток растёт быстрее пропускной способности, происходит накапливающийся отказ. В этот момент backpressure (обратное давление) и load shedding (сброс нагрузки) — единственное, что сохраняет систему в рабочем состоянии.

Если вы когда-нибудь были в Starbucks, заваленном мобильными заказами, вы знаете это чувство. Обслуживание в зале рушится. Вы не знаете, сколько заказов впереди вас. Нет понятной очереди, нет надёжной оценки времени ожидания, и часто нет реального способа отмены, если не начать возмущаться.

Вот на что похожи многие опенсорсные проекты, связанные с ИИ, прямо сейчас. И всё чаще так выглядят внутренние проекты компаний в «AI-first» инженерных командах, и это нежизнеспособно. Невозможно приоритизировать, невозможно делать ревью, и многие PR нельзя смержить после определённого момента, потому что они слишком устарели. А автор, возможно, уже потерял мотивацию довести их до слияния.

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

Мы уже были здесь

Человечество уже было здесь. Много раз. Мы часто вспоминаем луддитов в контексте ИИ, но интересно посмотреть, что к этому привело. Марк Картрайт написал отличную статью о текстильной промышленности Британии во время промышленной революции. В её основе лежала простая идея: каждый раз, когда устранялось узкое место, инновации происходили ниже по потоку. Ткачество ускорилось? Пряжа стала ограничением. Прядение стало быстрее? Волокно нужно было улучшить, чтобы выдерживать новые скорости, пока наконец спрос на хлопок не вырос, и его тоже пришлось автоматизировать. То же самое мы видели в судоходстве, что привело к современным автоматизированным портам и контейнеризации.

Как инженеры, мы тоже уже были здесь. Ассемблер не масштабировался на большие команды, и нам пришлось изобрести языки высокого уровня. Многое из того, что делали языки программирования и фреймворки — позволяло нам писать код быстрее и масштабироваться на большие кодовые базы. Чего они не делали до сих пор — не отнимали базовый навык инженерии.

Хотя писать на C определённо проще, чем на ассемблере, многие ключевые проблемы остаются теми же. Латентность памяти всё ещё важна, физика всё ещё наше главное ограничение, алгоритмическая сложность всё ещё определяет успех или провал ПО на масштабе.

Сдаться?

Когда одна часть pipeline (конвейера) становится радикально быстрее, нужно ограничивать входной поток. Pi — отличный пример. PR автоматически закрываются, если автор не в доверенных. Проект уходит в OSS-отпуска. Это один вариант: вы просто ограничиваете входящий поток. Вы сопротивляетесь своим новообретённым возможностям, пока не научитесь с ними справляться.

Или принять

Но что если скорость продолжит расти? Что ниже по потоку от написания кода нам придётся ускорить? Конечно, ревью пулл-реквестов явно становится узким местом. Но его нельзя по-настоящему автоматизировать. Если машина пишет код, машина лучше бы ревьюила его одновременно. Так что на человеческое ревью в итоге попадало бы то, что уже прошло максимально критичную проверку самой способной машины. Что ещё стоит на пути? Если мы продолжаем верить в фундаментальный принцип, что машины не могут нести ответственность, то люди должны быть способны понимать выход машины. А машина будет поставлять неустанно. Тикеты поддержки от клиентов пойдут напрямую к машинам для реализации улучшений и исправлений, для ревью другими машинами, для формального одобрения людьми по утрам.

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

Я — узкое место

Но для меня это всё равно ощущается иначе. Может, потому что мой скромный мозг не способен осознать изменения, через которые мы проходим, и будущие поколения будут просто смеяться над нашими проблемами. Это ощущается иначе, потому что то, что я вижу в некоторых опенсорсных проектах, в некоторых компаниях и командах, кажется глубоко неправильным и нежизнеспособным. Даже сам Стив Йегге теперь выражает сомнения в устойчивости постоянно растущего темпа создания кода.

Так что если нам придётся принять это? Если нам придётся проложить путь для того, чтобы этот новый тип инженерии стал стандартом? Какие affordances (возможности взаимодействия) нам придётся создать, чтобы это работало? Лично я не знаю. Я смотрю на это с очарованием и замешательством и пытаюсь осмыслить.

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

Я тоже теперь узкое место. Но знаете что? Два года назад я тоже был узким местом. Я был узким местом всё это время. Машина на самом деле этого не изменила. И пока я несу ответственность и подотчётен, так и останется. Если мы сумеем передвинуть ответственность выше, это может измениться, но пока неясно, как это произойдёт.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot