Проект markus появился как демонстрация возможностей вайб-кодинга: разработчик Райан попросил Claude Opus 4.5 написать single-header библиотеку для парсинга Markdown и конвертации в HTML. Результат — один файл markus.h на 6484 строки C++20. Сам автор честно предупреждает в README: «DO NOT USE IN PRODUCTION» — библиотека не проходила ревью на безопасность памяти, а производительность уступает эталонному парсеру cmark в 2–3 раза.
Внешне код производит сильное впечатление. Здесь есть подсказки компилятору через атрибут [[unlikely]], условная компиляция с if constexpr, табличные алгоритмы для быстрой классификации символов, контейнеры из std::pmr для управления памятью и функции с пометкой SIMD-friendly. Для неподготовленного читателя это выглядит как работа опытного системного программиста. Именно в этом и состоит ловушка.
Разбор функции IsSpanBlank — показательный пример. Комментарий обещает, что код написан так, чтобы компилятор мог векторизовать его с помощью SSE-инструкций: внешний цикл обрабатывает данные блоками по 8 байт, внутренний проверяет каждый байт на принадлежность к пробельным символам. На практике байты всё равно проверяются последовательно, один за другим. Вложенный цикл не создаёт никаких условий для векторизации — он просто разворачивает итерацию вручную без какого-либо выигрыша. Упрощённая версия той же функции с одним циклом была бы идентична по производительности, но читалась бы в разы проще.
Автор проекта сам предупреждает: не использовать в продакшене, производительность на 2–3× хуже cmark.
Чтобы компилятор действительно применил SIMD-инструкции (SSE, AVX), данные должны быть выровнены в памяти, а операции над несколькими элементами — выражены через интринсики или специальные структуры данных. Простой вложенный цикл с условными проверками этого не обеспечивает. ИИ воспроизвёл форму оптимизированного кода, не воспроизведя её содержание.
Отдельная история — табличные алгоритмы. Четыре таблицы по 256 элементов записаны в коде построчно: каждое значение на отдельной строке. Это добавляет около 1000 строк к общему объёму файла и не несёт никакой технической необходимости — компилятор одинаково обработает и компактную, и развёрнутую запись. Статический анализатор PVS-Studio при проверке проекта не выдал критичных предупреждений, что могло бы создать ложное ощущение надёжности кода.
Автор разбора, специалист по статическому анализу из команды PVS-Studio, формулирует более широкую проблему: ИИ хорошо справляется с локальными задачами и умеет имитировать стиль экспертного кода, но не удерживает архитектурную картину целиком. Роберт Мартин в своих заметках об ИИ-разработке писал примерно о том же: без надзора модель нагромождает код поверх кода, не имея представления о большой картине. Архитектурное мышление пока остаётся за пределами её возможностей.
Для C++ это особенно критично: язык выбирают именно тогда, когда нужна максимальная производительность и контроль над памятью. Если цель не достигнута — задача не решена, независимо от того, кто писал код. Вайб-кодинг не отменяет требований к качеству: к такому коду применимы те же процессы проверки, что описаны в SSDLC и стандарте РБПО. Ревью кода становится не менее важным навыком, чем умение его писать, — возможно, даже более важным.
