Мы пилим сук, на котором сидим

Не реклама, но если хочется узнать еще и про управление людьми, причем про бережливое управление, то лучше вот сюда @truefinance Длинно, сложно, но очень правильные мысли с примерами.

Продолжаем нашу тему про систему управления, которые некорректно называю ERP. Фактически я пишу про PSA / resource planning, но я до недавних пор не знал что это. А еще это подтверждает, что любые три английские буквы вместе обозначают либо ПО, либо технологию, либо методологию либо еще что то. Можно проверить забивая случаные буквы в поиск англовики. Из прошлых моих постов вышло, что ERP/PSA это больно, дорого, нужно. Больно потому что надо внедрять, нужно потому что бюрократия неизбежна, а что можно сделать с дорого? Можно, скажем, взять open-source. Тем более эпоха ИИ, наверняка гитхаб завалем таким. На самом деле да, так и есть. Проблема в том, что вайб-решения пишут под себя, это будет в следущем посте, кстати. А более менее взрослая система для всех тащит за собой приколы тех, кто ее делал. Самый простой пример - https://www.openproject.org. Он реально сефл, простите, хост, реально бесплатный, хотя часть функций за пейволл и требуют лицензии. Он реально умеет все, что заявлено на сайте. Но, он выглядит так, что я даже шутку не смог придумать. Плохо он выглядит. Скажие "не важно"? А я не поверю. Немалая часть функций за пейволл, включая даже возможность поменять цвет интерфейса. В настройке и наладке он такой же как и в интерфейсе, я пробовал. Но он работает. Его можно настроить и успешно пользоваться. А он не один такой. Про прочие решения написал, а точнее не про них, а про то какие есть сложности.

Продолжаю делиться очень важными мыслями про системы управления. Рано или поздно вам придется такое чудо заводить. Вам будут рассказывать как ваша жизнь поменяется после того как вы купите чудо за много денег и вы будете страдать думая, сколько же вы всего потеряли. Разумеется нет, никто так ничего не продает, все умные стали. Но выбирать все равно надо и надо понимать что и зачем. Самое главное в выборе системы - не повесить себе на шею дракона, который будет требовать золота и молодых администраторш. Самое важное что нужно понять - будет больно. Вам придется что то ломать у себя ради ERP. Процессы, задачи, людей, время. Не буду писать умных рекомендаций, просто продолжу делиться идеями. И продолжение будет.

Давайте еще раз поговорим по ERP. Я кучу своих мыслей свел в красивую статью, которую никто читать не будет, а потому ниже напишу вообще о другом. Точнее про системы учета и управления. Сразу скажу - я пишу только про системы учета человеческих ресурсов, не про гайки и трубы, там свои правила. Есть два полярных мнения - одно что нужно считать каждую секунду и нет учета нет работы. Второе - что все это дурь и бюрократия и не мешайте людям работать. Оба эти мнения имеют право на жизнь, оба верны и оба неверны. Если доводить до абсурда то первое мнение кончается Стахановцем, что крайне не одобряю, а второе вообще непоятно чем. Хотел написать пиратским кораблем, но вообще то у пиратов в море с дисциплиной все было круто и строго, а то как иначе? Любая организация, где больше, условно, 15 человек, требует учета и бюрократии. Чем больше - тем сложнее. Как говорит мой хороший друг Олег - если у вас 10 человек в команде вам никакие системы управления не нужны, вы и так все знаете. А вот если больше - надо как минимум помнить что кому когда и зачем вы поручили. Можно просто записывать. Можно письма слать. Можно стикеры клеить. И даже это уже система учета. А что делать если вас очень много и есть немалый шанс что многие просто ничего не делают? А вы уверены что все задачи поставлены и выполнены? А вы знаете сколько куда ушло времени/денег? А тут вопрос не праздный. Зная ваши затраты во времены вы понимаете хоть как то ваши сильные и слабые стороны, вы понимаете где у вас просадки, кто тянет и на ком тянут, в конце концов. Звучит красиво, но всем этим надо заниматься, причем не руками. Вот тут и приходят системы управления. Они могут быть чудовищами умеющими все (ничего) и малютками, которые не умеют ничего. Парадоксально - но чем меньше функций и кнопок - тем всегда лучше. Но не для всех. Обычному сотруднику надо работать, а не думать о кнопках и отчетах. Он должен знать свои задачи и указывать что он их сделал, в идеале еще за сколько. А большому боссу нужну очень много всяких кнопок и табличек, что бы видеть всю картину. К чему это я? А про это в следующий раз.

