Почему история cursed — это не просто мем?
Большинство «шутливых» языков программирования быстро забываются. Их создают ради развлечения: чтобы удивить сообщество или посмеяться над индустрией.
Но cursed оказался другим случаем.
На первый взгляд это выглядит как интернет-мем. Вместо привычных ключевых слов используются выражения из сленга поколения Z. Цикл for превращается в bestie, объявление функции — в slay, а переменные создаются через sus.
Например:
slay greet(name) {
lowkey("Hello " + name);
}
bestie (sus i = 0; i < 5; i++) {
greet("world");
}
Код выглядит абсурдно. Но главное здесь — не синтаксис.
Главное — способ создания.
Проект появился как эксперимент разработчика Джеффри Хантли, который решил проверить, насколько современные большие языковые модели способны помогать в разработке программных инструментов. В качестве основного помощника использовалась модель Claude от Anthropic.
За несколько месяцев появился полноценный open-source проект:
- собственный синтаксис;
- парсер;
- транслятор;
- документация;
- примеры программ;
- рабочий репозиторий.
Именно это сделало cursed заметным событием для индустрии.
Что такое язык cursed?
cursed — экспериментальный язык программирования с синтаксисом, стилизованным под интернет-сленг поколения Z.
Проект опубликовал разработчик Джеффри Хантли.
Идея проста:
Взять язык в стиле Go/JavaScript и заменить стандартные ключевые слова сленгом.
Например:
- for → bestie
- function → slay
- var → sus
- if → ready
- print / log → lowkey
Под мемной оболочкой скрывается вполне реальная инженерная задача.
Чтобы язык работал, необходимо:
- Разбирать исходный код на токены.
- Проверять синтаксис.
- Строить абстрактное синтаксическое дерево.
- Преобразовывать код в исполняемую форму.
- Обрабатывать ошибки.
Именно здесь начинается самая интересная часть истории.
Как ИИ участвовал в создании проекта?
Хантли рассказывал, что использовал Claude как постоянного соавтора проекта.
Модель помогала:
- генерировать части компилятора;
- предлагать синтаксис;
- исправлять ошибки;
- писать тесты;
- создавать документацию.
Важно понимать: ИИ не «самостоятельно придумал язык».
Архитектурные решения, постановка задачи и проверка результата оставались за человеком.
Но скорость итераций оказалась впечатляющей.
Раньше создание даже небольшого DSL — предметно-ориентированного языка — часто требовало недель ручной работы:
- написания грамматики;
- настройки парсера;
- тестирования;
- исправления конфликтов.
Современные LLM резко снижают порог входа.
Разработчик может описать желаемый синтаксис обычным текстом:
«Сделай язык в стиле Go, но замени ключевые слова сленгом поколения Z».
После чего модель генерирует черновой прототип.
Дальше начинается цикл:
- человек тестирует;
- находит ошибки;
- формулирует замечания;
- ИИ вносит изменения.
Именно этот процесс многие инженеры называют AI-first разработкой.
Почему проект оказался важным для индустрии?
Сам язык cursed вряд ли будут использовать в серьёзной коммерческой разработке.
Но проект показал нечто более важное:
Большие языковые модели начали уверенно работать с инфраструктурным кодом
Ещё несколько лет назад считалось, что ИИ хорошо подходит только для:
- автодополнения;
- шаблонного кода;
- простых функций;
- документации.
Компиляторы и парсеры относились к категории сложных инженерных систем.
Причина проста:
- строгая логика;
- множество edge-case сценариев;
- высокая чувствительность к ошибкам.
Однако современные модели всё чаще способны генерировать:
- AST-структуры;
- лексические анализаторы;
- PEG/BNF-грамматики;
- транспайлеры;
- DSL-инструменты.
Именно поэтому история cursed вызвала обсуждение не только среди любителей мемов, но и среди профессиональных разработчиков.
Что реально умеют современные LLM?
После появления cursed в сети начали появляться заявления вроде:
- «ИИ уже полностью заменил компиляторщиков»;
- «Через пару лет языки будут создавать кнопкой»;
- «Человек больше не нужен».
Это сильное преувеличение.
Сегодняшние модели действительно хорошо справляются с:
- генерацией шаблонных компонентов;
- простыми DSL;
- транспайлерами;
- тестами;
- синтаксическими преобразованиями.
Но они всё ещё испытывают сложности при работе с:
- сложными оптимизациями;
- системами типов;
- безопасностью памяти;
- многопоточностью;
- производительностью backend-компиляторов.
Создать аналог LLVM или GCC исключительно силами LLM пока невозможно.
Поэтому корректнее говорить не о замене инженеров, а о серьёзном ускорении части процессов.
Почему DSL и внутренние языки станут массовыми?
Именно здесь проект cursed может оказаться предвестником больших изменений.
Исторически создание собственного языка внутри компании было дорогим удовольствием.
Даже небольшой DSL требовал:
- специалистов по компиляторам;
- времени;
- поддержки.
Теперь ситуация меняется.
Команда может описать:
«Нужен язык для описания отчётов в человеческом стиле».
После чего LLM помогает создать:
- синтаксис;
- парсер;
- генератор SQL;
- документацию.
Это резко снижает стоимость создания специализированных инструментов.
Именно поэтому многие эксперты считают, что ближайшие годы приведут к росту количества внутренних DSL.
Почему разработчики одновременно смеются и нервничают?
Реакция сообщества на cursed оказалась показательной.
С одной стороны:
- мемы;
- шутки;
- видео-разборы.
С другой — заметное беспокойство.
Потому что инженеры увидели:
ИИ уже способен участвовать не только в написании приложений, но и в создании инструментов разработки.
Если модель умеет:
- генерировать парсер;
- строить AST;
- создавать транслятор;
- писать тесты;
- поддерживать документацию,
то это меняет требования к профессии.
Роль разработчика постепенно смещается:
от ручного написания большого объёма инфраструктурного кода
к:
- проектированию;
- архитектуре;
- проверке;
- управлению качеством.
Может ли ИИ создавать небезопасные компиляторы?
Это один из самых обсуждаемых вопросов.
Любой компилятор — критически важный инструмент.
Ошибка в нём способна:
- повредить данные;
- создать уязвимость;
- привести к нестабильной работе программы.
Главная проблема современных LLM:
они умеют генерировать код, но не всегда способны строго доказывать его корректность.
Особенно опасны:
- скрытые edge cases;
- ошибки в оптимизациях;
- проблемы безопасности.
Именно поэтому большинство специалистов сходятся в следующем:
ИИ сегодня ускоряет разработку компиляторов, но не отменяет необходимость человеческой проверки.
cursed — хороший пример такого подхода.
Человек оставался главным контролирующим звеном:
- проверял результат;
- запускал тесты;
- анализировал ошибки.
Как может выглядеть разработка через 5 лет?
Сегодня типичный процесс создания инструмента постепенно меняется.
Раньше:
- Человек проектирует.
- Человек пишет код.
- Человек тестирует.
- Человек документирует.
Теперь всё чаще появляется другая схема:
- Человек описывает задачу.
- ИИ генерирует черновой прототип.
- Человек проверяет.
- ИИ исправляет.
- Человек принимает архитектурные решения.
Это не означает исчезновение программистов.
Но это означает изменение роли.
В ближайшие годы особенно востребованными могут стать специалисты, которые умеют:
- комбинировать ИИ-инструменты;
- быстро проверять гипотезы;
- анализировать качество генерации;
- строить архитектуру сложных систем.
Главный вывод из истории cursed
Сам язык, вероятно, останется нишевым экспериментом.
Но его значение в другом.
Проект показал:
- большие языковые модели уже умеют работать с инженерной инфраструктурой;
- создание DSL и транспайлеров становится дешевле;
- скорость прототипирования резко растёт;
- профессия разработчика меняется прямо сейчас.
Сегодня ИИ помогает создавать экспериментальные языки.
Завтра — специализированные инструменты для бизнеса.
А послезавтра, возможно, целые программные платформы будут рождаться из текстового описания требований.
Не автоматически.
Не без ошибок.
Но значительно быстрее, чем ещё несколько лет назад.
Итог
cursed — это не конец профессии разработчика и не революция в программировании.
Но это важный сигнал.
Большие языковые модели уже перестали быть просто «умным автодополнением».
Они постепенно становятся полноценным инструментом инженерной разработки.
И вопрос уже не в том, будут ли ИИ участвовать в создании языков программирования.
Вопрос в другом:
насколько быстро индустрия научится безопасно и эффективно использовать эти возможности.
Вопрос для обсуждения:
Стоит ли доверять ИИ создание критически важных инструментов вроде компиляторов и системных библиотек — или такие проекты всегда должны проходить ручную инженерную проверку?