Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 18
Да, проблема очень актульна. Лично я работаю по принципу ревью на входе. Юзаю Zed, но без AI. Вообще. А по коду просто советуюсь с ИИшками (несколькими и разными по одной и той же задаче, для сверки), но код пишу сам. Либо копирую советуемый код если внешне выглядит годно, но после этого прохожусь по нему руками строка за строкой. Это не пиар; я действительно думаю, что это единственный разумный вариант сейчас.
По сути ты делаешь то что в статье Kapwing делают на уровне процесса - человек остаётся в петле на каждом шаге. Сверка с несколькими моделями кстати хороший приём, я сам так делаю когда не уверен в архитектурном решении - если две модели предлагают разное, значит задача неоднозначная и надо думать самому. Строка за строкой конечно замедляет, но зато ты понимаешь что у тебя в проде. А по данным из статьи это ровно то место где большинство команд срезают
Вот придурки) это я про тех, кто стал 11 PR фигачить, вместо 3. Вас же забьют задачами, раз вы справляетесь быстрее! Я наоборот, делаю примерно столько же, сколько и до ИИ, но щас я стал спокойне брать большую задачу, потому что знаю, что рутиный код она спокойно напишет, а я пока разберусь с задачей, позадаю вопросов бизнесу, поспрашиваю другую команду, если код связан с ними, подумаю как лучше реализовать… потом мы только пишем. И время на само тестирование на Деве осталось больше, качественней задача получается.
ну да)) тот чувак с 11 PR по сути переложил свою скорость на двух сеньоров-ревьюеров и создал им ад. А ты наоборот забрал сэкономленное время себе на этап до кода. И это как раз то что по данным работает - Kapwing из статьи тоже не стали фигачить больше PR, они стали закрывать мелкие баги автоматом а людей отправили думать. По-моему твой подход ближе к тому как AI реально помогает - не “больше кода за день” а “лучше подготовленная задача”
2-4 файла на коммит. Ну, так и поставьте такую кипиайку иишке. ) Пускай переходит в режим: "Миша, всё херня - переделывай!". А как выполнит кпэ, тогда и будем сравнивать "скорость написания адекватного кода" у неё и у человека. ;)
Идея норм, но тут ловушка - агент-то послушается, он формально разобьёт. Только 2-4 файла на коммит это не KPI а симптом. Если архитектура такая что любое изменение трогает 12 файлов, агент начнёт делать 3 коммита по 4 файла и каждый из них будет ломать прод по отдельности.
Метрика работает как диагностика, а не как ограничение - если git log показывает 8+ файлов, это значит что модули слиплись, и чинить надо модули, а не коммиты
Сопровождаемость имеет значение. Лиды и сеньоры раньше тратили время на то, чтобы:
PR занимал меньше строк кода. В идеале, если удаётся удалить больше старого легаси-кода, чем добавить нового - это показатель хорошего PR.
Код был разбит так, чтобы последующие изменения были атомарными. Здесь мы руководствуемся принципами Clean Code, SOLID, GRASP. Не всегда это даёт производительный код, но его сопровождаемость увеличивается.
Был соблюдён общий стиль кода, нэйминга и компоновки модулей.
Эти подходы приводили к тому, что в проде задачи на фичи делались быстро. Доставка кода в прод - моментальная. Сокращалось время тестирования и CR.
К сожалению, сопровождаемость трудно замерять. Скорость доставки фич в прод - один из показателей сопровождаемости, как и количество багов на PR. Однако, сейчас все сходят с ума по количеству строк кода, которые генерирует AI. По количеству задач, переданных в ревью. Хорошо, есть компании, где задача не считается закрытой до мержа PR как минимум в dev. А то и до доставки в тестовую среду. Если, конечно, не находится какой-нибудь продуктовый инженер, и не убеждает руководство в том, что нужно замерять количество строк кода в каждой ветке.
Про “удалить больше чем добавить” - это прям хороший индикатор, жаль что я его в статью не включил. По сути это ещё одна выходная метрика которую никто не считает когда хвалятся AI-продуктивностью. AI генерирует, он не удаляет. А хороший PR часто именно удаляет.
С сопровождаемостью сложнее - ты прав что её трудно замерять напрямую. Но косвенно она вылезает в том самом verification debt из статьи. Когда каждая AI-сессия пихает логику куда удобно прямо сейчас, без оглядки на SOLID, через полгода любое изменение трогает полпроекта.
И время на фичу растёт не потому что разработчик тупой а потому что код слипся
На прошлой работе интереса ради смотрел на статистику +- в гите. Корреляция была отличная. У топов минус преобладал над плюс. А у одного разработчика, чей код меня очень сильно напрягал, был почти один плюс, с минусом, близким к нулю.
Это ситуационно. Если мы говорим о новом компоненте, то, скорее-всего, код растёт. В АПИшках, вообще, добавление нового эндпоинта будет порождать кучу новых сущностей: модели и схемы данных, миграции, методы репозиториев, валидаторы, фильтры, сервисы/юз-кейсы. Ещё сверху добавятся интерфейсы. Прикол в том, что ИИ сделает это «в лоб». То есть, будет повторение кода, будут условные операторы вместо разделения интерфейсов. Будут непонятные связи в коде. Можно, конечно, разделить задачу для ИИ, заставив оптимизировать код. Можно сразу спроектировать все сущности и написать промпты для их создания. Но это не даст +150% к объёму создаваемого кода. Разработка будет быстрее, чем руками, но медленней, чем ИИ-соло. В этом ИИ походит на разработчика, который стремится решить задачу, но не соблюдает code-style и принципы/соглашения.
Когда мы пишем код, мы приходим к консенсусу между сопровождаемостью и эффективностью решения. Зачастую, лишние интерфейсы, инверсия зависимостей, обилие схем негативно влияют на скорость выполнения программы, а также, на количество занимаемой памяти. Однако, это гарантирует нам лёгкость изменений, их атомарность. Уменьшает связанность компонентов. Устраняет риски возникновения инцидентов. Зачастую, нам всё-равно: будет эндпоинт исполняться 50 мс или 20 мс в асинхронном коде, с обращением в кэш или базу, при нескольких тысячах RPS. А вот стоимость изменения и надёжность имеют наивысший приоритет. И в этих условиях крайне важно, чтобы новые фичи, если они похожи на существующие, поставлялись с уменьшением кодовой базы. Чем меньше кода, тем дешевле обслуживание. Но, при этом, если фича требует добавление кода, он должен быть добавлен. Вопрос в том, чтобы эта производная не давала слишком большой рост. Сдерживание роста кодовой базы - одна из основных задач инженеров на проекте. То есть, мы все понимаем что база кода будет расти. Наша задача минимизировать этот рост в разумных пределах. А если он случился, то обеспечить низкую связанность кода.
В статье нет другой важной метрики: количества инцидентов. Баги - это одно. Но вот я слышал от знакомых, которые проводят ревью вайб-кода, что количество инцидентов с развитием участия ИИ в разработке растёт. Порой настолько, что люди не успевают тушить пожары. Баги могут быть разными: не все приводят к конкретным проблемам доступности системы или изменению функциональности. Многие баги считают на этапе тестирования. То есть, они влияют на скорость T2M, а не на пост-деплоймент обслуживание.
Что касается роста кодовой базы, то это безумие - считать её рост развитием проекта. Таски, как я понял, стали закрывать до релизов, чтобы отчитаться о внедрении ИИ. Этот рост закрытых задач не говорит об успешной доставке фичи в прод. Фича должна пройти тестирование прежде, чем состоится релиз. По сути, из хвалёной продуктивности мы имеем только повышение скорости написания кода. Частично, рост выполненных за единицу времени задач (тех, которые, всё-таки, считают по факту доставки в прод). В остальном, имеем снижение сопровождаемости, увеличение количества багов на релиз, замедление T2M и увеличение количества инцидентов (пока о последнем сужу по слухам).
Фишка что incident rate идёт с большим лагом (пол-года у нас типично) так что разработчик успевает уволиться (но у нас все работают давно). А по стоимости дальнейшего сопровождения кода лаг ещё больше.
Вы правы. Вчера думал над вашим заявлением. Действительно, «лаг» - это точное описание временной задержки между деплойментом в продакшен и наступлением времени для сбора метрик.
Потенциал сопровождаемости, кстати, оценивается на месте. Мы можем сделать предиктивную оценку сопровождаемости, либо получить фактическую оценку сопровождаемости. Они могут различаться, но в человеческом коде - не сильно. Обычно, связанность видно сразу. Как и нарушение SOLID принципов. По ИИ коду не могу гарантировать что оценка и факт будут сходными. У ИИ много скрытых проблем в коде. Когда модель выбирает неожиданное решение, мы, как правило, доверяем ей, думая о том, что ИИ зачастую идёт отличным от человека путём. Но часть этих решений оказываются ошибочными и приводят к проблемам в будущем.
Сам факт сопровождаемости, на примере стартапов, появляется через год после запуска MVP, в среднем.
А теперь, смотрите, что я надумал, пока анализировал ваш полугодовой лаг по инцидентам. У нас синьоры по пол года сидят без работы после сокращения. Я слышу от людей, что им требуется сменить профессию. Эта усталость от профессии мне знакома: ты работаешь в своём грейде, берёшь на себя ответственность, выполняешь поставленные задачи. А потом раз, и ты на улице просто потому что! И ты начинаешь всё с начала. Ты выясняешь, что на рынке есть люди, которые врут. Они врут что работают, врут, что имеют положительные отзывы от руководителя. И тебе не верят: это там коллеги ходили к тебе за помощью, а твой начальник благодарил тебя за труд. А здесь ты - никто, и звать тебя никак. И, разумеется, рождается желание уйти туда, где проще и понятнее. Быть плотником или маляром. Варить пиво или делать кофе с такой красивой пенкой цветочком. А в последний год я слышал, что ведь уходят из профессии. Интересно, что и мошенники тоже уже доят с рынка: благодаря их стараниям, работодатель снижает условия. Устроиться становится всё тяжелей. А через пол года - год мы ожидаем отдачу по неразумной эксплуатации ИИ.
Что же я вижу? ИТ специальности остаются нужными, востребованными. Но через год мы ожидаем кризис: код от ИИ уже составляет 150% от того, что производил за единицу времени человек до ИИ. А ждём 200%, а то и 300%. При этом, мы прекрасно понимаем, что уже на 150% рост багов - в половину. Скорость доставки кода - почти в два раза медленнее. Количество инцидентов пока никто не замерял, но подозреваю, что будет в два, а то и в три раза больше. На эти показатели влияет, в том числе, активный набор мошенников - удобных и понятных приятных людей с минимальными знаниями и ИИ бэкграундом. При этом, толковые люди уходят из профессии, а менторство джунов мертво. То есть, получается, что ИТ при смерти. Мы ожидаем, что через год не будет обслуживаемого кода, общее качество ИТ проектов будет низким, и будет огромный дефицит людей, которые могут это исправить. Людей будет гораздо меньше, чем проектов и кода, которые насоздавала машина. И всё из-за лага. Это отложенный эффект, который, скорее-всего, поднимет зарплаты и условия айтишников на недосягаемый уровень. Потому, что есть ещё такая вещь как «совокупная стоимость владения». И убытки приходят к бизнесу тоже с лагом. Если обладание информационной системой будет вызывать убытки, то люди, способные остановить этот процесс деградации, будут цениться на вес золота.
Мне скорее интересен факт того, насколько сложнее эти инциденты решаются: когда у автора кода / его коллеги отсутствует хоть какая-та ментальная связь с написанным в его проекте коде, совершенно не ясно как без нее оперативно решить серьезный инцидент, не сидя, читая AI код несколько часов)
"Коллеги" утверждают, что основная стратегия решения инцидентов, связанных с багами в коде - это переписывание компонента с нуля. У них остаётся промт для полного написания компонента, и они вносят изменения в него, чтобы исправить проблему. К сожалению, я не уточнял у них: как быстро они переписывают систему с сотней компонентов или более? Также, не уточнял как они реагируют на инциденты, не связанные с багами в коде? "Коллеги" ведут себя как сектанты, и мне с ними очень трудно общаться.
похоже, что все идет к тому что ии-код люди вообще понимать и ревьювать не будут, возможно и код это будет писаться в нечитаемом для людей формате удобном для ии. а участие людей сведется к бизнес аналитике и ручному тестированию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Галлюцинация продуктивности