На Habr разработчик описал, как за один день собрал в Cursor три плагина для Mattermost Team Edition. Кейс показывает полезный сдвиг: небольшие внутренние инструменты, которые раньше могли не пройти по стоимости разработки, теперь стоит хотя бы прототипировать. Но только там, где частичный результат уже полезен, а ошибка не затрагивает критичный контур.
Это не история о том, что AI «написал всё сам». Скорее, это проверка нового порога окупаемости: сколько накопившейся боли можно снять личной инициативой одного разработчика, прежде чем задача успеет превратиться в тикет, проект и вечный пункт бэклога.
Что удалось собрать за день
У команды было три ежедневных неудобства в Mattermost. В канале нельзя было нормально ответить на сообщение, не было видно, прочитал ли его коллега, а для созвона приходилось отправлять ссылку на локальный Jitsi с отдельной авторизацией.
Автор кейса сделал reply с цитатой, статусы доставки и прочтения, а также голосовые комнаты на Pion прямо в server-плагине. Всё это было личной инициативой, а не задачей из бэклога. Коллегам результат понравился.
Для бизнеса здесь важны не сами галочки и цитаты. Важен масштаб работ: три точечных улучшения существующей системы появились за день без миграции на другой мессенджер. Cursor в таком сценарии работает не как замена продуктовой разработке, а как способ быстро проверить, стоит ли конкретная внутренняя боль собственного решения.
До этого выбор оператора выглядел неприятно: терпеть неудобство, ставить задачу в очередь или затевать более крупную замену инструмента. Теперь между этими вариантами появляется микрософт, собранный под локальный процесс. Иногда этого достаточно, чтобы небольшая интеграция начала окупаться.
Быстро собрать не значит закончить
Самое полезное ограничение кейса автор сообщает прямо: плагины не работают в нативных приложениях Mattermost. Значит, однодневный результат закрывает не весь пользовательский сценарий. Если часть команды живёт в таких клиентах, экономия разработки быстро встречается с расходами на совместимость.
Есть и второй пробел. В публикации не посчитано, сколько времени потребуют тесты, ревью, документация, исправления и дальнейшая поддержка. Это не опровергает ценность прототипа, но не позволяет приравнять день сборки к полной стоимости владения.
Ручной контроль начинается ещё до проверки кода. Автор пишет, что задавал AI рамки, и здесь помог его опыт с медиа. То есть скорость появилась не из пустого поля: человек понимал предметную область и мог ограничить пространство решений. Cursor сократил путь от замысла до работающего результата, но сам замысел, архитектурные границы и критерии полезности остались на человеке.
Отсюда и практическая граница. Reply с цитатой можно выпустить частично, собрать обратную связь и исправить. Подход нельзя автоматически переносить на права доступа, платежи и другие контуры, где цена ошибки выше. Этот кейс доказывает скорость прототипирования, но ничего не доказывает о надёжности AI-кода в критичных системах.
Что пересчитать уже сейчас
FDE и внутренним платформенным командам стоит поднять бэклог небольших интеграций и найти задачи с тремя признаками: боль повторяется, решение можно изолировать, а неполное покрытие не ломает основной процесс. Для них однодневный прототип становится разумной единицей эксперимента.
Смотреть дальше нужно не на число строк, написанных Cursor, и не на эффектную демоверсию. Конкретный маркер окупаемости такой: после прототипа команда отдельно считает время на интеграцию, проверку, поддержку клиентов, исправления и сопровождение. Если эти хвосты не съедают выигрыш от быстрой сборки, мелкий внутренний софт действительно стал дешевле. Если съедают, Cursor лишь перенёс работу с начала проекта на его конец.