IT-ХОЗЯЕВА

📰 RAG: eval и данные важнее кода По данным статьи, автор построил RAG-бота для модерации крипточатов и обнаружил, что стандартные улучшения (BM25, реранкер) на его данных ухудшили метрики. Ключевой вывод: настоящая работа — в создании честного eval-харнеса и чистке корпуса, а не в коде. Например, из-за неверной разметки эталона метрика показывала 38%, хотя реальная точность была выше. Меня зацепило, что автор честно признал: он чуть не пошёл улучшать рабочий поиск из-за кривой разметки. По-моему, это типичная ловушка для RAG-проектов — все гонятся за модными компонентами, но без качественного eval-набора любые «улучшения» — это гадание. Я бы добавил, что диагностика с разделением позиции правильного ответа и причины промаха должна быть обязательной, но её системно игнорируют. Источник #новости

🎙️ Бэкендеры заменят фронтов. Трансформация в корпорации. Что делать фронтам? Всё так плохо? 📅 25.07.2026 в 12:00 (МСК) Подробности на платформе #сообщество

​​Итоги CodeRun Summer: 15 задач и 636 попыток решения Финал CodeRun Summer Challenge выглядит аккуратно: 15 задач из 15 и третье место среди JavaScript-решений. Но за рейтингом остались 636 отправок, 443 WebAssembly-модуля и 548 тысяч строк тестов и бенчмарков.…

​​Итоги CodeRun Summer: 15 задач и 636 попыток решения Финал CodeRun Summer Challenge выглядит аккуратно: 15 задач из 15 и третье место среди JavaScript-решений. Но за рейтингом остались 636 отправок, 443 WebAssembly-модуля и 548 тысяч строк тестов и бенчмарков. Финальные 15 файлов заняли всего 1 142 строки. На одну строку решения пришлось около 480 строк экспериментов. Сложнее всего сказать когда соревнование алгоритмов переросло в соревнование моделей и микрооптимизаций. Немного сухой статистики - 15 решенных задач, итоговое 3 место - 1 задача с лучшим результатом, 39 мс - Репозиторий весом 1,35 ГБ и 4 708 файлов. - 199 052 строк на C - 1210 сессий с агентами - 8 852 044 861 чистых токенов без форка для сабагентов Главное открытие: Accepted — не конец работы. Интересные факты Самая большая задач имеет 507 кандидатов и 232 092 строк исходников, а самая маленькая 16 файлов и 1 821 строку. Для одной из задач пришлось создать 394 МБ тестовых данных. В одной задаче вычислительное ядро занимало около 1,36 мс, а весь прогон десятки миллисекунд. Мои главные уроки В начале я воспринимал задачу буквально: выбрал JS — значит решай на Pure JS. Но смена парсера, структур данных и алгоритмов не давали впечатляющих результатов. Опыт полезный, но слишком много попыток потрачено на такой принцип, а они были ограничены. Нельзя было пользоваться отправкой как способом подбора идей. Скрытые тесты живут в другой вселенной, и нельзя слепо верить принципу: локально стало быстрее, значит отправляем. Изначально выстраивать идеальный сценарий с агентом, который начинает не с кода, а с условия: фиксирует контракт задачи, ограничивает рантайм. Затем строит оракул, тесты и воспроизводимый бенчмарк на точной версии Node.js. Каждая идея проверяется в отдельном кандидате, и до браузера доходит только вариант, который сохраняет корректность и стабильно выигрывает на нескольких профилях. После отправки агент сверяет результат с тем исходником, который действительно ушёл в судью. Так CodeRun становится финальной проверкой измеренного улучшения, а не дорогим генератором случайных чисел. Wasm не оказался волшебной палочкой. Часто выигрыш съедала компиляция, иногда обмен с памятью. Локальные миллисекунды врут. На результат влияют прогрев, скрытые данные, ввод. Поэтому локальная медиана стала не доказательством, а основанием продолжить эксперимент. Однажды Monaco склеил старый код с хвостом нового. Так выяснилось, что сверка исходника перед отправкой — тоже часть алгоритма. В итоге сработал не один трюк, а смена процесса: замороженный контроль, проверка корректности, разные профили, одна гипотеза за эксперимент и отправка только при измеримом запасе. --- #CodeRun #Challenge #JavaScript #Benchmark #8bitJS

