Разработка
June 3

Я придумал формат для ИИ — и выкинул его через полгода

Framix я веду один. Фронтенд, бэкенд, DevOps, поддержка, маркетинг — в свободное время, поверх учёбы и работы. Каждое решение стоит моего времени, а не чужого. Именно поэтому особенно неприятно, когда одно из самых проработанных решений приходится разобрать.

Расскажу, как это вышло.


Как выглядел план

Framix начинался как конструктор сайтов. Визуальный редактор, блоки на холсте, абсолютное позиционирование — у каждого элемента свои координаты x/y. Я программировал движок раскладки: свободный, пиксель в пиксель.

Потом была долгая война с адаптивностью. Абсолютно спозиционированные элементы на мобилке — это боль. Я провозился с геометрией и алгоритмами переключения дольше, чем хотел бы признавать. Разобрался. Нарастил библиотеку блоков, дизайн-системы, палитры.

Ключевой момент настал, когда редактор научился отдавать страницу как JSON. Структура, где каждый блок описан целиком — тип, координаты, размеры, стили, вложенность, контент. Я формализовал собственный язык описания страниц.

Раз есть структурированный JSON со строгой схемой — ИИ можно его выучить. Логика казалась железной: модель генерирует JSON, редактор подхватывает напрямую, никаких промежуточных шагов, никаких потерь. Уникальный формат как конкурентное преимущество.

Я написал спецификацию. Учил модель, бился с галлюцинациями, подбирал параметры. Генерация начала работать — страницы получались красивыми. Был доволен. Редкий случай, когда что-то работало именно так, как задумывал.


Число, которое всё изменило

Потом я запустил счётчик токенов.

40 000. Только инструкции. Только спецификация формата — ещё до первого блока с контентом пользователя.

Каждый запрос к API нейросети начинался с сорока тысяч токенов накладных расходов. Юнит-экономика не просто «дорогая» — она не работала. При масштабировании каждый новый пользователь усугублял картину.

Несколько дней я ходил вокруг этого числа.

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

В какой-то момент я заметил, что делаю. Я не искал лучшее решение для пользователя. Я придумывал, как сохранить своё любимое архитектурное решение.

Это разные вещи.


Почему больно выбрасывать то, во что вложился

У инженеров (у меня точно) есть паттерн: чем больше вложено в решение, тем сложнее его менять. Не потому что менять невозможно — потому что больно признавать, что можно было проще.

Признак ловушки простой: начинаешь оптимизировать под сохранение решения, а не под решение задачи.

Задача была — дать пользователю красивую страницу быстро и дёшево. Задача не была «научить ИИ моему уникальному JSON». Я перепутал инструмент с целью.

Это случается не только в коде. Маркетолог влюбляется в кампанию, потому что долго над ней работал. Продукт-менеджер продолжает двигать фичу, потому что она уже в роадмапе. Основатель не меняет подход, потому что «на это ушли месяцы».

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


Что я сделал

Выпилил весь JSON-движок генерации. Перешёл на HTML.

Не потому что это проще строить. Потому что модели не нужна моя спецификация. HTML в интернете — миллиарды примеров в обучающих данных. Мой JSON-формат — ни одного примера, кроме тех, что я показал в промпте. Модели и так умеют генерировать HTML: хорошо, стабильно, с минимумом токенов на инструкции.

Я сделал HTML-редактор: видишь готовую страницу — правишь мышкой, двигаешь узлы, меняешь содержимое. AI-чат внутри генерит и правит точечно по запросу. Под капотом честный HTML, а не схема, которую надо объяснять модели заново на каждый запрос.

Генерация подешевела кратно. Стабильность выросла. Добавлять новые шаблоны и блоки стало проще.

Старый JSON-движок я не выбросил — выложил на GitHub (framix-builder-core). Может, кому-то пригодится архитектура визуального редактора с абсолютным позиционированием. Сам в него больше не смотрю.


Про ИИ в продуктах — конкретно

Из этой истории я вынес проверку, которую теперь применяю при каждом следующем AI-решении.

Когда встраиваешь ИИ в продукт, есть соблазн сделать что-то фирменное: свой протокол, свою схему, свой язык. Иногда это оправданно — когда задача действительно уникальная и модель не справится без специализации. Но сначала стоит задать честный вопрос: может, модель уже умеет делать то, что нужно, просто на другом языке?

Обратная инженерия обучающих данных — недооценённый приём при проектировании промптов. Если у модели уже есть миллиарды примеров в нужном формате, зачем объяснять ей новый?

Мне потребовалось столкнуться с 40 000 токенов накладных расходов, чтобы задать этот вопрос себе всерьёз.

Ответ оказался простым. Модели умеют HTML. Это и есть «мой уникальный формат» — только бесплатный, уже выученный и без 40 тысяч токенов в системном промпте.