Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 11
А ИИ, как мы прекрасно понимаем, иногда дословно выплёвывает код, на котором обучались
А можно примеры посложнее hello world и прочих, которые "реальный разработчик" тоже скопирует с SO? А то мне кажется, что любая мало-мальски современная модель уже слишком жирная, чтобы копировать 1-в-1 нестандартные решения.
А иначе получается как в российских ВУЗах: нам пожалуйста 70% уникальности в теме, по которой еще деды писали.
По теме статьи: условный claude code при поиске багов классифицирует их от critical до low. Critical может быть десяток, low - сотни. И если critical это "у вас память течет", то low это "у вас кнопка на 1 пиксель сьехала". В режиме ultracode claude запускает верификаторов в adversarial режиме, т.е. на доказательство того, что бага на самом деле нет. Можно подрядить агентов с той же философией на доказательство того, что баг безобиден (low) и просто их автореджектить. С этим справится и локальная модель, а так вроде openai и anthropic по очереди дают достаточно крупному попенсорсу акции на бесплатное использование их моделей - пользуйтесь.
Да, тут мне стоило сформулировать аккуратнее: не “модель гарантированно копирует сложные решения 1-в-1”, а “модель иногда может дословно воспроизводить фрагменты из обучающей выборки”. В ML это обычно обсуждают как memorization / training data extraction.
У нас был забавный случай в компании: два разработчика независимо принесли одинаковый 1-в-1 метод чтения файла строк на 30. Один открыто пользовался Claude Code, второй сначала не признавался, потом тоже признался. Это конечно не доказывает, что метод был именно из обучающей выборки — возможно, одинаковый контекст дал одинаковый boilerplate. Но подтверждает суть проблемы: автор не всегда знает/понимает происхождение кода, под которым подписывается.
Поэтому запрет ИИ сам по себе дыру не закрывает: человек, скопировавший кусок со стэковерфлоу или гитхаба, создаёт тот же риск. Нужны ответственность автора + сканеры лицензий/совпадений.
Мне кажется, вот эти AI гейты против AI мусора - это, объективно, бред, и ломает геймплей опенсорса, даже, инженерно, решая задачу.
Люди приходят контрибьютить, чтобы делать интересные задачи с интересными людьми. А засовывание их в один конвейер с ботами и унизительные комментарии от ботов превратят это из тусовки себе подобных в гринд.
То есть, сама вот эта идея, что суди код, а не кодера, - она достаточно сомнительная сама по себе. Осс это не олимпиада по программирования, где задача равенства и справедливого определения достойных является определяющей. Тут надо, чтобы всем участникам было в кайф, иначе, никто никого не держит. И, вот эта конструкция, когда гейткиперы, подобно команде дворового футбола, решили, что берём в команду только корешей, ибо они точно не будут творить херни на поле (хотя-бы потому, что им тусить в этой компании завтра, и можно стать тем, с кем более играть не захотят), довольно устойчива, и заставляет игроков приходить и играть каждый день. Трансформация в "перед каждым матчем проводим отбор с пробегом стометровки (в том числе теми, кто ранее играл хорошо, а то, вдруг, не в форме сегодня), битьем 3х пенальти и квизом по тактике футбола" скорее всего приведёт к тому, что только какие-то рандомные залетные играть и будут, а местные пацаны найдут себе другое развлечение
Не уверен, что согласен с частью про “унизительность”. Прогнать CI, линтеры, тесты и получить красный/зеленый статус — это не унижение, а обычная инженерная проверка. Код-ревью ведь тоже не считается унизительным само по себе.
Унизительным может быть тон, с которым дают фидбэк на код ревью: если агент (а еще унизительнее, если человек) напишет “ваш PR мусор, уходите”, это плохой процесс. Но если он говорит “не проходит форматирование / нет теста / нарушено правило архитектуры / нужно поправить вот эти места” — это ровно та же обратная связь, которую дал бы человек, только без траты его времени. Причём агента, если его нормально настроить, как раз проще удержать в нейтральном тоне, чем случайного уставшего ревьюера.
С тем, что OSS держится на людях и общении согласен. Но общаться на современных скоростях разработки интереснее уже после того, как PR хотя бы собрался, прошёл базовые проверки и не выглядит как “нагенерил и бросил”. Тогда и разговор будет предметным :)
OS проекты не борются с AI как таковым. Они борются с потоком шлака, который генерируют люди с AI в руках но без понимания как его использовать.
Обратите внимание каждый может сделать форк OS проекта и показать как правильно работать.
Всё так.
Собственно, это и есть мой главный тезис: бороться надо не с фактом использования ИИ, а с некачественным результатом. Если человек с ИИ в руках приносит шлак — его должен отсечь процесс/CI/ревью. Если человек с ИИ в руках приносит хороший, проверенный, поддерживаемый патч — мне кажется странным отклонять его только из-за инструмента.
Про fork — да, это всегда вариант. Но проблема в том, что большинству проектов не нужны десятки форков “как правильно”, им нужен управляемый способ принимать полезные изменения в основной проект, не сжигая внимание мейнтейнеров. Вот здесь и возникает вопрос: фильтровать людей/инструменты или формализовать требования к коду.
Если кто-то отправил PR на миллион строк, который невозможно отревьюить, очевидно, он и сам его не смотрел. Это ещё может работать с Rust, у которого строгий компилятор и понятные ошибки, но на каком-нибудь C легко нагенерировать код, который будет проходить по всем внешним критериям - статик-чекерам, тестам и т. д., - но упадёт с segfault через две минуты после запуска. Знаем, было.
Несмотря на предварительное использование plan mode и попытки самоаудита агентами собственного кода, Claude с завидной регулярностью правит то, что его не просили, и не видит проблем, пока ты ему явно на них не укажешь. Не говоря уже о том, что он постоянно переписывает свой же код, потому что в основном подгоняет его так, чтобы он работал здесь и сейчас, а при изменении связанных модулей часто может перекроить весь модуль заново.
инструментов и практик прям многовато и за всеми еще следить в плане актуальности, как будто не хватает хотя бы какого-нибудь репо с актуальным списком
Реально какой-то гейкипинг
На мой взгляд, гейткипинг по сути совпадает с обычным наймом. Никто не берёт на должность любого лишь всякого, даже в дворники не каждого возьмут. Гейткипинг ничем не отличается, только вместо официальной позиции человек получает роль в сообществе, уже доказав свою заинтересованность и квалификацию.
Для OSS это особенно важно, просто даже в силу того, что очень много открытых проектов имеют инфраструктурное значение. Демократизация тут не процветание принесёт, а падение качества и безопасности. Кто гарантирует, что в потоке пулл-реквестов хорошо мотивированная сторона не пронесёт зловредный код?
Но просто запрещать ИИ, мне кажется, тоже не совсем правильно. Только тогда на контрибьюторе ответственности больше, уже не только за код, но и за свою бдительность. Что опять же возвращает к полезности гейткипинга, потому что справится с этим всё-таки не каждый.
Понравился блок “Из чего собрать CI-гейт”. Хорошее пошаговое описание что учесть в ии-ревьюере написанного кода.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гейткипинг 2.0: почему open source воюет с ИИ — и что делать вместо этого