​​Ускоряем O(N + T), не меняя Big O. Часть 2. Четыре байта, которые могут изменить результат В первой части мы получили решение через разностный массив со сложностью O(N + T) и результатом 1,589 секунды. Big O отвечает на вопрос, как растет количество работы. Но внутри алгоритма куда более важную часть играют размер одной записи в памяти, количество временных объектов, случайные обращения к большому массиву, стоимость разбора входных данных. Теперь посмотрим не на количество операций, а на то, что именно лежит в памяти. В JavaScript все обычные числа имеют тип Number. По спецификации это 64-битные числа с плавающей точкой IEEE 754. Внутри V8 их представление может меняться: небольшие целые числа могут храниться как Smi, а остальные — как HeapNumber. Об этом подробнее писал ранее: Как V8 работает с числами. Small Integer теория и HeapNumber в V8. Как хранятся числа вне Smi. Теория часть 1 Но у TypedArray правила проще: - Int32Array хранит ровно 32-битные знаковые целые; - Float64Array хранит 64-битные числа с плавающей точкой. При T = 10 000 000 только сам разностный массив занимает примерно: Int32Array 4 байта на одну запись и для всего массива около 40 МБ Float64Array8 байт на одну запись и для всего массива около 80 МБ В два раза меньше памяти означает, что через иерархию кэшей процессора приходится протаскивать меньше данных. Выбор очевиден, но есть небольшое «но». Переполнение По условию одна заявка содержит не больше 1 000 000 велосипедов. Такое значение спокойно помещается в Int32. Но в одной точке разностного массива могут встретиться миллионы одинаковых событий: diff[a] += s; Отдельное значение s помещается в 32 бита, а их сумма — уже нет. Int32Array не бросает ошибку и не превращает значение в обычный Number. При записи он просто оставляет младшие 32 бита: const values = new Int32Array(1); values[0] = 2_147_483_647; values[0] += 1; console.log(values[0]); // -2147483648 Мы прибавили единицу к положительному числу и получили отрицательное — произошло переполнение. Для JavaScript Number это все еще безопасное целое значение, но для одной ячейки Int32Array — уже нет. Подведем итог На этом этапе становится понятно: оптимизация не только про уменьшение количества операций, но и про понимание того, как данные живут в памяти. Мы уменьшили размер массива в два раза, но столкнулись с проблемой переполнения. И это отличный пример того, как низкоуровневые детали могут незаметно повлиять на корректность результата. Любые оптимизации всегда требуют баланса между скоростью и памятью. —- #JavaScript #V8 #TypedArray #Int32Array #Overflow #Performance #CodeRun #8BitJS

Выступление от нашего гигачада @fronted_engineer https://youtu.be/XQ9E-r7i0oE

🗞️ Fedora 45 включает теневой стек: защита от ROP для новых процессоров Fedora 45 собирается включить защиту на основе теневого стека (Shadow Stack) по умолчанию для бинарников, собранных под x86_64. Это аппаратная фича Intel CET, доступная начиная с 11-го поколения Intel (Tiger Lake, Rocket Lake) и AMD Zen3. Включат поддержку в GCC, Clang и rustc — то есть под раздачу попадают C, C++ и Rust. Что это даёт на практике: если в приложении переполнят буфер на стеке и попытаются переписать адрес возврата, теневой стек это заметит — у него своя копия адресов в защищённой области памяти. ROP-атаки (Return-Oriented Programming) становятся значительно сложнее. Разумеется, на старых процессорах без аппаратной поддержки (Zen2 и старше) инструкции CET просто работают как NOP — защита не включается, но и не ломает совместимость. Лично я считаю это правильным шагом: лучше защитить пользователей современного железа, чем тянуть совместимость с процессорами десятилетней давности. Fedora всегда была дистрибутивом для тех, кто хочет новое, а не для тех, кто сидит на Pentium 4. Если у вас Zen2 — ну, может, пора подумать об апгрейде. А если боитесь, что какой-то старый софт сломается — всегда можно пересобрать пакет с флагом -fcf-protection=none. Но в целом, безопасность в продакшене того стоит. Источник #новости

🎉 Vue SOTA 2026: на чем строим фронтенд в эпоху ИИ Доклад о том, где мы находимся сейчас в экосистеме Vue и почему его по-прежнему можно использовать несмотря на то, что большинство вокруг использует React. Будет немного (немного) истории, еще немного сравнения фреймворков, а затем поговорим о том как теперь пишем на Вью и Наксте с агентами. 📅 09.07.2026 в 19:00 (МСК) Подробности на платформе #сообщество

telega-gleam 2.0 🚀 В целом, я убил все остальные фреймворки для тг ботов. Расходимся. Главная темка для меня была наконец завести канал зависимостей как R в Effect.ts чтобы из библиотечки можно было выйти действительно в станы фреймворков. Проблема была такая: все сервисы (db pool, http-клиент, i18n) приходилось пихать в сессию (а это персистируемое состояние) и в адаптере я откидывал эти поля и это по сути утекшая абстракция. Теперь у Context третий дженерик dependencies: telega.new_for_polling_with_dependencies( api_client:, dependencies: Deps(db:, http:, i18n:), ) И в любом хендлере можно достать зависимости из контекста. Ничего глобального, все покрыто типами, в тестах легко подменить что хочешь. Дальше всё нанизалось само: 💜storage-слой под одним контрактом сразу с реализацией для postgres / sqlite / redis 💜завел telemetry span-событий на BEAM которые можно нацепить на PromEx/otel 💜telega_webapp + telega_i18n позволяет по кайфу делать фуллстак-приложения целиком на Gleam 💜graceful shutdown теперь без потери апдейтов от телеграмма с полноценным дрейном соединений для всех адаптеров и RAII подходом для зависимостей 💜авто-команды для роутера и поддержка переводов для всего этого Мне лично кажется что я довел проект до отличного состояния и теперь точно дальше только полишинг. Тч ставим звездочки и пробуем

