Согласен с тем, что лопаты продаются проще, но, учитывая, что они уже вынуждены погружаться в предметные области и в том числе нанимают экспертов в этих областях (чтобы те тренировали модели и валидировали ответы моделей), то в целом есть вероятность сдвига их фокуса из мира ИИ в мир реальный для применения результатов дешевого интеллекта там, где это наиболее маржинально, либо для сотрудничества (чем они уже кажется занимаются на госконтрактах), либо для заработка (создание побочного бизнеса, мало ли у нас что-ли примеров компаний которые занимаются всем подряд).
Если бы они работали абсолютно точно и корректно всегда, то остальным компаниям пришлось бы просто свернуть работу и закрыться, чего не происходит.
Ни одна компания, производящая LLM и агентом не заявляет это, да, может быть маркетинг, что всё замечательно, но глобально среди тех, кто в теме, нет мысли, что всё замечательно.
Но вы зачем-то требуете идеальность в неидеальном мире)
Я не понимаю, вы что хотите доказать? Что если пустить кодовую базу на самотёк и довериться на 100% моделям, исключив личную ответственность, то будет плохо? Ну так я этого не отрицал и чуть ли не сразу об этом говорю, что текущий уровень моделей неидеален, говорил и о том, что моделям нужно объяснять принципы взаимодействия с кодовой базой.
Не надо параллельно. Не надо много. Надо одну, но хорошо. С типичным нечетким описанием. Но с учетом всех дефолтов мира, фирмы и проекта.
Ну вот это главное идеологическое расхождение, я говорю, что можно параллельно, можно много, но с четким описанием «хотелок».
Я ничего не смогу поделать, что вам это не нужно, но я по-прежнему придерживаюсь позиции, что нейросети — это инструмент, с которым можно научиться работать и стать эффективнее, либо быть техно-пессимистом и игнорировать новые технические возможности.
Не, я, конечно, могу быть несколько оптимистичен, но мне кажется, мы говорим о несколько разных вещах.
Как минимум, я не имел вайбкодинг в чистом его виде, то есть не отрицаю автотесты, контроль качества и ревью. Вайбкодинг без этого — хаос.
Качественный процесс разработки с нейросетями ближе к руководству над командой, где процесс разработки вертится вокруг проектирования, делегирования и составления и ревью тикетов, а не о самостоятельном кодинге.
Такие системы, как Codex, наглядно это показывают, позволяя ставить параллельно большое количество задач.
Насчёт обучаемости вы правы, базово модель не в курсе, что за проект, как с ним работать. Однако есть методики, которые улучшают «понимание» проекта моделями, и если следовать методикам, вы эту ситуацию до какой-то степени способны исправить, естественно, не до уровня опытного разработчика.
А вот насчёт техдолга я не согласен, люди годами придумывали паттерны и методологии, которые используют, чтобы минимизировать уровень техдолга, и если не пускать кодовую базу на самотёк, то всё будет адекватно.
Это я к тому, что нейросети — это инструмент, а вы, похоже, привыкли к молотку и гвоздям, но нейросети — это не молоток, а, условно, отвёртка или гаечный ключ, и вы, конечно, можете пытаться забивать саморезы привычным вам способом, однако при текущем уровне моделей задачи с постановкой «делай хорошо, а плохо не делай» результат будет непредсказуем и глуп.
Но, на мой взгляд, не всё так плохо, и при должной сноровке к нейросетям возможно адаптироваться, хотя бы ради автоматизации рутинных задач.
LLM'ки уже достаточно хорошо умеют переписывать код с одного языка на другой, рефакторить код, а новый код достойно они пишут только под присмотром знающего программиста-тимлида, который умеет ставить и описывать задачи.
Такая связка человек+агент дает возможность, например, легко писать код нативно сразу для нескольких платформ, перевозить простые приложения с одного стека на другой без затрат, измеряемых в человеко-годах, в общем, как минимум проблема с техдолгом при желании может стать заметно меньше.
Конечно, базовая тупость моделей пока ещё высока, и они часто генерируют бред, но под "руководством" грамотного технически подкованного человека код-агенты дают кратный рост в количестве написанного кода.
В общем, поменялось, теперь у вас есть junior+ разработчик, которому не нужно спать/отдыхать/заниматься личными делами, и при этом его можно масштабировать по размеру вашего кошелька.
Звучит нежизнеспособно, больше верю в то, что компании, обладающие качественным и неограниченным доступом к ИИ, просто начнут чаще патентовать идеи или заходить в интеллектуально ёмкие области для выполнения контрактов.
про котлин не скажу, вроде должно, а за Flutter могу сказать
по своему опыту, мобильное приложение достаточно легко запустилось на десктопе, отдельно есть вопросы с адаптацией под широкие экраны (но это в целом решаемо и не особо сложно учитывая современные возможности нейронок)
По перформансу все было в целом неплохо, на уровне Qt или хорошо оптимизированного электрона, ну то есть где-то 100-200мб ОЗУ на приложение.
С точки зрения UI, наверно притязательный пользователь распознает недоработанный мобильный юай, но в случае компании которая готова вкладывать ресурс именно в приложение, то это решаемо
Но к выше сказаному стоит учесть, что последний раз я взаимодействовал с десктопным флаттером где-то в 22-23 году и с тех пор ситуация скорее всего изменилась в лучшую сторону.
Зачем пользователю использовать дешевую модель, если она непредсказуемо врет?
Дороговизна модели не гарантирует вам, что модель будет в особых случаях вести себя адекватно. В целом у разных пользователей разные задачи, и для кого-то быстрая/дешевая модель лучше чем долгая/дорогая, например, в ситуациях когда количество важнее качества.
И по личному опыту замечал, что для креативных задач думающие модели пока что ведут себя более однообразно, чем те, которые пишут ответ сразу.
Они всегда используют самую дорогую модель для всего
OpenAi (и не только они) уже в какой-то степени решают это проблему: навешивают классификатор на запросы, и в зависимости от сложности задачи роутят в модель подороже/подешевле
Однако на мой взгляд тут нужно быть очень аккуратным чтобы желание экономить не привело к ухудшению UX, по своему опыту роутинг требует качество около 90-95+% точности, тк дифф с качеством дешевой/дорогой моделью часто заметен. При этом возвращаясь к OpenAI у них скорее роутинг хороший, но и ошибка при некорректном срабатывании менее незаметна
В общем пока на мой взгляд лучшее решение на текущий момент: включить автоматический роутинг на всех по умолчанию -> даст экономию, но при этом оставить возможность выбрать и зафиксировать этот выбор на топовую модель.
Тут правда есть вопрос с "пряником" для тех кто использует роутинг, но это как будто решаемо, главное без кнута в виде квот.
На мой взгляд, идея периодически издаваемых журналов в целом выглядит устаревшей.
Просто банально потому, что выпустить статью в нужный момент важнее, чем сам факт публикации в каком-то издании (конечно, если вы не под KPI публикаций).
Это у меня сложилось на основе наблюдений публикаций вокруг LLM. Компании сначала делают предварительную публикацию и, возможно, выкладывают результаты в общий доступ. Что удобно в такой схеме? Результат доступен сразу и бесплатно.
И как при таком происходит оценка качества/полезности статьи? Да по большому счету читатели как-то сами решают, то есть для определения важных статей нужна в большей степени не рецензирование (оно как раз само собой произойдет и бесплатно после момента публикации), а цитируемость и фактическая полезность статьи.
И кто-то может поспорить, что рецензенты должны как раз выфильтровывать статьи, полезность которых низка. Что в текущем положении дел как будто ошибочно — статья не обязана быть выграненым алмазом, а несколько итераций разных авторов над одной темой с доработками конкретной темы или статьи, наоборот, полезна и позволяет получать работы качественно сильно большего уровня, чем в среднем можно получить от индивидуального автора. Наверно, то, что я имею в виду = Википедия, но для ресерча и с возможностью выполнить KPI в рамках работы в наукоемких направлениях.
от того что у меня запись прервется через пол часа - не означает, что мне не нужно сделать часовую запись
я когда дойду до искусственного лимита в 30 минут просто включу ещё раз запись и на второй записи увижу, что
камера начинает давать артефакты через 45 минут
то есть вторая запись будет с артефактами, к производителю у меня будут вопросы в любом случае, хоть с кастомной прошивкой, хоть с его, и покупать товары его производства я, вероятно, больше не захочу.
в целом, да, придется завести второй номер, если его нет, и согласен - неприятно, но не смертельно
А вот что придется покупать другой телефон - сомневаюсь, почти в любом телефоне сейчас доступно либо две сим-карты либо сим+е-сим, что проблему сводит в разряд гипотетических
Для компании это тоже не так просто как корпоративный мессенджер
Вы так говорите будто корпоративный мессенджер - бесплатное удовольствие. Увы обычно это не так.
А в корпоративные телефоны компании мне кажется вкладываться не будут если нет какого-то особого требования к безопасности, но тогда там обычно даже не идет речь об использовании телеграмма как рабочего инструмента и критерии выбора там оперируют удобством далеко не первым пунктом.
я видел наверно штук 4-5 разных мессенджеров главная выгода которых и собственно причина переезда на них строится на этом доводе
тг большинством используется как мессенджер для личного общения
при этом большинство амбасадоров рабочих мессенджеров почему-то игнорируют идею завести рабочий тг аккаунт
сам существую в ситуации когда телега - рабочий мессенджер, но какой либо дискомфорт испытывать перестал после появления рабочего аккаунта. Остальное - как будто дело привычки и степени организованности коллектива.
И честно говоря, по моим ощущениям, трекер для исполнителя это не рабочий инструмент, в нем работы ведет менеджмент, а вот мессенджер вполне инструмент исполнителя. А ваше решение смотрится необычно и интересно, пусть я и не понимаю эффективность предложенных вами практик, но интересно узнать следующее:
Есть ли отзывы от команд которые внедрили ваш инструмент, интересно понять как меняются привычные паттерны общения.
Если команды отказываются от него, то почему?
Возрастает ли реальная эффективность у команд которые внедрили этот инструмент, и если да, то насколько?
А если эффективность не возрастает, то зачем повышать удобство сотрудников? :)
Согласен с тем, что лопаты продаются проще, но, учитывая, что они уже вынуждены погружаться в предметные области и в том числе нанимают экспертов в этих областях (чтобы те тренировали модели и валидировали ответы моделей), то в целом есть вероятность сдвига их фокуса из мира ИИ в мир реальный для применения результатов дешевого интеллекта там, где это наиболее маржинально, либо для сотрудничества (чем они уже кажется занимаются на госконтрактах), либо для заработка (создание побочного бизнеса, мало ли у нас что-ли примеров компаний которые занимаются всем подряд).
Ни одна компания, производящая LLM и агентом не заявляет это, да, может быть маркетинг, что всё замечательно, но глобально среди тех, кто в теме, нет мысли, что всё замечательно.
Но вы зачем-то требуете идеальность в неидеальном мире)
Мне кажется, вы спорите лишь бы поспорить, бесцельно, просто потому что вам новости про ИИ надоели.
Я не понимаю, вы что хотите доказать? Что если пустить кодовую базу на самотёк и довериться на 100% моделям, исключив личную ответственность, то будет плохо? Ну так я этого не отрицал и чуть ли не сразу об этом говорю, что текущий уровень моделей неидеален, говорил и о том, что моделям нужно объяснять принципы взаимодействия с кодовой базой.
Ну вот это главное идеологическое расхождение, я говорю, что можно параллельно, можно много, но с четким описанием «хотелок».
Я ничего не смогу поделать, что вам это не нужно, но я по-прежнему придерживаюсь позиции, что нейросети — это инструмент, с которым можно научиться работать и стать эффективнее, либо быть техно-пессимистом и игнорировать новые технические возможности.
Не, я, конечно, могу быть несколько оптимистичен, но мне кажется, мы говорим о несколько разных вещах.
Как минимум, я не имел вайбкодинг в чистом его виде, то есть не отрицаю автотесты, контроль качества и ревью. Вайбкодинг без этого — хаос.
Качественный процесс разработки с нейросетями ближе к руководству над командой, где процесс разработки вертится вокруг проектирования, делегирования и составления и ревью тикетов, а не о самостоятельном кодинге.
Такие системы, как Codex, наглядно это показывают, позволяя ставить параллельно большое количество задач.
Насчёт обучаемости вы правы, базово модель не в курсе, что за проект, как с ним работать. Однако есть методики, которые улучшают «понимание» проекта моделями, и если следовать методикам, вы эту ситуацию до какой-то степени способны исправить, естественно, не до уровня опытного разработчика.
А вот насчёт техдолга я не согласен, люди годами придумывали паттерны и методологии, которые используют, чтобы минимизировать уровень техдолга, и если не пускать кодовую базу на самотёк, то всё будет адекватно.
Это я к тому, что нейросети — это инструмент, а вы, похоже, привыкли к молотку и гвоздям, но нейросети — это не молоток, а, условно, отвёртка или гаечный ключ, и вы, конечно, можете пытаться забивать саморезы привычным вам способом, однако при текущем уровне моделей задачи с постановкой «делай хорошо, а плохо не делай» результат будет непредсказуем и глуп.
Но, на мой взгляд, не всё так плохо, и при должной сноровке к нейросетям возможно адаптироваться, хотя бы ради автоматизации рутинных задач.
LLM'ки уже достаточно хорошо умеют переписывать код с одного языка на другой, рефакторить код, а новый код достойно они пишут только под присмотром знающего программиста-тимлида, который умеет ставить и описывать задачи.
Такая связка человек+агент дает возможность, например, легко писать код нативно сразу для нескольких платформ, перевозить простые приложения с одного стека на другой без затрат, измеряемых в человеко-годах, в общем, как минимум проблема с техдолгом при желании может стать заметно меньше.
Конечно, базовая тупость моделей пока ещё высока, и они часто генерируют бред, но под "руководством" грамотного технически подкованного человека код-агенты дают кратный рост в количестве написанного кода.
В общем, поменялось, теперь у вас есть junior+ разработчик, которому не нужно спать/отдыхать/заниматься личными делами, и при этом его можно масштабировать по размеру вашего кошелька.
Звучит нежизнеспособно, больше верю в то, что компании, обладающие качественным и неограниченным доступом к ИИ, просто начнут чаще патентовать идеи или заходить в интеллектуально ёмкие области для выполнения контрактов.
про котлин не скажу, вроде должно, а за Flutter могу сказать
по своему опыту, мобильное приложение достаточно легко запустилось на десктопе, отдельно есть вопросы с адаптацией под широкие экраны (но это в целом решаемо и не особо сложно учитывая современные возможности нейронок)
По перформансу все было в целом неплохо, на уровне Qt или хорошо оптимизированного электрона, ну то есть где-то 100-200мб ОЗУ на приложение.
С точки зрения UI, наверно притязательный пользователь распознает недоработанный мобильный юай, но в случае компании которая готова вкладывать ресурс именно в приложение, то это решаемо
Но к выше сказаному стоит учесть, что последний раз я взаимодействовал с десктопным флаттером где-то в 22-23 году и с тех пор ситуация скорее всего изменилась в лучшую сторону.
или из современного Flutter или Kotlin Compose
Вы придумываете ChromeOS)
Дороговизна модели не гарантирует вам, что модель будет в особых случаях вести себя адекватно. В целом у разных пользователей разные задачи, и для кого-то быстрая/дешевая модель лучше чем долгая/дорогая, например, в ситуациях когда количество важнее качества.
И по личному опыту замечал, что для креативных задач думающие модели пока что ведут себя более однообразно, чем те, которые пишут ответ сразу.
OpenAi (и не только они) уже в какой-то степени решают это проблему: навешивают классификатор на запросы, и в зависимости от сложности задачи роутят в модель подороже/подешевле
Однако на мой взгляд тут нужно быть очень аккуратным чтобы желание экономить не привело к ухудшению UX, по своему опыту роутинг требует качество около 90-95+% точности, тк дифф с качеством дешевой/дорогой моделью часто заметен. При этом возвращаясь к OpenAI у них скорее роутинг хороший, но и ошибка при некорректном срабатывании менее незаметна
В общем пока на мой взгляд лучшее решение на текущий момент: включить автоматический роутинг на всех по умолчанию -> даст экономию, но при этом оставить возможность выбрать и зафиксировать этот выбор на топовую модель.
Тут правда есть вопрос с "пряником" для тех кто использует роутинг, но это как будто решаемо, главное без кнута в виде квот.
Подозреваю, что для запуска гигачата во внешнем контуре за пределами облака сбера, там где это облако использовать нельзя - вполне себе вариант.
На мой взгляд, идея периодически издаваемых журналов в целом выглядит устаревшей.
Просто банально потому, что выпустить статью в нужный момент важнее, чем сам факт публикации в каком-то издании (конечно, если вы не под KPI публикаций).
Это у меня сложилось на основе наблюдений публикаций вокруг LLM. Компании сначала делают предварительную публикацию и, возможно, выкладывают результаты в общий доступ. Что удобно в такой схеме? Результат доступен сразу и бесплатно.
И как при таком происходит оценка качества/полезности статьи? Да по большому счету читатели как-то сами решают, то есть для определения важных статей нужна в большей степени не рецензирование (оно как раз само собой произойдет и бесплатно после момента публикации), а цитируемость и фактическая полезность статьи.
И кто-то может поспорить, что рецензенты должны как раз выфильтровывать статьи, полезность которых низка. Что в текущем положении дел как будто ошибочно — статья не обязана быть выграненым алмазом, а несколько итераций разных авторов над одной темой с доработками конкретной темы или статьи, наоборот, полезна и позволяет получать работы качественно сильно большего уровня, чем в среднем можно получить от индивидуального автора. Наверно, то, что я имею в виду = Википедия, но для ресерча и с возможностью выполнить KPI в рамках работы в наукоемких направлениях.
примерно 130тыс по современным меркам?
формально уже может, только не всегда эффективно
ну вообще да, производитель виноват
от того что у меня запись прервется через пол часа - не означает, что мне не нужно сделать часовую запись
я когда дойду до искусственного лимита в 30 минут просто включу ещё раз запись и на второй записи увижу, что
то есть вторая запись будет с артефактами, к производителю у меня будут вопросы в любом случае, хоть с кастомной прошивкой, хоть с его, и покупать товары его производства я, вероятно, больше не захочу.
в целом, да, придется завести второй номер, если его нет, и согласен - неприятно, но не смертельно
А вот что придется покупать другой телефон - сомневаюсь, почти в любом телефоне сейчас доступно либо две сим-карты либо сим+е-сим, что проблему сводит в разряд гипотетических
Вы так говорите будто корпоративный мессенджер - бесплатное удовольствие. Увы обычно это не так.
А в корпоративные телефоны компании мне кажется вкладываться не будут если нет какого-то особого требования к безопасности, но тогда там обычно даже не идет речь об использовании телеграмма как рабочего инструмента и критерии выбора там оперируют удобством далеко не первым пунктом.
я видел наверно штук 4-5 разных мессенджеров главная выгода которых и собственно причина переезда на них строится на этом доводе
при этом большинство амбасадоров рабочих мессенджеров почему-то игнорируют идею завести рабочий тг аккаунт
сам существую в ситуации когда телега - рабочий мессенджер, но какой либо дискомфорт испытывать перестал после появления рабочего аккаунта. Остальное - как будто дело привычки и степени организованности коллектива.
И честно говоря, по моим ощущениям, трекер для исполнителя это не рабочий инструмент, в нем работы ведет менеджмент, а вот мессенджер вполне инструмент исполнителя. А ваше решение смотрится необычно и интересно, пусть я и не понимаю эффективность предложенных вами практик, но интересно узнать следующее:
Есть ли отзывы от команд которые внедрили ваш инструмент, интересно понять как меняются привычные паттерны общения.
Если команды отказываются от него, то почему?
Возрастает ли реальная эффективность у команд которые внедрили этот инструмент, и если да, то насколько?
А если эффективность не возрастает, то зачем повышать удобство сотрудников? :)