Неправильно выразился. Я имел ввиду, скорее что падение качества с дистилятами не линейное, и есть ощущение, что "достаточное качество" наступает уже где-то на уровне 48b моделей. И не обязательно сразу упарываться в полную модель, можно постепенно докупая железо остановиться на устраивающем уровне.
Как с принципом паретто - если 20% модели дают 80% результата, то может те оставшиеся 20% результата и нафиг не нужны)
Скорее всего вы ошиблись со специализацией. Есть направления где однотипные задачи, есть где разноплановые. Я намерено устраивался в компании, где "происходит какая то дичь" и намерено же брал все задачи, которые никто не знает как делать и не берет - и соотношение было куда веселее чем 20% на 80)) буквально 3 года у меня были только задачи уровня - "такое никто не делал, как сделать" или "похожий баг во всем интернете в поиске 1, он на китайском стаковерфлоу и без решения". После такого ещё и те задачи, в которых надо писать однотипный код - воспринимаются не как скука, а как моменты передышки перед новым эпическим сражением))
Я бы рекомендовал попробовать сменить либо направление либо работодателя и на бояться тех, кто на собеседовании говорит что у них свой фреймворк, 4 языка программирования в проекте и надо ещё немного уметь писать стихи - вот у таких будут самые интересные задачи - но будет сложно))
И да - про то, что нельзя использовать llm я не говорил, отвечал только на вопрос "в чем кайф".
У меня препод по матану так говорила - программирование это ваше, это просто пальцами в кнопки тыкать, а матан - вот тут наука)))
А на деле - программирование, это что-то на уровне решения задачек из игр - логических головоломок (portal там, talos principal, the witness или viewfinder) - когда у тебя есть кусочки пазла, куча идей как его сложить, и нужно выбрать лучшую, сложить и чтобы работало.
Есть люди, которым это весело) и по соревноваться с машиной и убедиться, что все эти вайбкодерские штуки пока в реальных задачах весьма сомнительны - тоже весело) и когда llm тебе выдаёт крутой код - а ты такой "подиш ты, че могёшь" - и идею конечно подворовываешь, чтобы в будущем использовать - тоже.
А тем кто пришёл в программирование "деньги лутать" - им и промпты писать через два месяца тошно станет, и ломающийся непонятно почему код, и споры с машиной вида - "но выдаёт ошибку - исправил - но всё равно выдает - исправил - но теперь другую выдаёт" - осточертееют - они все равно обречены)
Так есть дистиляты, которые не сильно хуже по качеству но и в 48гб озу влезают и даже в 12vram. Я с такими и работаю на связке idea + continue + ollama и в качестве помошника они отлично справляются. Правда сам continue как будто вайбкодерами написан (как кстати большая часть новомодных ai инструментов, которые кривые косые) и безбожно глючный, замену бы ему.
Побеждает не хорошее и качественное решение - побеждает всегда бабло - пиар, откаты, договорники с аккредитирующими компаниями, монопольные интеграция и прочие грязные методы. Именно из-за этого на пк победила x86 хотя была не лучшей архитектурой, из-за этого microsoft много лет доминирует на рынке настольных компьютеров, хотя windows умудряется с тормозами открывать пуск в 2025 и sap тоже завоевал свое доминирующее положение не качеством и функционалом.
Это не байки, это истории от специалистов поддержки третьей линии, которым это приходится разгребать, и работающих на большой холдинг, мясо которого вы можете купить в любом магазине рф, и не только.
Я может в терминах где-то ошибся, может там не палета а складкское место, или ещё что. Но история с распространяющимися битыми местами, из за которых невозможно было отгрузить поставки - точно была, и устраняли последствия большее месяца, и виновником было единственное битое место, которое ломало кажется коробки или что-то такое, а они ломали товары которые в них помещали.
И история с отрицательным запасом на складе для сапа чуть более чем реальная - когда по одним документам товар приняли, по другим отгрузили, а потом либо приемные поломали, либо приняли не до конца, либо списали параллельно - вот и получилось - что уехало товара больше чем приехало.
И историю с несколькими протухшими грузовиками - потому что товар есть, но отгрузить его не выходит - тоже было. Там то ли с размерностями, толи с округлениями проблемы были. Помню только что расхождение по весу было (из разряда приняли больше, чем отправили кажется) но все в рамках допусков погрешностей.
А вы и дальше верьте в святой безпроблемный сап - для которого три линии поддержки это стандарт, даже поддержка от головного офиса зачастую не решает проблемы, а ошибки имеют вид "Ошибка aa707" - где код указывает не на причину ошибки, а на операцию, в процессе которой ошибка произошла, а там иди - ищи по цепочке какой if не сработал.
Вот пример из жизни - дали мне задачу недавно - разработать api, для решения некоторого функционала.
Первые 3 - 4 часа я изучал задачу продуктово - накидывал пользовательские сценарии, граничные ситуации, проверял как оно работает сейчас. В это время на компьютере у меня была в основном статичная страница, к которой я иногда подбегал чтобы проверить, или записать одну строчку, а сам я вообще ходил по комнате кругами - так думается легче.
Следующие 3 - 4 часа я изучал текущую документацию и имеющиеся api и примерял их на то, что можно изменить - тут тоже была открыта одна старница с докой, которая иногда покручивалась туда сюда.
Дальше день я смотрел код, который уже есть - какие нюансы там есть, как работают разные куски логики которые нужны, с какой стороны к ним можно будет подлезть, чтобы дешево, обратносовместимо, некостыльно - тут тоже вялое кручение кода, хождение кругами, кручение кода, пара строчек записей в txt
Дальше день ушел на прототип, который показал невыловленные проблемы. Весь код конечно был роллбекнут - но тут да, хоть что-то есть показать, хотя... ну для несведущего человека - понять реально ли это прототип или просто что-то накалякано - невозможно.
По итогу на 5ый день - я проверил второй прототип, убедился что правдоподобно, и написал/оформил документацию. Вот - получается итог недели работы - документ на 3 страницы. Какие программы что тут могут доказать?) И как мне приложить к этому то озарение, которое случилось пока я принимал ванну и думал - как сделать, чтобы память не утекала?
Не знаю за что вас минусят, но мы ровно так и делали)) на задачу с полной неопределённостью - выделалось время на раскопки, и по итогу - либо оценка, либо еще итерация, либо решенная задача если повезло.
Специалисты - специализируются в своей области. Принимать решения о том сколько бюджета можно выделить на задачу - точно не область специализации программиста.
Разработчик, которому дали задачу, без ограничения по времени, приоритезированную как "выполнить", без необходимости отчетности, без контроля, без требования оценки - должен решить задачу, что-то другое - он не должен, просто потому, что "слишком долго", "не влезает в бюджет", "не рентабельно" - понятия относительные, и у разработчика (который бюджет/сроки/ущерб даже не знает) - оценить не может.
"Ваши сотрудники всегда будут делать какие-то ошибки, причём зачастую нечаянно, без умысла, а ваш вышестоящий босс, если узнает об этом, в большинстве случаев будет требовать наказать виноватого." - вы сначала спорите с тем, что проблема из за низкой квалификации топ менеджмента, а потом сами приводите пример неадекватного топ менеджмента, который хочет всех наказать.
Как раз адекватный управленец высшего звена не только понимает, что люди на местах будут совершать ошибки, он ещё и учитывает это, закладывает в расходы, оценивает как ошибки минимизировать сохранив кадры и коллектив.
И занимаясь искажением фактов - по итогу топы работают с искажонной информацией, принимают неправильные решения, и всем становится ещё хуже.
Ну и тут очевидно - не менеджер покрывает ошибку программиста, а наоборот - менеджер заставляет программиста покрыть свою ошибку
Куча тварищей работают с сап, в разработке и на разных уровнях линий поддержки. Даже как-то дебажил код с одним из них - они примерно тоже самое говорили. Сап ставится не потому, что он хороший - его тяжело интегрировать, тяжело поддерживать и в целом по моим наблюдениям в том числе - система малоадекватная. Когда у тебя грузовики с мясом тухнут из за того, что пользователь нажал не туда, а чтобы разобраться что пошло не так - нужно пачку спецов, которые ползают по таблицам с названиями типо er_pub_c12 зная их наизусть и сверяют названия переменных и поля (типо а вдруг запас стал отрицательным или поле заполнено с точкой а не запятой разделителем) - это какой-то мрак (хотя зуб давать что 1с лучше не буду, её не видел))). Меня привыкшего к продуктовой разработке вообще поражает, что пользователь может все сломать и местами как будто не то, что защиты от дурака - просто никакой защиты нет.
Были даже истории про то, как неправильно заполненная палета, ломала складское место, оно ломало новые товары которые в него попадали, а они ломали новые места - и это распространялось как вирус и стопорило работу начисто.
Тоже слышал, что используют - из-за откатов (заказал интеграцию в нужной компании, получил денюжку в карман, а цена интеграции сапа в 4 раза выше, значит и денюжки можно в 4 раза больше просить, и обосновать легко), аудитов иностранных компаний (которые зачастую западные и для них не существует ничего незападного), и отчасти возможности работать за рубежом (открывая филиал за пределами рф, специалистов на поддержку туда на 1с найти будет не всегда легко)
Хорошо бы, но пока так не работает. Пару раз уже встречал ситуацию когда бот видит ключевые слова и зацикливается. Вот пример со статусом - ты пишешь - статус моего заказа уже час не движется, всё ли с ним нормально - бот тригерится на слово статус и отвечает что означает текущий статус. Всё. Для него не существует понимания, что если заказ не был за 10 минут принят, то что-то не так, он так и будет отвечать - что все хорошо, статус вашего заказа "принят", это означает, что сейчас его начнут собирать, а потом привезут не беспокойтесь.
Или с банком была ситуация - я пытался уточнить конкретный вопрос который можно было в правилах двояко трактовать (ну например считаются ли активы на брокерском счёте в сумму всех средств на счетах для программы лояльности) - на что мне бот упорно скидывал цитату из документа про которую я собственно и спрашивал, где было что-то из разряда "сумма на всех счетах".
Да, мантра "оператор, оператор, оператор" уже начинает приобретать вид заклинания. (В некоторых сервисах ещё вроде можно матом написать что угодно, и сразу призвать этим человека)
Как ии будет решать фактические вопросы, требующие не отписки а исправления ситуации?
Например ошибки в данных пользователя, проверки чуть глубже автоматической, ситуацию в полях проверять? Никак. Llm способна работать только справочником. И когда у вас например заказ завис на стадии "обработка" и не движется - потому что человек на месте забыл нажать "принять" - оператор позвонит и узнает что с заказом, а ии просто выбесит ответом что "заказ в обработке, это означает что бла бла бла бла бла бла".
Если я позвоню и попрошу скорректировать заказ - а он прогалюцинирует - кто будет платить за кривой заказ?
Чтобы ии соблюдал правила игры - он должен их понимать. Иначе даже самый гениальный настоящий искусственный интеллект не пройдет тест тьюринга - потому что у него нет причин врать что он человек и понимания, что он должен это делать.
Жульничество - это настройка промпта в процессе проведения теста или любые изменения конфигурации по ходу. Если это делается до - то все совершенно честно.
Аналогично - человеку проходящему тест на вождение - перед тестом можно рассказать всё, что угодно о вождении, важно лишь, чтобы в процессе теста все решения он принимал сам.
Вам как владельцу компании, придётся сильно заранее занятся подготовкой, за много лет до иска - снимая наличные по чуть чуть и складывая под подушку. Потому что любая крупная операция со снятием денег со счета сразу привлечёт внимание.
Вам надо не только незаметно передать сумку с деньгами, но ещё и убедить человека не совершать крупных покупок в ближайший год, не класть их на счёт, и вообще никак не привлекать внимания налоговой.
Вам надо найти настолько нелояльного сотрудинка, который сразу согласится с вами сотрудничать. Причём это желательно должен быть первый человк к которому вы обратитесь - потому, что если кто-то даст показания о предложении взятки - делу может поплохеть.
Надо разработать предельно непротиворечивые свидетльские показания. Если свидетель скажет что видел вашу книгу, а потом окажется что издание, которое он видел физически не могло входить в поставку, и видел его только он - то он может внезапно стать из свидетеля подозреваемым в даче заведомо ложных показаний, и при лёгком давлении причин не сдать вас в рамках соглашения у него будет примерно 0, а выдать ему своего хорошего адваката не вызвав подозрений у вас уже не выйдет.
Риск и цена ошибки на каждом шаге огромна, а профит сомнителен т.к. даже показания одного сотрудника могут не сыграть роли без вещественных - ну показалось ему что он видел книгу, ну перепутал - что он, наизусть все названия и авторов помнит, а если именно вашу помнит - то какое-то удобное совпадение - почему?
Бизнесу нужны оценки и сроки и от этого никуда не деться. Иначе невозможно приоритизировать задачи, планировать работу и распределять ресурсы. Без сроков например не понятно - взять задачу А которая принесёт потенциально 3 профита, или Б которая принесёт 7. Если А делать 1, а Б - 10 станет очевидно, что брать надо А, и даже при промахе оценки в разы это будет верно.
Временные рамки также позволяют разработчику реактивно реагировать на изменение понимания задачи - например осознав на 1/3 срока, что задача не уложится и в х2 - разработчик может пойти к ПО и скорректировать либо сроки либо объем задачи. Часто режут задачи чтобы уменьшить ттм в таких случаях. Если разработчик сроков не знает - реагировать на них он не может.
Ну и в целом - в разработке как будто все и так понимают, что оценки и сроки - это прогноз а не факт
Вот я не понял прикола - вероятно в статье что-то не договорено.
Доктрина первой продажи - не допускает создания копий. А оцифровка, в результате которой получается электронная копия исходного текста, которую уже потом грузят в llm - разве не считается копией? Или вгрузка в llm не считается распространением?
Вы хотели сказать - не деньги с компании сдирать, а присесть за подкуп свидетля наверное? Потому что если вы даже попытаетесь "найти в компании человека, который согласиться сдать вас за 5-10+ окладов" - это уже уголовка.
Неправильно выразился. Я имел ввиду, скорее что падение качества с дистилятами не линейное, и есть ощущение, что "достаточное качество" наступает уже где-то на уровне 48b моделей. И не обязательно сразу упарываться в полную модель, можно постепенно докупая железо остановиться на устраивающем уровне.
Как с принципом паретто - если 20% модели дают 80% результата, то может те оставшиеся 20% результата и нафиг не нужны)
Скорее всего вы ошиблись со специализацией. Есть направления где однотипные задачи, есть где разноплановые. Я намерено устраивался в компании, где "происходит какая то дичь" и намерено же брал все задачи, которые никто не знает как делать и не берет - и соотношение было куда веселее чем 20% на 80)) буквально 3 года у меня были только задачи уровня - "такое никто не делал, как сделать" или "похожий баг во всем интернете в поиске 1, он на китайском стаковерфлоу и без решения". После такого ещё и те задачи, в которых надо писать однотипный код - воспринимаются не как скука, а как моменты передышки перед новым эпическим сражением))
Я бы рекомендовал попробовать сменить либо направление либо работодателя и на бояться тех, кто на собеседовании говорит что у них свой фреймворк, 4 языка программирования в проекте и надо ещё немного уметь писать стихи - вот у таких будут самые интересные задачи - но будет сложно))
И да - про то, что нельзя использовать llm я не говорил, отвечал только на вопрос "в чем кайф".
У меня препод по матану так говорила - программирование это ваше, это просто пальцами в кнопки тыкать, а матан - вот тут наука)))
А на деле - программирование, это что-то на уровне решения задачек из игр - логических головоломок (portal там, talos principal, the witness или viewfinder) - когда у тебя есть кусочки пазла, куча идей как его сложить, и нужно выбрать лучшую, сложить и чтобы работало.
Есть люди, которым это весело) и по соревноваться с машиной и убедиться, что все эти вайбкодерские штуки пока в реальных задачах весьма сомнительны - тоже весело) и когда llm тебе выдаёт крутой код - а ты такой "подиш ты, че могёшь" - и идею конечно подворовываешь, чтобы в будущем использовать - тоже.
А тем кто пришёл в программирование "деньги лутать" - им и промпты писать через два месяца тошно станет, и ломающийся непонятно почему код, и споры с машиной вида - "но выдаёт ошибку - исправил - но всё равно выдает - исправил - но теперь другую выдаёт" - осточертееют - они все равно обречены)
Дистиляты
Так есть дистиляты, которые не сильно хуже по качеству но и в 48гб озу влезают и даже в 12vram. Я с такими и работаю на связке idea + continue + ollama и в качестве помошника они отлично справляются. Правда сам continue как будто вайбкодерами написан (как кстати большая часть новомодных ai инструментов, которые кривые косые) и безбожно глючный, замену бы ему.
Побеждает не хорошее и качественное решение - побеждает всегда бабло - пиар, откаты, договорники с аккредитирующими компаниями, монопольные интеграция и прочие грязные методы. Именно из-за этого на пк победила x86 хотя была не лучшей архитектурой, из-за этого microsoft много лет доминирует на рынке настольных компьютеров, хотя windows умудряется с тормозами открывать пуск в 2025 и sap тоже завоевал свое доминирующее положение не качеством и функционалом.
Это не байки, это истории от специалистов поддержки третьей линии, которым это приходится разгребать, и работающих на большой холдинг, мясо которого вы можете купить в любом магазине рф, и не только.
Я может в терминах где-то ошибся, может там не палета а складкское место, или ещё что. Но история с распространяющимися битыми местами, из за которых невозможно было отгрузить поставки - точно была, и устраняли последствия большее месяца, и виновником было единственное битое место, которое ломало кажется коробки или что-то такое, а они ломали товары которые в них помещали.
И история с отрицательным запасом на складе для сапа чуть более чем реальная - когда по одним документам товар приняли, по другим отгрузили, а потом либо приемные поломали, либо приняли не до конца, либо списали параллельно - вот и получилось - что уехало товара больше чем приехало.
И историю с несколькими протухшими грузовиками - потому что товар есть, но отгрузить его не выходит - тоже было. Там то ли с размерностями, толи с округлениями проблемы были. Помню только что расхождение по весу было (из разряда приняли больше, чем отправили кажется) но все в рамках допусков погрешностей.
А вы и дальше верьте в святой безпроблемный сап - для которого три линии поддержки это стандарт, даже поддержка от головного офиса зачастую не решает проблемы, а ошибки имеют вид "Ошибка aa707" - где код указывает не на причину ошибки, а на операцию, в процессе которой ошибка произошла, а там иди - ищи по цепочке какой if не сработал.
Вот пример из жизни - дали мне задачу недавно - разработать api, для решения некоторого функционала.
Первые 3 - 4 часа я изучал задачу продуктово - накидывал пользовательские сценарии, граничные ситуации, проверял как оно работает сейчас. В это время на компьютере у меня была в основном статичная страница, к которой я иногда подбегал чтобы проверить, или записать одну строчку, а сам я вообще ходил по комнате кругами - так думается легче.
Следующие 3 - 4 часа я изучал текущую документацию и имеющиеся api и примерял их на то, что можно изменить - тут тоже была открыта одна старница с докой, которая иногда покручивалась туда сюда.
Дальше день я смотрел код, который уже есть - какие нюансы там есть, как работают разные куски логики которые нужны, с какой стороны к ним можно будет подлезть, чтобы дешево, обратносовместимо, некостыльно - тут тоже вялое кручение кода, хождение кругами, кручение кода, пара строчек записей в txt
Дальше день ушел на прототип, который показал невыловленные проблемы. Весь код конечно был роллбекнут - но тут да, хоть что-то есть показать, хотя... ну для несведущего человека - понять реально ли это прототип или просто что-то накалякано - невозможно.
По итогу на 5ый день - я проверил второй прототип, убедился что правдоподобно, и написал/оформил документацию.
Вот - получается итог недели работы - документ на 3 страницы. Какие программы что тут могут доказать?) И как мне приложить к этому то озарение, которое случилось пока я принимал ванну и думал - как сделать, чтобы память не утекала?
Не знаю за что вас минусят, но мы ровно так и делали)) на задачу с полной неопределённостью - выделалось время на раскопки, и по итогу - либо оценка, либо еще итерация, либо решенная задача если повезло.
Специалисты - специализируются в своей области. Принимать решения о том сколько бюджета можно выделить на задачу - точно не область специализации программиста.
Разработчик, которому дали задачу, без ограничения по времени, приоритезированную как "выполнить", без необходимости отчетности, без контроля, без требования оценки - должен решить задачу, что-то другое - он не должен, просто потому, что "слишком долго", "не влезает в бюджет", "не рентабельно" - понятия относительные, и у разработчика (который бюджет/сроки/ущерб даже не знает) - оценить не может.
"Ваши сотрудники всегда будут делать какие-то ошибки, причём зачастую нечаянно, без умысла, а ваш вышестоящий босс, если узнает об этом, в большинстве случаев будет требовать наказать виноватого." - вы сначала спорите с тем, что проблема из за низкой квалификации топ менеджмента, а потом сами приводите пример неадекватного топ менеджмента, который хочет всех наказать.
Как раз адекватный управленец высшего звена не только понимает, что люди на местах будут совершать ошибки, он ещё и учитывает это, закладывает в расходы, оценивает как ошибки минимизировать сохранив кадры и коллектив.
И занимаясь искажением фактов - по итогу топы работают с искажонной информацией, принимают неправильные решения, и всем становится ещё хуже.
Ну и тут очевидно - не менеджер покрывает ошибку программиста, а наоборот - менеджер заставляет программиста покрыть свою ошибку
Куча тварищей работают с сап, в разработке и на разных уровнях линий поддержки. Даже как-то дебажил код с одним из них - они примерно тоже самое говорили. Сап ставится не потому, что он хороший - его тяжело интегрировать, тяжело поддерживать и в целом по моим наблюдениям в том числе - система малоадекватная. Когда у тебя грузовики с мясом тухнут из за того, что пользователь нажал не туда, а чтобы разобраться что пошло не так - нужно пачку спецов, которые ползают по таблицам с названиями типо er_pub_c12 зная их наизусть и сверяют названия переменных и поля (типо а вдруг запас стал отрицательным или поле заполнено с точкой а не запятой разделителем) - это какой-то мрак (хотя зуб давать что 1с лучше не буду, её не видел))). Меня привыкшего к продуктовой разработке вообще поражает, что пользователь может все сломать и местами как будто не то, что защиты от дурака - просто никакой защиты нет.
Были даже истории про то, как неправильно заполненная палета, ломала складское место, оно ломало новые товары которые в него попадали, а они ломали новые места - и это распространялось как вирус и стопорило работу начисто.
Тоже слышал, что используют - из-за откатов (заказал интеграцию в нужной компании, получил денюжку в карман, а цена интеграции сапа в 4 раза выше, значит и денюжки можно в 4 раза больше просить, и обосновать легко), аудитов иностранных компаний (которые зачастую западные и для них не существует ничего незападного), и отчасти возможности работать за рубежом (открывая филиал за пределами рф, специалистов на поддержку туда на 1с найти будет не всегда легко)
Хорошо бы, но пока так не работает. Пару раз уже встречал ситуацию когда бот видит ключевые слова и зацикливается. Вот пример со статусом - ты пишешь - статус моего заказа уже час не движется, всё ли с ним нормально - бот тригерится на слово статус и отвечает что означает текущий статус. Всё. Для него не существует понимания, что если заказ не был за 10 минут принят, то что-то не так, он так и будет отвечать - что все хорошо, статус вашего заказа "принят", это означает, что сейчас его начнут собирать, а потом привезут не беспокойтесь.
Или с банком была ситуация - я пытался уточнить конкретный вопрос который можно было в правилах двояко трактовать (ну например считаются ли активы на брокерском счёте в сумму всех средств на счетах для программы лояльности) - на что мне бот упорно скидывал цитату из документа про которую я собственно и спрашивал, где было что-то из разряда "сумма на всех счетах".
😄😄😄 вот тут он как бы понял, а с другой стороны под рукой ли у вас номер яваточкаобджектточкаобджектточкалогинточканольноль)
Да, мантра "оператор, оператор, оператор" уже начинает приобретать вид заклинания. (В некоторых сервисах ещё вроде можно матом написать что угодно, и сразу призвать этим человека)
Как ии будет решать фактические вопросы, требующие не отписки а исправления ситуации?
Например ошибки в данных пользователя, проверки чуть глубже автоматической, ситуацию в полях проверять? Никак. Llm способна работать только справочником. И когда у вас например заказ завис на стадии "обработка" и не движется - потому что человек на месте забыл нажать "принять" - оператор позвонит и узнает что с заказом, а ии просто выбесит ответом что "заказ в обработке, это означает что бла бла бла бла бла бла".
Если я позвоню и попрошу скорректировать заказ - а он прогалюцинирует - кто будет платить за кривой заказ?
Чтобы ии соблюдал правила игры - он должен их понимать. Иначе даже самый гениальный настоящий искусственный интеллект не пройдет тест тьюринга - потому что у него нет причин врать что он человек и понимания, что он должен это делать.
Жульничество - это настройка промпта в процессе проведения теста или любые изменения конфигурации по ходу. Если это делается до - то все совершенно честно.
Аналогично - человеку проходящему тест на вождение - перед тестом можно рассказать всё, что угодно о вождении, важно лишь, чтобы в процессе теста все решения он принимал сам.
Вам как владельцу компании, придётся сильно заранее занятся подготовкой, за много лет до иска - снимая наличные по чуть чуть и складывая под подушку. Потому что любая крупная операция со снятием денег со счета сразу привлечёт внимание.
Вам надо не только незаметно передать сумку с деньгами, но ещё и убедить человека не совершать крупных покупок в ближайший год, не класть их на счёт, и вообще никак не привлекать внимания налоговой.
Вам надо найти настолько нелояльного сотрудинка, который сразу согласится с вами сотрудничать. Причём это желательно должен быть первый человк к которому вы обратитесь - потому, что если кто-то даст показания о предложении взятки - делу может поплохеть.
Надо разработать предельно непротиворечивые свидетльские показания. Если свидетель скажет что видел вашу книгу, а потом окажется что издание, которое он видел физически не могло входить в поставку, и видел его только он - то он может внезапно стать из свидетеля подозреваемым в даче заведомо ложных показаний, и при лёгком давлении причин не сдать вас в рамках соглашения у него будет примерно 0, а выдать ему своего хорошего адваката не вызвав подозрений у вас уже не выйдет.
Риск и цена ошибки на каждом шаге огромна, а профит сомнителен т.к. даже показания одного сотрудника могут не сыграть роли без вещественных - ну показалось ему что он видел книгу, ну перепутал - что он, наизусть все названия и авторов помнит, а если именно вашу помнит - то какое-то удобное совпадение - почему?
Бизнесу нужны оценки и сроки и от этого никуда не деться. Иначе невозможно приоритизировать задачи, планировать работу и распределять ресурсы. Без сроков например не понятно - взять задачу А которая принесёт потенциально 3 профита, или Б которая принесёт 7. Если А делать 1, а Б - 10 станет очевидно, что брать надо А, и даже при промахе оценки в разы это будет верно.
Временные рамки также позволяют разработчику реактивно реагировать на изменение понимания задачи - например осознав на 1/3 срока, что задача не уложится и в х2 - разработчик может пойти к ПО и скорректировать либо сроки либо объем задачи. Часто режут задачи чтобы уменьшить ттм в таких случаях. Если разработчик сроков не знает - реагировать на них он не может.
Ну и в целом - в разработке как будто все и так понимают, что оценки и сроки - это прогноз а не факт
Вот я не понял прикола - вероятно в статье что-то не договорено.
Доктрина первой продажи - не допускает создания копий. А оцифровка, в результате которой получается электронная копия исходного текста, которую уже потом грузят в llm - разве не считается копией? Или вгрузка в llm не считается распространением?
Звучит как будто очень очень тонко тут всё
Вы хотели сказать - не деньги с компании сдирать, а присесть за подкуп свидетля наверное? Потому что если вы даже попытаетесь "найти в компании человека, который согласиться сдать вас за 5-10+ окладов" - это уже уголовка.