Пока нигде, планировал задеплоить куда-то. А вообще, честно говоря, я хочу сделать проект worldbuilding, на котором смог бы в теории заработать. Задумка такая — сделать сервис генерации научно-обоснованных миров. Условно, если в определенном месте стоит континент или горы, значит там происходили некие процессы, которые послужили причиной.
В моей генерации вначале генерируются некие случайные стартовые параметры, типа master noise, которые задают изначальный температурный шум мантии, потом DFS обегает по "слабым" местам и формирует основы тектонических плит, таким образом формируя их органические границы.
Также в моем проекте предусмотрены "снапшоты" в таймлайне. Сейчас я пока сосредоточен на создании планеты в моменте, но есть и возможность просимулировать планеты во времени, тектонические плиты будут двигаться, и системы будут пересчитываться (в облегченном режиме), и дадут реальную историю, которую можно как-то использовать для лора, ну и в целом история будет отражаться на самой планете внешне. Можно проектировать в таймлайне как выглядела планета когда на ней была например Атлантида и какими событиями она была уничтожена.
Да, но пока в формате эксперимента. Я "продал" эту идею своим коллегам, теперь ставим на staging тестировать как оно себя покажет. Первое время будет разбирать падения тестов. Скорей всего нужно будет докручивать, но на тех примерах которых я проверял, вполне себе определяет. У нас используется локальная LLM.
Я использовал для основы LangGraph, каждые ноды ходят и делают что-то свое (подтягивают ресурсы, проверяют логи и тд), а потом сверху анализируются результаты.
Я где-то год наверное сижу на нейросетях и пилю свои пет-проекты до которых раньше не доходили руки из-за недостатка моральных сил.
Новогодний пет-проект для замены bitwarden/vault https://github.com/constXife/zann. Уже где-то год пилю несколько раз с нуля генератор планет на основе тектонических плит, с простенькой моделью климата, ветра, и тд
Не так давно еще открыл для себя NixOS, конфиги настраиваю через LLM и это очень круто. Начал пилить для себя self-hosted пет-проекты типа homepage с различными пространствами (для детей, для админа, для обычных людей):
Также LLM настраивает мне дашборды графаны в виде json файлов, а NixOS их автоматом провизионирует в графану.
Сейчас экспериментирую с автоматизированным RCA, которая собирает в кучу все сигналы а-ля логи, трейсы, sentry, и пытается найти автоматизированно проблему.
Ну, условно, я бы назвал экосистемой эпл, из коробки — 1) пуши/смс приходят на макбук, условные one-timepassword автоматически подставляются в формочки на ноутбуке. 2) пуши от доставок еды появляются в макбуке с прогрессом. 3) общий буфер обмена между macbook и айфоном 4) AirPods сами переключаются к устройству где ты включаешь музыку или еще что-то 5) в отеле на телефон прописываешь пароль wifi, другие устройства автоматом подтянут его. Это из повседневного и что я сходу вспомнил. Можно еще планшет подключить как отдельный монитор в макбук и чет порисовать. Ну то есть, для меня экосистема — это интеграция и кооперация устройств и систем между собой в среде Apple. А что вы подразумеваете под экосистемой?
ну вот у меня тогда более понятная (и нужная мне) хрень — парольный менеджер, ибо меня не устраивал bitwarden и его экосистема + хотелось аналог hashiecorp vault, но для "маленьких". Сейчас активно всё причёсываю, думал потом может более статью написать, не про очередной "смотрите как LLM умеет", а про сам пет проджект, может кому-то тоже пригодится.
● podman-zann.service
Loaded: loaded (/etc/systemd/system/podman-zann.service; enabled; preset: ignored)
Active: active (running) since Tue 2025-12-30 13:06:39 +04; 1 week 5 days ago
Invocation: 5f9c57b203a8480382f0a639cb9808ea
Main PID: 1722521 (conmon)
IP: 10.1K in, 5.9K out
IO: 0B read, 180K written
Tasks: 1 (limit: 18808)
Memory: 608K (peak: 11.6M)
CPU: 326ms
CGroup: /system.slice/podman-zann.service
Не знаю в чем перепредумывание. Как по мне, это просто реализация той же концепции. Обычно используют что-то типа Ansible, но система NixOS мне видится более правильной, ибо она все изменения применяет "транзакционно" и если какой-то конфиг не применился, то NixOS не переключится на него. А если переключился и "поломался", вы легко можете возвратиться к любым предыдущим версиям.
Мне не нравится, что просто перегнали диалог с ИИ и вот вам статья. У нас тоже есть интернет и порой даже доступы до LLM. Нужна какая-то собственная рефлексия. Если бы развили идею про Infrastructure as Code, было бы любопытнее.
В качестве своего примера расскажу, что я тоже подсел на "вайбо-администрирование", сначала пользовался Ansible+OpenTofu для Hetzner, потом купил себе Beelink N150 и освоил для себя NixOS и вот "тут мне карта поперла". Суть NixOS в том, что ты настраиваешь свой Linux декларативно и там в систему заложено использование git (откажется запускаться, если какой-то конфиг не в git), легко можно возвратиться к любой версии изменения, а также поднять с нуля до актуальной версии одной командой `sudo nixos-rebuild switch --flake .#desktop` и LLM (по крайней мере крупные) отлично крафтит конфиги для этой системы. Очень классная штука, планирую некоторые свои сервера на NixOS теперь перевести.
переписать драйвер SPI из SDK производителя в функции прямой работы с регистрами (такое нужно для сверх малого потребления функций).
Без деталей реализации, без плана? Ну как говорится, без ТЗ и результат ХЗ.
А claude меня как раз раздражал тем, что много "додумывает", сколько я его не бил инструкциями по лицу про отсутствие легаси, приоритет чистого дизайна, про отсутствие fallback, fail-fast, он он всегда норовит это добавить и в итоге код на половину у меня состоял из различных fallback.
Я обычно начинаю с плана обсуждая его с Gemini, потом прохожу итерацию с обсуждением плана. Вот одна итерация обсуждения Gemini+ChatGPT. Хз, не шарю за вашу тему, но вот вы сможете оценить.
I. Философия и Ценности
Автономность и Плоская структура:
Мы отказываемся от глубоких иерархий HAL (Handle -> Instance -> State).
Драйвер — это набор плоских, атомарных инструментов (static inline функций), которые дают вам полный контроль. Никаких «черных ящиков», скрывающих состояние системы.
Осознанность и Компетентность:
Мы убираем защиту «от дурака» (asserts, runtime checks) в пользу Контрактов. Мы исходим из того, что разработчик понимает, что делает, и не тратим энергию CPU на недоверие к нему.
Системное мышление:
Энергоэффективность — это не свойство функции, а свойство всей системы. Мы управляем не просто битами SPI, а всей цепочкой: тактирование -> шина -> периферия -> GPIO -> режим сна.
II. Стратегические Цели
Zero-Overhead: Каждый такт процессора должен приносить пользу. Исключаем паразитные пересылки структур и универсальный код.
Deep Low Power: Периферия должна потреблять энергию только в момент передачи полезного сигнала. В остальное время она должна быть электрически «мертва» (Clock Gated) и корректно изолирована.
Industrial Robustness: Код должен быть устойчив к граничным условиям (гонки, прерывания, рестарты), на которых обычно ломаются «самописные» драйверы.
III. План Реализации (Как мы соблюдаем ценности)
1. Архитектура «Контракт и Прозрачность»
Разделение (Decoupling):
BSP (Config): Жесткие константы времени компиляции (адреса, пины, тайминги).
Core (Logic): Чистые inline-функции логики.
Compile-time оптимизация: Вместо if (hspi->Init.Mode == ...) используем #define, позволяя компилятору вырезать мертвый код.
2. Протокол «Безопасное Энергосбережение»
Мы не просто выключаем бит. Мы реализуем процедуру Safe Drain, чтобы избежать скрытых багов:
Слив (Drain): Перед выключением принудительно вычитываем RX-буфер и сбрасываем FIFO, чтобы избежать флагов OVR (Overrun) при пробуждении.
Барьер завершения: Ждем не только TXE, но и BSY, прежде чем трогать SPE (SPI Enable).
Clock Gating: Отключаем тактирование в RCC только после полной остановки периферии.
3. Атомарность и Тайминги
Ручной CS (Chip Select): Прямое управление GPIO с использованием барьеров памяти (__DSB), чтобы гарантировать физическую установку уровня до начала клока.
Smart Polling: Использование инструкций WFE (Wait For Event) внутри циклов ожидания флагов, чтобы снизить динамическое потребление тока, пока CPU ждет периферию.
4. Верификация через Данные
Мы заменяем надежду на факт:
Ток: Измерение профиля потребления (интеграл энергии на транзакцию).
Сигнал: Логический анализатор для проверки таймингов Setup/Hold и отсутствия глитчей на линии CS при инициализации.
Да, и я какое-то время на нем сидел, но клиенты все еще тяжеловесные на электроне. Я начал задумываться о переписывания клиента, наклепал на swift что-то, а потом еще возникло желание иметь что-то вроде vault для хранения и ротации секретов для своих pet-проектов, но опять же легковесное + легкая возможность добавления своих типов (у bitwarden, насколько знаю, с этим не очень все хорошо), в итоге решил сделать свое сразу с 0 как мне нужно.
У меня: Есть легковесный self-hosted сервер, который умеет работать с двумя типами сейфов: shared (как у vault, сервер видит секреты, все клиенты по ACL видят секреты) и personal — (для синхронизации, сервер не видит секреты, только сам клиент умеет расшифровывать свои секреты)
Есть кроссплатформенный tauri, который умеет работать как локально, так и с подключением нескольких серверов (можно подключаться одновременно как к своему self-hosted серверу, так и к рабочему серверу).
Резюмируя, shared сейфы на сервере полезны, чтобы иметь у себя vault аналог и насыщать CI пайплайны секретами (они обращаются к твоему серверу через cli/api по токену), а personal сейфы на сервере для синхронизации и бекапа.
Ну вот у меня в pet проекте отборнейшего вкусного нейрослопа от chat gpt 5.2 codex на 28 304 строчек и у меня пока не было проблем, чтобы ИИ тупил. В какой-то момент меня выбесил bitwarden, я навайбоклепал сервер на rust с потреблением памяти Memory: 624K (peak: 11.4M), сделал tauri клиент с синхронизацией который в памяти ест в районе 50-100МБ. Плохо что ли? Хорошо же.
Ну не знаю, может у меня, конечно, моральная травма как россиянина, но я бы с подозрением к такому механизму отнесся. РКН начинал с самоубийц и педофилов и где теперь ваши ютубы, дискорды? Был бы механизм, а состав "интересных материалов" уже можно подобрать по своему вкусу. Вот придет через пару лет какой-нибудь политик со своим особенным путем, политический климат поменяется, и добрым словом будут вспоминать все эти удобные цифровые средства контроля и цензуру.
Сенсорное управление меня тоже сильно выбешивало, благо на такой-то день использования я смог скачать оф. приложение на телефон и оттуда отключить все, что не нужно, тогда хоть стало возможным пользоваться.
О, я решал тоже похожую задачу для своего хобби проекта. Я хотел сделать аналог игры для программистов Colobot, чтобы можно было программировать "роботов" для колонизации других миров. Сделал некий proof of concept на Unreal по такой схеме: есть внешний сервер, чтобы можно было "стримить" в интернет, через VPN подключение к моему ноуту с Linux где через docker compose запускалась в контейнере Unreal и обрабатывала команды.
Тоже да, прошел через весь головняк запуска Unreal в докере на Linux, переход к запуску по требованию и мониторингу процесса.
Проблема для меня случилась когда я захотел сделать поддержку сети: я хотел, чтобы можно было еще подключаться через VR шлем в игровой уровень и наблюдать через шлем как работают роботы, может быть проводить диагностику какую-то, видеть какие команды они выполняют + чтобы второй игрок мог параллельно подключаться и в соседней комнате тоже работать. И я даже это сделал, но запал иссяк. Морока с синхронизацией сетевого кода для меня оказалась изнуряющей, в отличие от легкой реализации подключения.
Ну из того что я помню из института (может другие поправят), ИИ это общее название раздела информатики, которая включает кучу подразделов, в которых даже нейросетями не пахнет, типа Байеса или Дейкстра. И в итоге, вместо ИИ агента будем писать что-то вроде "агент для коммуникации с генеративными ИИ на основе трансформеров с механизмом внимания"? Ну наверное это достаточно точно, но как-то длинновато.
Контекст зависит от модели (у Gemini большой контекст, у Sonnet 1m тоже), но в целом декомпозиция + в условном claude code есть compact, который суммаризирует прошлую беседу.
Например для моего pet-project Gemini придумывает ТЗ по моим хотелкам, потом создаем таски в подпапке с описанием того что нужно сделать, тесты и какие они должны покрывать кейсы, документация архитектуры системы (чтобы чат-бот Gemini в следующем чате сразу понимала что к чему).
Вот условный отрывок из моего CLAUDE.md
Project Structure
2 │ - Documentation is located in the @docs/ directory 3 │ - Using uv as the package manager 4 │ 5 │ ## Task Management 6 │ - Стратегические задачи хранятся в @docs/05_ROADMAP.md — глобальные задачи. 7 │ - Тактические задачи хранятся в @TODO.md - архитектурные улучшения и технические задачи 8 │ - После завершения задачи помечаются выполненными (✅) в TODO.md 9 │ - Обновляй статус в процессе работы - отслеживай прогресс по каждой задаче 10 │ 11 │ ## Core Programming Principles (из @docs/04_REQUIREMENTS/README.md) 12 │ 1. Fail-Fast - валидация на входе, исключения вместо null/undefined 13 │ 2. Явное лучше неявного - все зависимости явно переданы 14 │ 3. No Legacy, No Fallbacks, No Backward compatibility, No versioning 15 │ 4. Scalability by Design - "Как это будет работать для 100x данных?"
Правда все равно приходиться регулярно бить по рукам, потому что Claude иногда забивает на правила.
Иронично, конечно, что у человека были жалобы на сотни ботов, и ему отвечает как раз vesper-bot. Хорошее чувство юмора у вас там в пентагоне или где вас там компилировали жидомасонские рептилоиды на сатанинских LLM.
Пока нигде, планировал задеплоить куда-то. А вообще, честно говоря, я хочу сделать проект worldbuilding, на котором смог бы в теории заработать. Задумка такая — сделать сервис генерации научно-обоснованных миров. Условно, если в определенном месте стоит континент или горы, значит там происходили некие процессы, которые послужили причиной.
В моей генерации вначале генерируются некие случайные стартовые параметры, типа master noise, которые задают изначальный температурный шум мантии, потом DFS обегает по "слабым" местам и формирует основы тектонических плит, таким образом формируя их органические границы.
Также в моем проекте предусмотрены "снапшоты" в таймлайне. Сейчас я пока сосредоточен на создании планеты в моменте, но есть и возможность просимулировать планеты во времени, тектонические плиты будут двигаться, и системы будут пересчитываться (в облегченном режиме), и дадут реальную историю, которую можно как-то использовать для лора, ну и в целом история будет отражаться на самой планете внешне. Можно проектировать в таймлайне как выглядела планета когда на ней была например Атлантида и какими событиями она была уничтожена.
Да, но пока в формате эксперимента. Я "продал" эту идею своим коллегам, теперь ставим на staging тестировать как оно себя покажет. Первое время будет разбирать падения тестов. Скорей всего нужно будет докручивать, но на тех примерах которых я проверял, вполне себе определяет. У нас используется локальная LLM.
Я использовал для основы LangGraph, каждые ноды ходят и делают что-то свое (подтягивают ресурсы, проверяют логи и тд), а потом сверху анализируются результаты.
Я где-то год наверное сижу на нейросетях и пилю свои пет-проекты до которых раньше не доходили руки из-за недостатка моральных сил.
Новогодний пет-проект для замены bitwarden/vault https://github.com/constXife/zann.
Уже где-то год пилю несколько раз с нуля генератор планет на основе тектонических плит, с простенькой моделью климата, ветра, и тд
Не так давно еще открыл для себя NixOS, конфиги настраиваю через LLM и это очень круто. Начал пилить для себя self-hosted пет-проекты типа homepage с различными пространствами (для детей, для админа, для обычных людей):
Также LLM настраивает мне дашборды графаны в виде json файлов, а NixOS их автоматом провизионирует в графану.
Сейчас экспериментирую с автоматизированным RCA, которая собирает в кучу все сигналы а-ля логи, трейсы, sentry, и пытается найти автоматизированно проблему.
Ну, условно, я бы назвал экосистемой эпл, из коробки — 1) пуши/смс приходят на макбук, условные one-timepassword автоматически подставляются в формочки на ноутбуке. 2) пуши от доставок еды появляются в макбуке с прогрессом. 3) общий буфер обмена между macbook и айфоном 4) AirPods сами переключаются к устройству где ты включаешь музыку или еще что-то 5) в отеле на телефон прописываешь пароль wifi, другие устройства автоматом подтянут его. Это из повседневного и что я сходу вспомнил. Можно еще планшет подключить как отдельный монитор в макбук и чет порисовать. Ну то есть, для меня экосистема — это интеграция и кооперация устройств и систем между собой в среде Apple. А что вы подразумеваете под экосистемой?
ну вот у меня тогда более понятная (и нужная мне) хрень — парольный менеджер, ибо меня не устраивал bitwarden и его экосистема + хотелось аналог hashiecorp vault, но для "маленьких". Сейчас активно всё причёсываю, думал потом может более статью написать, не про очередной "смотрите как LLM умеет", а про сам пет проджект, может кому-то тоже пригодится.
https://github.com/constXife/zann
Не знаю в чем перепредумывание. Как по мне, это просто реализация той же концепции. Обычно используют что-то типа Ansible, но система NixOS мне видится более правильной, ибо она все изменения применяет "транзакционно" и если какой-то конфиг не применился, то NixOS не переключится на него. А если переключился и "поломался", вы легко можете возвратиться к любым предыдущим версиям.
Мне не нравится, что просто перегнали диалог с ИИ и вот вам статья. У нас тоже есть интернет и порой даже доступы до LLM. Нужна какая-то собственная рефлексия. Если бы развили идею про Infrastructure as Code, было бы любопытнее.
В качестве своего примера расскажу, что я тоже подсел на "вайбо-администрирование", сначала пользовался Ansible+OpenTofu для Hetzner, потом купил себе Beelink N150 и освоил для себя NixOS и вот "тут мне карта поперла". Суть NixOS в том, что ты настраиваешь свой Linux декларативно и там в систему заложено использование git (откажется запускаться, если какой-то конфиг не в git), легко можно возвратиться к любой версии изменения, а также поднять с нуля до актуальной версии одной командой `sudo nixos-rebuild switch --flake .#desktop` и LLM (по крайней мере крупные) отлично крафтит конфиги для этой системы. Очень классная штука, планирую некоторые свои сервера на NixOS теперь перевести.
Без деталей реализации, без плана? Ну как говорится, без ТЗ и результат ХЗ.
А claude меня как раз раздражал тем, что много "додумывает", сколько я его не бил инструкциями по лицу про отсутствие легаси, приоритет чистого дизайна, про отсутствие fallback, fail-fast, он он всегда норовит это добавить и в итоге код на половину у меня состоял из различных fallback.
Я обычно начинаю с плана обсуждая его с Gemini, потом прохожу итерацию с обсуждением плана. Вот одна итерация обсуждения Gemini+ChatGPT. Хз, не шарю за вашу тему, но вот вы сможете оценить.
I. Философия и Ценности
Автономность и Плоская структура:
Мы отказываемся от глубоких иерархий HAL (Handle -> Instance -> State).
Драйвер — это набор плоских, атомарных инструментов (
static inlineфункций), которые дают вам полный контроль. Никаких «черных ящиков», скрывающих состояние системы.Осознанность и Компетентность:
Мы убираем защиту «от дурака» (asserts, runtime checks) в пользу Контрактов. Мы исходим из того, что разработчик понимает, что делает, и не тратим энергию CPU на недоверие к нему.
Системное мышление:
Энергоэффективность — это не свойство функции, а свойство всей системы. Мы управляем не просто битами SPI, а всей цепочкой: тактирование -> шина -> периферия -> GPIO -> режим сна.
II. Стратегические Цели
Zero-Overhead: Каждый такт процессора должен приносить пользу. Исключаем паразитные пересылки структур и универсальный код.
Deep Low Power: Периферия должна потреблять энергию только в момент передачи полезного сигнала. В остальное время она должна быть электрически «мертва» (Clock Gated) и корректно изолирована.
Industrial Robustness: Код должен быть устойчив к граничным условиям (гонки, прерывания, рестарты), на которых обычно ломаются «самописные» драйверы.
III. План Реализации (Как мы соблюдаем ценности)
1. Архитектура «Контракт и Прозрачность»
Разделение (Decoupling):
BSP (Config): Жесткие константы времени компиляции (адреса, пины, тайминги).Core (Logic): Чистые inline-функции логики.Compile-time оптимизация: Вместо
if (hspi->Init.Mode == ...)используем#define, позволяя компилятору вырезать мертвый код.2. Протокол «Безопасное Энергосбережение»
Мы не просто выключаем бит. Мы реализуем процедуру Safe Drain, чтобы избежать скрытых багов:
Слив (Drain): Перед выключением принудительно вычитываем RX-буфер и сбрасываем FIFO, чтобы избежать флагов OVR (Overrun) при пробуждении.
Барьер завершения: Ждем не только
TXE, но иBSY, прежде чем трогатьSPE(SPI Enable).Clock Gating: Отключаем тактирование в RCC только после полной остановки периферии.
3. Атомарность и Тайминги
Ручной CS (Chip Select): Прямое управление GPIO с использованием барьеров памяти (
__DSB), чтобы гарантировать физическую установку уровня до начала клока.Smart Polling: Использование инструкций
WFE(Wait For Event) внутри циклов ожидания флагов, чтобы снизить динамическое потребление тока, пока CPU ждет периферию.4. Верификация через Данные
Мы заменяем надежду на факт:
Ток: Измерение профиля потребления (интеграл энергии на транзакцию).
Сигнал: Логический анализатор для проверки таймингов Setup/Hold и отсутствия глитчей на линии CS при инициализации.
Да, и я какое-то время на нем сидел, но клиенты все еще тяжеловесные на электроне. Я начал задумываться о переписывания клиента, наклепал на swift что-то, а потом еще возникло желание иметь что-то вроде vault для хранения и ротации секретов для своих pet-проектов, но опять же легковесное + легкая возможность добавления своих типов (у bitwarden, насколько знаю, с этим не очень все хорошо), в итоге решил сделать свое сразу с 0 как мне нужно.
У меня:
Есть легковесный self-hosted сервер, который умеет работать с двумя типами сейфов: shared (как у vault, сервер видит секреты, все клиенты по ACL видят секреты) и personal — (для синхронизации, сервер не видит секреты, только сам клиент умеет расшифровывать свои секреты)
Есть кроссплатформенный tauri, который умеет работать как локально, так и с подключением нескольких серверов (можно подключаться одновременно как к своему self-hosted серверу, так и к рабочему серверу).
Резюмируя, shared сейфы на сервере полезны, чтобы иметь у себя vault аналог и насыщать CI пайплайны секретами (они обращаются к твоему серверу через cli/api по токену), а personal сейфы на сервере для синхронизации и бекапа.
А в каком плане большим и законченным?
Ну вот у меня в pet проекте отборнейшего вкусного нейрослопа от chat gpt 5.2 codex на 28 304 строчек и у меня пока не было проблем, чтобы ИИ тупил. В какой-то момент меня выбесил bitwarden, я навайбоклепал сервер на rust с потреблением памяти Memory: 624K (peak: 11.4M), сделал tauri клиент с синхронизацией который в памяти ест в районе 50-100МБ. Плохо что ли? Хорошо же.
А чем подписка не нравится? Она как будто бы вполне контролируема.
Ну не знаю, может у меня, конечно, моральная травма как россиянина, но я бы с подозрением к такому механизму отнесся. РКН начинал с самоубийц и педофилов и где теперь ваши ютубы, дискорды? Был бы механизм, а состав "интересных материалов" уже можно подобрать по своему вкусу. Вот придет через пару лет какой-нибудь политик со своим особенным путем, политический климат поменяется, и добрым словом будут вспоминать все эти удобные цифровые средства контроля и цензуру.
Сенсорное управление меня тоже сильно выбешивало, благо на такой-то день использования я смог скачать оф. приложение на телефон и оттуда отключить все, что не нужно, тогда хоть стало возможным пользоваться.
Мне еще Амазон на днях присылал код через Whatsapp, что меня удивило.
О, я решал тоже похожую задачу для своего хобби проекта. Я хотел сделать аналог игры для программистов Colobot, чтобы можно было программировать "роботов" для колонизации других миров. Сделал некий proof of concept на Unreal по такой схеме: есть внешний сервер, чтобы можно было "стримить" в интернет, через VPN подключение к моему ноуту с Linux где через docker compose запускалась в контейнере Unreal и обрабатывала команды.
Тоже да, прошел через весь головняк запуска Unreal в докере на Linux, переход к запуску по требованию и мониторингу процесса.
Проблема для меня случилась когда я захотел сделать поддержку сети: я хотел, чтобы можно было еще подключаться через VR шлем в игровой уровень и наблюдать через шлем как работают роботы, может быть проводить диагностику какую-то, видеть какие команды они выполняют + чтобы второй игрок мог параллельно подключаться и в соседней комнате тоже работать. И я даже это сделал, но запал иссяк. Морока с синхронизацией сетевого кода для меня оказалась изнуряющей, в отличие от легкой реализации подключения.
Вот демо программирования робота — https://www.youtube.com/watch?v=vBKpZP6w6ss.
Ну из того что я помню из института (может другие поправят), ИИ это общее название раздела информатики, которая включает кучу подразделов, в которых даже нейросетями не пахнет, типа Байеса или Дейкстра. И в итоге, вместо ИИ агента будем писать что-то вроде "агент для коммуникации с генеративными ИИ на основе трансформеров с механизмом внимания"? Ну наверное это достаточно точно, но как-то длинновато.
Контекст зависит от модели (у Gemini большой контекст, у Sonnet 1m тоже), но в целом декомпозиция + в условном claude code есть compact, который суммаризирует прошлую беседу.
Например для моего pet-project Gemini придумывает ТЗ по моим хотелкам, потом создаем таски в подпапке с описанием того что нужно сделать, тесты и какие они должны покрывать кейсы, документация архитектуры системы (чтобы чат-бот Gemini в следующем чате сразу понимала что к чему).
Вот условный отрывок из моего CLAUDE.md
Project Structure
2 │ - Documentation is located in the @docs/ directory
3 │ - Using uv as the package manager
4 │
5 │ ## Task Management
6 │ - Стратегические задачи хранятся в @docs/05_ROADMAP.md — глобальные задачи.
7 │ - Тактические задачи хранятся в @TODO.md - архитектурные улучшения и технические задачи
8 │ - После завершения задачи помечаются выполненными (✅) в TODO.md
9 │ - Обновляй статус в процессе работы - отслеживай прогресс по каждой задаче
10 │
11 │ ## Core Programming Principles (из @docs/04_REQUIREMENTS/README.md)
12 │ 1. Fail-Fast - валидация на входе, исключения вместо null/undefined
13 │ 2. Явное лучше неявного - все зависимости явно переданы
14 │ 3. No Legacy, No Fallbacks, No Backward compatibility, No versioning
15 │ 4. Scalability by Design - "Как это будет работать для 100x данных?"
Правда все равно приходиться регулярно бить по рукам, потому что Claude иногда забивает на правила.
Я использую Gemini как архитектора — он отлично с этим справляется, а Claude кодит.
Иронично, конечно, что у человека были жалобы на сотни ботов, и ему отвечает как раз vesper-bot. Хорошее чувство юмора у вас там в пентагоне или где вас там компилировали жидомасонские рептилоиды на сатанинских LLM.
Jetbrains еще.