Первый в мире хамящий RAG.

А вы знали, что ИИ тяжело работать с таблицами? Не потому, что он “плохо считает”. А потому что таблица, которая для человека выглядит образцом читабельности, красоты и изящных формул, для ИИ часто превращается в мешанину из объединенных ячеек, заголовков, примечаний, формул и чисел. В итоге модель вынужденно схлопывает все это в плоский текст и пытается угадать, что там вообще было. Эксель, как ни странно, для людей, а не для машин. А правильный подход это не терзать машину неестественными для нее файлами, а ставить ее на паркет.

Давно ничего простого не писал. А напишу. По мотивам вопросов и того что я слышу. У вас у всех есть масса идей. Вы хотите себе помочь, облегчить себе работу, сделать что-то прикольное. Вы думаете что это все эти нейронки это либо сложно, либо криво, либо не получится либо вы не умеете. А вы попробуйте. Это не страшно, не больно, это весело. Начните с простого - купите себе на любом маркете учетку Antigravity. Или Codex. Или Devin. Или Cursor. Не чатик, агента. Стоит - как как крафтовое пиво. Запустите. Предложите идею - он сделает. Хотя бы попробует. Я для примера утром за пару запросов получил вот такую штуку. Вышло прикольно, может даже полезно. Главное - пробовать и не бояться. Пускай руки из седалища, но глаза бояться не должны.

Инновационные методы в написании промтов. Это вам не loops и оркестрация.

Пример относительно неочевидной, но вполне логичной идеи - ИИ как помощник в монтаже видео. Разумеется идея отдать ИИ сразу все исходники и поручить сделать монтаж многокамерного клипа, ориентируясь на того кто говорит - дурная, хотя он все честно сделает, задача вполне укладывается в алгоритм. Просто выйдет не то что вы хотите, а объяснять машине что и как вы хотите - сложно и лень. А вот сделать план по рилсам, титры, тизеры, черновой монтаж - а почему бы и нет?

О баснях, таблицах и грезах. Любая новая технология вызывает непреодолимое желание запихать ее вообще везде. Причем неважно, есть ли в этом смысл, поможет ли это делу и не будут ли над вами откровенно ржать. Одно дело, когда речь идет о биржах, где стоимость акций зависит исключительно от поднятого инфошума. Но совсем другое, когда технологию внедряют просто ради самого факта внедрения. Отлично помню, как ТИМ и BIM пытались натянуть по самые помидоры туда, где они никому не уперлись. Например, в разделы автоматики или в безумные попытки засунуть 3D-модели напрямую в SCADA. Потом все дружно пытались прикрутить куда угодно блокчейн. К счастью, технология оказалась сложной и нишевой, поэтому массово не взлетело. Шоу с галлюцинациями А теперь на сцену вышли нейросети и устроили нам шоу с галлюцинациями. И вот они уже реально везде. Недавно с огромным удивлением обнаружил ИИ-чат на нишевом сайте с игровыми гайдами. Зачем он там нужен, понять так и не смог. Нейронки скоро будут сидеть в утюгах и велосипедах, если уже не сидят. Пока затраты на токены стоят копейки, пускай народ балуется. Сама идея звучит, конечно, классно. Запустим алгоритм внутрь сервиса, пафосно назовем его «агентом» или «ассистентом», и пусть машина работает за нас, выдавая исключительно умные мысли. Суровая реальность инструмента Вот только нейронка все еще остается обычным инструментом с горой ограничений. Да, она соберет вам табличку из той кучи мусора, которую вы в нее загрузите. Но надо ли это делать, если можно написать удобный сервис по выгрузке нормальной сводки напрямую из системы? Это выйдет и дешевле, и предсказуемее. Если вы не можете вытащить данные в понятном виде без ИИ из вашей системы - ваша система неудобная, в том числе для ИИ, он же тоже данные должен брать из базы или форм. Совсем плохо когда ИИ заменяет аналитический аппарат, принимая решения на основе галлюцинаций. А еще хуже когда у вас в красивом ИИ дашборде данные из из тензорных грез мутируют в еще более бредовые веселые картинки. Модель, предоставленная самой себе на горе неструктурированных данных, будет на один и тот же запрос выдавать абсолютно разные вещи. Она просто так устроена. Главное правило: Чем сильнее модель зажата инструкциями, жесткими ограничениями, регламентами и доступами, тем лучше она работает. И часто лучше простая, тупая, но очень исполнительная модель, чем чудо-богатырь из басни.

