Видение · эссе
Большой Вижен
В эпоху предыдущего технологического уклада весь смысл исходил от человека — и только от человека. Что неудивительно: люди были единственными разумными существами, если не считать обезьян и дельфинов. Люди были источниками намерений по изменению мира (в лучшую или худшую сторону), создавали источники универсальной истины (такие как священные тексты или планы на следующий год) и в конечном счёте несли персональную ответственность за свои поступки.
Новые разумные существа
В новом технологическом укладе всё меняется: кроме нас, на Земле зарождается новый тип разумных существ — то, что мы сейчас называем искусственным интеллектом. ИИ не обладает недостатками, свойственными людям (типа необходимости в сне или ограниченности памяти), и может в конечном итоге полностью и в лучшую сторону преобразить если не всю жизнь на Земле, то по крайней мере ландшафт современной экономики.
К сожалению, у искусственного интеллекта есть ряд очевидных технических проблем — вроде трудностей с пониманием Реального Мира (это решает embodied AI), неумения нормально отделять важное от неважного и строить долговременные планы. VibeVM частично отвечает на вопрос важного и неважного, а агенты долгосрочного планирования (long-horizon agents), такие как Zap, позволяют запускать процессы длиной в дни, недели, месяцы или даже годы.
Второй источник намерения
Всем понятно, что разработка с помощью AI очень дорогая. Одна 200-баксовая подписка на Claude и Codex может улететь за считаные часы.
Есть много гипотез, что именно мы можем оптимизировать. В рамках AI-Native языков интересно следующее. Наибольшая разница тут в том, что источником намерения в новом технологическом укладе становится не только человек, но ещё и ИИ. ИИ обладает собственным взглядом на мир, собственным способом восприятия, своим способом мышления. Этот способ мышления лишь отдалённо напоминает то, как мыслят люди.
Это значит, что, делая процесс разработки более удобным не для понимания людьми, а для понимания машинами, мы можем достичь более быстрого, качественного и дешёвого результата. Люди тоже могут присоединиться — после изобретения устройств прямого подключения человек-машина. Например, очень много надежд возлагается на Neuralink.
Spec-Driven Development
Общий подход, позволяющий хранить хорошо структурированный, динамический контекст и наблюдать его эволюцию во времени, называется Spec-Driven Development. С ним много проблем.
Во-первых, вопреки всевозможным ожиданиям, SDD во всей красе показывает «нечеловечность» разработки с помощью AI. Объём спецификаций быстро переходит все разумные пределы и становится совершенно умонепостигаемым. Спецификации начинают состоять из странных слов и терминов, которые хорошо понятны ИИ, но для человека требуют долгих и сложных переводов. К счастью, такой перевод вполне возможен, хоть и неудобен.
Во-вторых — и это уже серьёзно — «настоящий» Spec-Driven Development, когда на каждое изменение весь код перегенерируется из спецификации, — недостижимая мечта: ни у кого нет столько денег. Для достижения абсолютного SDD нам пришлось бы воткнуть вилку нашего дата-центра напрямую в Солнце или в какую-то ещё звезду. Возможно, не в одну!
Спецификация и код
Наша дисциплина кодирования устроена достаточно необычно. Мы пишем код так, чтобы он в первую очередь был понятен машинам. Теряем ли мы что-то? И да и нет. Люди всё равно не хотят писать код, да и спецификации писать они тоже не хотят.
По-хорошему, все эти артефакты должны генерироваться автоматически, но так, чтобы как можно меньше ресурсов тратилось на генерацию с помощью LLM (напоминаю: генерация с помощью LLM — это очень дорого). Человек становится частью системы, его ценность — приносить новые смыслы и свои желания, но точно не писать и не читать миллионы строк спецификаций.
Наш стиль кодирования чем-то напоминает классическое разделение между интерфейсами и классами в Java или заголовочными файлами и файлами исходников в C++. Существует дихотомия между LLM-спецификацией и алгоритмической реализацией в коде.
Спецификация задаёт контракт. Код — его техническая реализация, наполненная множеством мелких подробностей.
Спецификация
- задаёт контракт
- проверяется и исполняется только с помощью LLM
- результат анализа — сэмплирование: размытое и неустойчивое
- очень дорогая
Код
- техническая реализация контракта
- проверяется чёткими и дешёвыми командами
- эффективно использует имеющиеся аппаратные ресурсы
- дёшев
Да, ты можешь описать все детали низкоуровневой реализации прямо в спецификации. Но быстро оказывается, что для деталей низкоуровневой реализации нет контракта лучше, чем сам код. Да, тот старый добрый код, к которому мы привыкли до изобретения AI. Например, лучший способ высокоуровнево описать работу процессора — это ассемблер. Сколько бы ты на английском языке ни описывал алгоритм на архитектуре x86_64 или Arm64, у тебя неизменно будет получаться более убогий аналог процессора.
При этом спецификация очень дорогая: проверять и исполнять её можно только с помощью LLM, результаты анализа будут сэмплированием — размытым и неустойчивым. Напротив, код можно проверять с помощью чётких и дешёвых команд, максимально эффективно использующих имеющиеся на данный момент аппаратные ресурсы.
Самое важное правило
Поэтому самое важное правило:
Всё, что можно сделать без LLM, должно быть сделано без LLM.
Без генерации — и уж тем более без перегенерации. Мы касаемся LLM, только когда переходим на территорию высокоуровневых смыслов, требующих написания абстрактной части в виде спецификации.
Трассируемые рёбра
Все AI-Native языки в VibeVM связаны трассируемыми и проверяемыми рёбрами. Для каждого куска кода мы можем сказать, какое требование или принцип этот кусок кода выполняет. Либо — что у этого куска кода нет никакой связанной спецификации, и в этом случае есть множество вариантов: либо код сам по себе и есть спецификация (нечто низкоуровневое), либо мы программируем в режиме прототипирования и пока не генерализовали требования, либо это кусок старого легаси-кода, либо — и это происходит чаще всего — это просто ошибка, которую нужно устранить. Мы можем построить графы связей и эволюции этих связей и делать на их основании всевозможные предположения.
Это позволяет брать на себя задачи, которые были непредставимы в недавнем прошлом, делать их в кратчайшее время — и прямо сейчас это не требует высасывать энергию звёзд и путешествовать в параллельные квантовые миры.
Один паттерн стоит отметить отдельно: это наследование спецификаций в том же стиле, в каком десятилетиями писали люди на объектно-ориентированных языках.
Возможно, это первый в истории случай, когда все сказки про ООП могут внезапно оказаться суровой реальностью.
Основа для сотрудничества
Более того, вся эта информация не просто вычислима внутри VibeVM, но и доступна любым long-horizon agents и другим инструментам. В качестве примера такого инструмента в дистрибутиве VibeVM идёт Zap, но вы легко можете написать свои инструменты. Очень хотелось бы, чтобы вы это сделали. VibeVM — это основа для сотрудничества разработчиков нового технологического уклада, а не повод для очередной ненужной конкуренции.
Стартовая точка
В идеальном мире, в котором мы все становимся киборгами, аугментированными с помощью мощных AI-инструментов, VibeVM — низкоуровневая система: её воспринимают примерно так, как сегодня воспринимают ассемблер. Это наша стартовая точка в новый мир, где всё будет совсем по-другому. В мир, где мы живём намного лучше, красивей и счастливей, чем сейчас.