Возможно, Грок умнее в полностью агентном цикле, но в парной работе "проанализируй - давай составим спеку - всё ли понятно - поехали", он заметно ниже по комфорту, чем собственный курсоровский Composer2.5. Понимает не так, при чём, не сказал бы, что от интеллекта. Постоянно лезет за пределы репа, без нужды решая, что в рамках репа ему данныхне достаточно.
GPT-5.5 заметно поумнее Композера и, вдобавок, комфортнее по разговору. А вот 5.6 ближе к Гроку - должен быть умнее, но коммуникативного комфорта меньше.
Ну, судя по отчёту, микроизменения температуры ничего невообразимого не вызвали. Далее, часть параметров будет достаточно измерять от бейзлайна. Остальное в широком диапазоне добьет обученная нейросеточка после начального накопления капитала данных.
Спасибо за статью. На консалтинге мы наблюдаем довольно интересную картину в России: ERP слишком сложны даже для большого бизнеса. Т.е., даже на крупных российских предприятиях ERP сидит как на корове седло: вроде и корова, но ехать надо, и без седла никак. Это становится обидно заметным в сравнении с транснационалами, у которых и конь-огонь, и наездник-джигит.
Задумавшись над этим вопросом, пришли к выводу, что у нас, в России, промышленный менталитет, ан масс - это второй уровень экономического сознания, т.е. основан на экспертности и личностях. На этом уровне нет (и не может быть) бизнес-процессов, есть только инструкции. По сути своей - обычаи и ритуалы, которые применяются экспертами по месту. И оно работает - когда экспертов-подвижников достаточно. Это про нас.
ERP - это артефакт третьего уровня, когда в основу производства ложатся регулярные процессы с точно воспроизводимыми процедурами . В России ERP часто становится имитацией бурной деятельности: если заглянуть "на землю", то мы увидим как дыры в планировочных схемах сшиваются вполне конкретными персоналиями, находящимися друг с другом в неуставных отношениях.
Есть ощущение, что это - не спроста, а вполне константный показатель для нашей территории развития. Для западной мысли ERP логичен и естественен и мы его импортировали. Более того, до появления ИИ он оставался наиболее близок к управленческому идеалу.
Но теперь появился ИИ... и есть ощущение, что он даёт возможность перейти от цифровой учётной механики к смысловой онтологической. Т.е., видится интересным использовать ИИ, в т.ч., для непрерывной систематизации процессов, сущностей и отношений, чтобы компенсировать невозможность полноценного внедрения ERP.
Запустить вместо ERP более низкий, операционный слой, который будет лучше сшиваться за счёт скорости и за счёт подхвата выпадающих учётных процедур (что и может дать ИИ). Бонусом будет кратно более высокая адаптивность таких управляющих механизмов по сравнению с классическими учётными системами.
Если более предметно: ИИ позволяет не только следовать процессам, а выявлять их, составлять карту "текучих" процессов и взаимосвязей. Для этого ему нужен язык описания, пригодный для отражения производственной действительности и, одновременно, позволяющий получать ограниченные контекстные слепки.
Если говорить о втором уровне, то интерпретация языка (моделирование) будет заключаться не столько в имитации прохождения предмета по цепочке, сколько в оценке наличия взаимосвязей от входа к выходу и наличия на всём протяжении необходимой пропускной способности для потока (объём, латентность). Это немного другая история, потому что там нет 100% утверждённых путей, там именно "русло и дельта".
И вот это был бы для ИИ очень хороший организационный... как нынче модно говорить "харнесс", а по простому говоря - операционная среда, реализующая ограничения.
Похоже, этот метод имеет смежное "бытовое" применение.
При создании ИИ-ассистента, мы обнаружили, что если пользователь немного понимает его механику, то ассистент способен упростить довольно сложные задачи. Но если человек мало знаком с ИИ и не мыслит как программист хотя бы немного, то первая же его задача "возьми эти три портянки и дай выкладку" приводит к тому, что ИИ "надумывет" себе тот самый бессмысленный план, затем по нему идёт.
И точно так же возникает задача проверяемого планирования и контроля.
Автор столь подробно отвечает, что это маловероятно. Кто любит писать, с нейросеткой не поделится ;-) И, кстати, не разделяю Вашего ощущения - в тексте нет вот этих нейросетевых залипух, о борьбе с которыми статья: когда слова статистически подобраны, а идеи за ними нет.
Судя по общему направлению действий Антропиков - сначала забанили OpenClaw, затем начали резать пользователей, у них, даже по тем конским ценам, что они продают токены, от продажи сырой мощности выходит не прибыль, а убыток.
В традиционной модели это же самое будет обозначено RBAC + DLP. Ровно с тем же набором требований. И они вполне законно являются частью старой, периметровой парадигмы.
Есть (скромное) мнение, что обозначенные Вами проблемы невозможно решить в той плоскости, которая описана как "новый подход". Потому что это та же самая старая плоскость - попытка расчертить ту же самую доску, только новыми линиями и застолбить для них маркетинговые термины.
Чтобы начать работать с кейсами, вроде описанных вами, система должна быть изначально нацелена не на персону, а на поведение. Иными словами, любая транзакция должна получать маркер источника и транслировтаь его на свой артефакт. Артефакты собираются в потоки. Чем чище поток, тем выше будет у него допуск. Например, поток, в котором есть примесь данных из интернета, никогда не получит допуск к осуществлению платежа.
Но чтобы это реализовать, необходимо перестраивать архитектуру ПО, потому что оно будет обязано перейти от "реакции на команды" - логин, переход, платёж, сохрениние и т.п. на приём обработку и формирование потоков окрашенных данных.
Но только это, опять же, будет не отмена периметра - периметр, как раз, останется, но перенос основного веса защиты с периметра (точнее, теперь - с периметров) на гейтование данных между ними.
А идея персоны, как идентификатора, как раз - устаревает. Потому что идентификатор маскирует окрашенность данных, с которыми он работает и это более не приемлемо.
Посмотрите со стороны бизнеса. Архитектор ест вместе с курсором две зарплаты, а выдает за шесть в прод, команда ест гораздо больше, а выдает номинал.
Вопроса "что будет делать архитектор, когда его решение начнет разваливаться" - нет. Нейроночка ландшафт за день поменяет.
Ответить на вопрос: кто из них останется в долгую, если архитектор не совсем дерево, думаю, не сложно.
Команде пора перестраиваться. Для начала порекомендовал бы перестать играть в техножрецов и написать тесты к поделию архитектора, чтобы его ииха могла их запускать. Следом провести код ревью и по результатам написать политики для той же иихи. Потом интегрировать их с авто код ревью.
В сумме получится вполне рациональный совместный вкат в экспириенс.
Сила Курсора всегда была не столько в интерфейсной обёртке, сколько в паттернах организации среды: как чанковать, как искать, как верифицировать и т.п. Этот задел нарабатывается месяцами и годами, но требует постоянного движения вперёд.
Хотя на сейчас вопрос, думаю закрыт - станут средой для Грока.
очинтересно. спасибо!
А какой софтиной гоняете?
Возможно, Грок умнее в полностью агентном цикле, но в парной работе "проанализируй - давай составим спеку - всё ли понятно - поехали", он заметно ниже по комфорту, чем собственный курсоровский Composer2.5. Понимает не так, при чём, не сказал бы, что от интеллекта. Постоянно лезет за пределы репа, без нужды решая, что в рамках репа ему данныхне достаточно.
GPT-5.5 заметно поумнее Композера и, вдобавок, комфортнее по разговору. А вот 5.6 ближе к Гроку - должен быть умнее, но коммуникативного комфорта меньше.
Субъективное, конечно.
Они выложили https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/tree/main/MTP
Ну, пропиарили аккуратно. С душой. Действительно, тот нечастый случай, когда есть ощущение, что получил что-то кроме рекламы. Было интересно.
Ну, судя по отчёту, микроизменения температуры ничего невообразимого не вызвали. Далее, часть параметров будет достаточно измерять от бейзлайна. Остальное в широком диапазоне добьет обученная нейросеточка после начального накопления
капиталаданных.Слово "хрень"?
Включайте mtp, он чутка добавит. На этих скоростях каждые 5т/с дороги.
А какая скорость при этом выходит? У нас где-то 50-60, в зависимости от погоды.
Спасибо за статью.
На консалтинге мы наблюдаем довольно интересную картину в России: ERP слишком сложны даже для большого бизнеса. Т.е., даже на крупных российских предприятиях ERP сидит как на корове седло: вроде и корова, но ехать надо, и без седла никак. Это становится обидно заметным в сравнении с транснационалами, у которых и конь-огонь, и наездник-джигит.
Задумавшись над этим вопросом, пришли к выводу, что у нас, в России, промышленный менталитет, ан масс - это второй уровень экономического сознания, т.е. основан на экспертности и личностях. На этом уровне нет (и не может быть) бизнес-процессов, есть только инструкции. По сути своей - обычаи и ритуалы, которые применяются экспертами по месту. И оно работает - когда экспертов-подвижников достаточно. Это про нас.
ERP - это артефакт третьего уровня, когда в основу производства ложатся регулярные процессы с точно воспроизводимыми процедурами . В России ERP часто становится имитацией бурной деятельности: если заглянуть "на землю", то мы увидим как дыры в планировочных схемах сшиваются вполне конкретными персоналиями, находящимися друг с другом в неуставных отношениях.
Есть ощущение, что это - не спроста, а вполне константный показатель для нашей территории развития. Для западной мысли ERP логичен и естественен и мы его импортировали. Более того, до появления ИИ он оставался наиболее близок к управленческому идеалу.
Но теперь появился ИИ... и есть ощущение, что он даёт возможность перейти от цифровой учётной механики к смысловой онтологической. Т.е., видится интересным использовать ИИ, в т.ч., для непрерывной систематизации процессов, сущностей и отношений, чтобы компенсировать невозможность полноценного внедрения ERP.
Запустить вместо ERP более низкий, операционный слой, который будет лучше сшиваться за счёт скорости и за счёт подхвата выпадающих учётных процедур (что и может дать ИИ). Бонусом будет кратно более высокая адаптивность таких управляющих механизмов по сравнению с классическими учётными системами.
Если более предметно: ИИ позволяет не только следовать процессам, а выявлять их, составлять карту "текучих" процессов и взаимосвязей. Для этого ему нужен язык описания, пригодный для отражения производственной действительности и, одновременно, позволяющий получать ограниченные контекстные слепки.
Если говорить о втором уровне, то интерпретация языка (моделирование) будет заключаться не столько в имитации прохождения предмета по цепочке, сколько в оценке наличия взаимосвязей от входа к выходу и наличия на всём протяжении необходимой пропускной способности для потока (объём, латентность). Это немного другая история, потому что там нет 100% утверждённых путей, там именно "русло и дельта".
И вот это был бы для ИИ очень хороший организационный... как нынче модно говорить "харнесс", а по простому говоря - операционная среда, реализующая ограничения.
Спасибо за Ваш опыт! Крутая статья.
Похоже, этот метод имеет смежное "бытовое" применение.
При создании ИИ-ассистента, мы обнаружили, что если пользователь немного понимает его механику, то ассистент способен упростить довольно сложные задачи. Но если человек мало знаком с ИИ и не мыслит как программист хотя бы немного, то первая же его задача "возьми эти три портянки и дай выкладку" приводит к тому, что ИИ "надумывет" себе тот самый бессмысленный план, затем по нему идёт.
И точно так же возникает задача проверяемого планирования и контроля.
Автор столь подробно отвечает, что это маловероятно. Кто любит писать, с нейросеткой не поделится ;-)
И, кстати, не разделяю Вашего ощущения - в тексте нет вот этих нейросетевых залипух, о борьбе с которыми статья: когда слова статистически подобраны, а идеи за ними нет.
Судя по общему направлению действий Антропиков - сначала забанили OpenClaw, затем начали резать пользователей, у них, даже по тем конским ценам, что они продают токены, от продажи сырой мощности выходит не прибыль, а убыток.
Спасибо
В традиционной модели это же самое будет обозначено RBAC + DLP. Ровно с тем же набором требований. И они вполне законно являются частью старой, периметровой парадигмы.
Есть (скромное) мнение, что обозначенные Вами проблемы невозможно решить в той плоскости, которая описана как "новый подход". Потому что это та же самая старая плоскость - попытка расчертить ту же самую доску, только новыми линиями и застолбить для них маркетинговые термины.
Чтобы начать работать с кейсами, вроде описанных вами, система должна быть изначально нацелена не на персону, а на поведение. Иными словами, любая транзакция должна получать маркер источника и транслировтаь его на свой артефакт. Артефакты собираются в потоки. Чем чище поток, тем выше будет у него допуск. Например, поток, в котором есть примесь данных из интернета, никогда не получит допуск к осуществлению платежа.
Но чтобы это реализовать, необходимо перестраивать архитектуру ПО, потому что оно будет обязано перейти от "реакции на команды" - логин, переход, платёж, сохрениние и т.п. на приём обработку и формирование потоков окрашенных данных.
Но только это, опять же, будет не отмена периметра - периметр, как раз, останется, но перенос основного веса защиты с периметра (точнее, теперь - с периметров) на гейтование данных между ними.
А идея персоны, как идентификатора, как раз - устаревает. Потому что идентификатор маскирует окрашенность данных, с которыми он работает и это более не приемлемо.
А можно на примере, как идентити фёст решит самый первый описанный инцидент?
Посмотрите со стороны бизнеса. Архитектор ест вместе с курсором две зарплаты, а выдает за шесть в прод, команда ест гораздо больше, а выдает номинал.
Вопроса "что будет делать архитектор, когда его решение начнет разваливаться" - нет. Нейроночка ландшафт за день поменяет.
Ответить на вопрос: кто из них останется в долгую, если архитектор не совсем дерево, думаю, не сложно.
Команде пора перестраиваться. Для начала порекомендовал бы перестать играть в техножрецов и написать тесты к поделию архитектора, чтобы его ииха могла их запускать. Следом провести код ревью и по результатам написать политики для той же иихи. Потом интегрировать их с авто код ревью.
В сумме получится вполне рациональный совместный вкат в экспириенс.
Хорошие вопросы, но не хватает приземления.
Один из ключевых вопросов, на которые, думаю, ответит это год - что именно даёт модели самоидентификацию? Какой тип данных и какая его организация?
Дообучение весов и Лоры тут, вроде, ни при чём. Они, скорее про навыки.
Сила Курсора всегда была не столько в интерфейсной обёртке, сколько в паттернах организации среды: как чанковать, как искать, как верифицировать и т.п. Этот задел нарабатывается месяцами и годами, но требует постоянного движения вперёд.
Хотя на сейчас вопрос, думаю закрыт - станут средой для Грока.