Сложно? Очень! Но с агентами под рукой все проще. Обещанный разбор ИИ агентов сделал и выкладываю. Постарался учесть все, а так же спасибо тем, кто дал комментарии про опыт работы.

Все же видели мемы в духе «найму программиста что бы разобраться в том что Клод наделал» и «Гемини снес мой репозиторий»? Такие штуки сильно сокращают вероятность таких приколов. А еще много много тестов, документация впереди кода и ручные проверки на всех этапах. Ну и умение читать код очень помогает, конечно.

Давно тут не было котиков. Циклы и подагенты: как ИИ-помощника научили не верить самому себе Разговоры про ИИ в разработке быстро покрываются словами, от которых хочется закрыть чат с ИИ, удалить его, закрыть ноутбук, сдать его в утиль и уйти в запой. “Автономные агенты”, “оркестрация”, “многошаговые контуры”. Звучит так, будто код сейчас сам встанет, соберётся и уйдёт на прод, а ты уйдешь в отдел кадров. На деле всё проще: ИИ-помощнику просто дают не только задачу, но и способ проверить, что он не наврал. Цикл - это обычное “сделал - проверил - исправил - снова проверил”. Например, помощник меняет код, запускает composer verify, читает ошибку, правит минимально и запускает проверку ещё раз. Не потому что он внезапно стал мудрым, а потому что красная команда в терминале отрезвляет лучше любого промпта. Без такого цикла работа часто выглядит подозрительно бодро. Ты просишь исправить баг, помощник читает пару файлов, что-то меняет и сообщает: “готово”. Иногда действительно готово. А иногда “готово” означает “я написал правдоподобный код и очень надеюсь, что тесты сегодня в хорошем настроении”. Проверка быстро возвращает всех в физический мир: синтаксис красный, тесты упали, сборка ругается, база не поднимается. Хороший цикл скучен. “Доведи composer verify до успешного выполнения”. “Доведи сборку viewer до зелёного состояния”. “Собери hotfix-пакет и проверь его штатным скриптом”. Чем меньше поэзии, тем лучше. Компьютер не впечатляется красивым отчётом: команда либо прошла, либо нет. А что же делать на практике? А написал целую статью про это, кому скучно читать воду - сразу идите в пункт 3.

🧱 Стек Локально: • Claude Code — оркестратор • Lemonade / Qwen3.5-9B на NPU — генерация конфигов • Python 3.14 — препроцессинг и постпроцессинг • Docker Desktop — OpenFOAM без WSL-боли • PyVista / Matplotlib — визуализация • ParaView — опционально, проверка сетки и расчётной модели В облаке: • 32 vCPU, 64 GB RAM, Ubuntu 24 • leoyue123/foamagent — OpenFOAM 10 в контейнере • mpirun -np 32 — параллельный расчёт Цепочка: LLM генерирует конфиг → Claude проверяет и согласовывает с пользователем → Docker гоняет первичные тесты на солвере → VPS берёт на себя полный расчёт → Python визуализирует → Claude интерпретирует результат ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Что реально делал Claude Не «помогал с кодом». Именно оркестрировал: — читал логи и диагностировал падения (FOAM FATAL, тепловое разбегание, артефакт −24 °C) — генерировал конфигурационные файлы OpenFOAM по ТЗ (20+ файлов на кейс) — запускал команды в Docker через PowerShell и bash — верифицировал метод по корреляциям Шервуда и Блазиуса — писал постпроцессинг-скрипты, читал VTK-файлы, строил графики Инженер ставит задачу, проверяет физику и принимает решения. Рутина — на Claude. ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ ☁️ VPS как множитель Первые черновые расчёты на 150 секунд физического времени были сделаны прямо на CPU ноутбука. Локальная машина (Ryzen AI HX 370, 8 ядер) считала тот же кейс в 2-2.5 раза медленнее облачного 32-ядерного сервера. VPS обошёлся в копейки и был выключен сразу после расчёта — грант бережём. Паттерн: локально — разработка и быстрые итерации. VPS — production-прогон, один раз, дёшево. Никакого постоянного железа. Ключевой урок для тех, кто решит повторить: PowerShell ломает кавычки в длинных SSH-командах. Решение — оборачивать в base64:

