Обвиняете - подтверждайте. Приведите мне цитату, из моего комментария, где я выражаю негатив к работе или добросовестным работодателям. Вы - рекомендующий втыкать незаконные пункты в договор, как и любой другой работодатель, пытающийся обмануть сотрудника на этапе заключения трудового договора (привет запрет на разглашение зарплаты, который пытаются воткнуть всякие сомнительные конторки) - кстати таковым не являетесь.
Кандидаты после курсов выявлюятся дейсвтительно очень просто - они хорошо знают ответы на общие вопросы (наизусть), но не могут развить диалог на их тему. Например человек рассказывает идеально и в подробность про то, как устроена hashMap - но одновременно не способен ни рассказать зачем она так устроена, ни как сделать, чтобы её производительность выродилась в связный список, ни что будет для null ключа и зачастую даже что такое хэш. Более того - такие вопросы их ставят в ступор. Разработчик с опытом который не знает ответа - может по рассуждать, и построить предположения - пусть даже не верные, но логику рассуждений и понимание темы сразу видно будет.
Претензии именно к вопросам из статьи - которые рассуждениям не поддаются, требуют однозначного ответа, и этот ответ может быть только заученым.
Вас опять в какие-то пространные дали унесло от темы. Вы в статье предлагаете гнобить работников, которых хотите уволить регламентами, и предлагаете вредные советы о том, как незаконные пункты в договоре и абсурдные внутренние документы которые ни один суд даже рассматривать не будет - позволят вам уволить сотрудника который не нравится.
Вам отвечают - что ваша позиция перед судом или еще какой инстанцией - выеденного гроша с такими аргументами стоить не будет. И работника придётся восстановить, заплатить ему запрплату за время судебных разбирательств за простой и судебные издержки оплатить.
Вы сначала утверждаете, что отправите судиться в магадан человека, спорите что у вас шансы на победу есть и что еще смешнее - предлагаете затягивать дело аппелируя к вышестоящим инстанциям (смешнее потому что затянув дело, вы еще больше зарплаты сотруднику за простой заплатите - а работать он в это время не будет).
Потом сами приводите пример - по которому очевидно насколько в данной ситуации позиция работодателя слаба в суде.
А дальше начинается - про-то, что деньги-то за простой заплатят, а вот плюшки и примеии нет - так вы изначально сотрудника из компании выдавить пытаетесь - ну так начните с того, что все мотивирующие надбавки снизить до 0, это совершенно законно и может помочь выдавить неугодного сотрудника. А не этот цирк с конями в виде "подосвывания" запрета на совместительство, создание абсурдных регламентов и прочие бесполезные советы.
При последнем трудоустройстве предлагали работу в компании, где 50% оклад 50% (гарантированная) премия - как раз вероятно чтобы неугодных сгонять. Конечно при выборе компании это сиграло им в минус - но в целом рабочий вариант, рекомендую, пользуйтесь. Если у вас за забором очередь. На текущем рынке с бесконечным кадровым голодом, на свой страх и риск.
Про "увольнение по статье" - тут уже всё разобрали, во первых уволить по статье следуя вашим рекомендациям законно - не получится. Получится незаконно - после чего человек в суде оспорит решение, вы ему заплатите денег за это, а дальше "В общем случае, запись об увольнении по статье, признанная судом незаконной, подлежит исправлению в трудовой книжке" - и всё. Чисто взятие на понт что человек не пойдет свои права защищать.
А в конце - завуалированная угроза, что после таких комментариев нас (комментаторов) на работу не возьмут. Ну честное слово - если человек вашу статью считает адекватной - я к нему сам на работу не хочу попасть, ни в коем случае))
Т.е. вы там сверху в комментариях с боем доказываете, что эти ваши суды фи, ничего не сделают, никого не восстановят, и судиться придётся в магадане. А тут сами приводите пример, где сотрудник в суде как тузик грелку порвал не абы кого, а способную позволить себе чертовски дорогих юристов студию лебедева. Получил все надлежащие выплаты и спокойненько на своих условиях покинул здание.
Так по соглашению сторон, без всей этой неработающей фигни из статьи было бы намного дешевле решить проблему)
А про отчеты каждые пол часа - так мало того, что опять же - уволить сотрудника это не поможет, задолбать только, так ещё и на деле - Вася с удовольствием может вписаться в правила игры и лутать с вас деньги дальше, с нулевой эффективостью работы)
А подскажите, если знаете, как это работает - когда открыта цепочка activity. Типо A -> B -> C. Я слышал расхожие мнения, и что ситуация когда A и B destroyed а C жива невозможна, и что сначала выгрузятся они, а C последней, и что при убийстве активити - выгружаются только все скопом.
А вы на лайвкодинге например требуете от кандидата знание наизусть названий методов? Просто именно на это походит часть (по крайне мере пара примеров) из статьи, из за которых у меня к ней большие вопросы.
Я вот вспоминая свои секции лайвкодинга - помню свои фразы из разряда - "тут length, или size или count - не помню как там метод называется, они в разных коллекциях по разному" и "тут метод обеспечивающий свертку математическую свертку, не помню, reduce скорее всего, или там он в kotlin fold с initalValue называется", "там callback на это дело есть специальный, onЧет-то там, onRetainObject или типо того"
Увидев такой код - хорошему программисту потребуется 5 секнуд чтобы понять, что он недаекватный и еще 10 чтобы загуглить как оно работает и исправить, еще 5 на то, чтобы сходить выдать наставление написавшему. Но этот хороший программист не будет работать в компании человека, который написал статью, ведь на собеседовании - он скажет - "да хрен знает как оно работает, не помню я к чему автоматически приводится 55, к true или false - но это явно надо исправить т.к. не очевидно" и его не возьмут т.к. "не знает базовых механик языка"
Давайте - расскажите мне, какая формула механик языка позволит понять во что преобразуется объект со значением null при автоматической конверсии в строку (например Obj(null) + " test").
Логически мне цепочку выводов постройте пожалуйста. (вида - я 20 лет не видел таких выражений, но исходя из того, что в языке все конверсии происходят... )
И вам повезет, если в вашем языке NULL - это отедльный singletone object, тогда хоть как-то обоснование можно будет притащить.
Вариант - "создатели языка решили что в 'null'" меня не устроит и "в документации языка так написано" тоже - с такими ответами вы как честный самурай должны сразу уволиться с работы. Потому что по вашему же мнению тут есть какие-то механики которые можно не заучить, а понять эмперерически не обладая этим знанием в заученном виде.
Про 55 == True is True аналогично - почему bool(55) == 0 ? а потому что создатели языка так решили. Могли бы решить что True = 0, а False = 1 - и нет причин почему так не может быть (в unix код выхода 0 - это успех, а код 1 - ошибка). В "C" - создатели решили что bool(55) == 1. В js создатели языка вообще решили что если a = 10, a != true, a != false.
Единственный способ ответить на такие вопросы - заучить. А если пишешь на языке больше 5 лет, то такая ерунда из головы улетучивается, потому что не встречается никогда, а когда встречается - то смотришь на неё, говоришь - какая-то херня, надо проверить че тут вообще будет, а потом переписываешь по нормальному.
Синтаксис языка или семантика опрелеляет будет ли 55 == True? Нет, это отдельное правило преобразования number -> boolean. Я мог прочитать его 10 лет назад когда учил основы языка, и с тех пор забыть 10 раз, потому что в здравом уме никто так делать не будет.
Это из разряда в java
Integer a = 100; Integer b = 100;
System.out.println(a == b); // true (значение в кэшированном диапазоне)
Integer c = 200; Integer d = 200;
System.out.println(c == d); // false (значение вне кэшированного диапазона)
Адекватные люди не запоминают эти правила так, они запоминают их как - "сравнение Boxed версий скалярных типов по == сломано" и "не используй boxed типы за пределами generic" (а там этой проблемы не будет), видишь что его используют - сделай нормально. И при разборе бага в коде - первое что делают - переписывают сравнение на нормальное и тестируют воспроизводиомсть.
И это вообще не показатель опыта - а супер частный случай который можно только заучить и нельзя понять интуитивно.
Я конечно не питонист но помню как 10 лет назад заучивал ответы на такие-же тупые вопросы вида "что вернёт 55 == True is True"
Почему это тупой вопрос? Да потому что это не настоящий проектный код. Кто в здравом смысле вообще будет число со True сравнивать?
Ошибиться тут легко - вспоминаем что в C (или js, черт их там разберёт) - любое число отличное от 0 - считается true и всё. 55 == True -> True, True is True -> true.
"даже самые недалекие и отбитые из таких «Василиев» резко перестают творить дичь, ознакомившись с официальным регламентом и проставления собственной подписи."
Ооо, опытный Василий после такого не только не перестанет творить дичь - он будет творить её с удвоенной силой, но полностью в рамках регламента. Его положительная, хоть и минимальная продуктивность - станет отрицательной. А любые претензии к скорости работы - скорее всего будут парированы необходимостью выполнения регламента в точности.
Если объявляете человеку войну - будьте готовы воевать до последнего цента на счету вашей компании.
Есть перечень исключений, когда это обоснованно законом, но в общем случае - такой допник в суде сочтут нарушающим свободу труда гарантированную констуцией, и он просто не будет учитываться как часть трудового договора. А если компания уволит сотрудника руководствуясь только этим документом - то постановят сотрудник восстановить, зарплату за весь срок простоя и судебных разбирательств выплатить, и заодно судебные издержки компенсировать.
В случае-же, если у работодателя найдутся ещё аргументы (например систематические опоздания после второй работы) - то нарушение этого допника (без попытки договориться с работодателем) сыграет против работника - но уже как показатель того, что он не то, чтобы старался быть хорошим работником. Но все равно - влияние окажет минимальное.
Там тонкий лёд. Запрет должен иметь под собой обоснования - а на просто "я хочу, чтобы совместительства не было". И при увольнении из-за нарушения этого запрета, сотрудник вполне может оспорить и в суде выиграть - если докажет, что работа по совместительству никак не мешала основной (читай - в суде работодатель должен будет доказать, что имело место влияние второй работы на основную)
По приведённой вами цитате совершенно очевидно, что речь про сотрудника, который соврал в резюме и на собеседованиях (из фразы "после чего все его знания, опыт и таланты внезапно пропадают") и не справляется с задачами, которые должен уметь выполнять, но вы решили прикопаться к фразе "и начинается применение ИИ".
Вы серьёзно не поняли посыл этой части текста? Вы считаете что ИИ это панацея, которая сделает вруна и безграмотного разработчика в 10 раз эффективнее экперта?
С такой формулировкой в корне не согласен. Но если вы имели в ввиду "проблема не(только) в оружии" - тогда согласен.
Если любой гражданский (в т.ч. неадекват) может купить оружие это проблема. Если общество культивирует неадектов это вторая проблема. Если неадекват может напечатать оружие это третья проблема.
Не надо их смешивать, решаются она раздельно и связаны поверхностно.
Да - если бы японцы могли покупать оружие - наверное уровень огнестрельных убийств там вырос бы незначительно - т.к. японцы очень хорошо прививают законопослушность. Но в той-же японии существовали якудза. Сколько бы общество не работало над воспитанием идеального гражданина - криминальные структуры и личности всё равно будут возникать, как и банальные больные психологически люди.
Учитывая что оружие никак не повышает уровень жизни - не вижу причин - почему его легализованная продажа гражданскому населению - это не проблема.
Я ниже описал проблематику. Помимо возможности обучаться, ему вероятно придётся дать возможность забывать - а тогда он станет похож на человека, и с одной стороны - это прекрасно и найдёт много применений, а с другой - мы получим разум похожий на обычного человека, а не гениального решателя всех человеческих проблем с помощью всех знаний мира, о которых все грезят при разговорах про ИИ. Эволюционная скорость развития, а не технологическая сингулярность
Представим, что чтобы открыть закон всемирного тяготения - нужно было, чтобы ньютону на голову упало яблоко. Это некое фундаментальное событие (знание) - в купе с его остальными знаниями и заблуждениями - привело к открытию закона тяготения. При этом, возможно, если бы он знал одновременно с этим современную (для своего времени) медицину на абсолютном уровне - то подумал бы не о законе всемирного тяготения, а о том, приведёт ли к каким-то последствиям в будущем для него - падение яблока на голову, и не открыл бы собственно закон (и может открыл бы что-то другое).
Из этой модели можно сделать предположение - что для создания "научного прорыва" нужен конкретный набор знаний (т.е. из множество всех данных - ограниченный набор, в котором присуствуют и что не менее важно - отсуствуют конкретные значения).
Если мы берём ИИ который оперирует всеми знаниями человечества (что кстати насколько я понял невозможно с llm) - то у него выборка всегда содержит все знания, но не содержит необходимых пробелов. Получается - взяв каждый раз условно все имеющиеся у нас знания мы будем каждый раз получать набор выводов, исключающий часть "научных прорывов".
А занчит - есть ненулевая вероятность, что чтобы получить новые "открытия" - нам нужно будет намеренно сократить обучающую выборку. И тут как будто мы подходим к аналогу полного перебора. Да - сформированные интелектом знания - куда лучше чем полностью случайные данные - т.к. они отсекают огромное количество случайных комбинаций, которые точно не будут новыми данными (я бы сравнил это с подбором с использованием радужных таблиц - мы сильно сокращем выборку, но всё равно остаемся с задачей полного перебора).
Но при этом - сколько не ускоряй ИИ - его гипотезы ничего не стоят без эксперементального подтверждения - а это задача.
И я вижу тут ситуацию - когда ИИ сгенерирует за 10 секунд, миллион гипотез, но наука всё равно не совершит качественный рывок вперёд - т.к. вместо задачи формирования гипотезы, мы получим задачу опровергнуть 10.
Я не говорю про полную бесполезность ии если он удастся, скорее про то, что вероятно есть фундаментальные ограничения скорости научного прогресса, в которые ИИ моментально упрется и вместо технологической сигнуалярности - мы снова получим небольшой эволюционный рост.
Вот давно сам хотел написать статью с рассуждениями на тему того, что возможно тот самый супер - интеллект, который решит все наши проблемы, должен быть невозможен чисто логически. Смысл интелекта - в том, чтобы в условиях недостаточной информации построить предположение, которое дополнит картину для оптимального решения задачи. И тут мы получаем - что это механизм, который из неполных данных строит полные - а значит имеем дело со сжатием - а оно либо с потерями, либо на сжимаемых данных. Если мы говорим про решение всех задач - данные у нас несжимаемые - а значит обязательно будут ошибки. И вот тут мы можем прийти к тому - что гениальность открытий - на деле результат случайности в обучающей выборке или в мире. А значит - обученный на всех знаниях мира ИИ - должен быть примерно так-же хорош в создании открытий - как человек средних знаний т.к. распределение вероятностей в полной выборке будет в среднем совпадать со случайным срезом.
И сейчас то покупать тяжело (зачастую чтобы понять подходит техника или нет например, приходится искать инструкцию на сайте производителя и читать её), а в будущем видимо вообще будет нереально.
Из описанного - реально полезным выглядит ответ на запрос как альтернатива простому поиску - типо "нужна штука чтобы ...". И автоподборки. Но учитывая что пихать они будут из расчёта продать, а не подобрать нуженое - пользоваться все равно не выйдет.
Все остальное - выглядит как усложнение и без того безумно сложных карточек - типо подстраивающегося интерфейса (который ты только выучил, а он подстроился), и не дай бог видео отзывов. Но вероятно так оно и будет(
Обвиняете - подтверждайте. Приведите мне цитату, из моего комментария, где я выражаю негатив к работе или добросовестным работодателям. Вы - рекомендующий втыкать незаконные пункты в договор, как и любой другой работодатель, пытающийся обмануть сотрудника на этапе заключения трудового договора (привет запрет на разглашение зарплаты, который пытаются воткнуть всякие сомнительные конторки) - кстати таковым не являетесь.
Я проводил собесдеования и не мало.
Кандидаты после курсов выявлюятся дейсвтительно очень просто - они хорошо знают ответы на общие вопросы (наизусть), но не могут развить диалог на их тему. Например человек рассказывает идеально и в подробность про то, как устроена hashMap - но одновременно не способен ни рассказать зачем она так устроена, ни как сделать, чтобы её производительность выродилась в связный список, ни что будет для null ключа и зачастую даже что такое хэш. Более того - такие вопросы их ставят в ступор. Разработчик с опытом который не знает ответа - может по рассуждать, и построить предположения - пусть даже не верные, но логику рассуждений и понимание темы сразу видно будет.
Претензии именно к вопросам из статьи - которые рассуждениям не поддаются, требуют однозначного ответа, и этот ответ может быть только заученым.
Вас опять в какие-то пространные дали унесло от темы. Вы в статье предлагаете гнобить работников, которых хотите уволить регламентами, и предлагаете вредные советы о том, как незаконные пункты в договоре и абсурдные внутренние документы которые ни один суд даже рассматривать не будет - позволят вам уволить сотрудника который не нравится.
Вам отвечают - что ваша позиция перед судом или еще какой инстанцией - выеденного гроша с такими аргументами стоить не будет. И работника придётся восстановить, заплатить ему запрплату за время судебных разбирательств за простой и судебные издержки оплатить.
Вы сначала утверждаете, что отправите судиться в магадан человека, спорите что у вас шансы на победу есть и что еще смешнее - предлагаете затягивать дело аппелируя к вышестоящим инстанциям (смешнее потому что затянув дело, вы еще больше зарплаты сотруднику за простой заплатите - а работать он в это время не будет).
Потом сами приводите пример - по которому очевидно насколько в данной ситуации позиция работодателя слаба в суде.
А дальше начинается - про-то, что деньги-то за простой заплатят, а вот плюшки и примеии нет - так вы изначально сотрудника из компании выдавить пытаетесь - ну так начните с того, что все мотивирующие надбавки снизить до 0, это совершенно законно и может помочь выдавить неугодного сотрудника. А не этот цирк с конями в виде "подосвывания" запрета на совместительство, создание абсурдных регламентов и прочие бесполезные советы.
При последнем трудоустройстве предлагали работу в компании, где 50% оклад 50% (гарантированная) премия - как раз вероятно чтобы неугодных сгонять. Конечно при выборе компании это сиграло им в минус - но в целом рабочий вариант, рекомендую, пользуйтесь. Если у вас за забором очередь. На текущем рынке с бесконечным кадровым голодом, на свой страх и риск.
Про "увольнение по статье" - тут уже всё разобрали, во первых уволить по статье следуя вашим рекомендациям законно - не получится. Получится незаконно - после чего человек в суде оспорит решение, вы ему заплатите денег за это, а дальше "В общем случае, запись об увольнении по статье, признанная судом незаконной, подлежит исправлению в трудовой книжке" - и всё. Чисто взятие на понт что человек не пойдет свои права защищать.
А в конце - завуалированная угроза, что после таких комментариев нас (комментаторов) на работу не возьмут. Ну честное слово - если человек вашу статью считает адекватной - я к нему сам на работу не хочу попасть, ни в коем случае))
Т.е. вы там сверху в комментариях с боем доказываете, что эти ваши суды фи, ничего не сделают, никого не восстановят, и судиться придётся в магадане. А тут сами приводите пример, где сотрудник в суде как тузик грелку порвал не абы кого, а способную позволить себе чертовски дорогих юристов студию лебедева. Получил все надлежащие выплаты и спокойненько на своих условиях покинул здание.
Так по соглашению сторон, без всей этой неработающей фигни из статьи было бы намного дешевле решить проблему)
А про отчеты каждые пол часа - так мало того, что опять же - уволить сотрудника это не поможет, задолбать только, так ещё и на деле - Вася с удовольствием может вписаться в правила игры и лутать с вас деньги дальше, с нулевой эффективостью работы)
А подскажите, если знаете, как это работает - когда открыта цепочка activity. Типо A -> B -> C. Я слышал расхожие мнения, и что ситуация когда A и B destroyed а C жива невозможна, и что сначала выгрузятся они, а C последней, и что при убийстве активити - выгружаются только все скопом.
А вы на лайвкодинге например требуете от кандидата знание наизусть названий методов? Просто именно на это походит часть (по крайне мере пара примеров) из статьи, из за которых у меня к ней большие вопросы.
Я вот вспоминая свои секции лайвкодинга - помню свои фразы из разряда - "тут length, или size или count - не помню как там метод называется, они в разных коллекциях по разному" и "тут метод обеспечивающий свертку математическую свертку, не помню, reduce скорее всего, или там он в kotlin fold с initalValue называется", "там callback на это дело есть специальный, onЧет-то там, onRetainObject или типо того"
Увидев такой код - хорошему программисту потребуется 5 секнуд чтобы понять, что он недаекватный и еще 10 чтобы загуглить как оно работает и исправить, еще 5 на то, чтобы сходить выдать наставление написавшему.
Но этот хороший программист не будет работать в компании человека, который написал статью, ведь на собеседовании - он скажет - "да хрен знает как оно работает, не помню я к чему автоматически приводится 55, к true или false - но это явно надо исправить т.к. не очевидно" и его не возьмут т.к. "не знает базовых механик языка"
Давайте - расскажите мне, какая формула механик языка позволит понять во что преобразуется объект со значением null при автоматической конверсии в строку (например Obj(null) + " test").
Варианты ответа -
"", "null", "Null", "NULL", null pointer exception , "Obj(null)"
Логически мне цепочку выводов постройте пожалуйста. (вида - я 20 лет не видел таких выражений, но исходя из того, что в языке все конверсии происходят... )
И вам повезет, если в вашем языке NULL - это отедльный singletone object, тогда хоть как-то обоснование можно будет притащить.
Вариант - "создатели языка решили что в 'null'" меня не устроит и "в документации языка так написано" тоже - с такими ответами вы как честный самурай должны сразу уволиться с работы. Потому что по вашему же мнению тут есть какие-то механики которые можно не заучить, а понять эмперерически не обладая этим знанием в заученном виде.
Про 55 == True is True аналогично - почему bool(55) == 0 ? а потому что создатели языка так решили. Могли бы решить что True = 0, а False = 1 - и нет причин почему так не может быть (в unix код выхода 0 - это успех, а код 1 - ошибка).
В "C" - создатели решили что bool(55) == 1.
В js создатели языка вообще решили что если a = 10, a != true, a != false.
Единственный способ ответить на такие вопросы - заучить. А если пишешь на языке больше 5 лет, то такая ерунда из головы улетучивается, потому что не встречается никогда, а когда встречается - то смотришь на неё, говоришь - какая-то херня, надо проверить че тут вообще будет, а потом переписываешь по нормальному.
Синтаксис языка или семантика опрелеляет будет ли 55 == True? Нет, это отдельное правило преобразования number -> boolean. Я мог прочитать его 10 лет назад когда учил основы языка, и с тех пор забыть 10 раз, потому что в здравом уме никто так делать не будет.
Это из разряда в java
Integer a = 100; Integer b = 100;
System.out.println(a == b); // true (значение в кэшированном диапазоне)
Integer c = 200; Integer d = 200;
System.out.println(c == d); // false (значение вне кэшированного диапазона)
Адекватные люди не запоминают эти правила так, они запоминают их как - "сравнение Boxed версий скалярных типов по == сломано" и "не используй boxed типы за пределами generic" (а там этой проблемы не будет), видишь что его используют - сделай нормально. И при разборе бага в коде - первое что делают - переписывают сравнение на нормальное и тестируют воспроизводиомсть.
И это вообще не показатель опыта - а супер частный случай который можно только заучить и нельзя понять интуитивно.
Я конечно не питонист но помню как 10 лет назад заучивал ответы на такие-же тупые вопросы вида "что вернёт 55 == True is True"
Почему это тупой вопрос? Да потому что это не настоящий проектный код. Кто в здравом смысле вообще будет число со True сравнивать?
Ошибиться тут легко - вспоминаем что в C (или js, черт их там разберёт) - любое число отличное от 0 - считается true и всё. 55 == True -> True, True is True -> true.
"даже самые недалекие и отбитые из таких «Василиев» резко перестают творить дичь, ознакомившись с официальным регламентом и проставления собственной подписи."
Ооо, опытный Василий после такого не только не перестанет творить дичь - он будет творить её с удвоенной силой, но полностью в рамках регламента. Его положительная, хоть и минимальная продуктивность - станет отрицательной. А любые претензии к скорости работы - скорее всего будут парированы необходимостью выполнения регламента в точности.
Если объявляете человеку войну - будьте готовы воевать до последнего цента на счету вашей компании.
Судебная практика показывает что нет)
Есть перечень исключений, когда это обоснованно законом, но в общем случае - такой допник в суде сочтут нарушающим свободу труда гарантированную констуцией, и он просто не будет учитываться как часть трудового договора. А если компания уволит сотрудника руководствуясь только этим документом - то постановят сотрудник восстановить, зарплату за весь срок простоя и судебных разбирательств выплатить, и заодно судебные издержки компенсировать.
В случае-же, если у работодателя найдутся ещё аргументы (например систематические опоздания после второй работы) - то нарушение этого допника (без попытки договориться с работодателем) сыграет против работника - но уже как показатель того, что он не то, чтобы старался быть хорошим работником. Но все равно - влияние окажет минимальное.
Там тонкий лёд. Запрет должен иметь под собой обоснования - а на просто "я хочу, чтобы совместительства не было". И при увольнении из-за нарушения этого запрета, сотрудник вполне может оспорить и в суде выиграть - если докажет, что работа по совместительству никак не мешала основной (читай - в суде работодатель должен будет доказать, что имело место влияние второй работы на основную)
По приведённой вами цитате совершенно очевидно, что речь про сотрудника, который соврал в резюме и на собеседованиях (из фразы "после чего все его знания, опыт и таланты внезапно пропадают") и не справляется с задачами, которые должен уметь выполнять, но вы решили прикопаться к фразе "и начинается применение ИИ".
Вы серьёзно не поняли посыл этой части текста? Вы считаете что ИИ это панацея, которая сделает вруна и безграмотного разработчика в 10 раз эффективнее экперта?
С такой формулировкой в корне не согласен. Но если вы имели в ввиду "проблема не(только) в оружии" - тогда согласен.
Если любой гражданский (в т.ч. неадекват) может купить оружие это проблема. Если общество культивирует неадектов это вторая проблема. Если неадекват может напечатать оружие это третья проблема.
Не надо их смешивать, решаются она раздельно и связаны поверхностно.
Да - если бы японцы могли покупать оружие - наверное уровень огнестрельных убийств там вырос бы незначительно - т.к. японцы очень хорошо прививают законопослушность. Но в той-же японии существовали якудза. Сколько бы общество не работало над воспитанием идеального гражданина - криминальные структуры и личности всё равно будут возникать, как и банальные больные психологически люди.
Учитывая что оружие никак не повышает уровень жизни - не вижу причин - почему его легализованная продажа гражданскому населению - это не проблема.
Я ниже описал проблематику. Помимо возможности обучаться, ему вероятно придётся дать возможность забывать - а тогда он станет похож на человека, и с одной стороны - это прекрасно и найдёт много применений, а с другой - мы получим разум похожий на обычного человека, а не гениального решателя всех человеческих проблем с помощью всех знаний мира, о которых все грезят при разговорах про ИИ. Эволюционная скорость развития, а не технологическая сингулярность
Попробую построить упрощенную модель моей идеи.
Представим, что чтобы открыть закон всемирного тяготения - нужно было, чтобы ньютону на голову упало яблоко. Это некое фундаментальное событие (знание) - в купе с его остальными знаниями и заблуждениями - привело к открытию закона тяготения.
При этом, возможно, если бы он знал одновременно с этим современную (для своего времени) медицину на абсолютном уровне - то подумал бы не о законе всемирного тяготения, а о том, приведёт ли к каким-то последствиям в будущем для него - падение яблока на голову, и не открыл бы собственно закон (и может открыл бы что-то другое).
Из этой модели можно сделать предположение - что для создания "научного прорыва" нужен конкретный набор знаний (т.е. из множество всех данных - ограниченный набор, в котором присуствуют и что не менее важно - отсуствуют конкретные значения).
Если мы берём ИИ который оперирует всеми знаниями человечества (что кстати насколько я понял невозможно с llm) - то у него выборка всегда содержит все знания, но не содержит необходимых пробелов. Получается - взяв каждый раз условно все имеющиеся у нас знания мы будем каждый раз получать набор выводов, исключающий часть "научных прорывов".
А занчит - есть ненулевая вероятность, что чтобы получить новые "открытия" - нам нужно будет намеренно сократить обучающую выборку.
И тут как будто мы подходим к аналогу полного перебора.
Да - сформированные интелектом знания - куда лучше чем полностью случайные данные - т.к. они отсекают огромное количество случайных комбинаций, которые точно не будут новыми данными (я бы сравнил это с подбором с использованием радужных таблиц - мы сильно сокращем выборку, но всё равно остаемся с задачей полного перебора).
Но при этом - сколько не ускоряй ИИ - его гипотезы ничего не стоят без эксперементального подтверждения - а это задача.
И я вижу тут ситуацию - когда ИИ сгенерирует за 10 секунд, миллион гипотез, но наука всё равно не совершит качественный рывок вперёд - т.к. вместо задачи формирования гипотезы, мы получим задачу опровергнуть 10.
Я не говорю про полную бесполезность ии если он удастся, скорее про то, что вероятно есть фундаментальные ограничения скорости научного прогресса, в которые ИИ моментально упрется и вместо технологической сигнуалярности - мы снова получим небольшой эволюционный рост.
Вам читать цикл про роботов Азимова. Рассказ "Улика"))
Вот давно сам хотел написать статью с рассуждениями на тему того, что возможно тот самый супер - интеллект, который решит все наши проблемы, должен быть невозможен чисто логически. Смысл интелекта - в том, чтобы в условиях недостаточной информации построить предположение, которое дополнит картину для оптимального решения задачи. И тут мы получаем - что это механизм, который из неполных данных строит полные - а значит имеем дело со сжатием - а оно либо с потерями, либо на сжимаемых данных. Если мы говорим про решение всех задач - данные у нас несжимаемые - а значит обязательно будут ошибки. И вот тут мы можем прийти к тому - что гениальность открытий - на деле результат случайности в обучающей выборке или в мире. А значит - обученный на всех знаниях мира ИИ - должен быть примерно так-же хорош в создании открытий - как человек средних знаний т.к. распределение вероятностей в полной выборке будет в среднем совпадать со случайным срезом.
И сейчас то покупать тяжело (зачастую чтобы понять подходит техника или нет например, приходится искать инструкцию на сайте производителя и читать её), а в будущем видимо вообще будет нереально.
Из описанного - реально полезным выглядит ответ на запрос как альтернатива простому поиску - типо "нужна штука чтобы ...". И автоподборки. Но учитывая что пихать они будут из расчёта продать, а не подобрать нуженое - пользоваться все равно не выйдет.
Все остальное - выглядит как усложнение и без того безумно сложных карточек - типо подстраивающегося интерфейса (который ты только выучил, а он подстроился), и не дай бог видео отзывов. Но вероятно так оно и будет(