Всем привет, это команда продуктаSimpleOne SDLC.
К нам периодически приходят истории от разработчиков — про процессы, инструменты, про то, как что-то пошло не так. Одну из таких историй нам рассказал фронтенд-разработчик из крупной ИТ-компании. Имена изменены, детали размыты. Но все, что вы прочитаете — было.
Один человек и $180
В команде пятеро разработчиков. Договорились попробовать Cursor — AI-редактор, который встраивает языковую модель прямо в IDE. Компания согласилась компенсировать подписку: $20 в месяц на человека.
Через месяц смотрят отчет: трое из команды потратили в сумме $60 за месяц, а один системный архитектор — $180. За три дня.
Что он там делал
Он обнаружил режим Agent в Cursor. Круто же — напиши промпт, нажми Enter и просто жди: Cursor сам пишет код, сам читает ошибки из терминала, сам их правит, сам запускает снова. Архитектор скормил редактору дизайн из Figma, исходник старого компонента, написал промпт — и получил таблицу. Потом еще одну, и еще. Руками он не писал ничего. Остальная команда три месяца строила свой модуль.
Когда оба решения оказались рядом, разница была вот такой.
Компонент команды имеет:
- Документацию Storybook
- Документацию JsDoc
- Unit-тесты на каждый модуль
Компонент архитектора:
Бизнес доволен. Команда — нет
Созвали встречу с бизнес-аналитиками и генеральным директором, чтобы решить, какое из двух решений идет в продакшн.
Команда к тому моменту три месяца писала отдельный модуль компонентов: TypeScript, код-ревью, 300 unit-тестов, покрытие минимум 85% — иначе в продакшн не попадает. Все задокументировано, все проверено. Архитектор за это время через Cursor сгенерировал свой вариант — живой прототип, который можно кликать и скроллить, с большим количеством функций.
Потом спросили архитектора про тесты:
— Тесты есть?— Ну есть.— Сколько?— Штук пять.— Какие метрики используете?— Спрошу у нейроночки…
То есть, архитектор, в общем-то, и сам особо не в курсе, что происходит у него в коде. Но не суть: бизнес-аналитикам нужен был результат, а не метрики — и у архитектора он был прямо сейчас. Получается, команда сделала меньше видимого, хотя делала надежнее.
Команда три месяца строила идеальный фундамент — а бизнесу нужен был работающий дом вчера. Мой код в проде, их — нет. Тесты можно дописать потом, рынок ждать не будет.
Команда отказалась переносить свою работу в решение архитектора: стек отличается, код написан на JavaScript вместо TypeScript. Архитектор считал, что они просто тратят время — у него уже есть рабочая форма, зачем ждать еще? Все остались при своем, и в итоге в одном проекте появились два параллельных решения одной задачи, которые никак не пересекались.
Команда (3 месяца)
Архитектор (3 дня)
TypeScript
Vanilla JS
300, покрытие 85%
Документация
Storybook + JSDoc
Стоимость инструмента
$60/мес на троих
$180 за 3 дня
Поддерживаемость
Любой в команде
Только автор + Cursor
Видимый результат для бизнеса
Модуль компонентов
Кликабельный прототип
Bus factor
1 (и тот не понимает свой код)
Автогенерация и пакет орешков
На следующий день один из разработчиков зашел в офис и увидел такую картину: архитектор сидит за тремя мониторами, на двух из которых генерируется код. Он настроил автоподтверждение изменений — даже нажимать «принять» не нужно. Cursor пишет, архитектор ест орешки из пакетика и смотрит на экраны.
За три дня он сгенерировал больше кода, чем команда написала за три месяца. Бизнес видит прогресс, дедлайны соблюдаются, формально все работает. Но вот вопрос: когда инструмент берет на себя не только рутину, но и само мышление — это все еще продуктивность? Или разработчик уже стал зрителем, но пока просто этого не заметил?
Чем это грозит
Обычный технический долг — «мы написали быстро и знаем, что надо переписать».ИИ-долгустроен иначе: никто не знает, что там происходит, и непонятно, с чего начать разбираться. Из нашего разговора с разработчиком:
«Если появится баг — чинить некому. Документации нет. Только этот человек знает, как оно работает. Придется снова идти в Cursor, скармливать весь код и надеяться, что модель не галлюцинирует. А когда контекст перегружен — она галлюцинирует. Синтетика будет чинить синтетику. Синтетикой.»
Нет типизации, нет тестов, нет диаграмм. Если автор уйдет — баг некому чинить. Если появится новое бизнес-правило — непонятно, куда добавить, чтобы не сломать остальное. Никто не хочет поддерживать код, который он не писал, не понимает и не может безопасно изменить.
Что с этим делать
Запрещать Cursor — не вариант, ведь инструмент хороший, и проблема-то не в нем. Мы вSimpleOne SDLCчасто видим одно и то же: компании внедряют AI-инструменты быстро, а процессы под них — нет. Потом удивляются, что кодовая база стала неуправляемой.
Мы спросили разработчика: а что бы помогло?Он ответил коротко: «Договориться до, а не после».
В этом конкретном случае хватило бы одного: перед началом работы зафиксировать стек и минимальные требования к тестам. Если бы архитектор знал, что Vanilla JS и 5 тестов не пройдут ревью — он бы либо настроил Cursor иначе, либо генерировал на TypeScript с самого начала.
Несколько вещей, которые помогают:
- Важно не столько выбирать между Ask- и Agent-режимом, сколько правильно выстраивать работу с ИИ: использовать его как инструмент для поиска решений, разбирать и осмыслять ответы, а не просто просить сделать всё за вас и копировать результат без анализа.
- Код-ревью остается ключевым этапом — просто с учётом AI-контента важно внимательнее относиться к архитектурным решениям, консистентности и соответствию принятым стандартам. И сами стандарты лучше зафиксировать заранее: стек, паттерны, требования к тестам — иначе ИИ будет принимать эти решения за вас.
- Ну и тесты: 6 против 300 — это фактически отсутствие сетки безопасности.
Открытый финал
Архитектор все еще в Cursor. Код генерируется. Бизнес все также доволен — прогресс виден, таблица кликается. Команда все также недовольна — они продолжают делать свое. Два решения существуют параллельно. Пока.
Так кто прав? Бизнес, который хочет результат сейчас — и получает его, пусть и ценой черного ящика в продакшне? Или команда, которая строит медленно, но строит то, что можно понять, изменить и передать дальше? Делитесь своими историями в комментариях.
На момент публикации оба решения всё ещё живут параллельно. Мы обновим статью, когда узнаем, чем это закончилось.
