IT

Все, с выходом Fable и 5.6 sol вы больше не должны понимать, что происходит у вас в коде. Не до всех еще дошло, но вы больше не software engineer, вы loop engineer

↑ Я думал, что это типичный твиттер шитпостинга, но реально начал видеть вокруг себя серьезных людей, кто так считает. Мол, раз у Бориса в антропике получается, то и мы так должны делать

Ну камон, ребят. Все же понимают, что публичные лица компаний, который продают лопаты всегда будут преувеличивать ценность этих лопат и формировать хайп, который через какое-то время действительно пушанет технологии до уровня, который они продвигали. Типичный fake it till your make it – так все технологии развиваются и всегда развивались. Но мы то с вами не обязаны собой жертвовать ради этого, ну Почему я считаю, что сейчас это все еще не работает и хорошие инженеры должны понимать что происходит под капотом систем, которые они строят (даже если они строят их печатая/наговаривая английский/русский текст)? Постараюсь порассуждать "из первых принципов": Дело в том, что это всегда так и было – хороший инженер всегда понимал систему как минимум на один уровень абстракции ниже того, на котором её писал. Хороший Python разработчик знает про GIL и 3.13, PyMalloc, сборщик мусора, ссылочную природу объектов, и что многие библиотеки написаны на других языках со своими ограничениями и возможностями. И для него код на пайтоне на самом деле раскрывается гораздо глубже чем он выглядит на первый взгляд – тот самый tacit context Хороший C++ разработчик скорее всего знает не только про разные виды памяти, устройство умных указателей и виртуальные таблицы, но и в курсе про уровни хардварного кэша, особенности архитекутры процессора и хаки, которые использует компилятор для компиляции под эти архитекутры. И может даже знать, в какие конкретно ассемблерные инструкции раскроется его код. Понимает как треды устроены на уровне ОС, какие механизмы их переключения на уровне ядра, и как писать lock-free код ↑ Этого всего нет напрямую в синтаксисе языка. Это особенности поведения систем на гораздо более низких уровнях. И проблема в том, что если инженер их не знает, то он даже не знает чего он не знает. А значит, не узнает и о наличии проблем на этих уровнях. В итоге прод ложится под растущей нагрузкой, баги не находятся неделями и затыкаются костылями, из-за которых прод снова ложится, но уже в следующем квартале ——— Короче, мало топить за loop enginering. Нужно понимать что в результате этих циклов получится Так же как когда вы пишете цикл на C++, вы понимаете, как данные будет лежать в кэше (и в каком), будут ли лишние аллокации в куче, и раскроется ли ваша числодробилка в SIMD-инструкции В общем, это фундаментальное свойство любого профессионала – видеть систему глубже чем она описана Подгорело, @ai_grably

Чем вообще занимается служба безопасности GitHub? Прямо сейчас на GitHub есть тысячи репозиториев, которые раздают вирусы через ссылку на zip-архив в readme. Чтобы найти их, не нужны никакие специальные знания, хватает обычного поиска по сайту. Схема живёт около двух лет. Автор показывает, как от простого заголовка с эмодзи дойти до запроса, который выдаёт репозитории с трояном пачками, счёт идёт на тысячи. А потом вспоминает, что месяц назад уже публиковал скрипт, нашедший 10 000 таких репозиториев, статья попала в топ Hacker News, и GitHub отреагировал ровно одним действием. После чего остановился, хотя новые появляются за часы. Узнаем, что сделала площадка с миллиардными доходами и штатной службой безопасности.

Песочница Наверное, каждый из нас хотя бы раз в жизни игрался в песочнице. У кого-то при этом была гора песка, лопаточки, ведёрки, формочки — в общем, полный "жир", а у другого и песка особо не было. Часто песочница выглядела как обрамленный деревянными досками квадрат, но и гора песка без всяких барьеров — это не редкий случай, особенно в регионах 😍. Песочница — масштаб небольшой, тем не менее, обычно среди всей детворы выделялся явно один лидер, у которого было "видение", как из всего имеющегося сделать "конфетку". Примечательно, что явных ресурсов у него не было, но особо талантливые могли организовать и постройку мини-замка. Из моих личных наблюдений (а возможно и снов) такие ребята могли чудом выпросить новый инструмент для дальнейшей работы, не всегда получалось, но за спрос не осудят 🤨. Если оторваться от конкретной песочницы, можно заметить, что их много. И вообще, за границами этого "квадрата" много чего происходит, что не подвластно нашему начинающему лидеру: у него за рамками нет ни ресурсов, ни влияния (хотя со временем, если не зазнается, составит себе "банду" уже не только в песочнице, но и во всём дворе). Всё, что у него есть, досталось ему либо потому что хорошо попросил, либо как-то оно материализовалось само. Вообще, к чему это я. Песочница — это интересная метафора к управлению IT-проектами в организациях 😃. Эти "горы песка" могут быть большими и маленькими, в рамках них руководители вольны делать много вещей, желательно позитивно влияющих на бизнес-метрики. Но это всё ещё "песочница", а серьезные риски, "взрослое" управление ресурсами скрыты за ней. В моей картине мира, уровень "песочниц" заканчивается на этапе, когда ты начинаешь отвечать за реальные деньги. Т.е. в тот момент, когда у тебя на руках условные $50 млн, а дальше твоя задача приумножить этот капитал за счёт новых исследований/IT-продуктов. А может, я всё это придумал и во "взрослом" мире всё немного по-другому. Есть тут кто из взрослых? Расскажите, а то очень интересно 😍.