Код от нейронки плоский — как и её тексты. Только в тексте это заметно всем Смотрите, я сам сижу на Claude Code каждый день, он реально ускоряет. Но есть вещь, которую вайб-кодеры упорно не видят: код, сгенерированный нейронкой, получается плоским. Как её тексты — гладкими, грамматически идеальными и абсолютно пустыми. Только в тексте это видит любой читатель, а в коде — только инженер, которого вайб-кодер из процесса выкинул. Возьмём конкретный пример — функцию secure_filename из Werkzeug. Наивный промпт «сделай безопасное имя файла» выдаёт вполне рабочую функцию: чистит пробелы, оставляет буквы и точки. Демка работает. Но она не обрабатывает кучу граничных случаев: имя файла «..» (ссылка на родительскую папку) останется как есть, «CON.txt» на Windows не переименуется в зарезервированное имя устройства, а «naïve.txt» не транслитерируется в ASCII. Оригинал делает всё это — и ещё кучу мелочей, которые автор просто знает, потому что писал не первый день. И это ключевой момент. Разрыв между кодом сеньора и кодом вайб-кодера — это разрыв в промпте. Сеньор знает, о каких граничных случаях надо сказать нейронке, потому что наступал на эти грабли. Вайб-кодер не знает даже, что такие случаи существуют, и не может попросить то, о чём не догадывается. В итоге он получает «работающий» код, который на самом деле гнилой. И главная проблема: он этого никогда не узнает, потому что оценить код некому. Тесты пройдены? Работает. А что под капотом — никого не волнует, пока не грохнется прод. Вывод простой: нейронка генерирует локально корректный код, который глобально ущербен. И если ты не умеешь читать код — ты покупаешь видимость работающей системы, а не систему. Промпт — вот где настоящая экспертиза, и её не заменят никакие AI-инструменты.

📚 AI-агенты — что это, как работают и как собрать своего в 2026 «Сделайте нам AI-агента» — за год это превратилось из хайпа в обычную строчку в задаче. Но под словом «агент» каждый понимает своё: кто-то чат-бота с кнопками, кто-то автономную систему, которая сама ходит по сервисам и что-то делает. Разбираем, что такое агент на самом деле, из чего он собран, где уже приносит пользу и почему первая версия так любит сжигать бюджет. Читать на ithozyaeva.ru #статьи

💡 Netflix сделала карту микросервисов, которой не хватало каждому Ночные инциденты в микросервисах — это всегда детектив: метрики орут, логи сыплются, трейсы показывают путь конкретного запроса, но ответа на вопрос «кто кого убил» нет. Netflix построила инструмент, который решает эту проблему в лоб — Service Topology. Это живая карта зависимостей между сервисами, которая обновляется в реальном времени и показывает не только «кто с кем говорит», но и статус здоровья каждого узла, бизнес-домен и владельца. Главный трюк в том, что они не полагаются на один источник данных. eBPF-сетевые потоки дают полноту (все соединения, даже неинструментированных сервисов), IPC-метрики добавляют прикладной контекст (конкретный endpoint, ошибки, задержки), а распределённые трейсы показывают реальное поведение запросов. Ни один слой не идеален, но вместе они компенсируют слабости друг друга. Система строит три независимых графа и сливает их по запросу за доли секунды. Что это даёт на практике? Инженер может за секунду узнать, кто upstream и downstream у любого сервиса, оценить зону поражения перед плановым отключением, одним кликом перейти от узла к трейсам или логам, а главное — наложить статус здоровья на граф и сразу понять, локальная проблема или каскадный сбой. Плюс «путешествие во времени»: можно посмотреть топологию на любой момент в прошлом без взрыва хранилища. Вся архитектура — графовая база поверх KV-стора, gRPC-API с фильтрами и ответом быстрее секунды. Для меня ключевой вывод: обычные инструменты наблюдаемости показывают симптомы, но не карту болезни. Если у вас больше пары десятков сервисов, инвестиция в такую топологию окупится первой же ночной аварией, когда не надо будет мысленно склеивать связи между панелями. Источник #новости

