$180 за три дня: история про архитектора, Cursor и пакет орешков

Всем привет, это команда продукта SimpleOne SDLC.

К нам периодически приходят истории от разработчиков — про процессы, инструменты, про то, как что-то пошло не так. Одну из таких историй нам рассказал фронтенд-разработчик из крупной ИТ-компании. Имена изменены, детали размыты. Но все, что вы прочитаете — было.

Один человек и $180

В команде пятеро разработчиков. Договорились попробовать Cursor — AI-редактор, который встраивает языковую модель прямо в IDE. Компания согласилась компенсировать подписку: $20 в месяц на человека.

Через месяц смотрят отчет: трое из команды потратили в сумме $60 за месяц, а один системный архитектор — $180. За три дня.

Что он там делал

Он обнаружил режим Agent в Cursor. Круто же — напиши промпт, нажми Enter и просто жди: Cursor сам пишет код, сам читает ошибки из терминала, сам их правит, сам запускает снова. Архитектор скормил редактору дизайн из Figma, исходник старого компонента, написал промпт — и получил таблицу. Потом еще одну, и еще. Руками он не писал ничего. Остальная команда три месяца строила свой модуль.

Когда оба решения оказались рядом, разница была вот такой.

Компонент команды имеет:

• Документацию Storybook

• Документацию JsDoc

• Unit-тесты на каждый модуль 

Компонент архитектора:

• Vanilla JS.

Бизнес доволен. Команда — нет

Созвали встречу с бизнес-аналитиками и генеральным директором, чтобы решить, какое из двух решений идет в продакшн.

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

Потом спросили архитектора про тесты:

— Тесты есть?

— Ну есть.

— Сколько?

— Штук пять.

— Какие метрики используете?

— Спрошу у нейроночки…

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

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

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

Автогенерация и пакет орешков

На следующий день один из разработчиков зашел в офис и увидел такую картину: архитектор сидит за тремя мониторами, на двух из которых генерируется код. Он настроил автоподтверждение изменений — даже нажимать «принять» не нужно. Cursor пишет, архитектор ест орешки из пакетика и смотрит на экраны.

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

Чем это грозит

Обычный технический долг — «мы написали быстро и знаем, что надо переписать». ИИ-долг устроен иначе: никто не знает, что там происходит, и непонятно, с чего начать разбираться. Из нашего разговора с разработчиком:

«Если появится баг — чинить некому. Документации нет. Только этот человек знает, как оно работает. Придется снова идти в Cursor, скармливать весь код и надеяться, что модель не галлюцинирует. А когда контекст перегружен — она галлюцинирует. Синтетика будет чинить синтетику. Синтетикой.»

Нет типизации, нет тестов, нет диаграмм. Если автор уйдет — баг некому чинить. Если появится новое бизнес-правило — непонятно, куда добавить, чтобы не сломать остальное. Никто не хочет поддерживать код, который он не писал, не понимает и не может безопасно изменить. 

Что с этим делать

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

Мы спросили разработчика: а что бы помогло?

Он ответил коротко: «Договориться до, а не после».

В этом конкретном случае хватило бы одного: перед началом работы зафиксировать стек и минимальные требования к тестам. Если бы архитектор знал, что Vanilla JS и 5 тестов не пройдут ревью — он бы либо настроил Cursor иначе, либо генерировал на TypeScript с самого начала.

Несколько вещей, которые помогают: 

1. Важно не столько выбирать между Ask- и Agent-режимом, сколько правильно выстраивать работу с ИИ: использовать его как инструмент для поиска решений, разбирать и осмыслять ответы, а не просто просить сделать всё за вас и копировать результат без анализа.

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

   

3. Ну и тесты: 6 против 300 — это фактически отсутствие сетки безопасности.

Открытый финал

Архитектор все еще в Cursor. Код генерируется. Бизнес все также доволен — прогресс виден, таблица кликается. Команда все также недовольна — они продолжают делать свое. Два решения существуют параллельно. Пока.

Так кто прав? Бизнес, который хочет результат сейчас — и получает его, пусть и ценой черного ящика в продакшне? Или команда, которая строит медленно, но строит то, что можно понять, изменить и передать дальше? Делитесь своими историями в комментариях.

На момент публикации оба решения всё ещё живут параллельно. Мы обновим статью, когда узнаем, чем это закончилось.