powershell $b64=[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($cmd))
ssh user@vps "echo $b64 | base64 -d | bash"

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ 🧠 CFD как фабрика обучающих данных Промышленный расчёт даёт размеченные поля физических величин: температура T(x,y,z,t), скорость U, концентрация — на десятках тысяч точек. Это дорогие ground-truth данные, которые в реальных экспериментах стоили бы на порядки больше. И именно здесь становится интересно. Surrogate models Нейросеть приближает CFD-солвер: вход — геометрия и граничные условия, выход — поля T и U. Инференс за миллисекунды вместо часов. Архитектуры: U-Net, MESHGRAPHNET, FNO. PINN Уравнения Навье-Стокса прямо в loss-функцию — сеть интерполирует между CFD-точками, не нарушая физику. LLM на конфиги Дообучить модель на паре «описание задачи → конфиг OpenFOAM». Каждый кейс пайплайна — готовый пример датасета. CFD + RL Агент меняет параметры и получает reward от солвера. Уже работает в аэродинамике у Tesla и Waymo — применимо к любым инженерным задачам. ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ 📦 Что нужно для старта

bash docker pull leoyue123/foamagent:latest
pip install pyvista pymeshfix numpy matplotlib

VPS с 8+ ядрами и Ubuntu 24 — около 0.10-0.20 евро в час на европейских облаках. Главное — правильно описать физическую задачу. LLM не знает что такое fixedFluxPressure, но если объяснить суть — генерирует рабочий конфиг с первой-второй попытки. ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ 💡 Вывод Связка open-source солвер + Docker + Claude + дешёвый VPS позволяет запустить промышленный расчёт за день — включая отладку, верификацию и постпроцессинг. Без дорогих лицензий и специализированных бюро. CFD-данные, которые при этом генерируются — это структурированные физические датасеты, которые пока почти никто не использует для обучения. Ниша открытая. В планах: сбор верифицированных кейсов и поиск датасетов для обучения собственной локальной surrogate model.

⚙️ CFD (Computational Fluid Dynamics) — как снизить порог входа в гидрогазодинамику с Claude, без СМС и регистрации 😄 Начну не с CFD, а с ИИ в непривычном понимании. Помимо ставших привычными LLM-моделей существуют специализированные модели без чата — так называемые Surrogate models: нейронные операторы, PINN-модели, графовые нейросети и другие. Их цель — заменить традиционные численные решатели вроде Ansys и Star-CCM+. Но чтобы это заработало, модель нужно натренировать на данных. Насобирать быстро данных по CFD микроклимата пока задачка со звёздочкой — но это пока. Поэтому на первом этапе пришлось собрать собственный пайплайн для CFD традиционным методом — тем, который ещё год назад потребовал бы отдельного инженера и недели ручной работы. Получилось запустить всё в связке: локальный LLM на NPU, Claude как оркестратор, Docker и облачный VPS. Без Ansys и Star-CCM+ — на базе OpenFOAM, уважаемого в научных кругах open-source решателя. Делюсь стеком и выводами.

Давайте немного отойдем в сторону и поговорим про ERP. Оно же система управления ресурсами предприятия. Кому-то радость, кому-то проклятие. Исторически сложилось так, что у современных корпоративных систем есть три разные "двери", и то, как работает софт, напрямую зависит от его генетики. Дверь в бухгалтерию: Наследие SAP В 1972 году выходцы из IBM основали компанию SAP. Их самый первый продукт был инструментом исключительно для финансового учета. Никаких станков, чертежей и конвейеров - только проводки, бюджеты и баланс. Спустя годы они догадались связать деньги с закупками и кадрами, а в 90-х аналитики назвали это модным словом ERP. Но главная проблема зародилась именно тогда: основным заказчиком такого софта стал финансовый директор. Фокус сместился на тотальный финансовый контроль. Бухгалтерская парадигма эволюционировала и подмяла под себя инженерию. Логика системы требует, чтобы каждая минута рабочего времени и каждый кусок кабеля были строго списаны на конкретный центр затрат. Дверь в цех: Физика процесса и MES Совершенно иначе развивалась ветвь производственных систем. Начиналось все с алгоритмов MRP - по сути, калькуляторов, которые считали, сколько гаек нужно привезти к утру, чтобы конвейер не остановился. Когда заводы поняли, что управлять станками через неповоротливые бухгалтерские ERP невозможно, родились MES (системы управления производственными процессами). MES забрала себе реальную физику: обороты шпинделя, температуру плавки, секундные простои. Вместо того чтобы заставлять мастера писать отчеты, умные станки сами начали отдавать цифровой след. MES стала работать как пассивный барьер между железом и бумажной бюрократией. Дверь в серверную: Мир виртуальных карточек Третья ветвь выросла из ИТ-отделов и Agile-подходов - это таск-трекеры (Jira, Trello). Они взяли идею японского канбана, но потеряли физику. Карточки превратились в обычные стикеры на экране. Этот софт писался программистами для программистов под концепцию "взял независимый тикет, написал код, закрыл". При попытке натянуть трекеры на сложный инжиниринг они ломаются: стикеры не видят жестких технологических связей, не понимают концепции очередей и топят руководство в визуальном шуме из сотен мелких задач. Парадокс ERP: Софт ради софта Глобальная проблема начинается, когда бизнесу открывают не ту дверь. И тут во всей красе проявляется парадокс систем управления: мы внедряем софт, чтобы работать быстрее, а в итоге получаем систему ради системы. Голдратт в книге "Цель-3" ("Необходимо, но не достаточно") предельно точно разобрал этот механизм. Любая технология приносит реальную пользу только в одном случае - если она снимает существующее ограничение компании. Но на практике внедрение классической ERP сводится к тому, что живые процессы перекраивают, чтобы подстроить их под архитектуру купленной базы данных. Чтобы руководство видело красивые диаграммы Гантта, дорогой инженер превращается в бесплатного оператора БД. Он вынужден тратить время на логирование часов, заполнение обязательных полей и ручное переключение статусов. Происходит разрыв: реальная свая может быть уже забита, но для системы этого не существует, пока человек не проведет нужную транзакцию.

