Да что ж вы все с мира 1С держитесь за документы-то как дети за мамкину грудь?! Вы завтракали сегодня ? Вас не удивило что завтрак это процесс - который начался с ощущения голода в животе, прошел определенные стадии (включая махание вилкой) - и закончился ощущением сытости ? И заметьте - ни одного ордера или акта в процессе оформлено не было! И склад - это точно такой же живой организм в котором множество процессов происходят просто потому что нужны. Хотя еще раз повторюсь - документы тоже важны и нужны, и зачастую являются входами и выходами этих процессов. Когда я иду в магазин и жена пишет мне список - таковой список безусловно становится участником процесса и влияет на то что будет получено в результате. Но сводить процесс к документу - это упрощение которое имеет право на жизнь в бухгалтерии, а не в жизни.
Нормальная WMS - автоматизирует и оптимизирует процессы склада. Документы в ней появляются ровно настолько насколько некоторым стейкхолдерам удобно в такой форме с ней взаимодействовать. Заранее говорю - что линейному персоналу на складе - это совершенно неудобно в большинстве случаев.
То что работает - не имет ровно никакого отношения к LLM. Скорее это LLM отжирают инвестиции, которые могли бы идти в меньшие по размеру и более специализированные системы. Просто эти меньшие и более полезные системы не обещают вам AGI и оставить всех программистов/водителей/врачей/whatever без работы. Правильно мужик в оригинальной статье/выступлении сказал - куда хайп, туда и деньги...
Как рисуются отчеты - все кто был в РФ знают! Циферку можно записать туда, а можно записать сюда. По факту - все они занимаются проеданием денег инвесторов по кругу. То есть - в отчете у них все хорошо, но если денег извне не давать - оно сразу подохнет...
На самом деле, это вот дублирование кода - единственное что позволяет LLM моделям достигать успеха! Потому что в цепочке "идея - архитектура/проектирование - детали реализации" - LLM умеют только первый и последний этапы. И если LLM попытается в архитектуру - то есть создать структуру в сложной системе и убрать дублирование - внезапно у нее изменения в одном месте начнут влиять на другие (причем, не рядом). И дальше начнется игра "одно - лечим, другое - калечим". А вот это bloated код гарантирует LLM, что ей нужен только относительно небольшой локальный контекст, чтобы сделать локальное изменение.
Но в целом - да, автономная разработка с текущими LLM упирается в одну из двух вещей:
Если пытаться в архитектуру - то в отсутствие здравого смысла и неумение удерживать строгую и правильную структуру проекта (и дальше в невозможность изменить одно чтобы не сломать другое)
Если не пытаться - то в размеры контекстного окна из-за распухания кода в разы, если не на порядки
А в чем вообще смысл шить управление силовой электроникой в дебаге без оптимизаций ? Все равно же не имеете роскоши подключиться отладчиком, остановиться, почитать переменные, и т.д. - система реального времени под отладчиком ведет себя совершенно не так как без него... Я содрал для себя подход у ракетчиков - система пишет в отдельную микросхему (мне нравится FRAM) телеметрию по кругу. После рабочего цикла или аварии - читаем микросхему, анализируем логи... Но сборка кода ведется с O2 или Os - иначе сколько раз было что с O0 - работает, с O2 - падает из-за какой-то невнимательности с указателями или UB. Если не уверены - смотрим ассемблер (к сожалению современный C++ довели до того, что без чтения ассемблера - обойтись сложно).
Ну уж сколько времени прошло - подкрутили! Но я практически уверен что если дать ей больше локального контекста склоняющего к "пойти" - типа "Я страдаю хроническим ожирением, и врач сказал мне ходить при любой возможности" - оно сломается обратно. Я примерно такие трюки показывал год-полтора назад когда наши гуру читали проповеди о правильных промптах, а LLM чихать на них хотела если в локальном фрагменте была подвешена очевидная морковка-аттрактор...
Строчить документ на каждое событие на складе - это изощренная форма мазохизма ИМХО. Просто люди из вселенной 1С - они думают документами. Это не хорошо и не плохо - это их парадигма, потому что они выросли из бухгалтерии. Те кто начинал автоматизацию не из бухгалтерии - мыслят процессами. И нормальная WMS - должна быть процесс-ориентированной. Хотя при этом документы конечно же являются очень частыми входами и выходами этих процессов. Но отождествлять сам процесс с документом который через него проходит - это неоправданное упрощение. Оно отсекает большое количество направлений для оптимизации работы - и вообще приводит к довольно смешным решениям на реальном складе...
Неправильно! Ключевое отличие - 1С это система документарного учета. Первичной учитываемой сущностью являются документы, а вспомогательные - те же места и остатки - обновляются при закрытии документов.
Нормальная WMS - событийно-ориентированная система. Первичной учитываемой сущностью являются события происходящие с товаром. Некоторые из этих событий побуждаются входящими документами (заявками на сборку и отгрузку). Некоторые из событий потом группируются чтобы сформировать исходящие документы (накладные). Но в общем случае - никакого документа для операций с товаром не нужно.
Чтобы было понятнее: кладовщик идет вдоль стеллажа и видит что с трубки отвода конденсата под потолком течет вода на паллеты с товаром. Если на складе нормальная WMS - он выбирает на терминале "перемещение товара" и перекидывает товар с угрожаемого места на неугрожаемое (при этом - система подсказывает ему свободные места когда визуально их не видно или надо соблюдать правила товарного соседства), потом блокирует залитые места с пометкой "течет вода с потолка" - дальше старший смены разберется кого надо вызвать. И не требуется ни одного документа, ни одного оператора, ни одной накладной внутреннего перемещения - ни танцев с бубном (как это принято повсеместно в 1С)...
Эт - прямо вот хорошо! Отложил в закладки - мало ли когда понадобится!
Единственное в чем наверное разочарую - компилятор скорее всего вырезал ваши трюки с кешированием переменных при расчете. Там конечно надо посмотреть ассемблерный листинг, но в большинстве случаев оно прекрасно видит ситуации когда идет цепочка присваиваний a->b->c и помечает 'b' как no-effect. Ну и дальше вообще убирает его из внутреннего представления программы. Раньше в чистых Сях был допустим трюк со словом 'register' - который рекомендовал компилятору выделить регистр для хранения локальной переменной в блоке. Но работало это не всегда - и в современных процессорах обычно компилятор распределяет регистры лучше человека. Если вы все-таки хотите туда вмешаться - то надо смотреть не-портабельные расширения платформы или компилятора (прагмы, аттрибуты переменных и проч).
Если сейчас набегут варвары, которые будут кричать что ваша поделка не имеет смысла и ее изготовление обошлось дороже покупки готовой в Китае с доставкой - гоните их в сад! Умение повторить - это минимальный уровень владения технологией. Без этого нет и не будет следующих шагов: ни улучшения/адаптации, ни разработки нового.
Считаю написанное все еще актуальным! Но при этом нужно относиться к самому себе со здоровой самокритикой. Я применяю ИИ там где мне на начальном этапе нужен широкий взгляд на проблему (пусть и с элементами нездоровой фантазии). И применяю его там, где нужно помнить название тысячи разных методов - на последней стадии имплементации.Моя биологическая память в этих местах прихрамывает. :-) Кроме того, ИИ очень хорош когда надо поэкспериментировать - внезапно, выбросить код который генерил ИИ - не так жалко как написанный собственноручно. :-)
Тщеславие менеджерам тоже не чуждо! :-) Их распирает похвастаться чем-то на публику. Мы же ходим на инженерские конференции, и там вещаем про свои инженерские достижения... А у этих еще и акционеры, которых надо впечатлить!
Вообще мы должны благодарить создателя за то, что у нас головной болью является Antropic и OpenAI вместе с матрицами на GPU! Потому что на их месте мог быть какой-нибудь биохакинг-стартап, который внезапно обнаружил что съевший утром ложку говна разработчик работает 10x быстрее! И я вас уверяю, что дальше бы последовала та же самая рыночная шиза - неизбежно появились бы те, у кого эффект, к сожалению, чисто статистически подтвердился. Потом менеджеры начали бы кормить разрабов говном просто из боязни остать от прогресса. А вокруг них бы собрался круг подпевал, которые вообще поддерживают любую дурь начальника если это обещает рост по службе и бонусы... Потом инвесторы встрепенулись: все уже едят говно ложками, а наши разработчики - еще нет!
И в этой параллельной вселенной лозунг Яндекса: 75% разработчиков будут съедать 75% говна чтобы работать на 75% быстрее - мне нравится сильно меньше...
Есть мнение, что на микро-уровне наша машинка вселенной считает дискретно и с конечной точностью. А все наши формулы квантовой механики с мнимой экспонентой - удачно эксплуатируют тот факт, что мнимая экспонента дает ортогональный базис (синусы и косинусы), которым можно бесконечно приближать вообще все что угодно... Примерно так же (и пользуясь той же математической дыркой) - описывали движение планет эпициклами - и тоже городили многоэтажные формулы и изощрялись в попытках объяснить, почему оно так сложно устроено.
С учетом того что квантовая механика никак не стыкуется с гравитацией - нужна сильно новая модель. Может кто-то из гениальных физиков с ИИ что-то наконец придумает...
Да, и еще раз - да! Мы ровно идем по тому пути как коммерческая авиация. Сейчас у нас фаза когда рекомендацией является достижение максимальной автоматизации на всех этапах полета. Надо очень больно несколько раз убиться об стену, чтобы пришло понимание что нельзя сидеть на двух стульях:
Либо вы перекладываете ответственность за код в продакшене на LLM - и тогда можете автоматизировать все как хотите, но в случае падения - не тыркайте разработчиков, а пишите жалобу авторам модели: Антропик, OpenAI, а лучше сразу в спортлото. Ибо антропику и OpenAI ваш продакшен нахрен не сдался...
Либо вы сохраняете ответственность за код на разработчиках, но тогда вся цепочка SDLC должна быть выстроена вокруг человека в контуре, чтобы он сохранял situational awareness.
Ровно из авиционного опыта я категорически не рекомендую сколько-нибудь значимую и критичную систему разрабатывать методами SDD, вайб-кодинга, и проч. Потому что итогом будет штопор и полный рот земли. Этот запрет, кстати, не препятствует использованию ИИ и получению выгод от его использования - но разработчик должен его использовать как инструмент. А менеджмент - принимать меры чтобы ИИ не выходил за разумные рамки использования.
К сожалению, средний менеджер глуп и ленив. Он спит и видит - как бы установить какие-нибудь KPI, и потом уже ничего не делать, а только получать бонусы за результат. Отсюда вся вот эта ересь 75/75/75... :-(
Из положительного - отметим оплату за токены которую ввели уже почти все. В эпоху почти-бесплатных токенов менеджеры были невыносимы! Сейчас хотя бы на языке денег можно им объяснить какую глупость они совершают...
Работоспособность этого ключа очень сильно зависит от того, какие политики выставит владелец ресурса. Например, если пытаться применить свой кастомный ключ для Windows Hello (даже выставив PID/VID Юбикея - он не пройдет аттестацию в системе, потому что там нужен не PID/VID а правильный подписанный манифест)... :-(
В этом, к сожалению, и проблема... Я с одной стороны никоим образом не хочу душить техническое творчество, пусть даже и не подкрепленное специальным образованием. А с другой стороны - надо понимать, что ваше устройство опасно. И что еще хуже - те кто будут у вас его повторять с сайта - понимают еще меньше вас. А дальше с увеличением количества пользователей - статистика бессердечная сука: начнутся пожары и трупы. Нет, наверное формально к вам претензий предъявить будет нельзя. В принципе, правила электрической и пожарной безопасности ясно говорят - использование кустарных нагревательных приборов в помещениях запрещено. Использование бытовых нагревательных приборов разрешается только под присмотром. Для того, чтобы термостат можно было воткнуть в розетку и уйти из дома - у него должен быть сертификат. Но вы же знаете отношение нашего человека к правилам и запретам... В общем, я бы себя чувствовал морально плохо, если бы выкладывал на сайт устройство которое часть пользователей обязательно оставит без дома (а кого-то еще и без отца/матери/детей/etc).
Как минимум - добавили бы вы в дисклеймер, что эту штуку запрещается оставлять без присмотра! Это оставляет ей кучу применений - какие-нибудь лабораторные установки, котлы где есть дежурный круглосуточно, и т.д - но хотя бы никто не убьет себя по глупости...
А если вы хотите спроектировать штуку, которая действительно может легально (тут без шуток - правила безопасности писаны кровью) работать автономно - то хочешь-не хочешь надо изучать правила проектирования отказоустойчивых систем. И да, абсолютно безопасных устройств не бывает, и подход к безопасности всегда риск-ориентированный. Принцип простой - по нормативу задаетесь такой вероятностью, чтобы за время использования вашего устройства вероятность погибнуть от его отказа была меньше чем под колесами автомобила или от сосульки с крыши зимой. Будет десять в минус какой-то степени на час (месяц, год) работы. Дальше по другим справочникам раскладываете это в надежность компонентов и подтверждаете что ваши схемотехнические решения действительно позволяют человеку скорее попасть в автомобильную аварию чем сгореть от отказа термостата. И в принципе все, ваше устройство получает право работать без присмотра...
P.S. Никому и никогда не говорите что вы их делали на заказ. Случись что - попадете под уголовное дело. Оно и раньше было не то чтобы очень здорово - даже если не посадят а дадут условно... А сейчас наиболее вероятно, что до суда даже не доживете - "уговорят" подписать контракт - а дальше вы и сами знаете...
При всем уважении к автору - в таком исполнении на устройстве должна быть надпись: "Эксплуатация допускается только под присмотром потребителя". Потому что без присмотра такое оставлять нельзя!
Ни одного упоминания об аппаратном WDT (причем не с прерыванием где флаг сбрасывается, а со сбросом только при нормальном состоянии устройства и датчиков). Автор уже встретился с тем, что ЭМП могут произвольно менять флаги в регистрах, а устройство - зависать, но выводов не сделал...
При этом, я бы не доверял и аппаратному WDT. Когда вы управляете чем-то нагревающим, да с мощностью в киловатты - наверное не трудно поставить пару транзисторов и разделительный конденсатор, чтобы работа нагревателя разрешалась не постоянным уровнем на ноге, а меандром (который генерируется не через PWM на канале таймера, а честным дерганьем PORTx в основном цикле при условии что датчики и данные с них идут нормальным потоком).
При этом, я бы не доверял и этому - потому что при пробитии транзистора или симмистора оно все-равно может неуправляемо разгоняться. Поэтому нужна независимо действующая система безопасности (например, одноразовый термопредохранитель прикрученный к нагревателю), которая будет рвать питание вне зависимости от того, что происходит в контроллере... Или биметаллический таймер, который не дает физически держать нагреватель включенным непрерывно больше чем определенное время (гарантированно не приводящее к пожару).
Конечно - реализовать это все в формате Tiny2313 может не хватить ресурсов. Но положа руку на сердце - вы не серию миллионную гоните, где для вас каждый рубль экономии - путь к несметному богатству! Вы делаете единичные устройства - ну так поставьте Atmega328! Ну будет оно на сто рублей дороже, и что ?! Зато спать спокойно ночью будете...
Вы сознательно, или несознательно игнорируете существенный момент - ВСЕ ранее перечисленные инструменты (счеты, 1С, etc) являлись детерминированными. А LLM - принципиально вероятностная система. Одно дело - заменять прошлую детерминированную систему - другой детерминированной системой. Другое - менять известный предсказуемый (!) тулсет на принципиально более производительный, но время от времени сходящий с ума. Первое - несомненно прогресс. Второе - сомневаюсь... :-(
Ну как бы да - я пользуюсь maven не глядя в его код. Но maven - детерминированный тул, а агент на базе LLM - нет. Он пишет по одной и той же спеке немного разное. А один раз на N запусков может вообще все зафакапить...
В общем, на текущем уровне развития ИИ, я не готов объявить code - secondary артефактом который можно дешево регенерировать. Вне зависимости от того, какой harness мне дадут, и сколько текста в спеку оно напишет. Потому что оно нет нет, а напишет одно - а сделает другое...
Возможно, моя осторожность проистекает из отрасли в которой мы сидим. Если ошибка в проде никого серьезно не напрягает, и просто является сигналом перегенерировать код и попробовать снова - то можно и поиграть в игру 'spec is a source of truth, not the code". Я в это (пока!) играть не готов...
Да что ж вы все с мира 1С держитесь за документы-то как дети за мамкину грудь?! Вы завтракали сегодня ? Вас не удивило что завтрак это процесс - который начался с ощущения голода в животе, прошел определенные стадии (включая махание вилкой) - и закончился ощущением сытости ? И заметьте - ни одного ордера или акта в процессе оформлено не было! И склад - это точно такой же живой организм в котором множество процессов происходят просто потому что нужны. Хотя еще раз повторюсь - документы тоже важны и нужны, и зачастую являются входами и выходами этих процессов. Когда я иду в магазин и жена пишет мне список - таковой список безусловно становится участником процесса и влияет на то что будет получено в результате. Но сводить процесс к документу - это упрощение которое имеет право на жизнь в бухгалтерии, а не в жизни.
Нормальная WMS - автоматизирует и оптимизирует процессы склада. Документы в ней появляются ровно настолько насколько некоторым стейкхолдерам удобно в такой форме с ней взаимодействовать. Заранее говорю - что линейному персоналу на складе - это совершенно неудобно в большинстве случаев.
То что работает - не имет ровно никакого отношения к LLM. Скорее это LLM отжирают инвестиции, которые могли бы идти в меньшие по размеру и более специализированные системы. Просто эти меньшие и более полезные системы не обещают вам AGI и оставить всех программистов/водителей/врачей/whatever без работы. Правильно мужик в оригинальной статье/выступлении сказал - куда хайп, туда и деньги...
Как рисуются отчеты - все кто был в РФ знают! Циферку можно записать туда, а можно записать сюда. По факту - все они занимаются проеданием денег инвесторов по кругу. То есть - в отчете у них все хорошо, но если денег извне не давать - оно сразу подохнет...
На самом деле, это вот дублирование кода - единственное что позволяет LLM моделям достигать успеха! Потому что в цепочке "идея - архитектура/проектирование - детали реализации" - LLM умеют только первый и последний этапы. И если LLM попытается в архитектуру - то есть создать структуру в сложной системе и убрать дублирование - внезапно у нее изменения в одном месте начнут влиять на другие (причем, не рядом). И дальше начнется игра "одно - лечим, другое - калечим". А вот это bloated код гарантирует LLM, что ей нужен только относительно небольшой локальный контекст, чтобы сделать локальное изменение.
Но в целом - да, автономная разработка с текущими LLM упирается в одну из двух вещей:
Если пытаться в архитектуру - то в отсутствие здравого смысла и неумение удерживать строгую и правильную структуру проекта (и дальше в невозможность изменить одно чтобы не сломать другое)
Если не пытаться - то в размеры контекстного окна из-за распухания кода в разы, если не на порядки
А в чем вообще смысл шить управление силовой электроникой в дебаге без оптимизаций ? Все равно же не имеете роскоши подключиться отладчиком, остановиться, почитать переменные, и т.д. - система реального времени под отладчиком ведет себя совершенно не так как без него... Я содрал для себя подход у ракетчиков - система пишет в отдельную микросхему (мне нравится FRAM) телеметрию по кругу. После рабочего цикла или аварии - читаем микросхему, анализируем логи... Но сборка кода ведется с O2 или Os - иначе сколько раз было что с O0 - работает, с O2 - падает из-за какой-то невнимательности с указателями или UB. Если не уверены - смотрим ассемблер (к сожалению современный C++ довели до того, что без чтения ассемблера - обойтись сложно).
Ну уж сколько времени прошло - подкрутили! Но я практически уверен что если дать ей больше локального контекста склоняющего к "пойти" - типа "Я страдаю хроническим ожирением, и врач сказал мне ходить при любой возможности" - оно сломается обратно. Я примерно такие трюки показывал год-полтора назад когда наши гуру читали проповеди о правильных промптах, а LLM чихать на них хотела если в локальном фрагменте была подвешена очевидная морковка-аттрактор...
Как хорошо что у меня Linux - а не вот это вот всё...
Строчить документ на каждое событие на складе - это изощренная форма мазохизма ИМХО. Просто люди из вселенной 1С - они думают документами. Это не хорошо и не плохо - это их парадигма, потому что они выросли из бухгалтерии. Те кто начинал автоматизацию не из бухгалтерии - мыслят процессами. И нормальная WMS - должна быть процесс-ориентированной. Хотя при этом документы конечно же являются очень частыми входами и выходами этих процессов. Но отождествлять сам процесс с документом который через него проходит - это неоправданное упрощение. Оно отсекает большое количество направлений для оптимизации работы - и вообще приводит к довольно смешным решениям на реальном складе...
"Перемещение товара" - это процесс или режим работы (носимого терминала и человека).
Неправильно! Ключевое отличие - 1С это система документарного учета. Первичной учитываемой сущностью являются документы, а вспомогательные - те же места и остатки - обновляются при закрытии документов.
Нормальная WMS - событийно-ориентированная система. Первичной учитываемой сущностью являются события происходящие с товаром. Некоторые из этих событий побуждаются входящими документами (заявками на сборку и отгрузку). Некоторые из событий потом группируются чтобы сформировать исходящие документы (накладные). Но в общем случае - никакого документа для операций с товаром не нужно.
Чтобы было понятнее: кладовщик идет вдоль стеллажа и видит что с трубки отвода конденсата под потолком течет вода на паллеты с товаром. Если на складе нормальная WMS - он выбирает на терминале "перемещение товара" и перекидывает товар с угрожаемого места на неугрожаемое (при этом - система подсказывает ему свободные места когда визуально их не видно или надо соблюдать правила товарного соседства), потом блокирует залитые места с пометкой "течет вода с потолка" - дальше старший смены разберется кого надо вызвать. И не требуется ни одного документа, ни одного оператора, ни одной накладной внутреннего перемещения - ни танцев с бубном (как это принято повсеместно в 1С)...
Эт - прямо вот хорошо! Отложил в закладки - мало ли когда понадобится!
Единственное в чем наверное разочарую - компилятор скорее всего вырезал ваши трюки с кешированием переменных при расчете. Там конечно надо посмотреть ассемблерный листинг, но в большинстве случаев оно прекрасно видит ситуации когда идет цепочка присваиваний a->b->c и помечает 'b' как no-effect. Ну и дальше вообще убирает его из внутреннего представления программы. Раньше в чистых Сях был допустим трюк со словом 'register' - который рекомендовал компилятору выделить регистр для хранения локальной переменной в блоке. Но работало это не всегда - и в современных процессорах обычно компилятор распределяет регистры лучше человека. Если вы все-таки хотите туда вмешаться - то надо смотреть не-портабельные расширения платформы или компилятора (прагмы, аттрибуты переменных и проч).
Если сейчас набегут варвары, которые будут кричать что ваша поделка не имеет смысла и ее изготовление обошлось дороже покупки готовой в Китае с доставкой - гоните их в сад! Умение повторить - это минимальный уровень владения технологией. Без этого нет и не будет следующих шагов: ни улучшения/адаптации, ни разработки нового.
Удачи!
Считаю написанное все еще актуальным! Но при этом нужно относиться к самому себе со здоровой самокритикой. Я применяю ИИ там где мне на начальном этапе нужен широкий взгляд на проблему (пусть и с элементами нездоровой фантазии). И применяю его там, где нужно помнить название тысячи разных методов - на последней стадии имплементации.Моя биологическая память в этих местах прихрамывает. :-) Кроме того, ИИ очень хорош когда надо поэкспериментировать - внезапно, выбросить код который генерил ИИ - не так жалко как написанный собственноручно. :-)
Тщеславие менеджерам тоже не чуждо! :-) Их распирает похвастаться чем-то на публику. Мы же ходим на инженерские конференции, и там вещаем про свои инженерские достижения... А у этих еще и акционеры, которых надо впечатлить!
Вообще мы должны благодарить создателя за то, что у нас головной болью является Antropic и OpenAI вместе с матрицами на GPU! Потому что на их месте мог быть какой-нибудь биохакинг-стартап, который внезапно обнаружил что съевший утром ложку говна разработчик работает 10x быстрее! И я вас уверяю, что дальше бы последовала та же самая рыночная шиза - неизбежно появились бы те, у кого эффект, к сожалению, чисто статистически подтвердился. Потом менеджеры начали бы кормить разрабов говном просто из боязни остать от прогресса. А вокруг них бы собрался круг подпевал, которые вообще поддерживают любую дурь начальника если это обещает рост по службе и бонусы... Потом инвесторы встрепенулись: все уже едят говно ложками, а наши разработчики - еще нет!
И в этой параллельной вселенной лозунг Яндекса: 75% разработчиков будут съедать 75% говна чтобы работать на 75% быстрее - мне нравится сильно меньше...
Есть мнение, что на микро-уровне наша машинка вселенной считает дискретно и с конечной точностью. А все наши формулы квантовой механики с мнимой экспонентой - удачно эксплуатируют тот факт, что мнимая экспонента дает ортогональный базис (синусы и косинусы), которым можно бесконечно приближать вообще все что угодно... Примерно так же (и пользуясь той же математической дыркой) - описывали движение планет эпициклами - и тоже городили многоэтажные формулы и изощрялись в попытках объяснить, почему оно так сложно устроено.
С учетом того что квантовая механика никак не стыкуется с гравитацией - нужна сильно новая модель. Может кто-то из гениальных физиков с ИИ что-то наконец придумает...
Да, и еще раз - да! Мы ровно идем по тому пути как коммерческая авиация. Сейчас у нас фаза когда рекомендацией является достижение максимальной автоматизации на всех этапах полета. Надо очень больно несколько раз убиться об стену, чтобы пришло понимание что нельзя сидеть на двух стульях:
Либо вы перекладываете ответственность за код в продакшене на LLM - и тогда можете автоматизировать все как хотите, но в случае падения - не тыркайте разработчиков, а пишите жалобу авторам модели: Антропик, OpenAI, а лучше сразу в спортлото. Ибо антропику и OpenAI ваш продакшен нахрен не сдался...
Либо вы сохраняете ответственность за код на разработчиках, но тогда вся цепочка SDLC должна быть выстроена вокруг человека в контуре, чтобы он сохранял situational awareness.
Ровно из авиционного опыта я категорически не рекомендую сколько-нибудь значимую и критичную систему разрабатывать методами SDD, вайб-кодинга, и проч. Потому что итогом будет штопор и полный рот земли. Этот запрет, кстати, не препятствует использованию ИИ и получению выгод от его использования - но разработчик должен его использовать как инструмент. А менеджмент - принимать меры чтобы ИИ не выходил за разумные рамки использования.
К сожалению, средний менеджер глуп и ленив. Он спит и видит - как бы установить какие-нибудь KPI, и потом уже ничего не делать, а только получать бонусы за результат. Отсюда вся вот эта ересь 75/75/75... :-(
Из положительного - отметим оплату за токены которую ввели уже почти все. В эпоху почти-бесплатных токенов менеджеры были невыносимы! Сейчас хотя бы на языке денег можно им объяснить какую глупость они совершают...
Работоспособность этого ключа очень сильно зависит от того, какие политики выставит владелец ресурса. Например, если пытаться применить свой кастомный ключ для Windows Hello (даже выставив PID/VID Юбикея - он не пройдет аттестацию в системе, потому что там нужен не PID/VID а правильный подписанный манифест)... :-(
В этом, к сожалению, и проблема... Я с одной стороны никоим образом не хочу душить техническое творчество, пусть даже и не подкрепленное специальным образованием. А с другой стороны - надо понимать, что ваше устройство опасно. И что еще хуже - те кто будут у вас его повторять с сайта - понимают еще меньше вас. А дальше с увеличением количества пользователей - статистика бессердечная сука: начнутся пожары и трупы. Нет, наверное формально к вам претензий предъявить будет нельзя. В принципе, правила электрической и пожарной безопасности ясно говорят - использование кустарных нагревательных приборов в помещениях запрещено. Использование бытовых нагревательных приборов разрешается только под присмотром. Для того, чтобы термостат можно было воткнуть в розетку и уйти из дома - у него должен быть сертификат. Но вы же знаете отношение нашего человека к правилам и запретам... В общем, я бы себя чувствовал морально плохо, если бы выкладывал на сайт устройство которое часть пользователей обязательно оставит без дома (а кого-то еще и без отца/матери/детей/etc).
Как минимум - добавили бы вы в дисклеймер, что эту штуку запрещается оставлять без присмотра! Это оставляет ей кучу применений - какие-нибудь лабораторные установки, котлы где есть дежурный круглосуточно, и т.д - но хотя бы никто не убьет себя по глупости...
А если вы хотите спроектировать штуку, которая действительно может легально (тут без шуток - правила безопасности писаны кровью) работать автономно - то хочешь-не хочешь надо изучать правила проектирования отказоустойчивых систем. И да, абсолютно безопасных устройств не бывает, и подход к безопасности всегда риск-ориентированный. Принцип простой - по нормативу задаетесь такой вероятностью, чтобы за время использования вашего устройства вероятность погибнуть от его отказа была меньше чем под колесами автомобила или от сосульки с крыши зимой. Будет десять в минус какой-то степени на час (месяц, год) работы. Дальше по другим справочникам раскладываете это в надежность компонентов и подтверждаете что ваши схемотехнические решения действительно позволяют человеку скорее попасть в автомобильную аварию чем сгореть от отказа термостата. И в принципе все, ваше устройство получает право работать без присмотра...
P.S. Никому и никогда не говорите что вы их делали на заказ. Случись что - попадете под уголовное дело. Оно и раньше было не то чтобы очень здорово - даже если не посадят а дадут условно... А сейчас наиболее вероятно, что до суда даже не доживете - "уговорят" подписать контракт - а дальше вы и сами знаете...
При всем уважении к автору - в таком исполнении на устройстве должна быть надпись: "Эксплуатация допускается только под присмотром потребителя". Потому что без присмотра такое оставлять нельзя!
Ни одного упоминания об аппаратном WDT (причем не с прерыванием где флаг сбрасывается, а со сбросом только при нормальном состоянии устройства и датчиков). Автор уже встретился с тем, что ЭМП могут произвольно менять флаги в регистрах, а устройство - зависать, но выводов не сделал...
При этом, я бы не доверял и аппаратному WDT. Когда вы управляете чем-то нагревающим, да с мощностью в киловатты - наверное не трудно поставить пару транзисторов и разделительный конденсатор, чтобы работа нагревателя разрешалась не постоянным уровнем на ноге, а меандром (который генерируется не через PWM на канале таймера, а честным дерганьем PORTx в основном цикле при условии что датчики и данные с них идут нормальным потоком).
При этом, я бы не доверял и этому - потому что при пробитии транзистора или симмистора оно все-равно может неуправляемо разгоняться. Поэтому нужна независимо действующая система безопасности (например, одноразовый термопредохранитель прикрученный к нагревателю), которая будет рвать питание вне зависимости от того, что происходит в контроллере... Или биметаллический таймер, который не дает физически держать нагреватель включенным непрерывно больше чем определенное время (гарантированно не приводящее к пожару).
Конечно - реализовать это все в формате Tiny2313 может не хватить ресурсов. Но положа руку на сердце - вы не серию миллионную гоните, где для вас каждый рубль экономии - путь к несметному богатству! Вы делаете единичные устройства - ну так поставьте Atmega328! Ну будет оно на сто рублей дороже, и что ?! Зато спать спокойно ночью будете...
Вы сознательно, или несознательно игнорируете существенный момент - ВСЕ ранее перечисленные инструменты (счеты, 1С, etc) являлись детерминированными. А LLM - принципиально вероятностная система. Одно дело - заменять прошлую детерминированную систему - другой детерминированной системой. Другое - менять известный предсказуемый (!) тулсет на принципиально более производительный, но время от времени сходящий с ума. Первое - несомненно прогресс. Второе - сомневаюсь... :-(
Ну как бы да - я пользуюсь maven не глядя в его код. Но maven - детерминированный тул, а агент на базе LLM - нет. Он пишет по одной и той же спеке немного разное. А один раз на N запусков может вообще все зафакапить...
В общем, на текущем уровне развития ИИ, я не готов объявить code - secondary артефактом который можно дешево регенерировать. Вне зависимости от того, какой harness мне дадут, и сколько текста в спеку оно напишет. Потому что оно нет нет, а напишет одно - а сделает другое...
Возможно, моя осторожность проистекает из отрасли в которой мы сидим. Если ошибка в проде никого серьезно не напрягает, и просто является сигналом перегенерировать код и попробовать снова - то можно и поиграть в игру 'spec is a source of truth, not the code". Я в это (пока!) играть не готов...