# «Конец программирования»: создатель InfluxDB о переписывании Bun на Rust силами ИИ
Каноническая страница: https://plainews.ru/posts/perevod-konec-programmirovaniya
Опубликовано: 2026-08-28T14:00:22.421Z

Создатель InfluxDB Пол Дикс считает, что переписывание Bun с Zig на Rust ИИ-агентами знаменует конец программирования. Разбираем факты и прогноз.
Пол Дикс, основатель и технический директор InfluxData и создатель InfluxDB, 25 августа опубликовал эссе «Конец программирования». Поводом стал вышедший неделей раньше релиз Bun 1.4 — версии, в которой кодовую базу переписали с Zig на Rust.

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

## Как Bun переписали на Rust

Дикс опирается на рассказ о переписывании в блоге Bun. Работу вёл один разработчик — создатель Bun Джаред Самнер. Он пользовался предрелизной версией модели Fable 5 и, судя по всему, практически неограниченным бюджетом токенов.

Самнер построил обвязку и фреймворк, в которых агенты параллельно переводили код с Zig на Rust. Дальше — цифры:

| Параметр | Значение |
| --- | --- |
| **Направление** | Zig → Rust |
| **Объём** | более 1 млн новых строк; мёрж показал +1 009 257 / −4 024 строки |
| **Первичное переписывание** | 11 дней |
| **Коммиты** | 6 778, их сделали несколько агентов |
| **Стоимость токенов** | около $165 000 по ценам API |
| **Модель** | предрелизная Fable 5 |

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

Споры вокруг переписывания начались ещё в начале мая, когда в репозитории появился тот самый мёрж. Тогда Дикс предположил в X, что работа сделана не на Opus 4.7, а на ещё не выпущенной Mythos: с Opus 4.7 такое, по его опыту, было бы невозможно.

Частое возражение — у агентов был «оракул», исходный код на Zig, с которым можно сверяться, поэтому задача была простой. Дикс считает, что это недооценка. Если построить систему проверки и правильно поставить задачу, ИИ способен создать очень сложный софт и дорабатывать его, пока он не заработает.

## Инженеры Anthropic и OpenAI «живут в ближайшем будущем»

Второй аргумент Дикс берёт из публичных высказываний сотрудников Anthropic и OpenAI в X за последние пару месяцев. По их словам, каждый из них отправляет десятки или сотни пулл-реквестов в неделю и переключился на задачи уровнем выше.

Внимательно отревьюить сотни PR в неделю и параллельно делать свою работу невозможно. Поэтому, если принимать их слова за чистую монету, очень внимательного ревью каждой строки они больше не делают. Время уходит на системы, промпты и инструменты верификации, чтобы ИИ писал софт в масштабе и быстро. Так Дикс понимает их разговоры о «петлях» (loops).

При этом у них неограниченный доступ к Fable и Astra — следующей модели OpenAI. Дикс называет это «ближайшим будущим», которое остальные «крестьяне», вероятно, увидят через год. Пока что остальные разработчики ждут, когда обнулится недельный лимит на Fable.

> **Важно.** Всё это — пересказ публичных заявлений сотрудников лабораторий, а не проверенные данные о внутренних процессах. Сам Дикс оговаривается, что так выходит, если принимать их слова буквально.

## Опыт самого Дикса: 14 и 28 часов автономной работы

По ощущениям Дикса, Fable качественно отличается от прошлых моделей — примерно так же, как в конце ноября прошлого года выделилась Opus 4.5. Модель перешла порог, после которого можно давать более высокоуровневые указания и меньше контролировать.

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

