Comments 57
Spec-driven-development?
Вот мы и увидели декларативный вайб-кодинг. Он конечно тоже немного недетерминирован как и императивный, но кому это интересно.
Вроде умные мысли говорит, но при этом пытается сделать из промпта полноценную замену. Я говорю "промпт", потому что вижу, что этот язык не является полной и исчерпывающей спецификацией, то есть позволяет множественную трактовку, равно как естественный язык. А если является, то как его синтаксис может быть в 5-10 раз короче?
Я не понимаю, как он собирается решать две основные проблемы.
Первая и самая главная: недетерменированость. Из одного и того же "исходника" получаются разные кодовые базы классического языка. Это делает невозможным итеративные улучшения, это делает невозможным багфикс (ну просто потому что сегодня баг есть, завтра нет и наоборот, и всё это с одним и тем же "исходником").
Вторая проблема: контекстное окно. Если раньше, когда вдруг оказывалось, что 640кб не хватает всем для компиляции, то покупалась плашка памяти за $100 и приводились исходники в порядок. Бедные страдали со свопом, но компилировали. А для увеличения контекстного окна вдвое надо построить новый дата-центр, потому что зависимость ну ни разу не линейная. А контекстное окно нужно обязательно, потому что проект планируется перегенерировать полностью и если ваш исправленный промпт не лезет в окно, то в окно пойдёте вы.
Один и тот же алгоритм можно и написать на разных языках программирования, а ещё применить разные специфические трюки для каждого языка, плюс учесть версии системных библиотеки, учесть особенности данных для этого алгоритма, например для строк или чисел и т. д.
Огромное число дополнительных параметров, которые в самом алгоритме не заложены, приводят к разному кожу. Поэтому и не удивительно что одна и та же спецификация может порождать разный код.
Да просто при смене версии языка или системных, или других библиотек, реализации одной и той же спецификации может поменяться с учётом внешних параметров, которые описаны в более общих спецификациях.
То что их одной спецификации можно получит разные реалии при изменении внешних параметров, наоборот является огромным преимуществом. Это позволит гораздо быстрее изменять большие кодовые базы, а не поддерживать старый код, который просто не кому сейчас переписать.
Сегодня код работает за константное время, завтра за квадратичное. Сегодня без side эффектов, завтра с промежуточными файлами. Сегодня интерфейс выглядит консистентентно, завтра на каждом экране свои формы.
Не будет такого при наличии хороших спецификаций. С ии агентами сейчас как раз чаще происходит когда вы начинаете новую сессию и вы ней не указали то что было в старой существенное и следовательно он не знает то, что знал в старой сессии. Спецификации как раз помогут и вам и ИИ агентам не терять важные детали. Они и нужны для того чтобы сгенерированный код оставался стабильным при этом его будет легче изменять при внешних изменениях. Например, вы изменили версию какой то использованной библиотеки и код будет переписан с учётом новых улучшений.
ИИ агенты не переписывают код если вы указываете одни и те же достаточно подробные спецификации. Обычно они такое начинают творить если вы открыли новую сессию и забыли туда перенести существенные детели из старой. А спецификации помогают не терять эти детали.
Например, такие важные места уточняютса хоть до уровня регистров, если сильно важны. Допустим, будет добавлен тэст, што при нажатии кнопок на такой-то странице, время реакцыи интрфэйса не должно превышать какое-то время.
Обычно проблема в том что на разные входные данные могут получаться разные результаты, зависеть от стейта внутри, от времени или значений случайных чисел, если такие используются. И всё это время шла борьба с этим. Оттуда появились виртуальные машины, докеры, кросс-платформенность и прочее.
Вы предлагаете всё выкинуть и сказать мол и так сойдет, зато ИИ пишет код. Если это какой-нибудь развлекательный сайт это ладно, если игра - это даже забавно, уникальное прохождение. Но я уверен что вы не захотите получить списание с вашего банковского счета только потому что сегодняшняя модель не так поняла назначение вашего платежа, или лежа под аппаратом коррекции зрения случайно получить прожженную дыру в сетчатке, потому что сегодня другие входные данные.
вы не захотите получить списание с вашего банковского счета только потому что сегодняшняя модель не так поняла назначение вашего платежа, или лежа под аппаратом коррекции зрения случайно получить прожженную дыру в сетчатке
От этово вы не застрахованы и сейчас. Такие важные програмы, очевидно, будут долго тэстироватса.
Считаю что спецификации которые тут предлагают, это достаточно строгий промпт, который будет создавать надёжные тесты и реализации.
Огромное множество проблем вайб разработки, достаточно строгие спецификации могут решить.
Множество раздельных спецификаций, которые являются частью проекта, сильно уменьшают требования к размеру контекстного окна. ИИ агентам для разработки локальной части не нужно знать все спецификации, только для этой части , плюс общий спецификации, плюс спецификации апи с которым идёт взаимодействие.
Выход - компонентный подход к проектированию. Чтобы агент работал только с одним компонентом, зная спецификацию его интерфейсов.
Детерминированность это очень неудобное слово для современных ИТ дискуссий, да и некогда про это, нужно агентов внедрять, так 'visibility' проще пропехнуть.
Это делает невозможным итеративные улучшения
Почему же? Итеративно добавляютса-удаляютса фичи, нет проблемы.
это делает невозможным багфикс (ну просто потому что сегодня баг есть, завтра нет и наоборот, и всё это с одним и тем же "исходником").
Выявляетса баг - добавляетса спецыфикацыя. Изначально там внутри, в коде, может быть куча проверок на всё, штобы програма не ломалась, а просто останавливалась и спрашывала што делать, раз тут выявился непродуманный момент. Например, банально неожыданные входные данные. И может даже прям там же после ответа инженера код дополнится и програма продолжит выполнятса с этово же места, не перезапуская всё заново.
Вторая проблема: контекстное окно.
Написано, што части спецыфикацыи независимы, т.е. незачем пихать вообще все спецыфикацыи.
Главная ценность такого подхода заключается в жесткой изоляции. Так как спецификация предельно четкая и имеет строгие контракты ввода-вывода, ИИ-агенту не нужно выдумывать, что именно реализовать, или галлюцинировать дополнительный функционал. Нейросеть ограничена рамками Markdown-файла. Если спустя время разработчику понадобится добавить извлечение даты получения письма, он просто допишет одну строку в раздел «Output Structure» в
.cs.mdфайле. После команды сборки CodeSpeak обновит исключительноeml_converter.pyи его тесты, совершенно не затрагивая остальную кодовую базу проекта.
Так и как это реализовано? За счёт чего удается избежать галлюцинаций (тем более, что исследователи OpenAI уже доказали, что это невозможно) и написания лишнего функционала?
избежать галлюцинаций (тем более, что исследователи OpenAI уже доказали, что это невозможно)
Но можно при желании полностью отключить нейроны, рождающие галлюцинации - https://github.com/thunlp/H-Neurons
Береслав предлагает обязательно генерировать тесты и генерировать код до тех пор пока он не будет соответствовать спецификации и проходить все тесты. Ошибки конечно будут проскакивать, но скорость итераций, и общая управляемость кода обеспечит их меньшее количество по сравнению с человеком. Я думаю если каким либо образом внедрить шаблоны кода и типовые решения которые будут использоваться при использовании связанных с ними типовых фраз и выражений в спецификации, то это ещё уменьшит количество багов и увеличит детерминированность кода.
Какая интересная идея - для борьбы с нейрослопом генерировать тесты, которые будут нейрослоп отсекать. Но как бороться с нейрослопом в тестах? Тесты на тесты?
Платформа CodeSpeak меняет этот парадокс, фиксируя диалог с ИИ в виде статических файлов спецификаций. Спецификация становится главным артефактом, подлежащим контролю версий и код-ревью. Команда обсуждает и утверждает смысловую часть алгоритма, оставляя валидацию синтаксиса на откуп автоматизированным тестам.
А чем это отличается от обычной спецификаций в .md для языковых моделей?
Чем это отличается... наглой наивностью, что придумал что-то радикально новое.
Иногда достаточно формализировать и автоматизировать то что используется продвинутыми разработчиками при работе с ИИ агентами.
Работать с формальными спецификациями, которые не теряются между сессиями просто удобнее и надежнее.
А приживется или нет такой подход покажет время. Мне он показался достаточно интересным чтобы о нем рассказать.
Мне непонятно одно - как система контролирует, что тесты написаны правильно и действительно проверяют работу алгоритма? Что если все тесты PASSED, а ничего не работает? В этом состоит основная претензия к вайбкодерам (что потом надо будет ковыряться вручную и пытаться понять, почему не работает).
Вышло обсуждение языка CodeSpeak в подкасте Подлодка на русском языке с самим Андреем https://youtu.be/s5vqzH31tRE?si=fvuxqpIcpZl0MqYj
Любой ИИ - подражание разрабу, любая нейросетка - роботизированный вор (плагиатор). Любой алгоритм можно описать с помощью классов, тем не менее, все будет железозависимым и ламеро-определяемым. Тем не менее, это не приблизит нас к решению больгиествс проблем, не комьютеры юудут помогать людям, а люди будут обслуживать компы.
Гораздо более актуально создание семантической нотации для взаимодействия человека (предлагаю вернуться к иероглифике, скорость вывода зрительно повышается в десятки раз, а ввод может быть целебральным, смысло-симолами) и машины, или как более правильно - между людьми, ибо вычислит.техника - это лишь инструмент обмена инфой между человеческими особями в пространстве и времени (этап вслед за печатной книгой). Некое подобие Матрицы создаст Коллективное Сознание (ступень интернета), в соотв.фильме оно стало хранилищем цивилизации в разуме спящих тел, чтобы со временем пробудились не овощи. Не будет интерпретаций, за которыми маячат катастрофы, описаннные фантастами еще в 60-е, включая порабощение людей своим несовершенными созданиями, и в итоге к гибели всего вида.
А теперь давайте представим ситуацию. Спеку создали всё ок. Но llm сгенерила код с проблемой n+1. Через какое-то время заметили что всё тормозит. Код при этом мы писать уже не умеем и вообще плохо понимаем что там под капотом работает. Дальше что делать? Идея всё таки кажется утопичной в плане генерации по этой спеке кода.
Но в целом как инструмент спецификации может быть интересно. Идея ввести универсальный язык, и попросить llm следить чтобы спека была непротиворечива. Это прямо топ идея. Опять же просто просить проверять на соответствие спеку и код, может быть очень полезным. Поэтому думаю в целом может получится очень хороший инструмент
Дальше что делать?
Попросить LLM: "Что-то всё тормозит. Сделай, чтобы не тормозило". На будущее добавить, чтобы при разработке максимально оптимизировала код всеми известными человечеству способами оптимизации.
Такие задачи решаются без проблем. А вот что делать, когда LLM просто не может одолеть какой-то баг из-за недостатка контекста или просто в силу ограниченного интеллекта, пока не ясно. Обычно просто выходит новая версия Клода \ GPT \ Gemini и на какое-то время поднимает эту планку.
Ну я привел просто пример. Не все проблемы решаются общеизвестными практиками. Очень часто проблемы специфичные для твоего кейса и нужно подумать чтобы их решить. А не просто известное решение подставить. Собственно решение багов ту да же. И каким образом это можно только спекой решить мне не понятно. Нужен качественно иной ии, для таких задач. И скорее всего это не llm. Но вот проверить спеку на логичность, сделать процесс разработки проще вполне такой инструмент может. Идея в целом мне нравится.
Код при этом мы писать уже не умеем и вообще плохо понимаем что там под капотом работает. Дальше что делать?
В конце статьи:
Умение разобраться в том, как всё устроено «под капотом», вскоре станет редкой и крайне востребованной экспертизой на рынке, переполненном операторами нейросетей.
Т.е. отдаёте тому, кто знает, как там устроено всё внутри. Ну вот ему и ево команде, например.
Помню когда то мне предлагали возглавить альфатим в неткрекере. Команду которая будет тушить пожары за джунами студентами. Мне тогда уже эта идея не понравилась. Делать правки в сложном домене в котором не работаешь очень сложно и рискованно. За тобой уже никто не проревюит. Поэтому как мне кажется эта идея провальна. Разработка будет буксовать и останавливаться слишком часто. А выиграют в итоге те кто сохранит экспертизу в командах и не поддастся сиюминутному желанию срезать косты. Поэтому на мой взгляд пока не будет создан ии который думает примерно как человек, может в голове крутить абстракции, а не просто по предыдущему тексту выводить следующий, идея эта о обречена на провал.
А если всё сведётся лиш к производительности? Код от такой ИИ будет надёжен и делать то, што от нево просили, но внутри куча неэфективностей типа считание длины строки каждую итерацыю цикла.
И вот тут этим спецам, знающим все уровни вплоть до регистров, не надо будет разбиратса в самой програме. Им будет дана цель разобратса лиш в указанных местах, которые работают слишком медленно.
сложные проекты на Python
Авторы действительно уверены, что Питон - подходящий инструмент для создания сложных проектов?
Созданию языков спецификаций уже 50 лет: CASE, RAD, MDD, SoftwareFactory... Но если те подходы были детерминистскими, и сокращали затраты на тестирование, то использование БЯМ в качестве универсального генератора будет порождать разные результаты и требовать максимального покрытия тестами всех уровней.
https://habr.com/ru/articles/994838/
Полноценное внедрение инструмента позволяет сократить объем кодовой базы в проектах в пять-десять раз.
Как, а главное, зачем?
Я вот одного не понимаю, почему все так прутся со спецификаций в текстовом формате. Ведь уже на этом этапе могут быть косяки разбора нейронка информации. То, что вы в md поставили две решетки, типа как начало заголовка это же не означает, что нейронка 100% догадается что это именно заголовок, что он относится к какому-то абзацу, а дальше недо еще интерпретировать что делать с информацией из этого абзаца.
Если у на спецификация, то почему не какой-нить машиночитаемый формат, вроде yaml, и пусть в нем будут стандартные этапы, вроде: testing, styling, functional_requirements, etc.
Агент понимает на каком он этапе плана выполнения и тянет только релевантную информацию в контекст.
Спека в git, модель под ней обновляется. Один .cs.md файл на Opus 4.6 и на Opus 5 даст разный код. В roadmap написано "при удалении кода его можно восстановить из спецификации" - но из какой версии модели восстанавливать? Обычные компиляторы дают reproducible builds, тут каждое обновление модели потенциально меняет реализацию
Так ли это важно, если реализацыю меняет уже просто перекомпиляцыя на одной и той же модели?
система должна гарантировать, что при удалении кода его всегда можно в точности восстановить из спецификации
Тут не очень понятно, почему код может быть удалён - будто вырвано из контекста.
Это то, что хотят достичь создатели языка. Как они хотят это достичь пока непонятно.
Наверно, имеетса в виду, што текущая спецыфикацыя будет создавать тот же код. Но если начать новый проект, то по этой же спецыфикацыи будет уже чуть другой код?
Если не менять разработчика и попросить по спецификации написать код заново он напишет идентичный код? В чем тут вы видете проблему?
Главное чтобы ИИ агент тесты нормально написал заново.
В чем тут вы видете проблему?
В вопросительном знаке первово предложения. Он вообще сломал мне мозг - это я у вас спрашываю, а вы задаёте этот вопрос мне %)
Главная проблема вот:
при удалении кода
Вы только догадываетесь што это означает или же точно знаете? Почему код удаляетса? Можно было бы написать проще - "Одни и те же спецификации создают идентичный код", значит тут што-то другое. То ли если во время разработки удалили ненужную часть кода, +синхронизацыя там в предыдущем предложении.
Ответил как Сакрат, наводящими вопросами. Могу без вопросов.
При стирании старого кода и генерации нового кода он будет разным. Особенно если сменить модель ИИ агента и т.д.
Но важная логика не должна нарушаться и тесты должны проходиться и т.д.
Это то, что хотят достичь создатели языка. Как они хотят это достичь пока непонятно.
Вы пишете ТЗ на разработку одной библиотеки двум разным программистам. Они решают по разному, но если ТЗ и тесты написаны правильно то библиотеки написанные разными программистами по разному, будут работать одинаково (согласно спецификации) - если что не так - уточняйте спецификацию и правьте тесты.
Я подозреваю теперь так будем работать.
Лет 10 назад я тут в коментариях на Хабре описывал способ создания програм, который хочу создать. В нём всё так же - любой человек описывает што хочет от програмы, програма вся изолирована проверками на всё, при попадании в такую проверку (случился баг - например, пришли неожыданные данные) програма зависает, штобы человек доуточнил детали.
Но при таком способе програмисты полностью не исчезали, из них оставались в професии те, кто знает все уровни програм вплоть до регистров. Как и тут в тексте:
Умение разобраться в том, как всё устроено «под капотом», вскоре станет редкой и крайне востребованной экспертизой на рынке, переполненном операторами нейросетей.
Т.к. оставалась основная проблема - производительность. Код хоть и будет надёжным, но не будет эфективным, и жывые програмисты это должны решыть, т.е. кому надо - нёс бы свою програму такому програмисту.
Но теперь мне кажетса, што и они тоже в опасности, т.к. как видим - люди готовы терпеть медленные програмы. А там, где таки нужна скорость, там "оператор" может попросить ускорить нужное место, и нейросети-агенты или быстро подберут алгоритм, или же могут это сделать дольше брутфорсом.
Тогда действительно останутса самые-самые хардкорные редкие прогеры. Такие, как сейчас прогают микроконтролеры или компиляторы, штобы работали серверы с агентами-оптимизаторами.
Вспомнил, што вообще-то текущим ИИ сложно даётса творчество, создание чево-то новово, неизвестново. Обычным людям агенты пока недоступны (?), поэтому пока сужу только по доступным мне ДипСику и Гроку.
Задача, которую они не смогли решыть:
Windows, консольная програма. Надо, штобы при перетаскивании файла в окно консоли програма провела действия над ним без нажатия Enter или чево-либо. Например, показала размер этово файла или вывела текстовое сообщение из нево.
Запрещено создавать дополнительные окна и использовать всякие хаки и хуки.
Если сейчас агенты не (с)могут это решыть, то тогда для нас, програмистов, надежда ещё есть.
обсуждение языка CodeSpeak в подкасте Подлодка
Посмотрел, но показалось, что до 1.0 там еще далеко.
Полагаю, что нужно идти параллельно двумя путями:
DSL для каждого класса ПО
верхнеуровнеывый JS/Java (условно) для каждого языка программирования - возможно единая оболочка, транслирующая верхнеуровневый код в классический язык программирования JS/Java (условно), типа "BPMN Next" (условно)
Подробнее тут
Мертворождённый псевдоинтеллектуальный концепт который решает выдуманные проблемы. Rust уже существует, ничего больше пока что не надо
Архитектура вместо синтаксиса: CodeSpeak — язык разработки следующего поколения, использующий силу LLM спецификаций