Архитектура вместо синтаксиса: CodeSpeak — язык разработки следующего поколения, использующий силу LLM спецификаций

[Florelit]

Spec-driven-development?

[Testfreecloud]

Вот мы и увидели декларативный вайб-кодинг. Он конечно тоже немного недетерминирован как и императивный, но кому это интересно.

[Kerman]

Вроде умные мысли говорит, но при этом пытается сделать из промпта полноценную замену. Я говорю "промпт", потому что вижу, что этот язык не является полной и исчерпывающей спецификацией, то есть позволяет множественную трактовку, равно как естественный язык. А если является, то как его синтаксис может быть в 5-10 раз короче?

Я не понимаю, как он собирается решать две основные проблемы.

Первая и самая главная: недетерменированость. Из одного и того же "исходника" получаются разные кодовые базы классического языка. Это делает невозможным итеративные улучшения, это делает невозможным багфикс (ну просто потому что сегодня баг есть, завтра нет и наоборот, и всё это с одним и тем же "исходником").

Вторая проблема: контекстное окно. Если раньше, когда вдруг оказывалось, что 640кб не хватает всем для компиляции, то покупалась плашка памяти за $100 и приводились исходники в порядок. Бедные страдали со свопом, но компилировали. А для увеличения контекстного окна вдвое надо построить новый дата-центр, потому что зависимость ну ни разу не линейная. А контекстное окно нужно обязательно, потому что проект планируется перегенерировать полностью и если ваш исправленный промпт не лезет в окно, то в окно пойдёте вы.

[ARad]

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

То что их одной спецификации можно получит разные реалии при изменении внешних параметров, наоборот является огромным преимуществом. Это позволит гораздо быстрее изменять большие кодовые базы, а не поддерживать старый код, который просто не кому сейчас переписать.

[Spyman]

Сегодня код работает за константное время, завтра за квадратичное. Сегодня без side эффектов, завтра с промежуточными файлами. Сегодня интерфейс выглядит консистентентно, завтра на каждом экране свои формы.

[ARad]

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

[GerrAlt]

del

[nin-jin]

CodeSpeak является не языком, а агентом, примеры "спецификаций" в навайбкоженном лендинге совсем уж не строгие, и тоже навайбкожены, как и скорее всего весь проект, Бреслав тупо хайпожорит, а вам лично не хватает экспертизы, чтобы это всё понять.

[rbdr]

А самое главное, что этой супер-пупер-"новой" концепцией уже пользуются все, кто более-менее набрался опыта работы с LLM ИИ.

[ARad]

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

[d3d12]

Выход - компонентный подход к проектированию. Чтобы агент работал только с одним компонентом, зная спецификацию его интерфейсов.

[RomanVelichkin]

Главная ценность такого подхода заключается в жесткой изоляции. Так как спецификация предельно четкая и имеет строгие контракты ввода-вывода, ИИ-агенту не нужно выдумывать, что именно реализовать, или галлюцинировать дополнительный функционал. Нейросеть ограничена рамками Markdown-файла. Если спустя время разработчику понадобится добавить извлечение даты получения письма, он просто допишет одну строку в раздел «Output Structure» в .cs.md файле. После команды сборки CodeSpeak обновит исключительно eml_converter.py и его тесты, совершенно не затрагивая остальную кодовую базу проекта.

Так и как это реализовано? За счёт чего удается избежать галлюцинаций (тем более, что исследователи OpenAI уже доказали, что это невозможно) и написания лишнего функционала?

[Ingref]

избежать галлюцинаций (тем более, что исследователи OpenAI уже доказали, что это невозможно)

Но можно при желании полностью отключить нейроны, рождающие галлюцинации - https://github.com/thunlp/H-Neurons

[RomanVelichkin]

Платформа CodeSpeak меняет этот парадокс, фиксируя диалог с ИИ в виде статических файлов спецификаций. Спецификация становится главным артефактом, подлежащим контролю версий и код-ревью. Команда обсуждает и утверждает смысловую часть алгоритма, оставляя валидацию синтаксиса на откуп автоматизированным тестам.

А чем это отличается от обычной спецификаций в .md для языковых моделей?

[rbdr]

Чем это отличается... наглой наивностью, что придумал что-то радикально новое.

[ARad]

Иногда достаточно формализировать и автоматизировать то что используется продвинутыми разработчиками при работе с ИИ агентами.
Работать с формальными спецификациями, которые не теряются между сессиями просто удобнее и надежнее.
А приживется или нет такой подход покажет время. Мне он показался достаточно интересным чтобы о нем рассказать.

[Ingref]

Мне непонятно одно - как система контролирует, что тесты написаны правильно и действительно проверяют работу алгоритма? Что если все тесты PASSED, а ничего не работает? В этом состоит основная претензия к вайбкодерам (что потом надо будет ковыряться вручную и пытаться понять, почему не работает).

[ARad]

Вышло обсуждение языка CodeSpeak в подкасте Подлодка на русском языке с самим Андреем https://youtu.be/s5vqzH31tRE?si=fvuxqpIcpZl0MqYj