원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
После того как инструменты искусственного интеллекта проникли в продакшн-код, ландшафт репозиториев изменился. Согласно исследованию компании GitClear, занимающейся анализом данных программных репозиториев, которая изучила более 211 миллионов строк продакшн-кода в период с 2020 по 2024 год, показатель Code Churn (доля кода, который изменяется или полностью удаляется в течение двух недель после слияния) вырос с исходных 3.1% до 7.1%. Эмпирический анализ платформы для код-ревью CodeRabbit также показывает, что код, созданный искусственным интеллектом, порождает на 1.7 больше дефектов на пулл-реквест, чем код, написанный человеком. Дефекты бизнес-логики возникают в 75 процентах случаев, пропуски обработки исключений — в 2 раза чаще, а уязвимости безопасности — в 2.74 раза чаще. Исследование SmartBear показывает, что как только размер изменений в одном пулл-реквесте превышает 400 строк, процент обнаружения дефектов ревьюером падает ниже 70 процентов. Постраничное чтение сотен строк кода, созданного джуниорами, как раньше, вызывает когнитивную перегрузку и в конечном итоге приводит к игнорированию критических структурных дефектов.
Чтобы разрушить узкое место ручного ревью, старшие инженеры-лиды должны перестать играть роль проверяющих синтаксис и действовать как системные архитекторы. Рассматривайте пулл-реквест как непроверенный бинарный файл, выданный компилятором, и запустите протокол архитектурной проверки для оценки структурной целостности всего за 10 минут. В первые 3 минуты сопоставьте поставленные задачи в тексте с Diff Delta — списком реально измененных файлов. Если в нем присутствуют модули или файлы конфигурации, не упомянутые в описании, не читая детальный код, немедленно отклоните его. В течение следующих 4 минут проверьте наличие нарушений границ доменов: не проникает ли уровень представления напрямую в базу данных, минуя бизнес-сервисы. В оставшиеся 3 минуты следите за тем, сможет ли система выдержать сбои внешних API или состязания за консистентность, с точки зрения гарантии ключей идемпотентности и отката распределенных транзакций. Создайте поле для логов архитектурных решений и исходных промптов в файле .github/pull_request_template.md репозитория, и даже не открывайте Diff для кода, в котором не указаны альтернативные проектные решения.
Прежде чем человек начнет читать код целиком, необходимо отсечь все ошибки, которые может определить машина. Интегрировав инструмент семантического код-ревью CodeRabbit в 285 репозиториев, японская финтех-компания freee сэкономила 32.8 недели ресурсов старших ревьюеров всего за 6 месяцев и зафиксировала 54-процентный показатель принятия указаний на важные дефекты. Уведомления о ревью отправляются старшим разработчикам только для пулл-реквестов, прошедших трехэтапные автоматические фильтры, что сокращает время ручной проверки вдвое.
В CI-пайплайн необходимо встроить последовательные проверочные фильтры. На первом этапе, детерминированном статическом анализе, запускаются ESLint, Biome и Ruff, чтобы повысить уровень предупреждений линтера до ошибок и зафиксировать цикломатическую сложность на функцию на уровне не выше 15. На втором этапе, строгой типизации и архитектурных инвариантов, в файле tsconfig.json включается strict: true, а с помощью dependency-cruiser предотвращаются неавторизованные обходные вызовы слоев. На третьем этапе семантического код-ревью с помощью LLM подключаются CodeRabbit или Qodo для отлова дефектов P1, P2 и пропущенных тестов. Если предыдущий этап не пройден на 100 процентов, переход к следующему этапу или назначение человеческого ревьюера блокируется полностью.
При внедрении агентов искусственного интеллекта в монолитную структуру или устаревшую кодовую базу происходит загрязнение контекста, когда модель игнорирует существующие общие утилиты и дублирует их независимые реализации. Поскольку подход с одним корневым файлом .cursorrules по мере роста проекта чрезмерно пожирает контекст модели, следует использовать модульную структуру .cursor/rules/*.mdc. Поскольку MDC-файлы внедряются условно только тогда, когда целью работы является определенный шаблон файлов, это сокращает потребление токенов более чем на 40 процентов и максимизирует уровень соблюдения правил.
Для сохранения целостности ключевого домена необходимо принудительно заблокировать директории. Создайте файл .cursor/rules/core-boundaries.mdc в корне проекта и сделайте ключевые директории, такие как src/core/ledger/**, доступными только для чтения с настройкой alwaysApply: true. Добавьте .cursor/rules/api-contracts.mdc, чтобы при работе со слоем API запретить удаление полей существующих схем ответа и принудительно использовать классы доменных исключений. Зарегистрируйте .env* и историю миграций в .cursorignore, чтобы в зародыше пресечь сканирование конфиденциальной информации моделью. Дублирование утилит агентом исчезает более чем на 90 процентов.
Когда джуниор поручает искусственному интеллекту написание модульных тестов, покрытие строк превышает 90 процентов, однако возникают скрытые сбои — тесты не ловят баги в ключевой бизнес-логике. Единственный способ убедиться, что тесты работают должным образом — измерить мутационный балл, определяющий, смогут ли тесты обнаружить намеренно внедренные дефекты кода и вызвать сбой.
Внедрите фреймворк мутационного тестирования Stryker в CI-пайплайн. Создайте файл stryker.config.json в корне проекта, добавьте src/domains/**/*.ts в пункт mutate, а затем установите значение thresholds.break на уровне 70. Добавьте команду npx stryker run --since origin/main в рабочий процесс GitHub Actions .github/workflows/mutation-gate.yml для инкрементной проверки только измененного кода. С 15:00 до 18:00 каждую пятницу прекращается разработка нового функционала и внимание сосредоточено на удалении выживших мутантов и консолидации дублирующегося кода. Если мутационный балл нового кода оказывается ниже 70 процентов, пайплайн немедленно выдает ошибку и блокирует слияние.
Самая большая проблема в процессе внедрения искусственного интеллекта — это разрыв между пассивностью старших разработчиков и слепой зависимостью младших. Компания Shopify придерживается принципа, согласно которому, даже если 95 процентов кода написала языковая модель, инженер, чье имя указано в пулл-реквесте, несет стопроцентную ответственность за каждую строку. Лиды должны запустить процедуру разрушения слепой веры джуниоров и передачи ноу-хау по внедрению контекста.
Для выравнивания навыков промпт-инжиниринга у джуниоров еженедельно проводятся 30-минутные интенсивные клиники. В течение первых 10 минут, когда джуниор вместе со старшим разработчиком делится экраном по тикету спринта и дает указания агенту, наблюдают, не задает ли он расплывчатые требования. В следующие 10 минут старший разработчик демонстрирует контекстную инженерию, накладывая правила обработки ошибок проекта и уровень изоляции транзакций в качестве ограничений во время ввода промпта. В последние 10 минут учат не получать от искусственного интеллекта единственный правильный ответ, а сравнивать несколько архитектурных паттернов и переспрашивать о пропущенных граничных условиях в виде тест-кейсов. После прохождения этого процесса уровень ошибок в промптах у джуниоров снижается более чем на 60 процентов.
