Да, тут мне стоило сформулировать аккуратнее: не “модель гарантированно копирует сложные решения 1-в-1”, а “модель иногда может дословно воспроизводить фрагменты из обучающей выборки”. В ML это обычно обсуждают как memorization / training data extraction.
У нас был забавный случай в компании: два разработчика независимо принесли одинаковый 1-в-1 метод чтения файла строк на 30. Один открыто пользовался Claude Code, второй сначала не признавался, потом тоже признался. Это конечно не доказывает, что метод был именно из обучающей выборки — возможно, одинаковый контекст дал одинаковый boilerplate. Но подтверждает суть проблемы: автор не всегда знает/понимает происхождение кода, под которым подписывается.
Поэтому запрет ИИ сам по себе дыру не закрывает: человек, скопировавший кусок со стэковерфлоу или гитхаба, создаёт тот же риск. Нужны ответственность автора + сканеры лицензий/совпадений.
Не уверен, что согласен с частью про “унизительность”. Прогнать CI, линтеры, тесты и получить красный/зеленый статус — это не унижение, а обычная инженерная проверка. Код-ревью ведь тоже не считается унизительным само по себе.
Унизительным может быть тон, с которым дают фидбэк на код ревью: если агент (а еще унизительнее, если человек) напишет “ваш PR мусор, уходите”, это плохой процесс. Но если он говорит “не проходит форматирование / нет теста / нарушено правило архитектуры / нужно поправить вот эти места” — это ровно та же обратная связь, которую дал бы человек, только без траты его времени. Причём агента, если его нормально настроить, как раз проще удержать в нейтральном тоне, чем случайного уставшего ревьюера.
С тем, что OSS держится на людях и общении согласен. Но общаться на современных скоростях разработки интереснее уже после того, как PR хотя бы собрался, прошёл базовые проверки и не выглядит как “нагенерил и бросил”. Тогда и разговор будет предметным :)
Собственно, это и есть мой главный тезис: бороться надо не с фактом использования ИИ, а с некачественным результатом. Если человек с ИИ в руках приносит шлак — его должен отсечь процесс/CI/ревью. Если человек с ИИ в руках приносит хороший, проверенный, поддерживаемый патч — мне кажется странным отклонять его только из-за инструмента.
Про fork — да, это всегда вариант. Но проблема в том, что большинству проектов не нужны десятки форков “как правильно”, им нужен управляемый способ принимать полезные изменения в основной проект, не сжигая внимание мейнтейнеров. Вот здесь и возникает вопрос: фильтровать людей/инструменты или формализовать требования к коду.
Добавлю ещё такую проблему: при найме тимлида извне компании зачастую сами не понимают, какой набор навыков им нужен и какие задачи они хотят закрыть. В итоге почти все компании ищут "играющего тренера" (как же меня бесит эта формулировка), собеседуют его по технике как синьор+, а затем он ~70%* времени занимается пипл менеджментом, целеполаганием и прочими делами, которые у него могли даже не спросить на собеседовании.
* "Половина руководителей пишет код или занимается другой инженерной работой. Большинство занимается этим в пределах трети своего времени." (source: https://devcrowd.ru/tl23/profession/ )
Автор совершенно не понимает, как в 2021 году работают лейблы.
"Однако есть подозрение, что до музыкантов доходит лишь часть этих средств — например, лоу-фай лейбл Strange Fruits делится с ними лишь третью доходов, хотя в этой нише принято распределять заработки в равных долях."
Откуда такое подозрение? С чего автор решил, что в нише принято распределять заработок со стримов в равных долях?
Согласен, получилось немного неоднозначно из-за того, что слово «students» было переведено буквально. Но тем не менее если дочитать до конца (см. последний параграф), то становится понятно, что речь идет о тех людях, для которых Лидия выступала наставником.
Уточнил перевод, спасибо.
Привет, есть проблема: смог собрать apk, но не могу никак настроить resources files, IDEA не видит их. Сори, что пишу здесь, не нашел нигде ответа и ваших контактов тоже, чтобы спросить лично. Может кто помочь?
В этой статье я не буду делать сильный акцент на Java
Я не хочу показаться каким-то «хейтером», но на мой взгляд надо было прямо так и написать, что в этой статье не будет ничего ни про Java ни про Android тем более.
И что за странная мода пошла на хабре такая, дробить цельную статью на мелкие части без видимых на то причин?)
А прочитанная статья на хабре для вас имеет значимость? =) Я считаю, что изложить свои мысли на бумаге, а затем прочитать их не есть что-то плохое, наоборот, помогает структурировать свою идею и преподнести ее другим.
Да, тут мне стоило сформулировать аккуратнее: не “модель гарантированно копирует сложные решения 1-в-1”, а “модель иногда может дословно воспроизводить фрагменты из обучающей выборки”. В ML это обычно обсуждают как memorization / training data extraction.
У нас был забавный случай в компании: два разработчика независимо принесли одинаковый 1-в-1 метод чтения файла строк на 30. Один открыто пользовался Claude Code, второй сначала не признавался, потом тоже признался. Это конечно не доказывает, что метод был именно из обучающей выборки — возможно, одинаковый контекст дал одинаковый boilerplate. Но подтверждает суть проблемы: автор не всегда знает/понимает происхождение кода, под которым подписывается.
Поэтому запрет ИИ сам по себе дыру не закрывает: человек, скопировавший кусок со стэковерфлоу или гитхаба, создаёт тот же риск. Нужны ответственность автора + сканеры лицензий/совпадений.
Не уверен, что согласен с частью про “унизительность”. Прогнать CI, линтеры, тесты и получить красный/зеленый статус — это не унижение, а обычная инженерная проверка. Код-ревью ведь тоже не считается унизительным само по себе.
Унизительным может быть тон, с которым дают фидбэк на код ревью: если агент (а еще унизительнее, если человек) напишет “ваш PR мусор, уходите”, это плохой процесс. Но если он говорит “не проходит форматирование / нет теста / нарушено правило архитектуры / нужно поправить вот эти места” — это ровно та же обратная связь, которую дал бы человек, только без траты его времени. Причём агента, если его нормально настроить, как раз проще удержать в нейтральном тоне, чем случайного уставшего ревьюера.
С тем, что OSS держится на людях и общении согласен. Но общаться на современных скоростях разработки интереснее уже после того, как PR хотя бы собрался, прошёл базовые проверки и не выглядит как “нагенерил и бросил”. Тогда и разговор будет предметным :)
Всё так.
Собственно, это и есть мой главный тезис: бороться надо не с фактом использования ИИ, а с некачественным результатом. Если человек с ИИ в руках приносит шлак — его должен отсечь процесс/CI/ревью. Если человек с ИИ в руках приносит хороший, проверенный, поддерживаемый патч — мне кажется странным отклонять его только из-за инструмента.
Про fork — да, это всегда вариант. Но проблема в том, что большинству проектов не нужны десятки форков “как правильно”, им нужен управляемый способ принимать полезные изменения в основной проект, не сжигая внимание мейнтейнеров. Вот здесь и возникает вопрос: фильтровать людей/инструменты или формализовать требования к коду.
Добавлю ещё такую проблему: при найме тимлида извне компании зачастую сами не понимают, какой набор навыков им нужен и какие задачи они хотят закрыть. В итоге почти все компании ищут "играющего тренера" (как же меня бесит эта формулировка), собеседуют его по технике как синьор+, а затем он ~70%* времени занимается пипл менеджментом, целеполаганием и прочими делами, которые у него могли даже не спросить на собеседовании.
* "Половина руководителей пишет код или занимается другой инженерной работой. Большинство занимается этим в пределах трети своего времени." (source: https://devcrowd.ru/tl23/profession/ )
Автор совершенно не понимает, как в 2021 году работают лейблы.
"Однако есть подозрение, что до музыкантов доходит лишь часть этих средств — например, лоу-фай лейбл Strange Fruits делится с ними лишь третью доходов, хотя в этой нише принято распределять заработки в равных долях."
Откуда такое подозрение? С чего автор решил, что в нише принято распределять заработок со стримов в равных долях?
Уточнил перевод, спасибо.
Я не хочу показаться каким-то «хейтером», но на мой взгляд надо было прямо так и написать, что в этой статье не будет ничего ни про Java ни про Android тем более.
И что за странная мода пошла на хабре такая, дробить цельную статью на мелкие части без видимых на то причин?)