| Задача | Время работы | Результат |
| --- | --- | --- |
| **Интеграция с Iceberg**: доступ к данным InfluxDB через Iceberg REST или внешний бакет S3 с каталогом Glue | 14 часов | Рабочая версия; затем сквозная проверка на кластере InfluxDB с DuckDB и PyIceberg в роли клиентов, модель исправила несколько багов |
| **Репликация с edge-узлов**: узлы-спутники периодически отправляют сжатые данные в центральный кластер | 28 часов | В основном рабочая реализация; после развёртывания в тестовой инфраструктуре AWS и нескольких итераций — сквозная рабочая реализация, которая работает до сих пор, спустя несколько месяцев |

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

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

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

## Горы мусора и организационная инерция

Дикс не рисует идиллию. Он прямо пишет, что будет и «гора мусора» (mountain of slop): забагованный, бесполезный, ужасный и оскорбительный софт, который не соответствует ничьим представлениям программистов об эстетике, назначении и стиле. Но рядом с ним появится и хорошо спроектированный рабочий софт, который решает реальные задачи, хотя люди не проверяли его код в деталях.

Взрывной рост уже виден на графике из поста GitHub о сбое 17 августа: с прошлого года объём создаваемого кода круто растёт по экспоненте. Гипотеза Дикса — в основном это пет-проекты, внутренние экспериментальные проекты компаний и софт для личного пользования, то есть некритичные вещи.

В большинстве компаний, пишет он, есть серьёзное организационное сопротивление тому, чтобы разработчик выпускал в ключевые продукты вдвое больше кода, не говоря уже о 10- или 100-кратном росте. К тому же почти весь этот код написан не нынешними топовыми моделями вроде Fable 5 и GPT 5.6 Sol, а флагманами нескольких месяцев давности.

## Прогноз Дикса по срокам

Год назад были Opus 4.1 и GPT-5. В конце ноября — начале декабря прошлого года вышли Opus 4.5 и GPT 5.2 — модели, из-за которых, по выражению Дикса, каждый технический директор в зимние праздники запаниковал, осознав, что фичи и софт теперь можно создавать по желанию. Дальше он ожидает:

| Когда | Что ожидает Дикс |
| --- | --- |
| **Сентябрь 2026** | Astra от OpenAI — модель класса Mythos/Fable, вероятно, способнее Fable 5 |
| **Конец 2026 — начало 2027** | Для Fable и Astra — такой же «пороговый» скачок, каким были Opus 4.5 и GPT 5.2 |
| **Конец 2027** | Этот уровень интеллекта подешевеет настолько, что большинство сможет работать с ним полный день, как Самнер с предрелизной Fable |
| **Ещё через год-два** | Широкий доступ к системам, которые генерируют токены в 10–100 раз быстрее и намного дешевле; он ссылается на анонс Cerebras C4 и результаты OpenAI Jalapeño |
| **Следующее десятилетие** | Многие, если не большинство компаний по инерции продолжат писать код вручную и ревьюить каждую строку |

Самые продуктивные создатели софта, по Диксу, будут работать без программирования в привычном смысле: направлять ИИ, строить обвязки, «фабрики софта», системы QA и верификации. И наступит момент, когда работающего в продакшене кода, написанного ИИ, станет больше, чем написанного людьми. Это и будет конец программирования.

## Что это значит для читателя

Ниже — наша оценка того, как выглядит смена ролей в картине Дикса:

| Сейчас | По Диксу, станет |
| --- | --- |
| Код пишет человек | Код пишут агенты, человек задаёт требования, архитектуру и направление |
| Люди ревьюят каждую строку | Люди проверяют конечный результат, а не код |
| Качество держится на код-ревью | Качество держится на тестах, верификации и циклах улучшения |
| Главное ограничение — скорость написания кода | Главный вопрос — что выпускать и что поддерживать |

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

> **К сведению.** Кейс Bun стоил около $165 000 в токенах и опирался на готовый эталон — исходную реализацию на Zig. Повторить такой масштаб без бюджета и надёжной системы проверки вряд ли получится, и Дикс сам признаёт, что его эксперименты упираются в недельный лимит.

## Источники

- pauldix.com: The end of programming — Paul Dix