Comments 12
Да, проблема очень актульна. Лично я работаю по принципу ревью на входе. Юзаю 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 и увеличение количества инцидентов (пока о последнем сужу по слухам).
похоже, что все идет к тому что ии-код люди вообще понимать и ревьювать не будут, возможно и код это будет писаться в нечитаемом для людей формате удобном для ии. а участие людей сведется к бизнес аналитике и ручному тестированию.
Галлюцинация продуктивности