Всем привет, это команда продукта 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. Архитектор считал, что они просто тратят время — у него уже есть рабочая форма, зачем ждать еще? Все остались при своем, и в итоге в одном проекте появились два параллельных решения одной задачи, которые никак не пересекались.
Команда (3 месяца) |
Архитектор (3 дня) |
|
|---|---|---|
Стек |
TypeScript |
Vanilla JS |
Тесты |
300, покрытие 85% |
~5 |
Документация |
Storybook + JSDoc |
Нет |
Стоимость инструмента |
$60/мес на троих |
$180 за 3 дня |
Поддерживаемость |
Любой в команде |
Только автор + Cursor |
Видимый результат для бизнеса |
Модуль компонентов |
Кликабельный прототип |
Bus factor |
5 |
1 (и тот не понимает свой код) |
Автогенерация и пакет орешков
На следующий день один из разработчиков зашел в офис и увидел такую картину: архитектор сидит за тремя мониторами, на двух из которых генерируется код. Он настроил автоподтверждение изменений — даже нажимать «принять» не нужно. Cursor пишет, архитектор ест орешки из пакетика и смотрит на экраны.
За три дня он сгенерировал больше кода, чем команда написала за три месяца. Бизнес видит прогресс, дедлайны соблюдаются, формально все работает. Но вот вопрос: когда инструмент берет на себя не только рутину, но и само мышление — это все еще продуктивность? Или разработчик уже стал зрителем, но пока просто этого не заметил?
Чем это грозит
Обычный технический долг — «мы написали быстро и знаем, что надо переписать». ИИ-долг устроен иначе: никто не знает, что там происходит, и непонятно, с чего начать разбираться. Из нашего разговора с разработчиком:
«Если появится баг — чинить некому. Документации нет. Только этот человек знает, как оно работает. Придется снова идти в Cursor, скармливать весь код и надеяться, что модель не галлюцинирует. А когда контекст перегружен — она галлюцинирует. Синтетика будет чинить синтетику. Синтетикой.»
Нет типизации, нет тестов, нет диаграмм. Если автор уйдет — баг некому чинить. Если появится новое бизнес-правило — непонятно, куда добавить, чтобы не сломать остальное. Никто не хочет поддерживать код, который он не писал, не понимает и не может безопасно изменить.
Что с этим делать
Запрещать Cursor — не вариант, ведь инструмент хороший, и проблема-то не в нем. Мы в SimpleOne SDLC часто видим одно и то же: компании внедряют AI-инструменты быстро, а процессы под них — нет. Потом удивляются, что кодовая база стала неуправляемой.
Мы спросили разработчика: а что бы помогло?
Он ответил коротко: «Договориться до, а не после».
В этом конкретном случае хватило бы одного: перед началом работы зафиксировать стек и минимальные требования к тестам. Если бы архитектор знал, что Vanilla JS и 5 тестов не пройдут ревью — он бы либо настроил Cursor иначе, либо генерировал на TypeScript с самого начала.
Несколько вещей, которые помогают:
Важно не столько выбирать между Ask- и Agent-режимом, сколько правильно выстраивать работу с ИИ: использовать его как инструмент для поиска решений, разбирать и осмыслять ответы, а не просто просить сделать всё за вас и копировать результат без анализа.
-
Код-ревью остается ключевым этапом — просто с учётом AI-контента важно внимательнее относиться к архитектурным решениям, консистентности и соответствию принятым стандартам. И сами стандарты лучше зафиксировать заранее: стек, паттерны, требования к тестам — иначе ИИ будет принимать эти решения за вас.
Кнопка «Запустить ИИ-код ревью» — тот самый этап, на котором ИИ-код перестаёт проходить незамеченным Ну и тесты: 6 против 300 — это фактически отсутствие сетки безопасности.
Открытый финал
Архитектор все еще в Cursor. Код генерируется. Бизнес все также доволен — прогресс виден, таблица кликается. Команда все также недовольна — они продолжают делать свое. Два решения существуют параллельно. Пока.
Так кто прав? Бизнес, который хочет результат сейчас — и получает его, пусть и ценой черного ящика в продакшне? Или команда, которая строит медленно, но строит то, что можно понять, изменить и передать дальше? Делитесь своими историями в комментариях.
На момент публикации оба решения всё ещё живут параллельно. Мы обновим статью, когда узнаем, чем это закончилось.
Комментарии (13)
AlekseyPraskovin
28.04.2026 12:06Обычный технический долг — «мы написали быстро и знаем, что надо переписать»
Знаете вы это первые 3 месяца. А потом ключевой знающий уволился, в документацию 100% никто ни строчки не вписал и через год от вашего знания осталась только уверенность, что вы что-то знаете.
AlekseyPraskovin
28.04.2026 12:06Но проблема как всегда не в разработчиках. А в управленцах. Которые позволяют существовать вот такому:
Архитектор все еще в Cursor. Код генерируется. Бизнес все также доволен — прогресс виден, таблица кликается. Команда все также недовольна — они продолжают делать свое. Два решения существуют параллельно
Потому что не хватает ни компетенций, чтобы правильно выбрать, ни яиц, чтобы этот выбор сделать.
Ну и да: если у вас архитектор занят написанием фронтовых формочек - вы делаете что-то не так, ребята...
HotBoom
28.04.2026 12:06Cursor, а конкретно модель GPT 5.4 отлично справляется с документацией. Ее можно скорректировать и использовать как промт чтобы переписать все с нуля на другом стеке.
Zoolander
28.04.2026 12:06Ситуация жизненная, а статья синтетическая. Потому что не описаны реальные проблемы.
Во первых где примеры багов в коде от нейронки. Даже на уровне пользователя у этих систем есть серьёзные баги они к примеру не могут в пиксель перфект.
Во вторых, реалистичная ситуация в таком в случае это увольнение классических программистов. То что вы описываете это какой то нонсенс. Зачем держать команду если архитектор уже поставляет целый продукт. Обычно в две тысячи двадцать шестом это ведёт к тому что либо его код не работает от слова совсем. Либо классические программисты увольняются владельцем бизнеса.
Так что все фигня и верните статью на доработку скажите нейронке придумать нормальные жизненные ситуации
Mausglov
28.04.2026 12:06А мне вот кажется, что кейс вполне реальный, а вы слишком категоричны. Смотрите:
Во первых где примеры багов в коде от нейронки.
Насколько я вижу, речь про продукт для внутреннего употребления. Так что код нам не покажут, увы.
они к примеру не могут в пиксель перфект.
Я бэкендер, но однажды один из наших менеджеров спросил меня "А можно ли из нашей внутренней системы получить вот такой отчёт?". Я посидел день, и сваял прототип: внешний вид там был вырвиглазный, в духе "голый HTML 4.0" , но оно работало.
В итоге бизнес так и пользовался этим прототипом несколько лет. А вы говорите "pixel perfect".Зачем держать команду если архитектор уже поставляет целый продукт.
В статье речь идёт только про один компонент. Может, это даже не 1% всего продукта.
Обычно в две тысячи двадцать шестом это ведёт к тому что либо его код не работает от слова совсем.
Еслы бы он не работал - статьи бы не было. Фокус как раз в том, что оно работает - но, возможно, в гораздо более узком спектре возможностей. Например, на мобильных разъезжается в хлам - но именно бизнес-аналитики из статьи не работают с продуктом на мобильных. Или там инъекции - но пока продукт внутренний, их никто не видит. Или через год бизнес попросит "поправить немножко" - а ИИ перепишет всё в новом интерфейсе, потому что такой интерфейс сейчас на хайпе. И тогда те бизнес-аналитики станут перед выбором: "старый привычный интерфейс, но без нужной фичи" (это если он выживет в каком-то бэкапе. С вайб-подходом может и не выжить) или "переучиваться на новый интерфейс. Вот я уверен, что все поворчат, но переучатся. А через полгода ещё раз.
Дело в точке зрения и целях:
Можно ли этот продукт продать? Скорее всего, нет - слишком рискованно.
Можно ли этот продукт поддерживать? Нет. Максимум - нейронка может его как-то переписывать ( и никто не знает, как).
Можно ли этот продукт использовать? Да.
P.S. я тут подумал, что веселее всего будет, если этот компонент от архитектора начнёт ломать остальную часть системы - например, гадит в глобальную область видимости, или стили переопределяет, или ещё что-то. Архитектор выглядит белым и пушистым ( "у меня всё красиво!" ), а у команды головная боль на ровном месте.
Jacov911
28.04.2026 12:06Ии вроде вполне дописывать свой код уже научился.
Так что новые фичи легко внедрит в старый интерфейс
sergeyssv
28.04.2026 12:06Нейронам генеоят по тому что они знают
Решить новый вопрос они не могут.
Например, они не смогут найти тебе новую телку )
FlyGst
28.04.2026 12:06Слушайте, я не понимаю высказываний "программисты не могут дописывать код от нейронки". Вижу в статьях цифры 20'000 строк...50'000...100'000. Но это же не единым файлом сделано? Вы приходите работать в новую компанию и вас подключают к работе над проектом в 50'000 строк - у вас есть время чтобы разобраться в проекте. Какие то вещи проясняются через отладку. Что-то узнаешь из документации. И это уже задача бизнеса оценивать, сможет ли он оплачивать программиста для поддержки проекта от ИИ.
makssof
28.04.2026 12:06Поддерживаемый код в метриках имеет не только кол-во строк. Пизанскую башню нормально стабилизировали только к 2000м годам, все предыдущее время ее “поддерживали” (не от слова держать, а как код) разными методами на протяжении всей истории. А все почему? Потому что с самого начала были допущены ошибки: фундамент недостаточен, грунт мягок и т.д. Т.е. целая история башни существует из за неправильной разработки вначале.
Dr_Mobius
28.04.2026 12:06-
Метрика «300 тестов» подаётся как достоинство сама по себе. Не «тесты ловят баги», не «тесты позволяют рефакторить» — просто число. Это типичный признак человека, который путает ритуал с результатом.
«Ел орешки» — попытка пристыдить. Но если агент делает работу правильно, то что разработчик должен делать — страдать для приличия? Это морализаторство вместо анализа.
«Bus factor = 1» — подаётся как катастрофа, но команда из 5 человек на TypeScript с JSDoc имеет bus factor… тоже фактически 1-2, потому что реально в чужой компонент никто не лезет. Просто иллюзия размазана на больше людей.
Открытый финал — это вообще трусость. Автор не готов сказать «архитектор был прав» или «команда была права», потому что сам не знает. Но статью пишет с позиции «я объясню вам как надо». Самое смешное — реальный вывод из его же истории: «если один человек с AI за 3 дня делает то, на что команде нужно 3 месяца — пересматривайте не AI, а команду и процессы». Но автор делает ровно противоположный.
-
maksim_sitnikov
28.04.2026 12:06Кто прибыль генерирует тот и прав, через три месяца бизнес уже может хотеть старое выкинуть и получить новое, если быстро растет. А может наоборот, бизнес хочет заниматься созвонами и долгим внедрением - другая бизнес модель, когда деньги не зарабатывают, а осваивают. Мнение лучше узнавать у бизнеса и его потребителей, а не на Хабре.
KSupalo
Менеджмент не прав - вначале договариваются о процессах (кто, что, сколько и как), а потом делают - хоть на десяти мониторах.
Когда сделали без договоренности, нужно провести анализ и передоговориться.
Поэтому сама постановка вопроса не правильная.... Фактически руководство самоустранилось
Evgenii_ESM
очень в точку