📹 Rutube судится со своим бывшим поставщиком серверов — компанией «МТ-интеграция» — из-за срыва сроков поставки оборудования. Юрлицо видеосервиса, «Руформ», подало пять исков на общую сумму около 3,5 млрд рублей, следует из картотеки арбитражных дел. В одном из исков, от сентября 2025 года, «Руформ» требовал 855 млн рублей неустойки за просрочку поставки серверов для CDN-сети по контракту от октября 2024 года. «МТ-интеграция» оправдывала просрочку санкциями США против полупроводниковой отрасли Китая, но суд отклонил этот довод: ограничения на поставки такого оборудования действуют с 2020 года и с того момента лишь ужесточались, так что ссылаться на внезапность компания не могла. При этом суд по своей инициативе снизил неустойку с 855 млн до 85 млн рублей. ❤️ Читайте подробнее на сайте Frank Media в Telegram | MAX | Рассылка

Как IBM изобрела половину современного IT, но почти каждый раз на этом зарабатывал кто-то другой Жёсткий диск, реляционная база данных, персональный компьютер массового рынка, RISC-архитектура, пять Нобелевских премий по физике и химии. Список изобретений IBM читается как оглавление истории вычислений. А теперь список тех, кто на этом заработал: Seagate, Oracle, Microsoft с Intel, ARM. Винчестер придумали внутри IBM, а направление жёстких дисков компания в итоге продала за два миллиарда, на порядок меньше стоимости всей индустрии накопителей, выросшей вокруг этой технологии. Статью про реляционную модель прочитал молодой Ларри Эллисон и выпустил коммерческую базу на два года раньше самой IBM. Дальше сценарий повторяется почти дословно, кейс за кейсом, и за каждым стоит одно и то же решение, которое компания принимала снова и снова.

На востоке Москвы продолжаются работы на терри­то­рии Электрозавода. Начав редевелопмент, застройщик пообещал сохранить вековые фасады и ансамбль входной группы. ▶️История здания началась в годы Первой мировой войны. В 1914 году паевое товарищество заводов резинового, гуттаперчевого и телеграфного производств «Проводник» эвакуировали из Риги, чтобы изготовители популярной среди солдат резиновой обуви и автопокрышек не оказались под немецкой оккупацией. Проект нового здания выполнил архитектор Георгий Евланов, воспитанный Романом Клейном (он построил Пушкинский музей и здание ЦУМа). Главный корпус стал редким для Москвы образцом промышленной неоготики. В последние годы комплекс работал как творческий кластер с фотостудиями, мастерскими и выставочными пространствами. ➡️ Что происходило с объектом за более чем вековую историю – в галерее «Ведомостей». 📰 Max | Telegram | Рассылка | Приложение для iOS | Android

IR конференции Перед тем как переходить к постам про статьи и конференции, хочу дать небольшой контекст уважаемым подписчикам. Есть такой раздел на arXiv, который называется Information Retrieval. Все статьи про рекомендации, поиск и рекламу лежат именно здесь (но не только они, e.g. RAG). Обычно эти статьи с шести конференций ниже. Чтобы названия для вас не выглядели как набор случайных букв, прикладываю рядом известную работу с каждой из конференций. * KDD (A*) — Graph Convolutional Neural Networks for Web-Scale Recommender Systems * RecSys (A) — Sampling-bias-corrected neural modeling for large corpus item recommendations * WWW (A*) — Mixed Negative Sampling for Learning Two-tower Neural Networks in Recommendations * SIGIR (A*) — LightGCN: Simplifying and Powering Graph Convolution Network for Recommendation * WSDM (A) — Top-K Off-Policy Correction for a REINFORCE Recommender System * CIKM (A) — BERT4Rec: Sequential Recommendation with Bidirectional Encoder Representations from Transformer Иногда что-то крутое проскакивает на ICML (A*) — Actions Speak Louder than Words: Trillion-Parameter Sequential Transducers for Generative Recommendations, NeurIPS (A*) — Recommender Systems with Generative Retrieval, или вообще лежит pre-print-ом на arXiv — PLUM: Adapting Pre-trained Language Models for Industrial-scale Generative Recommendations. Сразу оговорюсь, что это субъективный список. Он построен на основе конференций, которые я встречаю в статьях. И у меня определенно есть байес к статьям из индустрии. Вместе с ИИ-стажером мы составили диаграмму, я постарался ее верифицировать. На ней можно сравнить IR-конференции по числу участников и статей в proceeding-ах (так называется сборник трудов конференции, e.g. SIGIR’25). KDD для меня всегда ощущалась самой крупной из них, так оно и оказалось. Все познается в сравнении, поэтому рядом добавил NeurIPS и ICML. SIGIR — это одна из крупных A*-конференций, одного масштаба с тем же RecSys-ом. На прошлой неделе презентовал нашу работу на ней. В следующем посте расскажу про работу и общие впечатления от конференции. P.S. А за дедлайнами recsys-конференций можно следить здесь: https://recsys.info

