Cómo Cursor Creó un Prototipo en Tres Días por $180 Que Dividió al Equipo de Desarrollo

В одной крупной ИТ-компании эксперимент с Cursor быстро превратился в спор о том, что важнее: скорость доставки или управляемость кода. Системный архитектор потратил $180 за три дня и показал бизнесу кликабельный результат, пока команда три месяца строила типизированный и покрытый тестами модуль.

Три дня против трех месяцев История началась как обычный пилот AI-инструмента.

В команде было пятеро разработчиков, и компания согласилась компенсировать каждому подписку на Cursor за $20 в месяц. Через месяц цифры выглядели спокойно: трое сотрудников вместе потратили $60. Но затем выяснилось, что системный архитектор израсходовал $180 всего за три дня.

Он использовал Agent-режим, загрузил в редактор макет из Figma, старый компонент и текстовый промпт, а дальше почти не писал код руками. Cursor сам генерировал интерфейсы, читал ошибки в терминале, исправлял их и запускал сборку заново. На другом полюсе была команда, которая три месяца делала свой модуль по классическим правилам.

У них были TypeScript, code review, Storybook, JSDoc и около 300 unit-тестов с покрытием не ниже 85%. Архитектор за это же время получил кликабельный прототип с большим количеством функций, но на Vanilla JS и примерно с пятью тестами. Когда оба варианта поставили рядом, бизнес увидел не дисциплину разработки, а два разных темпа доставки: медленный и надежный против быстрого и эффектного.

Почему победил прототип Решение принимали на встрече с бизнес-аналитиками и руководством.

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

«Тесты можно дописать потом, рынок ждать не будет».

Эта логика и стала точкой разрыва. Команда не захотела переносить свою работу в решение архитектора: там другой стек, почти нет документации и слишком мало проверок. Архитектор, наоборот, считал, что коллеги усложняют процесс и тратят время, хотя рабочая форма уже существует. В результате в одном проекте появились два параллельных решения одной задачи. Формально прогресс есть, но у компании теперь не единая архитектура, а конфликт между скоростью, стандартами и ответственностью за будущую поддержку.

Обратная сторона AI-скорости

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

• Нет единого стека и типизации, на которые рассчитывает команда Почти отсутствуют тесты и документация, значит падает предсказуемость изменений Bus factor стремится к единице: поддержка зависит от одного автора и того же инструмента * Любое новое требование повышает риск сломать код, который никто толком не понимает Авторы кейса не призывают запрещать Cursor. Наоборот, вывод у них практический: проблема не в инструменте, а в отсутствии правил до старта работы. Если бы команда заранее зафиксировала обязательный стек, минимальный набор тестов и формат ревью для AI-сгенерированного кода, спор мог бы не возникнуть. Cursor можно использовать как ускоритель поиска решений, черновиков и прототипов, но не как замену инженерному мышлению. Иначе разработчик начинает не писать систему, а наблюдать, как система пишет себя сама.

Что это значит

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