Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 6
Проблема в том, что юниты проверяют только то, что Cursor только что написал, а не то, что он сломал по пути в соседних модулях, контрактах и интеграциях.
И что? То, что ломается в других модулях, ловится тестами этих модулей и пул-реквест их ломающий нельзя замержить.
Cursor любит «поумничать» — переписать старый рабочий код «по-современному».
А ревьюверы почему пропустили это и не развернули вернуть назад работающий код?
а интеграция с легаси-модулем или внешним сервисом падает.
Интенграционных тестов у вас нет?
Интеграционные API-тесты и E2E никто не обновляет автоматически — их пишут люди, а людей на это не выделили.
Всетаки есть. А значит они должны поймать, что интеграция сломалась, разве нет? И зачем их обновлять если АПИ не менялось?
А если АПИ поменялось, как можно пропустить пул реквест который меняет АПИ и не создает интеграционные тесты для измененного АПИ?
Честно говоря, я не вижу в чем именно у вас виноват курсор. Больше похоже на организационные проблемы. Можно просто нанять новых людей и получить все те же самые проблемы.
А ревьюверы почему пропустили это и не развернули вернуть назад работающий код?
Код ревью это больше про социализацию разработчиков в команде и обмен знаниями. На ревью обычно не проверяют валидность самого решения - это ответственность автора. Оценивается общая адекватность и следование каким-то принятым в команде стандартам, которые сложно формализовать. По умолчанию считается, что специально лажу ни кто писать не будет. Ошибки выбиваются из общей канвы. Поэтому они хорошо заметны и ревью не отнимает много времени.
LLM хорошо следуют паттернам (особенно если они задокументированы), код на выходе смотрится стройно и убедительно. Но фактически может делать ерунду. Такие изменения ревьювать гораздо сложнее. Как если бы у вас в команде был злодей, который сознательно пытается всех запутать.
По хорошему, в отношении AI-generated кода нужно включать 0-trust режим, используя практики Security Code Review с чеклистами в сотню пунктов, - но это будет кратно дольше и дороже. А Cursor'ы ведь не для этого внедряют.
следование каким-то принятым в команде стандартам, которые сложно формализовать
Угу. Когда команда маленькая, стандарты размытые и не формализованные. Однако чем больше людей работает над одним кодом, тем больше формальностей, типа, код нарезается на участки с выделенными codeiwner-aми, чтоб замержиться, обязательно аппрув овнера, что автоматически приводит к более мелким пул-реквестам, ибо большой на десятки файлов это боль из-за необходимости получить аппрув от множества людей. Ну и если код рефакторится, необходимо либо отдельный тикет на рефакторинг, либо в комментариях пул-реквеста расписать почему именно он рефакторинг здесь так необходим. Формальзуются разные уровни тестов, формализуется цикл фиче флагов, тикетов на тех долг и тд.
Все эти формальности тормозят и мешают маленьким командам, но для больших становятся важными чтоб избегать проблем описанных в статье, не важно, используется ии в разработке, или нет.
дел. Не туда
Думаю, что упор на том, что важна не только скорость написания кода, но и его стабильность актуальна как никогда. Курсор может подсобить в том, что бы на него можно было спихнуть часть рутинных задач, но люди с огромным опытом разработки на проекте просто необходимы, иначе это приведет только к тому, что это станет источником дополнительных проблем, ввиду отсутствия здравого смысла
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cursor и ИИ-ассистенты ускоряют разработку — но без нормальных автотестов топят всю команду