Команда разработчиков под руководством Андрея Бреслава, российского разработчика и автора языка программирования Kotlin, представила публичную альфа-версию нового инструмента для разработчиков — CodeSpeak. Платформа позиционируется как язык программирования нового поколения, в котором инженеры пишут спецификации на английском языке, а нейросети берут на себя генерацию, тестирование и рефакторинг исполняемого кода. Полноценное внедрение инструмента позволяет сократить объем кодовой базы в проектах в пять-десять раз. Технология поддерживает интеграцию в существующие сложные проекты на Python.
ИИ-язык, созданный для людей
Переход от кода к управлению смыслом
В феврале 2026 года проект CodeSpeak перешел в стадию открытого альфа-тестирования, предложив инженерам концепцию поддержания спецификаций вместо исходного кода. Платформа представляет собой консольную утилиту, которая интегрируется в рабочее окружение и выступает прослойкой между разработчиком, пишущим требования на английском языке, и большой языковой моделью, которая эти требования реализует. В качестве основного движка генерации CodeSpeak использует модель Claude Opus 4.6 от компании Anthropic.
Основной метрикой эффективности CodeSpeak разработчики называют кратное уменьшение объема проекта, с которым напрямую взаимодействует человек. На примере перевода существующих open-source библиотек под управление платформы, объем исходных файлов сокращается в среднем от шести до десяти раз. Человеку остается поддерживать только короткий текстовый документ, описывающий суть алгоритма, в то время как техническая реализация скрыта под капотом системы тестирования и сборки.
В отличие от популярных чат-ботов и ИИ-агентов, CodeSpeak ориентирован не на быстрое прототипирование, а на долгосрочную поддержку продакшен-систем. Платформа изначально создавалась для работы в командах и подразумевает управление сложной архитектурой. Система умеет разворачивать проекты с нуля, однако ее главная особенность заключается в способности встраиваться в существующие кодовые базы и локально перехватывать управление отдельными модулями, не нарушая работу остального приложения.
Обновление: Вышел свежий выпуск подкаста Подлодка, посвящённый языку CodeSpeak. Ведущие поговорили с самим Андреем Бреславым (ex-JetBrains, один из создателей Kotlin, ныне основатель CodeSpeak) о том, как LLM меняют парадигму разработки.
Эволюция абстракций: от Kotlin к спецификациям
Переход к разработке на естественном языке стал для Андрея Бреслава логичным продолжением его предыдущей работы. Во время работы в JetBrains в 2010-х годах он спроектировал язык Kotlin с целью избавить Java-разработчиков от избыточного шаблонного кода. В то время синтаксис Kotlin позволил автоматизировать множество рутинных операций на уровне компилятора, сделав программы более читаемыми.
С развитием больших языковых моделей проблема избыточности вышла на новый уровень. По мнению Бреслава, огромный пласт современного кода является очевидным не только для инженера, но и для алгоритмов машинного обучения. Если раньше компилятору требовались точные синтаксические конструкции для понимания задачи, то сегодня нейросеть способна извлечь нужную техническую реализацию из своего внутреннего представления, обученного на всем мировом открытом коде. Это делает ручное написание стандартных алгоритмов неэффективной тратой времени.
При разработке CodeSpeak команда исходила из того, что программирование исторически двигалось по пути повышения уровня абстракций: от машинных кодов к ассемблеру, затем к языкам высокого уровня вроде C и Java. CodeSpeak рассматривается как следующий шаг в этой иерархии, где уровень абстракции поднимается до естественного языка, а языковая модель выполняет роль сверхмощного компилятора, генерирующего итоговую логику.
Архитектура файлов и автоматическое тестирование
Процесс разработки в CodeSpeak кардинально отличается от классического цикла. Точкой входа служит файл с расширением .cs.md, содержащий спецификацию конкретного модуля. Инженер описывает в нем структуру данных, логику обработки и форматы вывода. После запуска команды сборки система анализирует этот файл, собирает контекст проекта и передает план действий языковой модели.
Важнейшим элементом архитектуры платформы является автономное тестирование. В процессе сборки CodeSpeak не просто генерирует код, но и самостоятельно пишет модульные тесты для проверки заявленных в спецификации требований. Если тесты не проходят, система итеративно исправляет сгенерированный код до тех пор, пока функциональность не будет полностью соответствовать тексту. Для разработчика процесс выглядит как компиляция: на входе подается текстовое описание, на выходе получается рабочий и протестированный модуль.
В текущей версии система глубоко интегрирована с экосистемой Python и менеджером пакетов uv. Инструмент автоматически управляет виртуальными окружениями и зависимостями, позволяя создавать полноценные веб-приложения, например, на базе фреймворка Django, буквально из одного файла спецификации.
Анатомия спецификации: как ИИ понимает задачу
Чтобы понять, как абстрактный текст превращается в детерминированную логику, достаточно взглянуть на структуру типичного исходника CodeSpeak. На прикрепленном к статье демонстрационном видео показан процесс работы с платформой, где разработчик оперирует исключительно такими текстовыми контрактами.
Допустим, нам нужно написать конвертер для разбора сохраненных почтовых сообщений. Вместо написания десятков строк на Python разработчик создает файл eml_converter.cs.md со следующим содержимым:
# EmlConverter Converts RFC 5322 email files (.eml) to Markdown using Python's built-in `email` module. ## Accepts `.eml` extension or `message/rfc822` MIME type. ## Output Structure 1. **Headers section**: From, To, Cc, Subject, Date as `**Key:** value` pairs 2. **Body**: plain text preferred; if only HTML, convert to markdown 3. **Attachments section** (if any): list with filename, MIME type, human-readable size ## Parsing Requirements - Decode RFC 2047 encoded headers (e.g., `=?UTF-8?B?...?=`) - Decode body content (base64, quoted-printable) - Handle multipart: walk parts, prefer `text/plain` over `text/html` - For `message/rfc822` parts: recursively format as quoted nested message - Extract attachment metadata without decoding attachment content
Главная ценность такого подхода заключается в жесткой изоляции. Так как спецификация предельно четкая и имеет строгие контракты ввода-вывода, ИИ-агенту не нужно выдумывать, что именно реализовать, или галлюцинировать дополнительный функционал. Нейросеть ограничена рамками Markdown-файла. Если спустя время разработчику понадобится добавить извлечение даты получения письма, он просто допишет одну строку в раздел «Output Structure» в .cs.md файле. После команды сборки CodeSpeak обновит исключительно eml_converter.py и его тесты, совершенно не затрагивая остальную кодовую базу проекта.
Режим частичной интеграции и перевод легаси-кода под управление спецификациями
Понимая, что переписать существующие энтерпрайз-проекты с нуля практически невозможно, создатели CodeSpeak предусмотрели возможность частичной интеграции. В так называемом смешанном режиме (Mixed Mode) разработчик может инициализировать CodeSpeak внутри старого репозитория и строго ограничить список файлов, с которыми системе разрешено взаимодействовать. Это позволяет внедрять новые функции через текстовые спецификации, не подвергая риску устоявшуюся архитектуру.
Для работы с уже написанным кодом реализован механизм автоматического реверс-инжиниринга и передачи управления (команда takeover). Инженеру достаточно указать утилите конкретный исходный файл: система проанализирует алгоритмы и извлечет их бизнес-логику, сгенерировав для нее новый текстовый Markdown-файл со спецификацией. В официальном блоге проекта приводится показательный пример с конвертером форматов из библиотеки Microsoft MarkItDown, где CodeSpeak успешно превратил сотни строк Python-кода в лаконичное текстовое описание правил парсинга.
Как только существующий код переведен под контроль платформы, править оригинальные исходники вручную больше не нужно. Если в дальнейшем потребуется, например, добавить обработку нового поля в почтовом сообщении, разработчик просто вписывает одно дополнительное требование в Markdown-спецификацию. Опираясь на это обновление, CodeSpeak самостоятельно перепишет исходный код конвертера, создаст нужные вспомогательные методы и расширит тестовую базу для проверки новых требований.
Проблема потерянного контекста в ИИ-кодинге
Архитектура CodeSpeak решает одну из главных проблем современных ИИ-помощников вроде Cursor или GitHub Copilot. При использовании агентов инженер формулирует свои намерения в интерфейсе чата. Агент выдает готовый код, который затем отправляется в репозиторий проекта. При этом сам диалог, содержащий истинный смысл и бизнес-логику решения, теряется навсегда.
Бреслав отмечает, что при таком подходе коллеги разработчика видят только результат работы машины, а не изначальное намерение. Код становится языком общения между инженерами, хотя изначально он генерировался машиной для машины. В долгосрочной перспективе это приводит к усложнению код-ревью и потере контроля над архитектурой, так как тестировать и проверять огромные массивы сгенерированного кода без понимания изначальной логики практически невозможно.
Платформа CodeSpeak меняет этот парадокс, фиксируя диалог с ИИ в виде статических файлов спецификаций. Спецификация становится главным артефактом, подлежащим контролю версий и код-ревью. Команда обсуждает и утверждает смысловую часть алгоритма, оставляя валидацию синтаксиса на откуп автоматизированным тестам.
Следующий уровень абстракции: ИИ-агенты как авторы спецификаций
Подход с использованием формальных спецификаций решает проблему масштабирования и поддержки больших кодовых баз, однако ручное создание таких документов, вероятно, окажется лишь промежуточным этапом в эволюции разработки. Логика развития инструментов на базе больших языковых моделей указывает на то, что в обозримом будущем инженеры перестанут писать даже сами спецификации.
Вместо структурированных файлов разработчик будет формулировать бизнес-требования на свободном естественном языке — в виде высокоуровневых продуктовых пожеланий или пользовательских историй. ИИ-агенты возьмут на себя роль системных аналитиков: они будут переводить неструктурированный текст от человека в строгие формальные спецификации. Этот процесс станет логичным развитием механизма реверс-инжиниринга, который уже сейчас используется в CodeSpeak для генерации контрактов из старого кода. Сформировав спецификацию, машина самостоятельно сгенерирует по ней исполняемый код и тесты.
В такой парадигме роль программиста кардинально меняется. Навык написания формальных контрактов с нуля будет требоваться крайне редко, уступая место навыку аналитического чтения. Главной задачей разработчика станет умение читать спецификации, понимать заложенную в них архитектуру и верифицировать логику. Человеку предстоит выступать в роли валидатора, который проверяет, правильно ли ИИ-агент интерпретировал изначальную бизнес-идею, прежде чем эта спецификация превратится в работающий продукт. Фокус профессии окончательно сместится от создания строк кода или текста к экспертной оценке и управлению смыслом.
Иллюзия программирования естественным языком и преждевременные похороны джуниоров
Развитие ИИ-агентов породило в индустрии феномен, который западные разработчики в шутку окрестили vibe-coding — подходом, при котором человек просто описывает желаемый результат текстом, а нейросеть выдает готовое приложение. На фоне резкого скачка возможностей моделей многие компании начали замораживать наем младших разработчиков, ошибочно полагая, что алгоритмы способны полностью заменить начинающих специалистов.
В большом интервью, видео которого представлено ниже, Андрей Бреслав прямо называет массовый отказ от найма джуниоров глупой и временной ошибкой рынка. По его словам, управленцы сейчас ослеплены хайпом вокруг ИИ-инструментов, но эта эйфория неизбежно пройдет, когда индустрия столкнется с необходимостью поддерживать сгенерированные проекты на длинной дистанции. Рано или поздно бизнес осознает, что для развития технологий в индустрию должен постоянно поступать приток новых людей.
Главная проблема бездумного делегирования заключается в потере контроля. Бреслав подчеркивает, что если всю архитектурную работу начнут выполнять исключительно модели, а люди перестанут понимать, как именно работает код, это приведет к потере субъектности инженера. Задача человека — управлять так называемой «сущностной сложностью» (essential complexity), точно формулировать намерения и принимать технические решения. Машина выступает лишь исполнителем, и для корректной постановки задач ей по-прежнему требуется полноценный инженерный склад ума.
Начинающим разработчикам создатель Kotlin советует не поддаваться панике, а извлекать из ситуации выгоду. С одной стороны, необходимо в совершенстве освоить новые ИИ-инструменты, чтобы многократно повысить свою продуктивность. С другой — использовать освободившееся время для максимально глубокого погружения в фундаментальные, хардкорные основы программирования. Умение разобраться в том, как всё устроено «под капотом», вскоре станет редкой и крайне востребованной экспертизой на рынке, переполненном операторами нейросетей.
Ближайшие перспективы проекта
На данный момент CodeSpeak имеет статус альфа-версии и требует от пользователей готовности к техническим шероховатостям. Команда проекта фокусируется на улучшении механизмов синхронизации: система должна гарантировать, что при удалении кода его всегда можно в точности восстановить из спецификации, а любые изменения текста транслируются в адекватные изменения архитектуры. Несмотря на раннюю стадию, инструмент уже обозначает новый вектор развития индустрии, где главной компетенцией инженера становится умение структурировать сложность и управлять намерениями, а не владение синтаксисом конкретных языков программирования.
Источники
CodeSpeak: Software Engineering with AI — CodeSpeak
Андрей Бреслав — российский программист, один из создателей языка программирования Kotlin (руководитель группы разработчиков в компании JetBrains), сооснователь сервиса подбора психологов Alter.ru, основатель CodeSpeak.
Комментарии (55)
Testfreecloud
14.03.2026 03:05Вот мы и увидели декларативный вайб-кодинг. Он конечно тоже немного недетерминирован как и императивный, но кому это интересно.
Kerman
14.03.2026 03:05Вроде умные мысли говорит, но при этом пытается сделать из промпта полноценную замену. Я говорю "промпт", потому что вижу, что этот язык не является полной и исчерпывающей спецификацией, то есть позволяет множественную трактовку, равно как естественный язык. А если является, то как его синтаксис может быть в 5-10 раз короче?
Я не понимаю, как он собирается решать две основные проблемы.
Первая и самая главная: недетерменированость. Из одного и того же "исходника" получаются разные кодовые базы классического языка. Это делает невозможным итеративные улучшения, это делает невозможным багфикс (ну просто потому что сегодня баг есть, завтра нет и наоборот, и всё это с одним и тем же "исходником").
Вторая проблема: контекстное окно. Если раньше, когда вдруг оказывалось, что 640кб не хватает
всемдля компиляции, то покупалась плашка памяти за $100 и приводились исходники в порядок. Бедные страдали со свопом, но компилировали. А для увеличения контекстного окна вдвое надо построить новый дата-центр, потому что зависимость ну ни разу не линейная. А контекстное окно нужно обязательно, потому что проект планируется перегенерировать полностью и если ваш исправленный промпт не лезет в окно, то в окно пойдёте вы.
ARad Автор
14.03.2026 03:05Один и тот же алгоритм можно и написать на разных языках программирования, а ещё применить разные специфические трюки для каждого языка, плюс учесть версии системных библиотеки, учесть особенности данных для этого алгоритма, например для строк или чисел и т. д.
Огромное число дополнительных параметров, которые в самом алгоритме не заложены, приводят к разному кожу. Поэтому и не удивительно что одна и та же спецификация может порождать разный код.
Да просто при смене версии языка или системных, или других библиотек, реализации одной и той же спецификации может поменяться с учётом внешних параметров, которые описаны в более общих спецификациях.То что их одной спецификации можно получит разные реалии при изменении внешних параметров, наоборот является огромным преимуществом. Это позволит гораздо быстрее изменять большие кодовые базы, а не поддерживать старый код, который просто не кому сейчас переписать.
Spyman
14.03.2026 03:05Сегодня код работает за константное время, завтра за квадратичное. Сегодня без side эффектов, завтра с промежуточными файлами. Сегодня интерфейс выглядит консистентентно, завтра на каждом экране свои формы.
ARad Автор
14.03.2026 03:05Не будет такого при наличии хороших спецификаций. С ии агентами сейчас как раз чаще происходит когда вы начинаете новую сессию и вы ней не указали то что было в старой существенное и следовательно он не знает то, что знал в старой сессии. Спецификации как раз помогут и вам и ИИ агентам не терять важные детали. Они и нужны для того чтобы сгенерированный код оставался стабильным при этом его будет легче изменять при внешних изменениях. Например, вы изменили версию какой то использованной библиотеки и код будет переписан с учётом новых улучшений.
ИИ агенты не переписывают код если вы указываете одни и те же достаточно подробные спецификации. Обычно они такое начинают творить если вы открыли новую сессию и забыли туда перенести существенные детели из старой. А спецификации помогают не терять эти детали.
Belarus
14.03.2026 03:05Например, такие важные места уточняютса хоть до уровня регистров, если сильно важны. Допустим, будет добавлен тэст, што при нажатии кнопок на такой-то странице, время реакцыи интрфэйса не должно превышать какое-то время.
Format-X22
14.03.2026 03:05Обычно проблема в том что на разные входные данные могут получаться разные результаты, зависеть от стейта внутри, от времени или значений случайных чисел, если такие используются. И всё это время шла борьба с этим. Оттуда появились виртуальные машины, докеры, кросс-платформенность и прочее.
Вы предлагаете всё выкинуть и сказать мол и так сойдет, зато ИИ пишет код. Если это какой-нибудь развлекательный сайт это ладно, если игра - это даже забавно, уникальное прохождение. Но я уверен что вы не захотите получить списание с вашего банковского счета только потому что сегодняшняя модель не так поняла назначение вашего платежа, или лежа под аппаратом коррекции зрения случайно получить прожженную дыру в сетчатке, потому что сегодня другие входные данные.ARad Автор
14.03.2026 03:05
Belarus
14.03.2026 03:05вы не захотите получить списание с вашего банковского счета только потому что сегодняшняя модель не так поняла назначение вашего платежа, или лежа под аппаратом коррекции зрения случайно получить прожженную дыру в сетчатке
От этово вы не застрахованы и сейчас. Такие важные програмы, очевидно, будут долго тэстироватса.
ARad Автор
14.03.2026 03:05Считаю что спецификации которые тут предлагают, это достаточно строгий промпт, который будет создавать надёжные тесты и реализации.
Огромное множество проблем вайб разработки, достаточно строгие спецификации могут решить.
nin-jin
14.03.2026 03:05CodeSpeak является не языком, а агентом, примеры "спецификаций" в навайбкоженном лендинге совсем уж не строгие, и тоже навайбкожены, как и скорее всего весь проект, Бреслав тупо хайпожорит, а вам лично не хватает экспертизы, чтобы это всё понять.
rbdr
14.03.2026 03:05А самое главное, что этой супер-пупер-"новой" концепцией уже пользуются все, кто более-менее набрался опыта работы с LLM ИИ.
ARad Автор
14.03.2026 03:05Вот и замечательно что появляются инструменты для этого подхода, которые позволяют и людям между собой и ИИ агентам по одинаковому понимать спецификации.
ARad Автор
14.03.2026 03:05Множество раздельных спецификаций, которые являются частью проекта, сильно уменьшают требования к размеру контекстного окна. ИИ агентам для разработки локальной части не нужно знать все спецификации, только для этой части , плюс общий спецификации, плюс спецификации апи с которым идёт взаимодействие.
d3d12
14.03.2026 03:05Выход - компонентный подход к проектированию. Чтобы агент работал только с одним компонентом, зная спецификацию его интерфейсов.
kituru
14.03.2026 03:05Детерминированность это очень неудобное слово для современных ИТ дискуссий, да и некогда про это, нужно агентов внедрять, так 'visibility' проще пропехнуть.
Belarus
14.03.2026 03:05Это делает невозможным итеративные улучшения
Почему же? Итеративно добавляютса-удаляютса фичи, нет проблемы.
это делает невозможным багфикс (ну просто потому что сегодня баг есть, завтра нет и наоборот, и всё это с одним и тем же "исходником").
Выявляетса баг - добавляетса спецыфикацыя. Изначально там внутри, в коде, может быть куча проверок на всё, штобы програма не ломалась, а просто останавливалась и спрашывала што делать, раз тут выявился непродуманный момент. Например, банально неожыданные входные данные. И может даже прям там же после ответа инженера код дополнится и програма продолжит выполнятса с этово же места, не перезапуская всё заново.
Вторая проблема: контекстное окно.
Написано, што части спецыфикацыи независимы, т.е. незачем пихать вообще все спецыфикацыи.
RomanVelichkin
14.03.2026 03:05Главная ценность такого подхода заключается в жесткой изоляции. Так как спецификация предельно четкая и имеет строгие контракты ввода-вывода, ИИ-агенту не нужно выдумывать, что именно реализовать, или галлюцинировать дополнительный функционал. Нейросеть ограничена рамками Markdown-файла. Если спустя время разработчику понадобится добавить извлечение даты получения письма, он просто допишет одну строку в раздел «Output Structure» в
.cs.mdфайле. После команды сборки CodeSpeak обновит исключительноeml_converter.pyи его тесты, совершенно не затрагивая остальную кодовую базу проекта.Так и как это реализовано? За счёт чего удается избежать галлюцинаций (тем более, что исследователи OpenAI уже доказали, что это невозможно) и написания лишнего функционала?
Ingref
14.03.2026 03:05избежать галлюцинаций (тем более, что исследователи OpenAI уже доказали, что это невозможно)
Но можно при желании полностью отключить нейроны, рождающие галлюцинации - https://github.com/thunlp/H-Neurons
MAT-POC
14.03.2026 03:05Береслав предлагает обязательно генерировать тесты и генерировать код до тех пор пока он не будет соответствовать спецификации и проходить все тесты. Ошибки конечно будут проскакивать, но скорость итераций, и общая управляемость кода обеспечит их меньшее количество по сравнению с человеком. Я думаю если каким либо образом внедрить шаблоны кода и типовые решения которые будут использоваться при использовании связанных с ними типовых фраз и выражений в спецификации, то это ещё уменьшит количество багов и увеличит детерминированность кода.
nin-jin
14.03.2026 03:05Какая интересная идея - для борьбы с нейрослопом генерировать тесты, которые будут нейрослоп отсекать. Но как бороться с нейрослопом в тестах? Тесты на тесты?
ARad Автор
14.03.2026 03:05Создается ощущение что вы ИИ агенты не использовали. Попробуйте, хотя бы для тестов. Они придумывают и реализовывают тесты лучше людей очень часто. Людям просто лень писать и переписывать простыни кода только для тестов. ИИ агентам нет.
RomanVelichkin
14.03.2026 03:05Платформа CodeSpeak меняет этот парадокс, фиксируя диалог с ИИ в виде статических файлов спецификаций. Спецификация становится главным артефактом, подлежащим контролю версий и код-ревью. Команда обсуждает и утверждает смысловую часть алгоритма, оставляя валидацию синтаксиса на откуп автоматизированным тестам.
А чем это отличается от обычной спецификаций в .md для языковых моделей?
rbdr
14.03.2026 03:05Чем это отличается... наглой наивностью, что придумал что-то радикально новое.
ARad Автор
14.03.2026 03:05Иногда достаточно формализировать и автоматизировать то что используется продвинутыми разработчиками при работе с ИИ агентами.
Работать с формальными спецификациями, которые не теряются между сессиями просто удобнее и надежнее.
А приживется или нет такой подход покажет время. Мне он показался достаточно интересным чтобы о нем рассказать.
Ingref
14.03.2026 03:05Мне непонятно одно - как система контролирует, что тесты написаны правильно и действительно проверяют работу алгоритма? Что если все тесты PASSED, а ничего не работает? В этом состоит основная претензия к вайбкодерам (что потом надо будет ковыряться вручную и пытаться понять, почему не работает).
Belarus
14.03.2026 03:05Что если все тесты PASSED, а ничего не работает?
Видимо, откат на предыдущее состояние, до изменения.
ARad Автор
14.03.2026 03:05Вышло обсуждение языка CodeSpeak в подкасте Подлодка на русском языке с самим Андреем https://youtu.be/s5vqzH31tRE?si=fvuxqpIcpZl0MqYj
kostjaden
14.03.2026 03:05Любой ИИ - подражание разрабу, любая нейросетка - роботизированный вор (плагиатор). Любой алгоритм можно описать с помощью классов, тем не менее, все будет железозависимым и ламеро-определяемым. Тем не менее, это не приблизит нас к решению больгиествс проблем, не комьютеры юудут помогать людям, а люди будут обслуживать компы.
Гораздо более актуально создание семантической нотации для взаимодействия человека (предлагаю вернуться к иероглифике, скорость вывода зрительно повышается в десятки раз, а ввод может быть целебральным, смысло-симолами) и машины, или как более правильно - между людьми, ибо вычислит.техника - это лишь инструмент обмена инфой между человеческими особями в пространстве и времени (этап вслед за печатной книгой). Некое подобие Матрицы создаст Коллективное Сознание (ступень интернета), в соотв.фильме оно стало хранилищем цивилизации в разуме спящих тел, чтобы со временем пробудились не овощи. Не будет интерпретаций, за которыми маячат катастрофы, описаннные фантастами еще в 60-е, включая порабощение людей своим несовершенными созданиями, и в итоге к гибели всего вида.
pkokoshnikov
14.03.2026 03:05А теперь давайте представим ситуацию. Спеку создали всё ок. Но llm сгенерила код с проблемой n+1. Через какое-то время заметили что всё тормозит. Код при этом мы писать уже не умеем и вообще плохо понимаем что там под капотом работает. Дальше что делать? Идея всё таки кажется утопичной в плане генерации по этой спеке кода.
Но в целом как инструмент спецификации может быть интересно. Идея ввести универсальный язык, и попросить llm следить чтобы спека была непротиворечива. Это прямо топ идея. Опять же просто просить проверять на соответствие спеку и код, может быть очень полезным. Поэтому думаю в целом может получится очень хороший инструмент
Ingref
14.03.2026 03:05Дальше что делать?
Попросить LLM: "Что-то всё тормозит. Сделай, чтобы не тормозило". На будущее добавить, чтобы при разработке максимально оптимизировала код всеми известными человечеству способами оптимизации.
Такие задачи решаются без проблем. А вот что делать, когда LLM просто не может одолеть какой-то баг из-за недостатка контекста или просто в силу ограниченного интеллекта, пока не ясно. Обычно просто выходит новая версия Клода \ GPT \ Gemini и на какое-то время поднимает эту планку.
pkokoshnikov
14.03.2026 03:05Ну я привел просто пример. Не все проблемы решаются общеизвестными практиками. Очень часто проблемы специфичные для твоего кейса и нужно подумать чтобы их решить. А не просто известное решение подставить. Собственно решение багов ту да же. И каким образом это можно только спекой решить мне не понятно. Нужен качественно иной ии, для таких задач. И скорее всего это не llm. Но вот проверить спеку на логичность, сделать процесс разработки проще вполне такой инструмент может. Идея в целом мне нравится.
Belarus
14.03.2026 03:05Код при этом мы писать уже не умеем и вообще плохо понимаем что там под капотом работает. Дальше что делать?
В конце статьи:
Умение разобраться в том, как всё устроено «под капотом», вскоре станет редкой и крайне востребованной экспертизой на рынке, переполненном операторами нейросетей.
Т.е. отдаёте тому, кто знает, как там устроено всё внутри. Ну вот ему и ево команде, например.
pkokoshnikov
14.03.2026 03:05Помню когда то мне предлагали возглавить альфатим в неткрекере. Команду которая будет тушить пожары за джунами студентами. Мне тогда уже эта идея не понравилась. Делать правки в сложном домене в котором не работаешь очень сложно и рискованно. За тобой уже никто не проревюит. Поэтому как мне кажется эта идея провальна. Разработка будет буксовать и останавливаться слишком часто. А выиграют в итоге те кто сохранит экспертизу в командах и не поддастся сиюминутному желанию срезать косты. Поэтому на мой взгляд пока не будет создан ии который думает примерно как человек, может в голове крутить абстракции, а не просто по предыдущему тексту выводить следующий, идея эта о обречена на провал.
Belarus
14.03.2026 03:05А если всё сведётся лиш к производительности? Код от такой ИИ будет надёжен и делать то, што от нево просили, но внутри куча неэфективностей типа считание длины строки каждую итерацыю цикла.
И вот тут этим спецам, знающим все уровни вплоть до регистров, не надо будет разбиратса в самой програме. Им будет дана цель разобратса лиш в указанных местах, которые работают слишком медленно.
cross_join
14.03.2026 03:05сложные проекты на Python
Авторы действительно уверены, что Питон - подходящий инструмент для создания сложных проектов?
Созданию языков спецификаций уже 50 лет: CASE, RAD, MDD, SoftwareFactory... Но если те подходы были детерминистскими, и сокращали затраты на тестирование, то использование БЯМ в качестве универсального генератора будет порождать разные результаты и требовать максимального покрытия тестами всех уровней.
https://habr.com/ru/articles/994838/
koreychenko
14.03.2026 03:05Я вот одного не понимаю, почему все так прутся со спецификаций в текстовом формате. Ведь уже на этом этапе могут быть косяки разбора нейронка информации. То, что вы в md поставили две решетки, типа как начало заголовка это же не означает, что нейронка 100% догадается что это именно заголовок, что он относится к какому-то абзацу, а дальше недо еще интерпретировать что делать с информацией из этого абзаца.
Если у на спецификация, то почему не какой-нить машиночитаемый формат, вроде yaml, и пусть в нем будут стандартные этапы, вроде: testing, styling, functional_requirements, etc.
Агент понимает на каком он этапе плана выполнения и тянет только релевантную информацию в контекст.Belarus
14.03.2026 03:05Штобы человеку понимать, што происходит там внутри. Почему бы вам не прочитать статью? Она же интересная, это же хоть што-то новое в вайб-кодинге.
diffnotes-tech
14.03.2026 03:05Спека в git, модель под ней обновляется. Один .cs.md файл на Opus 4.6 и на Opus 5 даст разный код. В roadmap написано "при удалении кода его можно восстановить из спецификации" - но из какой версии модели восстанавливать? Обычные компиляторы дают reproducible builds, тут каждое обновление модели потенциально меняет реализацию
Belarus
14.03.2026 03:05Так ли это важно, если реализацыю меняет уже просто перекомпиляцыя на одной и той же модели?
система должна гарантировать, что при удалении кода его всегда можно в точности восстановить из спецификации
Тут не очень понятно, почему код может быть удалён - будто вырвано из контекста.
ARad Автор
14.03.2026 03:05Это то, что хотят достичь создатели языка. Как они хотят это достичь пока непонятно.
Belarus
14.03.2026 03:05Наверно, имеетса в виду, што текущая спецыфикацыя будет создавать тот же код. Но если начать новый проект, то по этой же спецыфикацыи будет уже чуть другой код?
ARad Автор
14.03.2026 03:05Если не менять разработчика и попросить по спецификации написать код заново он напишет идентичный код? В чем тут вы видете проблему?
Главное чтобы ИИ агент тесты нормально написал заново.Belarus
14.03.2026 03:05В чем тут вы видете проблему?
В вопросительном знаке первово предложения. Он вообще сломал мне мозг - это я у вас спрашываю, а вы задаёте этот вопрос мне %)
Главная проблема вот:
при удалении кода
Вы только догадываетесь што это означает или же точно знаете? Почему код удаляетса? Можно было бы написать проще - "Одни и те же спецификации создают идентичный код", значит тут што-то другое. То ли если во время разработки удалили ненужную часть кода, +синхронизацыя там в предыдущем предложении.
ARad Автор
14.03.2026 03:05Это то, что хотят достичь создатели языка. Как они хотят это достичь пока непонятно.
MAT-POC
14.03.2026 03:05Вы пишете ТЗ на разработку одной библиотеки двум разным программистам. Они решают по разному, но если ТЗ и тесты написаны правильно то библиотеки написанные разными программистами по разному, будут работать одинаково (согласно спецификации) - если что не так - уточняйте спецификацию и правьте тесты.
Я подозреваю теперь так будем работать.
Belarus
14.03.2026 03:05Лет 10 назад я тут в коментариях на Хабре описывал способ создания програм, который хочу создать. В нём всё так же - любой человек описывает што хочет от програмы, програма вся изолирована проверками на всё, при попадании в такую проверку (случился баг - например, пришли неожыданные данные) програма зависает, штобы человек доуточнил детали.
Но при таком способе програмисты полностью не исчезали, из них оставались в професии те, кто знает все уровни програм вплоть до регистров. Как и тут в тексте:
Умение разобраться в том, как всё устроено «под капотом», вскоре станет редкой и крайне востребованной экспертизой на рынке, переполненном операторами нейросетей.
Т.к. оставалась основная проблема - производительность. Код хоть и будет надёжным, но не будет эфективным, и жывые програмисты это должны решыть, т.е. кому надо - нёс бы свою програму такому програмисту.
Но теперь мне кажетса, што и они тоже в опасности, т.к. как видим - люди готовы терпеть медленные програмы. А там, где таки нужна скорость, там "оператор" может попросить ускорить нужное место, и нейросети-агенты или быстро подберут алгоритм, или же могут это сделать дольше брутфорсом.
Тогда действительно останутса самые-самые хардкорные редкие прогеры. Такие, как сейчас прогают микроконтролеры или компиляторы, штобы работали серверы с агентами-оптимизаторами.
Belarus
14.03.2026 03:05Вспомнил, што вообще-то текущим ИИ сложно даётса творчество, создание чево-то новово, неизвестново. Обычным людям агенты пока недоступны (?), поэтому пока сужу только по доступным мне ДипСику и Гроку.
Задача, которую они не смогли решыть:
Windows, консольная програма. Надо, штобы при перетаскивании файла в окно консоли програма провела действия над ним без нажатия Enter или чево-либо. Например, показала размер этово файла или вывела текстовое сообщение из нево.
Запрещено создавать дополнительные окна и использовать всякие хаки и хуки.
Если сейчас агенты не (с)могут это решыть, то тогда для нас, програмистов, надежда ещё есть.
itGuevara
14.03.2026 03:05обсуждение языка CodeSpeak в подкасте Подлодка
Посмотрел, но показалось, что до 1.0 там еще далеко.
Полагаю, что нужно идти параллельно двумя путями:
DSL для каждого класса ПО
верхнеуровнеывый JS/Java (условно) для каждого языка программирования - возможно единая оболочка, транслирующая верхнеуровневый код в классический язык программирования JS/Java (условно), типа "BPMN Next" (условно)
Подробнее тут
Florelit
Spec-driven-development?