В начале было слово. И слово было в чате. Вы задавали вопросы, ИИ генерил код. Этот код то работал, то не работал. Но чтобы это проверить, надо было вручную копипастить и запускать его. Было не очень удобно, но все равно круто! А потом кто-то приделал чату руки — tools —и появились ИИ-агенты.
Это выглядело уже совсем магически: ты говоришь агенту, что нужно, а он выкатывает тебе готовое приложение. С легкой руки Андрея Карпатого такой стиль программирования стали называть вайбкодингом. И развелось этих вайбкодеров видимо-невидимо. На первых порах все были счастливы: «Вы только посмотрите, что я вчера навайбкодил! И оно работает! Разве это не чудо?»
Когда восторги немного улеглись, пришло осознание, что ИИ-шечка неплохо справляется только с простыми задачами — запилить небольшой сайт, игру, что-нибудь автоматизировать для личных нужд. Это делалось действительно на вайбе — ты только накидываешь идеи, а оно само как-то генерится. А как пошли серьезные проекты, то выяснилось, что с полпинка ничего не получается. Что агенту надо долго и нудно объяснять, что от него требуется и только тогда может что-нибудь получится. А может и нет.
Вайбы кончились
Тем не менее, от самой идеи, что агент должен создавать работающий код по описанию задачи на естественном языке, не отказались. Стали обвешивать LLM скиллами, правилами и прочей «упряжью» — harness. Стали готовить все более подробные спецификации, ввели этап планирования перед непосредственно генерацией кода.
Теперь, прежде чем кинуть задачу агенту, приходилось подолгу скрипеть мозгами и сочинять спеку, чтобы он в итоге написал то, что нужно, а не фантазировал. В общем, вайбы кончились, пошла обычная инженерная работа, только с новыми инструментами. Даже слово новое придумали — агентский кодинг. Типа теперь все по-взрослому.
«Так что же, вайбкодинг облажался?» — с надеждой спросят ИИ-скептики, — «Не дождетесь!» — скажем мы им. Да, задача оказалась сложнее, чем это виделось сначала. Однако, и польза вполне ощутима.
Есть очень много вещей, которые агенты делают практически идеально и это экономит уйму времени разработчику: SQL-запросы, регулярные выражения, сериализация в JSON и обратно, REST API, экспорты-импорты и всю прочую шаблонную рутину. Попробовав раз, вы уже никогда не захотите вручную лабать штук двадцать DTO-шек и заниматься тому подобной ерундой.
Также, весьма недурно агент справляется с задачей, когда у него есть образец — будь то один класс или целое приложение. А вот когда выходим на оперативный простор и надо создавать архитектуру с чистого листа, тут агент может начудить, если предоставить ему полную свободу творчества.
Например, может запихнуть всю бизнес-логику в один огромный класс тыщи на две строк. Работать-то это будет, но как потом поддерживать? Или вдруг решит, что вам какой-то модуль не нужен и удалит его. Истинного вайбкодера это не остановит, но если вам за код платят и его надо сдавать заказчику, то так дело не пойдет.
В поисках секрета трансмутации
Средневековые алхимики верили, что можно превратить свинец в золото — если у вас есть философский камень. И часто посвящали его безуспешным поискам всю свою жизнь. Так и вайбкодеры верят, что можно превратить обычные слова в код, только найти такой формат, чтобы агент в точности мог реализовать ваш замысел.
Исходная посылка выглядит правдоподобной: у нас есть один текст на обычном человеческом языке, надо преобразовать его в другой текст на языке программирования, который будет компилироваться и выполняться.
Ведь мы так всегда и делали: бизнес-аналитик приносил ТЗ на человеческом языке, а разработчик вручную переводил его в код.
Надо всего лишь автоматизировать этот процесс перевода и золотой ключик у нас в кармане! А кто, как не LLM сегодня лучше всех умеет работать с текстами и с легкостью переводит их на любые языки? Вот ей и карты в руки. Не получается с ходу, так значит надо лучше стараться, искать волшебные слова, которые заставят модель это сделать.
Что ж, определенный и немалый прогресс есть. Кодинг-агенты становятся все умнее и умнее, их код все хорошеет и хорошеет, как Москва. Люди строят системы из множества агентов, которые по идее должны работать как команда живых разработчиков, архитекторов и аналитиков и по заданной спецификации создавать безупречные приложения. Отчасти это работает. Если агенту дать четкую инструкцию, то он действительно может написать почти то, что вы задумали. Ключевое слово здесь «почти» — точное попадание практически невероятно, какой бы хитрый промпт вы ни сочинили.
Решаема ли эта задача в принципе — трансмутация текста на обычном языке в код? Или апологеты вайбкодинга так и состарятся в бесплодных попытках найти этот секретный ингредиент?
Семиотика дает ответ
И ответ этот отрицательный. Семиотика недвусмысленно нам говорит, что это иллюзия, будто бы можно написать спецификацию, по которой агент построит в точности то, что было задумано. Она возникает из скрытого предположения, что спецификация — это кодирование смысла без потерь. Но в реальности это не передача смысла, а семиотическая цепочка трансформаций.
Когда-то давно попалась мне в руки книга Умберто Эко «Отсутствующая структура». Я думал, что это очередной роман умнейшего итальянца, а оказалось, научный труд по семиотике. Честно скажу, целиком не осилил, но что-то в голове осталось. И это имеет прямое отношение к нашей теме вайбкодинга.
Слова —это знаки для вещей или абстракций, неважно. Значение знака не лежит внутри него готовым грузом, который можно просто передать от одного сознания к другому. И это ломает наивную модель коммуникации
мысль → слова → мысль
Слово имеет значение потому, что занимает определенное место среди других знаков. Мы понимаем «день» через его отличие от «ночи», «большой» — через отличие от «маленький», «отец» — через систему родственных отношений. Поэтому невозможно взять и придумать универсальный набор знаков, в котором каждому знаку будет навсегда присвоено одно значение.
Но и это еще не все. Теперь появляется интерпретатор — тот, кто смотрит на знак. Человек или LLM. Он привносит в понимание знака свой опыт и ощущения.
Это не означает, что люди (и агенты) не могут понимать одни и те же знаки. Но это будет работать всегда в каком-то ограниченном случае — слова русского языка, синтаксис Java, медицинская терминология. Это всегда локальная семиотическая система. И она всегда требует интерпретации. Ее нужно постоянно поддерживать, обучать новых участников, обновлять правила, если нужно.
Здесь стоит обратиться к идее «открытого произведения» Эко: текст допускает пространство интерпретаций, но это не означает, что интерпретировать его можно, как угодно. Между полной однозначностью и полной произвольностью существует огромное поле ограниченных интерпретаций.
И возвращаемся к теме про агентский кодинг: harness может сужать пространство интерпретаций, но не превратить знак в его означаемое. То есть, агент не выполняет ваши инструкции в том смысле как их выполняет калькулятор — строго по правилам. Агент эти правила интерпретирует, и потом уже действует. В том числе, иногда нарушает. Или так старается, что выходит только хуже. Не стремитесь добиться полной детерминированности поведения агента, это ловушка.
Например, мы пишем в спецификации: «Пользователь может отменить заказ.»
Потом уточняем: «Заказ можно отменить только в статусах A и B.»
Потом: «В статусе A отмена доступна всегда, в B — только до момента X.»
Потом: «При отмене в статусе B необходимо...»
Вроде бы мы все больше закрываем пространство интерпретаций.
И если детализировать все дальше и дальше, то кажется, что все-таки можно дать агенту исчерпывающее задание. Но при этом спецификация сама станет практически кодом.
Я склоняюсь к мысли, что бесконечная детализация задачи для агента не просто раздувает контекст, она еще съедает ваше время и не факт, что гарантирует лучший результат.
Нужно больше DSL, хороших и разных
Окей, примем, что действительно невозможно создать универсальный механизм, который будет так управлять работой агента, чтобы получать результат в точности по спецификации. — Расходимся?
Отнюдь. Можно взглянуть на ситуацию под другим углом: нам же никто не запрещает создавать системы знаков для различных частных случаев, да?
Собственно, мы этим занимаемся уже давно. Называется это DSL — domain-specific language, предметно-ориентированный язык.
И вот здесь есть важный момент. Мы не можем построить универсальный язык, однозначно выражающий любые замыслы разработчика. Зато можем построить язык, в котором определенный класс замыслов выражается существенно точнее. Чем уже предметная область, тем меньше пространство интерпретаций. Чем лучше определена семантика языка, тем меньше агенту приходится додумывать.
Вот, например, SQL — язык для работы с реляционными данными. Вы бы видели, какие нечеловечески красивые SQL-запросы пишут агенты, когда рассказываешь им обычными словами, что добыть из базы! И, как правило, это сразу нормально работает.
Скептики будут в шоке: «Вы хоть представляете себе, во что выльется разработка нового языка под каждую задачу? И что потом с ним делать? Нужен ведь еще софт, который его понимает. Это годы времени и миллионы долларов.»
Действительно, раньше, если кто-то хотел создать DSL для какой-нибудь узкой предметной области, то нужно было сначала спроектировать язык, придумать синтаксис и семантику, написать грамматику, парсер, валидатор, интерпретатор или генератор кода, сделать tooling, документацию. Даже если сам язык был маленьким, инфраструктура вокруг него могла стоить дороже, чем решаемая им задача.
Поэтому DSL имели экономический смысл только там, где предметная область была достаточно большой и стабильной.
Если тупо экстраполировать прошлый опыт, то ситуация далеко не радужная. Тот же SQL прошел путь от идеи до стандарта где-то за 15 лет. Ни один вайбкодер такого не переживет. Но есть и хорошие новости!
Кодинг-агент как раз отлично справляется с подобными задачами разработки языков, они для него практически нативные. То есть, благодаря ИИ сроки и стоимость разработки DSL радикально снизилась. Теперь становится экономически возможным создавать языки для гораздо более узких областей.
Вернемся к нашему примеру с отменой заказа. На естественном языке это звучит так:
«Заказ можно отменить, пока его еще не начали отправлять».
DSL для него получился бы примерно таким:
cancellation { allowed_when status in [CREATED, PAID] forbidden_when status in [SHIPPED, DELIVERED] }
— А не фантазирует ли автор на ровном месте? — Нисколько. Вот, смотрите сами:
· Programming with Representations (PwR), Microsoft Research, 2023
· Custom programming languages make agents really, really good, 2026
· Anka: A Domain-Specific Language for Reliable LLM Code Generation, 2026
· Text2DSL: LLM-Based Code Generation for Domain-Specific Languages, 2026
· DSLs Enable Reliable Use of LLMs, 2026
Все статьи говорят примерно об одном:
DSL делает пространство решений для LLM меньше и тем самым повышает надежность.
LLM потенциально делает дешевле саму реализацию DSL.
В результате возникает положительная обратная связь:
дешевый AI-кодинг ↓ становится выгоднее создавать узкоспециализированные языки ↓ DSL ограничивает пространство интерпретаций агента ↓ агенты лучше работают с DSL ↓ создание специализированного ПО становится еще дешевле ↓ появляется экономический смысл делать еще более узкие DSL
Так что DSL для агента это вполне себе тренд.
Заключение
Однако, не стоит обольщаться. DSL не решает семиотическую проблему. Универсального языка для спецификаций все равно создать нельзя и нельзя однозначно и исчерпывающе написать постановку задачи для агента на естественном языке.
Но можно довольно успешно решать частные задачи, создавая для них свои языки, которые будут понятны и людям, и агентам.
Если даже мы наперед знаем, что найти философский камень нельзя, это не значит, что не надо его искать. Сам поиск может принести нам множество открытий. Ну и что с того, что алхимики не научились превращать свинец в золото? Они не очень-то и хотели. В одной из алхимических рукописей говорится, что изготовление золота — лишь самая незначительная цель алхимии.
На самом деле они искали способ сделать несовершенное совершенным.
А эта цель никуда не делась, можно продолжать к ней идти.
Подпишитесь на канал Agentic Enterpise — о жизни ИИ-агентов в кровавом энтерпрайзе
