Если для так называемой "адаптации" разработчикам KiCad придется выпускать патчи для Wayland, GNOME, KDE и т.д., то ничего удивительного. Думаю, что у них и своих задач хватает по продукту.
Tesla делает ставку на биологическое подражание. Если человек справляется с вождением, используя только зрение и мозг, то машина, оснащённая камерами и ИИ, тем более должна справляться. Маск говорил об этом ещё в 2021: «Люди водят с помощью глаз и биологических нейросетей. Значит, камера и кремниевые нейросети — единственный путь к универсальному автопилоту».
Странный конечно подход. В чём проблема обучать ту же нейросеть данными ещё и с лидара? Зачем себя сознательно ограничивать?
Основная проблема автора, насколько можно понять, заключается в том, что он и бизнес, в лице CEO говорят на разных языках. Доводы для бизнеса также должны быть в рамках, которые могут быть им поняты.
Нет смысла упирать на качество архитектуры проекта, его отлаженность и прочее. Это всё технические термины и менеджеры их могут не понимать или не воспринимать всерьёз. Тут скорее надо указать на потенциальные потери бизнеса когда продакшен встанет колом из-за очередных навайбкоденных фич. На то, что доработки станут дороже в процессе расширения присутствия ИИ-кода в кодовой базе проекта.
Было бы неплохо уговорить руководство не класть все яйца в одну корзину, а выделить для вайб-кодинга отдельный проект, не самый критичный, но чтобы эффект от него можно было прочуствовать. И там всё и протестировать, без разрушения кодовой базы основного проекта.
Проблема в том, что процесс поиска и исправления ошибок после LLM - так себе занятие. Заниматься этим целыми днями на постоянной основе - удовольствие ниже среднего, даже если платить за это будут по повышенной ставке.
Автономная работа в агентском режиме? Самостоятельное закрытие тикетов? Ну конечно.. Пока что это всё далеко от реальности - даже для идеально поставленной задачи, нет никаких гарантий, что она будет корректно решена, а сборка проекта не будет падать. Основная проблема тут даже не в том, что ИИ недостаточно "умён" (при взаимодействии с ним, если не знать что это ИИ, вполне может сложиться впечатление, что это довольно опытный разработчик), а в том, что нет постоянности результата. Вот вы вроде бы "поняли" друг-друга, согласовали какой-то вариант решения задачи и тут раз - откуда вдруг не возьмись лезет отсебятина, о которой или вообще ранее не говорили или же прямо было сказано так не делать.
Скорее всего, проблему производительности можно будет решить за счёт увеличенного потребления памяти, заранее выделяя большие участки под вычисления. Так что ждём второго конкурса - теперь уже на снижение потребления памяти, относительно решения на C.
Если эти ИИ-агенты будут настолько хороши, что их надо только контролировать (а не переписывать половину кода, который они нагенерировали), то тогда программистов вовсе не надо будет. Менеджеры проекта будут сразу задачи нарезать ИИ, да и всё. А скорее всего и самих менеджеров не потребуется. Достаточно будет совета директоров компании и договора с компанией поставляющей ИИ-услуги, вместе с технической поддержкой.
Это да, LLM довольно неплохо справляются с ограниченными задачами, без зависимостей, с малым количеством чётко поставленных условий.
Непонятно правда как это эффективно использовать. Ведь разбиение бизнес-задачи на множество небольших, с проработкой иерархии и зависимостей - это самое сложное. Опять же, если поручать задачу ИИ, то придется предварительно эти условия четко проработать, что в Agile может быть довольно таки нетривиально.
На хоть сколько то серьезной кодовой базе навряд ли получится эффективно использовать какую-либо из актуальных моделей LLM. Как только код становится достаточно сложным, то нужного результата будет добиться весьма и весьма непросто. Придется постоянно уточнять запросы, а модель будет галлюцинировать и игнорировать прямые инструкции.
Будет любопытно посмотреть, решили ли эти проблемы в Codex, но что-то у меня бооольшие в этом сомнения...
Можно создать идеальный сортировщик, но не сортировщик-упаковщик-грузчики- машинист, синкэбаут.
я бы сказал, что с точностью до наоборот. как раз вот эти новые человекоподобные роботы - явно расчитаны на максимальную универсальность. даже если по каким то причинам не получится сделать универсальный ИИ для таких устройств, то ничего не мешает подгружать нужные модели специализированного ИИ по мере необходимости. сегодня это грузчик, завтра слесарь, работник склада и т. д.
не понимаю вот этого всего хайпа на тему ИИ в IT. да, LLM хороши для простеньких ограниченных задач, результат которых несложно проверить. но как только заходит речь об интеграции в сложную уже существующую систему - всё, приехали. можно бесконечно писать-уточнять промпты - нормального результата добиться будет очень непросто. реально быстрее самому сделать оказывается. и это ещё не упомянуты ИИ-галлюцинации, когда в сгенерированном коде присутствует вызовы несуществующих функций и прочее в таком духе. и надо хорошо разбираться в предметной области, чтобы это понять, потому что всё выглядит очень правдоподобным.
Да, поэтому сейчас (не в РФ) регулярно слышу как пытаются избавиться от индусов на аутсорсе (я про спецов, а не заскриптованную поддержку) официально звучит нам надоела разница во времени и хочется локальных людей.
слышу про ровно обратные процессы: массовые увольнения локальных сотрудников и заменой их индийскими откуда-нибудь из Бангалора.
да уж, JS был хорош лет 20 назад, когда надо было прикрутить простенькую логику к сайту на PHP. но сейчас он уже полностью морально устарел. когда там к WASM прикрутят нормальную поддержку взаимодействия с браузером, чтобы можно было полностью отказаться от JS и использовать нормальные современные языки программирования?
Тоже именно этот момент зацепил. Ну хотите вы 24/7 для клиентов обеспечить, создавайте в компании отдел технической поддержки, набирайте сервис-инженеров на первые линии поддержки. Заводите посменное дежурство в команде, разумеется компенсируя это зарплатами x2 от обычных.
К этому возрасту уже не ты должен искать работу, а работа тебя.
регулярно слышу подобные фразы, но сильно сомневаюсь, что это работает для всех. вот не припомню, чтобы по рекомендациям своих знакомых хоть раз куда-то устраивался. всё как обычно, на общих основаниях.
хотя вот для менеджеров это может быть и правда. там софт-скиллы - это ключевой навык зачастую.
Наблюдал схожее поведение на разных стеках и моделях LLM. Наиболее сильная модель из тех, что пробовал, на мой взгляд, была Claude 3.7. Но даже её вывод надо контролировать, на миддл+ задачах уже спотыкается и без проверки высок риск запушить багов на прод.
Честно говоря, пугает вот это: "ИИ написал за меня всё что нужно и это было сделано отлично, даже ничего исправлять не пришлось". Постоянно пытаюсь делегировать ИИ сколько-то серьезные участки работы и каждый раз требуется, как минимум, достаточно существенная переделка сгенерированного кода. Причем время вдумчивой проверки этого кода вполне себе сравнимо с тем временем, что потребуется на его самостоятельную реализацию.
а что будет в том случае если обычный художник будет рисовать в данном стиле? это тоже будет запрещено? почему не использовать единый подход как для ИИ так и для людей?
Если для так называемой "адаптации" разработчикам KiCad придется выпускать патчи для Wayland, GNOME, KDE и т.д., то ничего удивительного. Думаю, что у них и своих задач хватает по продукту.
Ну с таким подходом странно, что в Tesla не ДВС стоит ))
Да можно и upgrade kit-ы продавать. Кому нужен полный автопилот - покупают комплект с лидаром. Ещё и заработали бы на этом.
Странный конечно подход. В чём проблема обучать ту же нейросеть данными ещё и с лидара? Зачем себя сознательно ограничивать?
Основная проблема автора, насколько можно понять, заключается в том, что он и бизнес, в лице CEO говорят на разных языках. Доводы для бизнеса также должны быть в рамках, которые могут быть им поняты.
Нет смысла упирать на качество архитектуры проекта, его отлаженность и прочее. Это всё технические термины и менеджеры их могут не понимать или не воспринимать всерьёз. Тут скорее надо указать на потенциальные потери бизнеса когда продакшен встанет колом из-за очередных навайбкоденных фич. На то, что доработки станут дороже в процессе расширения присутствия ИИ-кода в кодовой базе проекта.
Было бы неплохо уговорить руководство не класть все яйца в одну корзину, а выделить для вайб-кодинга отдельный проект, не самый критичный, но чтобы эффект от него можно было прочуствовать. И там всё и протестировать, без разрушения кодовой базы основного проекта.
Проблема в том, что процесс поиска и исправления ошибок после LLM - так себе занятие. Заниматься этим целыми днями на постоянной основе - удовольствие ниже среднего, даже если платить за это будут по повышенной ставке.
Автономная работа в агентском режиме? Самостоятельное закрытие тикетов? Ну конечно.. Пока что это всё далеко от реальности - даже для идеально поставленной задачи, нет никаких гарантий, что она будет корректно решена, а сборка проекта не будет падать. Основная проблема тут даже не в том, что ИИ недостаточно "умён" (при взаимодействии с ним, если не знать что это ИИ, вполне может сложиться впечатление, что это довольно опытный разработчик), а в том, что нет постоянности результата. Вот вы вроде бы "поняли" друг-друга, согласовали какой-то вариант решения задачи и тут раз - откуда вдруг не возьмись лезет отсебятина, о которой или вообще ранее не говорили или же прямо было сказано так не делать.
Скорее всего, проблему производительности можно будет решить за счёт увеличенного потребления памяти, заранее выделяя большие участки под вычисления. Так что ждём второго конкурса - теперь уже на снижение потребления памяти, относительно решения на C.
Если эти ИИ-агенты будут настолько хороши, что их надо только контролировать (а не переписывать половину кода, который они нагенерировали), то тогда программистов вовсе не надо будет. Менеджеры проекта будут сразу задачи нарезать ИИ, да и всё. А скорее всего и самих менеджеров не потребуется. Достаточно будет совета директоров компании и договора с компанией поставляющей ИИ-услуги, вместе с технической поддержкой.
Это да, LLM довольно неплохо справляются с ограниченными задачами, без зависимостей, с малым количеством чётко поставленных условий.
Непонятно правда как это эффективно использовать. Ведь разбиение бизнес-задачи на множество небольших, с проработкой иерархии и зависимостей - это самое сложное. Опять же, если поручать задачу ИИ, то придется предварительно эти условия четко проработать, что в Agile может быть довольно таки нетривиально.
На хоть сколько то серьезной кодовой базе навряд ли получится эффективно использовать какую-либо из актуальных моделей LLM. Как только код становится достаточно сложным, то нужного результата будет добиться весьма и весьма непросто. Придется постоянно уточнять запросы, а модель будет галлюцинировать и игнорировать прямые инструкции.
Будет любопытно посмотреть, решили ли эти проблемы в Codex, но что-то у меня бооольшие в этом сомнения...
я бы сказал, что с точностью до наоборот. как раз вот эти новые человекоподобные роботы - явно расчитаны на максимальную универсальность. даже если по каким то причинам не получится сделать универсальный ИИ для таких устройств, то ничего не мешает подгружать нужные модели специализированного ИИ по мере необходимости. сегодня это грузчик, завтра слесарь, работник склада и т. д.
не понимаю вот этого всего хайпа на тему ИИ в IT. да, LLM хороши для простеньких ограниченных задач, результат которых несложно проверить. но как только заходит речь об интеграции в сложную уже существующую систему - всё, приехали. можно бесконечно писать-уточнять промпты - нормального результата добиться будет очень непросто. реально быстрее самому сделать оказывается. и это ещё не упомянуты ИИ-галлюцинации, когда в сгенерированном коде присутствует вызовы несуществующих функций и прочее в таком духе. и надо хорошо разбираться в предметной области, чтобы это понять, потому что всё выглядит очень правдоподобным.
слышу про ровно обратные процессы: массовые увольнения локальных сотрудников и заменой их индийскими откуда-нибудь из Бангалора.
да уж, JS был хорош лет 20 назад, когда надо было прикрутить простенькую логику к сайту на PHP. но сейчас он уже полностью морально устарел. когда там к WASM прикрутят нормальную поддержку взаимодействия с браузером, чтобы можно было полностью отказаться от JS и использовать нормальные современные языки программирования?
Тоже именно этот момент зацепил. Ну хотите вы 24/7 для клиентов обеспечить, создавайте в компании отдел технической поддержки, набирайте сервис-инженеров на первые линии поддержки. Заводите посменное дежурство в команде, разумеется компенсируя это зарплатами x2 от обычных.
регулярно слышу подобные фразы, но сильно сомневаюсь, что это работает для всех. вот не припомню, чтобы по рекомендациям своих знакомых хоть раз куда-то устраивался. всё как обычно, на общих основаниях.
хотя вот для менеджеров это может быть и правда. там софт-скиллы - это ключевой навык зачастую.
Наблюдал схожее поведение на разных стеках и моделях LLM. Наиболее сильная модель из тех, что пробовал, на мой взгляд, была Claude 3.7. Но даже её вывод надо контролировать, на миддл+ задачах уже спотыкается и без проверки высок риск запушить багов на прод.
Честно говоря, пугает вот это: "ИИ написал за меня всё что нужно и это было сделано отлично, даже ничего исправлять не пришлось". Постоянно пытаюсь делегировать ИИ сколько-то серьезные участки работы и каждый раз требуется, как минимум, достаточно существенная переделка сгенерированного кода. Причем время вдумчивой проверки этого кода вполне себе сравнимо с тем временем, что потребуется на его самостоятельную реализацию.
а что будет в том случае если обычный художник будет рисовать в данном стиле? это тоже будет запрещено? почему не использовать единый подход как для ИИ так и для людей?