На прошлой неделе вышел Bun 1.4. В этом релизе Bun переписан с Zig на Rust: более миллиона новых строк кода. Смена языка вызвала волну обсуждений в сообществе, но главное здесь другое: как именно выполнялась миграция и какого масштаба она достигла. Детали этой истории, мой собственный опыт и уже близкие достижения ИИ убеждают меня: мы пришли к концу программирования в привычном смысле.
Речь о том, что ручное написание кода с его последующей человеческой ревью как способ создания работающего программного обеспечения движется к исчезновению. Точнее, этот подход утонет в лавине работающего ПО, которое будут создавать агенты, а люди будут проверять лишь конечный результат, а не сам код. Программного обеспечения станет больше, чем когда-либо, но большую часть кода не напишет и не прочитает ни один человек.
Да, вместе с ним появится гора мусора: глючного, бесполезного, ужасного программного обеспечения, которое не соответствует ни одному программистскому стандарту качества и стиля. Но будут и хорошо спроектированные, работающие программы, решающие реальные задачи, хотя ни один человек не изучил их код в деталях.
Этот взрывной рост производства ПО уже виден на графике из поста GitHub об инциденте 17 августа:
С прошлого года объём производимого кода растёт по экспоненте. Моя гипотеза: большая его часть приходит из сайд-проектов или внутрикорпоративных инициатив, которые считаются некритическими. В большинстве компаний существует организационное трение, которое мешает отдельным разработчикам выпускать в два раза больше на продуктах, критически важных для бизнеса, не говоря уже о десятикратном или стократном росте.
Почти весь код на этих графиках создан моделями, которые уже не являются самыми передовыми. Это фронтирные модели месячной давности: не Fable 5 и не GPT 5.6 Sol.
Если статья понравится — приглашаю в канал AI for Devs. Каждый день публикую похожие материалы: модели, агенты, практические кейсы и новости из мира AI.
Разработчики Anthropic и OpenAI живут в ближайшем будущем
Если почитать подробности о миграции Bun на Rust, главное выглядит так: всё это сделал один разработчик, Джаррэд Самнер, работавший с пре-релизной версией Fable 5 и практически неограниченным бюджетом на токены. Он создал рабочий каркас и инфраструктуру, в которой агенты параллельно переводили кодовую базу с Zig на Rust.
За 11 дней несколько агентов сделали 6 778 коммитов и сожгли столько токенов, что по стандартным ценам API это обошлось бы примерно в 165 000 долларов.
Я помню, как драма вокруг этой переписки началась ещё в начале мая, задолго до публикации того поста в блоге. Факт миграции раскрылся только через мерж с изменениями. Меня поразил масштаб, и я строил теории о том, что это сделано с неограниченными токенами Mythos:
Я очень хочу знать, сделано ли это с неограниченными токенами Mythos. Это ближайшее будущее для остальных? Или настоящее, и они использовали токены Opus 4.7? Моё предположение: первое. Значит, это предпросмотр того, что станет возможным позже в этом году.
Тогда я был уверен, что с Opus 4.7 такая миграция невозможна, а значит, её обеспечил ещё не выпущенный Mythos.
ИИ написал миллион строк кода, затем несколько месяцев доводил его до ума, и в итоге получился надёжный инструмент, работающий на миллионах машин разработчиков. Можно сказать: "Не так уж впечатляет, ведь был оракул для сравнения, переход с одного языка на другой был простым". Но это недооценка произошедшего. Если выстроить систему верификации и задать правильное направление, ИИ способен создать сложный, высококлассный программный продукт и продолжать его улучшать до тех пор, пока всё не заработает.
Если следить за тем, что разработчики Anthropic и OpenAI пишут в X последние несколько месяцев, картина такая: каждый из них выпускает десятки или сотни PR в неделю и сосредоточился на задачах более высокого уровня. Невозможно детально ревьюить сотни PR в неделю и параллельно делать собственную работу — отсюда и смещение фокуса.
Если верить тому, что они говорят публично, они уже не проводят детальную проверку каждой строки кода. Они строят системы, пишут промпты и верификационный инструментарий, чтобы ИИ создавал их программное обеспечение в масштабе и с высокой скоростью. По крайней мере, так я интерпретирую их разговоры о "loops".
Но они работают в мире, где у них неограниченный доступ к Fable и Astra (следующая модель OpenAI). Они живут в ближайшем будущем, которое остальные из нас, вероятно, увидят примерно через год. Их опыт использования ИИ для разработки ПО разительно отличается от опыта всех остальных, кто ждёт еженедельного обновления лимита на Fable.
Релиз Bun 1.4 даёт ясное представление о том, что возможно, когда интеллект уровня Fable сочетается с практически неограниченными токенами: поставка ПО в масштабе, которое работает, как доказывают миллионы работающих деплоев.
Мой личный опыт
Два свежих примера из моей практики. На уровне ощущений Fable качественно отличается от предыдущих моделей примерно так же, как люди замечали разницу с Opus 4.5, вышедшим в конце прошлого ноября. Пройдена некая граница: можно добиться большего с высокоуровневыми указаниями и меньшим надзором. Я задаю требования, архитектуру и инструкции для функции, которую хочу разработать, и модель создаёт полностью работающую первую версию за несколько рабочих часов без дальнейшего участия с моей стороны.
Оба примера касаются вещей, которые пока не выпущены в InfluxDB, но реализованы в виде новых возможностей в форке. Я выбрал их, чтобы проверить возможности новой модели.
Первый пример: интеграция с Iceberg, благодаря которой данные в InfluxDB становятся доступны через Iceberg REST или через внешний S3-бакет и каталог Glue. Это сложная функция:
API и CLI для включения функции
Реализация Iceberg REST API
Глубокая интеграция с компактором для создания Iceberg-манифестов и данных Parquet во внешнем хранилище
Создание Iceberg-манифестов или запросов к Glue
S3 API, реализованный в InfluxDB для сценариев, не связанных с экспортом
Тысячи строк реализации и тестового кода. Я набросал примерную архитектуру и требования, затем дал указание Fable выполнить работу через субагентов, запуская код-ревью и контролируя процесс. Через 14 часов получилась работающая версия. Затем я дал команду проверить всё сквозным тестом с запущенным кластером InfluxDB и DuckDB с PyIceberg в качестве внешних клиентов. Модель исправила несколько багов и подтвердила корректность работы.
Второй пример: система репликации данных с граничных узлов для InfluxDB. Несколько отдельных нод InfluxDB работают как спутники и периодически реплицируют сжатые данные в центральный кластер InfluxDB. Система включает:
API для настройки того, что реплицируется и с какой периодичностью
CLI для доступа к нему
Обновления компактора для фильтрации, агрегации и создания сжатых данных для репликации, а также отслеживания того, что уже отправлено и что ещё нет
API для доступа граничного узла к каталожной информации, используемой в нагрузке репликации
API для получения сжатых блоков данных в конвейер
Метрики и системные таблицы для полной наблюдаемости всей установки
Я описал архитектуру и привёл примеры того, как должен выглядеть пользовательский опыт. Совместно с Fable мы разработали дизайн, после чего я дал указание приступить к реализации, выступая в роли супервайзера. Через 28 часов получилась реализация с работающей основной функциональностью.
Затем я дал команду развернуть её в тестовой инфраструктуре AWS, наблюдать за метриками и логами и исправлять баги по ходу. После нескольких коротких итераций появилась сквозная работающая реализация, которая продолжает работать несколько месяцев спустя. Позже я даже попросил модель создать UI, отображающий репликацию между нодами с показателями скорости передачи данных — почему бы и нет.
Конечно, ни один из этих проектов пока не выпущен, не поддерживается и не является production-ready в полном смысле слова. Можно сказать то, что обычно говорят об ИИ: он помогает быстрее сделать прототип. Но это недооценивает происходящее.
Прототип, это работающее программное обеспечение. А его улучшение и тестирование обеспечиваются дальнейшими петлями улучшения с ИИ. Продукт становится лучше не через человеческий код-ревью, а через использование и тестирование.
Оба проекта я сделал в рамках еженедельного лимита Fable и моей подписки (между ними пришлось подождать неделю). Чего я не смог сделать, так это запустить это в облаке, в бесконечной петле улучшения с неограниченными кредитами Fable. Мы не можем себе позволить сотни тысяч долларов ежемесячных расходов, которые я, скорее всего, накопил бы, отправив топового фронтирного агента работать на меня 24/7.
Джаррэд завершил миграцию на Rust за 11 дней, но затем агенты ещё несколько месяцев занимались непрерывным улучшением, прежде чем вышел официальный поддерживаемый релиз. Прототип, это начало, но агент поможет вам выпустить и итерированный, улучшенный, закалённый production-ready продукт.
Ближайшее будущее для нас, обычных программистов
Год назад у нас были Opus 4.1 и GPT-5. Теперь лучший интеллект можно купить за долю прежней цены. В конце ноября и начале декабря прошлого года вышли Opus 4.5 и GPT 5.2, именно эти две модели заставили каждого CTO переосмыслить зимние каникулы и осознать, что функции и программное обеспечение теперь можно создавать по запросу.
Я ожидаю ещё один-два крупных релиза от OpenAI и Anthropic в этом году. Мой прогноз: в сентябре выйдет Astra от OpenAI, она будет уровня Mythos/Fable и, вероятно, превзойдёт Fable 5 по возможностям.
Аналоги Fable и Astra, сопоставимые по пересечению порога с Opus 4.5 и GPT 5.2, я ожидаю либо к концу этого года, либо в начале следующего.
Такой уровень модельного интеллекта и возможностей позволит создавать любые функции для программного обеспечения. Оно будет работать. Система сможет тестировать и верифицировать за вас. Производство пойдёт настолько быстро, насколько вы готовы принимать код. Единственный вопрос: что именно вы хотите выпустить и что готовы поддерживать.
К концу следующего года такой интеллект будет достаточно дешёвым, чтобы большинство из нас работало с ним полный рабочий день, как Джаррэд работал с пре-релизным Fable при создании Bun 1.4.
Ещё через год-два появится широкий доступ к системам, способным генерировать токены в 10-100 раз быстрее за долю нынешней стоимости. Смотрите анонс Cerebras C4 и результаты OpenAI Jalapeño. Широкий, дешёвый доступ к фронтирному интеллекту с невероятной скоростью уже на пути.
Организационная инерция, скорее всего, означает ещё десятилетие ручного написания кода и детального ревью со стороны коллег. Многие, если не большинство компаний продолжат разрабатывать ПО по-прежнему.
Но самые продуктивные создатели программного обеспечения будут делать это без традиционного программирования. Они будут управлять ИИ, создавать каркасы, программные фабрики, системы QA и верификации, которые выпускают работающее программное обеспечение быстрее, чем мы когда-либо видели.
И мы придём к тому, что работающего, production-ready программного обеспечения, написанного ИИ, станет больше, чем написанного людьми. Конец программирования наступит.
Русскоязычное сообщество про AI в разработке
Друзья! Эту статью подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-агентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!
Комментарии (49)
debagger
28.08.2026 09:47Переписать хорошо покрытый тестами проект на другой язык, это идеальная задача для ИИ. Ноль неопределенности, понятный достижимый результат.
tuxi
28.08.2026 09:47Намек, что еще раз переписать уже будет не совсем реально с точки зрения надежности?
debagger
28.08.2026 09:47Не, это намек на то, что такое переписывание это вообще не о "конце программирования"
tuxi
28.08.2026 09:47Ну формально, экономически выигрывать начнут самые быстрые по времени создания реализации. Далее остается только вопрос - насколько бизнес (если говорим про гражданские бизнес приложения) готов мириться с артефактами "переписывания".
Мне видится, что каждый новый релиз/версию будет проще всего делать "с нуля", главное спецификацию и требования держать в должном виде.
С такой точки зрения, у классического программирования шансов и правда не так много. И скорей всего вырастет роль аналитиков/архитекторов.
Nihiroz
28.08.2026 09:47Аналитики/архитекторы будут обновлять документацию, написанную на специальном формализованном языке, не допускающем разночтений. А специализированная детерминированная llm с нулевой температурой каждый раз будет заново генерировать новую реализацию
tuxi
28.08.2026 09:47Ну как то так, да. Остается открытым вопрос о чувствительных сферах: типа авиастроение, космос, оборонка. Но кмк, это крохи по сравнению с "перекладыванием json-ов"
alan008
28.08.2026 09:47Так обсуждалось же уже в соседних статьях, что спецификация всегда менее детализирована, чем реализация на конкретном ЯП. И из-за этого несоответствия на языке можно много где реализовать спецификацию не так как надо. Cамое "точное" поведение описывается только кодом.
Yuriy_75
28.08.2026 09:47Кодирование будет проходить мгновенно и недорого, если вложить в разы больше человеко-часов в подготовку документации.
При том что многие из работающих сейчас аналитиков не факт что вообще смогут выдать доки приемлемого для генерации уровня, таких аналитиков нужно будет заменять более квалифицированными.
И что такое "специальный формализированный язык"? Какие-то спецификации уже есть? (Просьба не шутить про то, что таким языком является язык программирования, эта шутка слишком очевидна).tuxi
28.08.2026 09:47Ну был когда-то Rational Rose, но не взлетел. Но по сути это были первые попытки довести формализацию требований до ситуации "нажал потом кнопочку и основной код (каркас классов) сгенерился сам"
ksbes
28.08.2026 09:47Если что - почти весь кровывый Ынтерпраз 00х и 10х именно так и сделан, обычно. Где-то (часто в БД) задаётся “конфигурация” (на страшно коммерчески-тайном языке-“велосипеде”, если в БД, то схема этой БД - часть этого языка) и по нажатию кнопки кодогененрируется весь копроативный жутко правильный Ынтерпразный сайт (иногда - через неделю компиляций).
alhimik45
28.08.2026 09:47детерминированная llm с нулевой температурой
Назовём её general cold copilot, сокращённо gcc…
wert_lex
28.08.2026 09:47Пока из известных человечеству языков, который достаточно формализован, и не так чтобы прям сильно допускает разночтения, я знаю только один - математика.
Ну и не надо объяснять что за пределами
CRUDшкольной математики - это становится прям сильно развлечением не для всех.
akabrr
28.08.2026 09:47Аналитики/архитекторы будут обновлять документацию, написанную на специальном формализованном языке, не допускающем разночтений.
не на таких ли языках сейчас разработка ведётся?
cher11
28.08.2026 09:47Да, задача не самая сложная. Тут более интересна смена парадигмы - что можно, что нельзя. Раньше было нельзя сменить язык большого проекта, потому что это выливалось в кучу человеко-часов, которые люди не были готовы тратить. А сейчас потратит нейронка. Тоже самое с рефакторингом, тестами, какими-то фичами, которые постоянно откладывались на потом, потому что некогда. А сейчас закинул агенту, пару раз проверил - вот, пожалуйста, готово. Локализация еще очень хороший пример, добавление новых языков (с вполне себе хорошим качеством) таким простым не было никогда
randomsimplenumber
28.08.2026 09:47А зачем переписывать? Компилятору все равно на каком оно языке.
petsernik
28.08.2026 09:47Чтобы удобнее было прикрутить фичу засчёт того, что в другом языке она проще и приятнее выглядит и пишется
Nihiroz
28.08.2026 09:47Каждый раз, читая подобные статьи, думаю: “Ну вот, очередной человек навайбкодил что-то неподдерживаемое, ничего нового”. Но, вместе с тем, всё равно остаётся подозрение, что замедляющееся развитие llm, может, переступит какой то порог и количество таки перейдёт в качество, а я, в своём луддизме, этого не замечу
Dhwtj
28.08.2026 09:47Доказать что решение плохое иногда труднее, чем написать его полностью. Потому что для этого решение нужно понять.
Такой вот теперь расклад.
Хотя качество не всем нужно... Кому и кобыла невеста©
Скрытый текст
удивлён, как такую зоофилию пропустили на широкие экраны СССР
KoIIIeY
28.08.2026 09:47А где у вас там плохо?
Норм они кодят, при чем уже даже с запросом "сделай нормально"
artptr86
28.08.2026 09:47Хотя качество не всем нужно...
Бизнесу же всегда хотелось не идеального качества ПО, а возможности сделать его побыстрее и подешевле. А теперь цены на LLM для бизнеса почти сравнялись с ценами на программистов.
MEGA_Nexus
28.08.2026 09:47может, переступит какой то порог и количество таки перейдёт в качество
Это уже произошло. Изначально LLM улучшались за счёт увеличения данных для их обучения, т.е. чем больше качественных статей скормил LLM при обучении, чем качественнее ответ от неё можно получить. Потом, когда LLM скормили все доступные книги, форумы и сайты, начался плач, что данных для обучения больше нет, а значит LLM достигли своего пика и никаких качественных изменений ждать не стоит. Синтетические данные ситуацию совсем не спасли.
В этот момент произошёл переход от количества к качеству. Разработчики LLM начали внедрять: SFT (Supervised Fine-Tuning), RLHF (Reinforcement Learning from Human Feedback), DPO (Direct Preference Optimization) / PPO, RL (Reinforcement Learning), MoE — Mixture of Experts и т.д. Иными словами внедряли технологии, чтобы повысит качество своих LLM.
Так что постепенно качество LLM будет улучшаться и перелом случится тогда, когда ИИ агенты с использованием LLM начнут писать код на уровне middle разработчика. Сейчас это лишь уровень продвинутого junior'а. Но даже сейчас проблемы продвинутого junior'а обходятся внедрением дополнительных проверок и ревью со стороны других ИИ агентов, а также дополнительными тестами, которые тоже пишут ИИ.
FlyingDutchman2
28.08.2026 09:47О конце программирования я слышал еще в 1993 году от одного программиста в Харькове. Подробности Здесь
alef13
28.08.2026 09:47Люди придумали и разработали языки программирования и компиляторы(интерпретаторы) для того, чтобы было проще и быстрее преобразовывать свои мысли в машинный код. С ростом объёмов, сложностью и угроз в части безопасности и надёжности со временем выработаны принципы "гигиены" процессов разработки - один из них это ревью кода. Т.к. переход к вайбкодингу из-за скорости и объёмов появления кода фактически исключает человека из этих процессов, то и смысла в них, а также в изначальных инструментах, ориентированных на человека, нет. Я имею в виду, что для ИИ нет смысла в "промежуточных" стадиях написания программ на языке программирования - разбираться, корректировать этот код никто не будет. Ревью тем более. Пусть генерирует сразу в двоичном коде.
asdadn
28.08.2026 09:47Если честно, то достали уже эти фантазии про LLM и машинные коды. Даже базовых знаний об LLM должно быть достаточно, чтобы понять, что это плохая идея. Во-первых машинный код очень беден на семантику. Это создаёт проблемы с обучением(конкретно взятый токен или набор токенов может означать на порядки больше разных вещей, нежели в человекчитаемых языках). Во-вторых средний размер токена будет что-то около двух символов. В-третьих, я не думаю что нейронка очень стабильно будет управляться с арифметикой указателей, например. Если подумать больше минуты, то становится понятно насколько это чушь.
ksbes
28.08.2026 09:47Во-первых машинный код очень беден на семантику.
Это наоборот - хорошо. Пространство эмбедингов мизерное. Можно на выходных слоях сэкономить.
конкретно взятый токен или набор токенов может означать на порядки больше разных вещей, нежели в человекчитаемых языках
Что за бред вы несёте? Машинный код несёт один единственный смысл и только его. Весь смысл машинного кода в этом. Даже если вы ассемблер с машинными кодами путаете (это простительно неспециалисту) - многозначных команд в ассемблере почти нет. О чём вы?
Во-вторых средний размер токена будет что-то около двух символов.
Во первых, в чём проблема? Во-второых в мпрограмме на машинных кодах очень много “стандартных” многокомандных последовательностей (типа, сложение двух регистров - условный переход-сохранение стэка-долгий прыжок), которые скорее всего попадут в один токен “вызов функции по условию”
В-третьих, я не думаю что нейронка очень стабильно будет управляться с арифметикой указателей, например.
Странно. В сях сях-два-креста справляется а в машинных кодах нет? Нет что-то бесплатное чалоподобное - наверняка запутается, а вот всякие соташные “фейблы” вполне себе и могут.
Так что вопрос там именно в контроле поведения бинарников (коде-ревью не сделаешь), чем в том что агенты не справятся.
Bindus
28.08.2026 09:47а реально есть такие программисты, кто уверен что НЕ останется без работы через 3-5 лет? соболезную)
ksbes
28.08.2026 09:47Да. И много их. Не магазинчиками едиными. Кому-то ещё по микросекундам шпиндели вращать. И миллионами сантикопеек на КОБОЛе ворочить.
press_a_key
28.08.2026 09:47Конечно! На моем опыте даже при миграции вроде как покрытых тестами биллингов с php на go и perl на python, даже руками программистов, вылезала куча проблем. Потому что покрывать код все нормальными тестами тестирующими все возможные кейсы бизнес логики - не рентабельно в подавляющем большинстве случаев. В случае с LLM проблема будет ровно та же, причем в обычном перекладывании джейсонов. Потому что довести проект до уровня когда по спекам нейронка все сгенерит стоит дороже самого проекта.
aleksey314
28.08.2026 09:47Короче. Автору заплатили 30 серебряннмков за очередную рекламу нейросети. Нейросети нужно отдавать не более 10-25% от общего объёма работы. Потому что даже так она способна на ломать огромное количество дров.
Rive
28.08.2026 09:47Нейросети нужно отдавать не более 10-25% от общего объёма работы. Потому что
... иначе уволят её оператора.
S1908
28.08.2026 09:47А кто щас управляет вашими так называемыми нейросетями способными заменить человека? Человек программист и управляет. До этого он управлял кодом сейчас ии что поменялось? Думаете по другому тогда вы впадаете в иллюзию. Трудная проблема так и не решена а любые попытки повторить человека встретят комбинаторный взрыв.
Ну для планктонов конечно рисуются красивые сказки и длинная лапша. Но текущее состояние таково. Мы ни на шаг не приблизились к решению трудной проблемы, но закопались в ллм.
agray
28.08.2026 09:47ПРОГРАММИРОВАНИЕ ТОЧНО ВСЁ
@
AI СОЗДАЁТ ЧТО УГОДНО ПРЯМО СЕЙЧАС
@
МИЛЛИОНЫ БИЗНЕСОВ БЕЗ ЗНАНИЙ
@
ИЗИ МАНИ ПРЯМО СЕЙЧАС
@
К-к-купите наши курсы пожалуйста...
sashape89
28.08.2026 09:47А вы попросите написать тот же bun только с чистого листа. Вот тут и начнутся проблемы.
Dhwtj
Lift and shift при смене близких языков это успех. Но история багов uutils говорит другое: надо таки и предметную область знать лет 20, как её знали создатели GNU Coreutils