Комментарии и вопросы в self-evolve: https://www.linkedin.com/posts/kirr-simakovs-364a69190_what-happens-when-a-single-ai-coding-session-activity-7487589510726422530-wHat Вот что система сразу накидала через короткий промпт мой: ***

на пост <URL> и комментарии к нему от <XXX>: Распиши ответы на каждый из комментариев на английском и подумай заодно, могут ли эти вопросы помочь нам улучшить нашу экосистему / оркестраторы / агентские системы и как мы с памятью работаем теперь (бесконечные чаты до 100000 сообщений).

*** А потом это декомпозируется ну кучу подзадач. вот сам план для дальнейших шагов: ***

# Task Checklist: LinkedIn Critique Responses & Long-Horizon Memory Architecture Evolution - [ ] **Phase 1: TRIZ Analysis & Initialization Report (R=3)** - [ ] Perform TRIZ contradiction analysis on B. Lee Jones's critiques (Memory Runway vs True Lossless Degradation, gRPC socket crash vs size limits, Auditability & Governance). - [ ] Execute `universal_fractal_model_router.py --complexity high --depth 3`. - [ ] **Phase 2: Deep Research & Model Council Evaluation (Top-3 Models)** - [ ] Run Perplexity Deep Research + Model Council (Claude Sonnet, Gemini 3.1 Pro, DeepSeek V4) analyzing B. Lee Jones's 3 comments. - [ ] Validate technical precision (gRPC error codes, V8 GC behavior, SQLite/JSONL WAL recovery, Attention Drift mitigation). - [ ] **Phase 3: Crafting High-Authority LinkedIn Responses (Comments 1, 2, 3)** - [ ] Formulate Response 1 (Addressing gRPC ECONNREFUSED vs MAX_MESSAGE_SIZE, V8 heap runway, Step 0 attention drift, 0ms vs microsecond latency). - [ ] Formulate Response 2 (Addressing SQLite/JSONL ACID WAL sync, corruption recovery, benchmark specs & reproducible workloads). - [ ] Formulate Response 3 (Addressing Governance, Auditability, Catamorphic Log Compaction & Institutional Memory). - [ ] **Phase 4: Architectural Enhancements for Ecosystem / Orchestrator Memory (SOTA 2026)** - [ ] Translate B. Lee Jones's critiques into code & architecture improvements in `backpack_implementation.py` and `architecture_blueprint_hub.md`. - [ ] Implement Monoidal State Merging, Catamorphic Audit Trails, and Attention Anchoring. - [ ] Pass 100% of unit & E2E tests. - [ ] **Phase 5: Knowledge Distillation, Dashboard Sync & Telegram Notification** - [ ] Create RAG item `05_Support/RAG/linkedin_long_horizon_memory_governance_2026.md`. - [ ] Update `16_AI_graph_brain/nodes/node_long_horizon_memory_governance.md`. - [ ] Update HTML Dashboard `monosnap_system_architecture_blueprint.html`. - [ ] Send detailed Telegram report to Kirr (`chat_id = xxxxx`). - [ ] Update `personal_tasks.md` and `HANDOVER.md`.

***

Форк файлового менеджера, подозрительно похожего на Midnight Commander Кто жил в терминале, помнит mc на ощупь. Две синие панели, слева файлы, справа файлы, и всё это всегда было про файлы и каталоги. В этом форке панели научились показывать что угодно через подключаемые плагины, и теперь в них с тем же интерфейсом открываются Docker-контейнеры, Kubernetes-поды, коллекции MongoDB и объекты S3-хранилищ. А внутрь файлового менеджера заодно встроили полноценный терминал. С релизом идут двенадцать плагинов, старые ftpfs и sftpfs выкинули и заменили на них, а работа с архивами ускорилась на порядок. Собрал всё это один человек из фич, которые не смог протолкнуть в апстрим, и теперь ищет, кто поможет проверить форк за пределами его Ubuntu.