Спасибо за статью! сам растом пока ещё не пользовался, только планирую. Очень здорово что вы поделились местом где лежат грабли и советами как обойти. С вашего позволения хочу предложить свои 5 копеек:
Мне кажется, часть этих проблем можно снижать не только промптами и CI, но и устройством самой кодовой базы.
Если коротко:
Делать в коде “липкие комментарии” в узловых местах. Не комментарии вида “тут создаём кеш”, а предупреждения: “этот кусок связан с таким-то внешним контрактом, не упрощать, не переносить, не менять порядок операций”.
Комментарий должен быть не источником истины, а навигатором: “смотри такой-то контракт / blueprint / ADR / тест”. Тогда агент, который пришёл менять локальный кусок кода, получает шанс добрать нужный внешний контекст.
Важные правила лучше фиксировать в нескольких слоях: документ → схема/тип → тест → runtime check → sticky comment рядом с местом риска. Тогда LLM не просто “прочитала пожелание”, а попала в систему ограничителей.
Нужны не только промпты “напиши правильно”, а проектные skills/runbooks: если меняешь async-код — проверь отмену; если меняешь публичный API — проверь совместимость; если трогаешь кеш/транзакции/lock — проверь порядок владения и побочные эффекты.
Агенту полезно давать не весь репозиторий сразу, а маршрутизированный контекст: какие документы канонические, какие решения уже приняты, какие места нельзя “улучшать”, какие инварианты обязательны.
После реализации агент должен не просто прогнать тесты, а сделать контрактный аудит: какие инварианты затронуты, какие sticky comments обновлены, какие рисковые места проверены.
То есть проблема не только в том, что LLM не видит контекст. Проблема в том, что контекст часто не оформлен как инженерная система. Если превратить его в контракты, локальные маяки, тесты и обязательные проверки, часть “слепых зон LLM” становится обычным управляемым риском.
И все таки еще раз спасибо за статью! В эпоху вайбкодинга, такие материалы от реальных разработчиков на вес золота!
Если говорить про самую громкую идею — что из данных Pokémon Go строится «большая геопространственная модель мира» для ИИ, роботов и автономных систем, — то тут корректнее говорить так: фундамент уже существует, данные уже собираются и используются, но глобальный LGM — это пока стратегическое направление и активная разработка, а не готовый массовый продукт, который повсеместно работает в промышленности. Niantic сама пишет о long term goal и о том, что этот model “will be” основой пространственно-интеллектуального ИИ.
А можно больше деталей? Речь идет о генерации задач, материалов? По каким дисциплинам? Почему fine tuning а не rag? Были ли у вас r&d , неужели системный Промт + rag не вывез бы этот кейс?
Автор (Юрий Строжевский, @ystr — опытный разработчик с 1998 года, автор «КриптоАРМ» и нескольких статей по криптографии/Kerberos) пошёл дальше стандартной документации MSDN и книг типа «Windows Internals». Он собрал в одном месте то, что обычно приходится собирать по кусочкам и за это огромное спасибо!!!
Ключевые "жемчужины", которых почти нигде нет в таком виде:
Полный цикл кодирования/декодирования всех основных типов NDR через низкоуровневые функции (пример в папке NDR2).
Реализация сервера, который работает с произвольными (неструктурированными) данными в многопоточной среде, с разными object ID и manager EPV (RPCServer2).
Как использовать manager EPV нестандартно (автор даже хранит в нём целые числа вместо указателей на функции — это уже хакерский уровень).
Динамическая регистрация object/type ID, security callback, расширенные ошибки (RPC_EE_INFO), impersonation клиента и получение его адреса.
Полноценный клиент без MIDL (RPCClient2) + отдельный пример клиента для самого EPMAPPER с ручным разбором tower.
Так смотрите я правильно понял суть вашего проекта что теперь openclaw может общаться через API с wb, Yandex market, ozon и основной интерфейс у вас это мессенджеры которые подключены к openclaw?
Если бы вы знали, сколько раз ко мне люди обращались с просьбой восстановить удалённую ими же информацию и в этом им не "помогал" агент они сами , вполне самостоятельно мудрялись удалять важную для них информацию.
Все ок. Вы все понятно и доступно объяснили. Возможно я жестянул, если хотите, могу поправить свой коммент. В любом случае респект, что поделились опытом. Кому то может и пригодится.
Описанное в статье «автоматическое чанкование» — это подмена понятий: авторы называют автоматизацией обычную замену стандартного токенизатора на не менее стандартный сплиттер по заголовкам Markdown, который в LangChain существует уже несколько лет. Весь «кастомный алгоритм» сводится к двум эвристикам — «склеивать чанки меньше 100 токенов» и «добавить overlap 15%». Это базовая настройка, которая делается за час любым стажёром, прочитавшим документацию, а не результат R&D, достойный отдельной статьи с пафосным заголовком про «95% точности».
Метрики, которыми авторы козыряют, не выдерживают критики. Бенчмарк составлен «для себя» на неизвестном количестве примеров — нет ни слова про объём выборки, её репрезентативность или хотя бы методологию исключения переобучения под конкретные запросы. Триграммное сходство с порогом 80% — это мера буквального совпадения текста, а не семантической релевантности; такими «метриками» нельзя измерить качество RAG, ими можно только создать иллюзию измеримости. Реранкер поднял точность с 70% до 95% — это неизбежно следует из самой архитектуры cross-encoder, но авторы умалчивают, что эта «точность» посчитана на том же куцем бенчмарке, и что платой за неё стали 16 секунд latency на CPU, которые в продакшене означают непригодность решения без покупки GPU. По сути, перед нами типичный корпоративный отчёт «как мы перестали использовать параметры по умолчанию и начали пользоваться платными моделями», раздутый до масштаба открытия.
Валидация: Скрипт проверяет regex на исторических данных.
Коммит: Автоматический пул-реквест в Git с файлом regex и объяснением.
Ревью (опционально, но желательно): Человек проверяет не сам regex (это сложно), а логику объяснения. "Да, верно — это действительно логи входа от Django, и IP-адрес нам критически важен".
Деплой: После мержа PR пайплайн автоматически обновляет парсер в боевой системе.
А так в целом молодцы! Было интересно. А впечатления после -n времени эксплуатации этого подхода?
Краткое содержание статьи «Почему ничего нельзя вайбкодить — на примере Телеграм-бота»
В статье на примере создания Telegram-бота разбирается, почему попытка быстро «навайбкодить» (сгенерировать с помощью ИИ) сложный продукт без должных знаний обречена на провал. Автор сравнивает путь своего друга-«вайбкодера» с использованием готового профессионального сервиса **ChatKeeperBot**.
Ключевые проблемы, с которыми столкнулся «вайбкодер»:
1. Модерация и антиспам:
* Невозможность создать эффективный фильтр против умных спамеров, прячущих рекламу в описании профиля.
* ИИ забыл про базу данных для системы предупреждений (варнов), из-за чего данные обнулялись после перезапуска.
* Проблемы с конкурентным доступом к БД (когда два пользователя действуют одновременно).
2. **Триггеры и логика (киллер-фича)**:
* Для реализации цепочки действий «запрос -> проверка подписки -> выдача промокода» потребовалось вручную реализовывать **машину конечных состояний (FSM)**.
* Код от ИИ был неполным, содержал ошибки (например, путал состояния при двойном нажатии кнопки) и превратился в нечитаемое месиво.
* В готовом сервисе та же логика настраивается визуально за минуты через конструктор цепочек.
3. Геймификация и аналитика:
* Простая система репутации («плюсов») сразу же подверглась накрутке друзьями.
* Хранение данных в JSON стало неэффективным при росте аудитории, а миграция на SQL выявила новые проблемы с конкурентными запросами.
* В готовом боте система уровней с защитой от накрутки включается одной галочкой.
Основной вывод
ИИ — это инструмент, а не волшебная кнопка.Он не может заменить понимание архитектуры, фреймворков и принципов работы (базы данных, состояния гонки, FSM). Попытка создать сложный продукт только на промптах приводит к потере времени, созданию неустойчивого кода и решению уже решенных другими проблем. Профессиональные готовые решения часто экономичнее, так как избавляют от необходимости изобретать, отлаживать и поддерживать сложные системы с нуля.
Автор активно продвигает конкретный сервис (ChatKeeperBot) и является его пользователем. Хотя примеры наглядны, сложно исключить предвзятость. Его цель — не только предостеречь от «вайбкодинга», но и показать преимущества готового решения, что несколько смещает фокус с объективного анализа.
MeshCentral. Бесплатно.
Спасибо за статью! сам растом пока ещё не пользовался, только планирую. Очень здорово что вы поделились местом где лежат грабли и советами как обойти. С вашего позволения хочу предложить свои 5 копеек:
Мне кажется, часть этих проблем можно снижать не только промптами и CI, но и устройством самой кодовой базы.
Если коротко:
Делать в коде “липкие комментарии” в узловых местах. Не комментарии вида “тут создаём кеш”, а предупреждения: “этот кусок связан с таким-то внешним контрактом, не упрощать, не переносить, не менять порядок операций”.
Комментарий должен быть не источником истины, а навигатором: “смотри такой-то контракт / blueprint / ADR / тест”. Тогда агент, который пришёл менять локальный кусок кода, получает шанс добрать нужный внешний контекст.
Важные правила лучше фиксировать в нескольких слоях: документ → схема/тип → тест → runtime check → sticky comment рядом с местом риска. Тогда LLM не просто “прочитала пожелание”, а попала в систему ограничителей.
Нужны не только промпты “напиши правильно”, а проектные skills/runbooks: если меняешь async-код — проверь отмену; если меняешь публичный API — проверь совместимость; если трогаешь кеш/транзакции/lock — проверь порядок владения и побочные эффекты.
Агенту полезно давать не весь репозиторий сразу, а маршрутизированный контекст: какие документы канонические, какие решения уже приняты, какие места нельзя “улучшать”, какие инварианты обязательны.
После реализации агент должен не просто прогнать тесты, а сделать контрактный аудит: какие инварианты затронуты, какие sticky comments обновлены, какие рисковые места проверены.
То есть проблема не только в том, что LLM не видит контекст. Проблема в том, что контекст часто не оформлен как инженерная система. Если превратить его в контракты, локальные маяки, тесты и обязательные проверки, часть “слепых зон LLM” становится обычным управляемым риском.
И все таки еще раз спасибо за статью! В эпоху вайбкодинга, такие материалы от реальных разработчиков на вес золота!
Вы к нам давно приехали из идеального мира?)))) тут у людей каждое второе слово галлюцинация!
Если говорить про самую громкую идею — что из данных Pokémon Go строится «большая геопространственная модель мира» для ИИ, роботов и автономных систем, — то тут корректнее говорить так: фундамент уже существует, данные уже собираются и используются, но глобальный LGM — это пока стратегическое направление и активная разработка, а не готовый массовый продукт, который повсеместно работает в промышленности. Niantic сама пишет о long term goal и о том, что этот model “will be” основой пространственно-интеллектуального ИИ.
А можно больше деталей? Речь идет о генерации задач, материалов? По каким дисциплинам? Почему fine tuning а не rag? Были ли у вас r&d , неужели системный Промт + rag не вывез бы этот кейс?
Иммунитет снижает армия, я такой делаю вывод 🤷
https://github.com/techserv/Open-NotebookLM
100%
Гранд респект!!!!
Автор (Юрий Строжевский, @ystr — опытный разработчик с 1998 года, автор «КриптоАРМ» и нескольких статей по криптографии/Kerberos) пошёл дальше стандартной документации MSDN и книг типа «Windows Internals». Он собрал в одном месте то, что обычно приходится собирать по кусочкам и за это огромное спасибо!!!
Ключевые "жемчужины", которых почти нигде нет в таком виде:
Полный цикл кодирования/декодирования всех основных типов NDR через низкоуровневые функции (пример в папке NDR2).
Реализация сервера, который работает с произвольными (неструктурированными) данными в многопоточной среде, с разными object ID и manager EPV (RPCServer2).
Как использовать manager EPV нестандартно (автор даже хранит в нём целые числа вместо указателей на функции — это уже хакерский уровень).
Динамическая регистрация object/type ID, security callback, расширенные ошибки (RPC_EE_INFO), impersonation клиента и получение его адреса.
Полноценный клиент без MIDL (RPCClient2) + отдельный пример клиента для самого EPMAPPER с ручным разбором tower.
Так смотрите я правильно понял суть вашего проекта что теперь openclaw может общаться через API с wb, Yandex market, ozon и основной интерфейс у вас это мессенджеры которые подключены к openclaw?
По сути у вас получился своеобразный "MCP" слой?
Смоки тесты не?
Если бы вы знали, сколько раз ко мне люди обращались с просьбой восстановить удалённую ими же информацию и в этом им не "помогал" агент они сами , вполне самостоятельно мудрялись удалять важную для них информацию.
Подгорает))))
Все ок. Вы все понятно и доступно объяснили. Возможно я жестянул, если хотите, могу поправить свой коммент. В любом случае респект, что поделились опытом. Кому то может и пригодится.
Описанное в статье «автоматическое чанкование» — это подмена понятий: авторы называют автоматизацией обычную замену стандартного токенизатора на не менее стандартный сплиттер по заголовкам Markdown, который в LangChain существует уже несколько лет. Весь «кастомный алгоритм» сводится к двум эвристикам — «склеивать чанки меньше 100 токенов» и «добавить overlap 15%». Это базовая настройка, которая делается за час любым стажёром, прочитавшим документацию, а не результат R&D, достойный отдельной статьи с пафосным заголовком про «95% точности».
Метрики, которыми авторы козыряют, не выдерживают критики. Бенчмарк составлен «для себя» на неизвестном количестве примеров — нет ни слова про объём выборки, её репрезентативность или хотя бы методологию исключения переобучения под конкретные запросы. Триграммное сходство с порогом 80% — это мера буквального совпадения текста, а не семантической релевантности; такими «метриками» нельзя измерить качество RAG, ими можно только создать иллюзию измеримости. Реранкер поднял точность с 70% до 95% — это неизбежно следует из самой архитектуры cross-encoder, но авторы умалчивают, что эта «точность» посчитана на том же куцем бенчмарке, и что платой за неё стали 16 секунд latency на CPU, которые в продакшене означают непригодность решения без покупки GPU. По сути, перед нами типичный корпоративный отчёт «как мы перестали использовать параметры по умолчанию и начали пользоваться платными моделями», раздутый до масштаба открытия.
5 копеек:
Рабочий процесс с CI/CD
Генерация: LLM создаёт regex + объяснение.
Валидация: Скрипт проверяет regex на исторических данных.
Коммит: Автоматический пул-реквест в Git с файлом regex и объяснением.
Ревью (опционально, но желательно): Человек проверяет не сам regex (это сложно), а логику объяснения. "Да, верно — это действительно логи входа от Django, и IP-адрес нам критически важен".
Деплой: После мержа PR пайплайн автоматически обновляет парсер в боевой системе.
А так в целом молодцы! Было интересно. А впечатления после -n времени эксплуатации этого подхода?
Lemonfox движок whisper, цена 0.17$ час
Краткое содержание статьи «Почему ничего нельзя вайбкодить — на примере Телеграм-бота»
В статье на примере создания Telegram-бота разбирается, почему попытка быстро «навайбкодить» (сгенерировать с помощью ИИ) сложный продукт без должных знаний обречена на провал. Автор сравнивает путь своего друга-«вайбкодера» с использованием готового профессионального сервиса **ChatKeeperBot**.
Ключевые проблемы, с которыми столкнулся «вайбкодер»:
1. Модерация и антиспам:
* Невозможность создать эффективный фильтр против умных спамеров, прячущих рекламу в описании профиля.
* ИИ забыл про базу данных для системы предупреждений (варнов), из-за чего данные обнулялись после перезапуска.
* Проблемы с конкурентным доступом к БД (когда два пользователя действуют одновременно).
2. **Триггеры и логика (киллер-фича)**:
* Для реализации цепочки действий «запрос -> проверка подписки -> выдача промокода» потребовалось вручную реализовывать **машину конечных состояний (FSM)**.
* Код от ИИ был неполным, содержал ошибки (например, путал состояния при двойном нажатии кнопки) и превратился в нечитаемое месиво.
* В готовом сервисе та же логика настраивается визуально за минуты через конструктор цепочек.
3. Геймификация и аналитика:
* Простая система репутации («плюсов») сразу же подверглась накрутке друзьями.
* Пришлось вручную дописывать сложные проверки: таймауты, запрет самолайков, суточные лимиты.
* Хранение данных в JSON стало неэффективным при росте аудитории, а миграция на SQL выявила новые проблемы с конкурентными запросами.
* В готовом боте система уровней с защитой от накрутки включается одной галочкой.
Основной вывод
ИИ — это инструмент, а не волшебная кнопка.Он не может заменить понимание архитектуры, фреймворков и принципов работы (базы данных, состояния гонки, FSM). Попытка создать сложный продукт только на промптах приводит к потере времени, созданию неустойчивого кода и решению уже решенных другими проблем. Профессиональные готовые решения часто экономичнее, так как избавляют от необходимости изобретать, отлаживать и поддерживать сложные системы с нуля.
Автор активно продвигает конкретный сервис (ChatKeeperBot) и является его пользователем. Хотя примеры наглядны, сложно исключить предвзятость. Его цель — не только предостеречь от «вайбкодинга», но и показать преимущества готового решения, что несколько смещает фокус с объективного анализа.
Если просто, то двоечника заставляют рассуждать как отличника.