Для выступления на ТИМ/BIM завтраке я взял недавний свой опус про уровни зрелости и сложности РАГ-машин и сделал его еще больше и сложнее. Раньше там была по сути одна теория, но сейчас стало больше практики и даже примерно написано как завести у себя дома/в организации РАГ. Эту тему, как и то зачем вам вообще RAG я буду развивать, а то слишком далеко ушел в теорию, еще немного и начну курсы продават. Нет, не буду никогда.

Не могу не поделиться. Всегда интересен практический опыт.

Как мы пришли к использованию ИИ-агентов 👩‍💼 «ИИ-агент — что за пугающий набор слов?», — думала я еще в начале марта этого года. Честно сказать, как и большая часть людей, я не очень люблю изменения. И моя эмоциональная часть не всегда приветствует авантюры со сложными задачами и новыми терминами. Спасибо части рациональной, я пошла узнавать. Ведь они обещали делать такие крутые штуки малыми ресурсами! 😯 Итак, я познала мир ИИ-агентов, а если конкретнее — попробовала Cursor, как наиболее user-friendly на мой взгляд из того, что я видела. Он устанавливается прямо на компьютер в свою локальную папочку, сохраняет туда файлы, правила, сам создает нужную структуру хранения, в которой легко найти файлы. Не нужно каждый раз получать коды подтверждения на почту или делать еще какие-то лишние телодвижения для открытия, а это так важно для массового внедрения продукта в компании. Внутри вшиты все основные нейросети, история обучения и запросов хранится в одном локальном месте у тебя на ПК. В чем же разница ИИ-агентов от простого использования ИИ? Нейросеть отвечает или создаёт текст, изображения или другие результаты по запросу, а ИИ-агент может сам выполняет действия: ищет, сравнивает, может запускать программы, публиковать что-то, открывать сайты, приложения, соц. сети и т.д. Сейчас мы всей командой VDC перешли с разрозненных запросов в нейросетях и различных чатах на осознанное накопление общих знаний компании в локальных ИИ-агентах. И вот что мы уже делаем: 🔵Проектирование: пакет проверок проектной документации всех стадий. 🔵Юристы: корректировка договоров и матрица рисков по направлениям. 🔵HR: создание офферов, корректировка договоров и проверка. 🔵Диалоги о развитии: обработка матриц компетенций, формирование индивидуального плана в табличном виде. 🔵Администрирование: создание презентаций, официальных писем в шаблоне организации. 🔵Финансы: аналитика, создание дашбордов, графиков и презентаций. 🔵Маркетинг: анализ контента, создание текстов, отправка сразу в Telegram. ИИ-агент точно не заменяет проектирование и экспертизу команды. Мы честно говоря пока не нашли, как прикрутить ИИ к самому процессу проектирования, там мы используем автоматизацию, скрипты, плагины. А ИИ-агенты усиливают нас в поддерживающих процессах: освобождают время для проработки деталей реализации проектных решений, координации — того, что действительно влияет на качество продукта на всем жизненном цикле девелоперского проекта. Текст написан по запросу коллег, задавайте вопросы, что еще осветить в этой теме, о чем рассказать подробнее, будем рады ответить! #ПодходыVDC #ОтЕленыЗолотаревой 🇷🇺 Теперь в MAX