🎙️ Хватит сливать токены! Базовая гигиена для экономии лимитов ИИ-агентов Разберём базовую гигиену работы с ИИ-агентами: как не засорять контекст, не терять качество ответов и экономнее расходовать лимиты. На встрече обсудим основы, без сложной теории и глубокой технической части — особенно актуально для тех, кто использует недорогие подписки на ИИ, где лимиты улетают быстрее всего. 📅 20.06.2026 в 20:00 (МСК) Подробности на платформе #сообщество

📰 Переработки: как компании превращают вашу ответственность в бесплатный ресурс Исследование: переработки в IT редко начинаются с прямых требований — компании просто создают среду, где отказаться "неудобно". Автор разбирает механизм: сначала «чуть-чуть дожать», потом «важный релиз», и вот ты уже в 23:17 с холодным ужином. Главный вывод: переработки — это не про плохое планирование инженера, а про системные проблемы — сжатые сроки, игнорирование рисков и героический менеджмент. Если в твоей команде «авральный режим» стал нормой — это не твоя вина, а повод пересмотреть процессы. Источник #новости

🤝 Локальные LLM: как и зачем запускать ИИ у себя дома. Краткое введение в локальные большие языковые модели: что это такое, чем они отличаются от облачных frontier-моделей, на каком железе их запускать и какие задачи они уже могут решать. Разберём практические сценарии для разработчиков, ограничения локальных моделей, роль RAG, tooling вокруг моделей и почему будущее, скорее всего, не в выборе “локально или облако”, а в гибридном AI-runtime. 📅 23.06.2026 в 20:00 (МСК) Подробности на платформе #сообщество

⚡️ Мы попробовали Claude Code в энтерпрайз-разработке и собрали за вас восемь проблем Коллеги из Циана попробовали Claude Code в энтерпрайз-разработке и собрали 8 проблем. Главная боль: хранение конфигов в репозиториях — если не класть .claude и claude.md в компонент, помощник теряет настройки. Решение — плагины для общей конфиги и MCP для компонентоспецифичной. Вторая проблема — Windows: Claude Code путается в bash-командах, а инструменты сборки отличаются. Циан видит выход в WSL или отказе от Windows. Ещё петли обратной связи: корневой агент должен проверять субагентов, иначе код может не соответствовать требованиям. Итог: Claude Code мощный, но внедрение в большую компанию — это не «поставил и забыл», а настройка инфраструктуры и процессов. Источник #новости

📚 RAG на практике — как построить поиск по своим данным для LLM RAG (Retrieval-Augmented Generation) — самый частый запрос к AI-инженеру: «сделай, чтобы модель отвечала по нашим документам». На бумаге всё просто: нарезал документы, сложил в векторную базу, достал релевантное, подсунул модели. На практике первая версия почти всегда отвечает мимо. Разбираем, как RAG устроен на самом деле, где он ломается и когда его вообще не нужно строить. Читать на ithozyaeva.ru #статьи

🗞️ Смогут ли LLM выжить во время катастрофы? Gemini, ChatGPT и другие играют в «Бункер» (анализ поведения) LLM-модели проверили в игре «Бункер» — выживание с голосованием и скрытыми картами. 8 моделей (Gemini 3 Flash, ChatGPT 5 mini, Grok 4.3 и др.) соревновались, кто останется в убежище. Интересно: проверяли, будут ли модели поддаваться толпе, оценивать скрытые риски и отдавать предпочтение прикладным профессиям. Результаты — в статье. Хороший повод задуматься, насколько ваши AI-агенты адекватны в нестандартных задачах. Источник #новости

🔍 MCP-серверы — что это, зачем нужны и как подключить в 2026 MCP (Model Context Protocol) — это протокол, через который AI-ассистенты подключаются к вашим инструментам: базам данных, API, файлам, браузеру. Если вайбкодинг — это «AI пишет код», то MCP — это «AI дотягивается до всего остального». Разбираем, как устроен протокол, какие серверы реально полезны и как подключить первый MCP-сервер за пять минут. Читать на ithozyaeva.ru #статьи

🗞️ Cloudflare приобрела VoidZero — создателей Vite, Vitest и Rolldown Cloudflare купила VoidZero — компанию Эвана Ю (создателя Vue.js), которая стоит за Vite, Vitest, Rolldown и Oxc. Вся команда переходит в Cloudflare, но проекты остаются открытыми (MIT) и независимыми. Cloudflare выделила $1 млн в фонд экосистемы Vite. Vite — это 129 млн загрузок в неделю, его используют Vue, SvelteKit, Nuxt, Astro, Solid, Qwik, Angular, React Router и даже Next.js. В краткосроке ничего не меняется, в долгом — Cloudflare построит CLI на основе Vite. Хорошая новость: инфраструктурный гигант вкладывается в открытый инструмент, не пытаясь его закрыть. Источник #новости