​​Book Review: Build a DeepSeek Model (From Scratch) Мне прислали на ревью очередную книжку, на этот раз от Manning. Идея простая: взять ключевые находки DeepSeek и собрать каждую из них с нуля в уменьшенном виде, так чтобы всё запускалось на ноутбуке. Порядок такой: KV-кэш и его memory cost (плюс MQA и GQA как стандартные ответы), потом Multi-Head Latent Attention с decoupled RoPE и DeepSeek-MoE, потом multi-token prediction, FP8 и DualPipe, и в конце GRPO и дистилляция. Книга не для новичков: предполагается, что трансформеры вы уже понимаете. Авторы обычно демонстрируют подходы по шагам. Например, вот так демонстрируется RoPE: сначала добавляют целые числа (ломают эмбеддинги большими значениями), потом бинарные векторы (чинят магнитуду, но дают разрывы), потом синусоиды. И заодно показывают, что бинарное кодирование — это мультичастотный сигнал (младшие биты осциллируют быстро, старшие медленно), а синусоиды просто его непрерывная версия. Из минусов: эксперименты идут на TinyStories и на маленьком масштабе, так что разница в метриках маленькая. И архитектурная часть заканчивается на V3 и R1, а attention с тех пор ушёл в сторону sparse-стеков. Amazon Manning Code Мои обзоры: Personal blog Medium #bookreview

Китайская индустрия роботов превратилась в гигантское казино Аналитики полагают, что это самый дорогой в истории сеанс технологического гипноза инвесторов В марте в посте «Не дайте себя обмануть китайским роботам с гала-концерта Unitree Spring Festival» я писал о том, как китайская индустрия роботов превращается в грандиозную панаму. Теперь, с живописными фактами, о том же пишут аналитики авторитетного китайского делового технологического издания LatePost (晚点), специализирующегося на глубоких журналистских расследованиях, анализе рынков и эксклюзивных материалах в сфере ИИ и робототехники (профессиональный перевод Джефри Динга здесь). Далее о том, что мне больше всего понравилось в расследовании аналитиков LatePost.   Робот против рабочего: смерть здравого смысла На производственной линии BYD разворачивается технологическая комедия. Обычный рабочий берет подшипник с лотка и помещает его в стоящий рядом пластиковый контейнер за 2 сек. Антропоморфному роботу, «венцу творения», на ту же операцию требуется 70 сек. Его эффективность – жалкие 3% от человеческой. При цене в 200 000 юаней (40 месячных зарплат рабочего) этот «помощник» ломается через 10 дней интенсивной работы. Казалось бы, проект пора закрывать, но венчурные капиталисты выписывают чеки с еще большим энтузиазмом. Почему? Потому что в мире роботов («воплощенного ИИ», как это называют авторы статьи) реальная производительность – это последнее, что кого-то волнует.   Техасский холдем на 900 миллиардов Индустрия превратилась в гигантское казино. В первом полугодии 2026 года объем инвестиций в сектор превысил 900 млрд юаней, а 22 компании получили оценку выше 10 млрд. Это уже не инвестиции, а «Club Deal» – игра в покер, где Sequoia и Hillhouse садятся за один стол, чтобы просто не дать друг другу забрать банк. Абсурд достигает пика в оценке компании Unitree (宇树). Ее капитализация взлетела выше 400 млрд юаней. Для контекста: это больше, чем совокупная стоимость четырех столпов китайского автопрома – Li Auto, Nio, Xpeng и Leapmotor. Компании, продавшие 1,75 млн реальных машин, стоят дешевле стартапа, который отгрузил 5 тысяч медлительных прототипов.   Как поддерживается этот пузырь С помощью круговых схем и «фабрик данных», которые активно субсидируют местные власти, обожающие «экологичные» проекты. Схема проста: компании продают роботов подставным фирмам или партнерам, чтобы имитировать спрос и собирать данные. - Дутая выручка. Из 1,699 млрд юаней выручки Unitree на реальное производство (логистику и заводы) пришлось лишь 15,7 млн юаней – это меньше 1%. - Кулуарный маркетинг. Успех здесь куется не в лабораториях, а за столами KTV (караоке-клуб – популярный в Китае формат заведений для отдыха и неформального делового общения), куда поставщики водят инженеров Tesla Optimus, чтобы выведать секреты и создать видимость «причастности к будущему».   15 минут и 4 стадии позора Авторы статьи LatePost пишут: «Инвестиционный банкир, участвовавший в роуд-шоу для трех робототехнических компаний, вспоминает визит в мае в компанию, занимающуюся разработкой искусственного интеллекта, стоимость которой превышает 20 миллиардов юаней. Инженеры попросили робота продемонстрировать складывание полотенца; процесс занял 15 минут, но задача так и не была выполнена.» А в заключение статьи приводятся слова одного из инвесторов в китайскую индустрию роботов, описывающую эволюцию взглядов инвесторов за последние несколько лет весьма хлесткой формулой (видимо, это отсылка к пяти стадиям принятия неизбежного по модели Кюблер-Росс): сомнение – не пузырь ли это; понимание – да, это пузырь; принятие этого факта и, наконец, вкушание его плодов. Вот только о том, какой будет пятая стадия, тот инвестор предпочел умолчать.   #Роботы #Китай

Изучение странных кварков указывает на возможность существования новых частиц Несмотря на все усилия ученых по классификации огромного множества субатомных частиц, открытых за последние десятилетия, природа некоторых экзотических разновидностей до сих пор не поддается объяснению. Физики-ядерщики из США обнаружили свидетельства существования двух неожиданных структур, помогают упорядочить этот «зоопарк» экзотических частиц. Возможно, они дадут новое представление о загадочном семействе объектов, известных как XYZ-состояния. https://hightech.plus/2026/08/24/izuchenie-strannih-kvarkov-ukazivaet-na-vozmozhnost-sushestvovaniya-novih-chastic

#Нейропрожарка Баба Яга. Доставка, сахар и ПВО Автор: Алексей Лотков / @aleksejlotkov (Insta/Tg) Описание: Короткий абсурдный фолк-мокьюментари про Бабу Ягу в современном российском быту: она летает в ступе, покупает сахар по акции в «Пятерочке», заказывает доставку в избушку на курьих ножках, сталкивается с курьерами, говорящим котом, Лешим-алкашом и ПВО, которое принимает ее за дрон. Главная идея была сделать не сказку и не фэнтези, а максимально приземленный документальный реализм: handheld-камера, бытовой свет, неловкие паузы, мокрый лес, старые интерьеры, реальные магазины и абсурд, сыгранный абсолютно серьезно. Производство: Сначала была собрана раскадровка и история, разбитая на отдельные сцены. Для каждого шота делались ключевые кадры и отдельные ассеты с промптами с точным действием, камерой, таймингом и стилем. Основной пайплайн: генерация ассетов по отдельности → анимация в Seedance 2.0/2.5 В работе использовались Flux 2 Max/Reve/Seedream 5 и др. Для анимации - клинг 3 и сидэнс 2.0/2.5. Голоса склонированы и синтезированы в elevenlabs, липсинк был сделан в synclabs lipsync v3. Больше всего времени ушло на удержание единого тона: модели постоянно тянули всё в фэнтези, хоррор или глянец, а задача была оставить ощущение реального документального видео. Очень много времени ушло на перебирание и создание концептов на персонажей и локацию. Время / бюджет: Время: 2 месяца по 1-2 часа в день Бюджет: 250-300 долларов — в основном генерации, подписки / кредиты @cgevent

CLI → SDK Выше я писал про то, почему с MCP переходят на CLI (кроме некоторых ситуаций). Сегодня – про еще один переход, которы у меня случился пару недель назад Рассмотрим на примере коннектора к тг У меня самописный CLI тул, куда я понемногу добавляю разные функции. Сначала я его использовал просто для того, чтобы агент отправлял текстовые нотификашки ботиком в чат. Потом добавил туда поддержку медиа. Потом отправку в другие чаты. Потом – чтение предыдущих сообщений в любом чате и парсинг каналов (тут понадобилось перенести с урезанного Bot API на полноценный телеграмный MTProto) И каждый раз когда я прошу сделать что-то, чего в моем CLI нет – агент идет его переписывать. Как результат – я по сути воссоздаю весь интерфейс библиотеки mtcute, но в виде CLI команды. Что уже как бы попахивает лишним слоем Так еще и интерфейс текстовой команды сильно беднее чем интерфейс SDK – нет честной типизации, объектов и т.д. Если я хочу сделать какое-то действие в цикле, или хитро обработать вывод, то агент все равно пишет bash-скрипт поверх CLI Так что пару недель назад, я полностью выпиливаю CLI и просто прописываю агенту, как ему использовать SDK напрямую. То есть он пишет код под задачу и сразу его запускает. А если у меня есть какие-то повторяющиеся задачи – я оставляю их в виде импортируемых TS модулей. Теперь агент может делать что угодно, что можно делать ботом в тг. Мне не нужно заранее продумывать сценарии и постоянно обновлять код. Он сам соберет его точно под задачу из исходных модулей библиотеки, либо моих скриптов. Тут правда я натыкаюсь на пару проблем. Основная – это то, что агент постоянно пишет временные скрипты, что убивает всю легкость, которая была у запуска CLI команды раньше. Да, он может писать код inline прям в команде, но внешние библиотеки так не установятся Решается это достаточно просто – нужен раннер с поддержкой autoinstall

Для TS – это bun/deno, а для python – uv

Тогда команда агента выглядит примерно так:

bun --install=force run - <<'TS'
import { Api } from 'grammy'
// используем Bot API либу вместо MTProto для простоты

const { botToken } = await Bun.file(`${process.env.HOME}/.tg-agent-bot/config.json`).json()

const api = new Api(botToken)
console.log('sent:', (await api.sendMessage(373021550, 'Привет через grammY')).message_id)
TS

Проблема номер два – где хранить всякие полезные данные. Например, известные id-шники с описанием или helper-скрипты. Тут все по классике как с CLI – создаем ~/.tg-agent-bot и храним там config.json и папку со скриптами. Там же и токен бота (либо в keychain системы) Получается, из конфигурации skill+cli мы убираем cli и просто описываем все тонким скиллом. Агент сам пишет скрипт прям в момент вызова ——— Осторожно: нет смысла использовать эту штуку, когда у вас узкая задача. Ее имеет смысл завозить, если много кейсов использования и нужна гибкость. И особенно, если нужно как-то хитро обрабатывать вызовы, собирать из них цепочки и т.д. Тема экспериментальная, пользуюсь ей несколько недель, мб чего-то не замечаю – интересно, что думаете

☺️ СОКОТРИС: ЗАДАЧКА С ФЕСКОЙ ☺️ Что такое игра для разработчика? Это вдохновение! Это творчество! И если вы думаете, что сейчас будет циничное упоминание о необходимости игрой заработать денег — НЕТ! Я просто порой настолько погружаюсь в разработку, что ловлю ветер вдохновения и на всех парусах плыву по реке творчества 😎 Разработка игры вообще всегда становится задачкой со звёздочкой ⭐️ 🔘Как сделать интересно? 🔘Что добавить? 🔘Что убрать? 🔘Как подружить между собой механики и при этом придумать что-то, чего ещё не было? Именно такой задачкой стала наша с Женей попытка скрестить Сокобан и Тетрис ✨✨✨ Кто следит за чатом, тот помнит моё длиннющее описание механик. А теперь у нас есть первый прототип 🟢 Что тут происходит? Есть Соко — маленький робот-архивариус Вселенной, педантичный клерк в смешной красной феске. После катастрофы он восстанавливает повреждённые файлы миров 💊 Проблема в том, что сами миры «схлопнулись» из 3D в 2D. Поэтому Соко может двигаться только влево-вправо в текущей проекции. Поворачиваем ракурс — и бывшая глубина становится новой горизонталью 📊 Нужно, переключаясь между проекциями, дотолкать тетрис-фигуру до нужного места. Вроде Сокобан. Вроде Тетрис. Но в какой-то момент начинаешь думать уже не только «куда толкнуть?», а «с какой стороны на это вообще посмотреть?» И у нас получился первый прототип: 🖥 https://freeprogrammer.ru/games/socotris/ Чтобы было чуть понятнее: X — место, куда должна попасть фигура O — реальное положение героя S — его положение в текущей проекции F — рычаг, на котором можно повернуть фигуру Перемещаемся Соко влево-вправо в текущей проекции и пытаемся доставить фигуру куда нужно 🎁 Понятно, что сначала это выглядит как какая-то чёрная магия 👍 Но игра никуда не торопит. Можно покрутить ракурсы, потыкать, поломать голову — и, возможно, поймать тот самый момент, когда механика внезапно начинает складываться в голове ➕ И вот теперь мне очень интересно ваше мнение: В это можно играть? Понятно ли, что вообще нужно делать? Возникает ли желание разобраться? Дальше у нас два пути: 🔘Сделать более привычный Сокобан с тетрис-фигурами и препятствиями 🔘Оставить эту странную механику и развивать именно её, улучшая UI и подачу Я пока остановился на втором 🤩 Нишево? Да. Но, может быть, кому-то именно такого странного Сокобана и не хватало 🐢

Что делать, если все заинтересованные стороны по-своему правы Одна из сложных ситуаций в работе менеджера продуктов: когда в обсуждении вариантов решения каждый стейкхолдер приводит свои веские аргументы, конфликтующие друг с другом, — но нужно договориться. ➡️ Отдел продаж хочет добавить интеграцию с конкретной системой, потому что без нее крупный клиент не подпишет контракт. ➡️ Команда разработки говорит, что интеграция потребует серьезных изменений в архитектуре и создаст новую статью расходов на поддержку. ➡️ Менеджер продукта уже провел исследование среди действующих клиентов и считает, что ресурсы стоит вложить в другую проблему, которая касается большого сегмента пользователей. ➡️ CEO напоминает, что выход в сегмент, из которого пришел крупный заказчик, — одна из стратегических целей года. Решение предстоит принять, учитывая все аргументы, интересы и последствия. Что особенно важно при этом не упустить — рассмотрим ниже на примере. 1️⃣ Сначала разберитесь, что именно стоит за позицией участника Допустим, менеджер по продажам хочет закрыть сделку, чтобы выполнить KPI и закрыть свои личные финансовые нужды. В разработке треть команды уходит в отпуск, и ресурсов на быстрый запуск интеграции просто нет. Команда продукта уже прошла часть пути для повышения LTV действующих клиентов и не хочет бросать, пока есть возможность вовремя добавить востребованную функцию. А CEO делает на новый сегмент большую ставку из-за его платежеспособности — и надеется за счет этого вывести компанию на самоокупаемость, потому что привлекать инвестиции стало сложнее. 2️⃣ Сведите аргументы к общим критериям Когда каждая сторона защищает свою ценность, нужно привести аргументы к одному знаменателю — стоимости: 🔵 Каковы минимальные требования конкретного клиента и сколько ресурсов потребуется на разработку? 🔵 Какие технические последствия и статьи расходов создаст? 🔵 Какой коммерческий эффект ожидаем? 🔵 Можно ли использовать решение для других клиентов и какой объем рынка им можно охватить?  Тогда становится понятно, между какими величинами стоит выбор. 3️⃣ Проверьте цену отказа от каждого варианта Если не делаем интеграцию, то: 🟦 сохраняем архитектуру; 🟦 экономим ресурс и можем завершить разработку функции для действующих пользователей, от которой ожидаем прироста LTV на 2%; 🟦 рискуем потерять крупного клиента; 🟦 откладываем выход в новый сегмент на 3–4 месяца и теряем возможность получить критически важные Х миллионов, а это означает необходимость срочно искать инвесторов или сокращать издержки. Так становятся ясны возможные последствия не только активных действий, но и бездействия. 4️⃣ Распишите все возможные варианты и последствия Чтобы понять, какой вариант решения действительно будет оптимальным, полезно создать канву для дальнейшего обсуждения:  🔵 исходный контекст и данные; 🔵 варианты решения и их стоимость; 🔵 возможные последствия и риски по каждому варианту, в том числе в денежном выражении; 🔵 необходимые для проверки вопросы.  Это позволяет сделать логику выбора ясной для всех участников. 5️⃣ Найдите способ проверить самое дорогое неизвестное Недостаток каких данных может привести к самой дорогой ошибке в выборе решения? В нашем случае это может быть вопрос о клиенте: действительно ли для заключения сделки нужна полноценная интеграция или основную потребность можно закрыть минимальной версией или даже ручной обработкой данных?  Может быть вопрос о рынке: нужна ли интеграция с этим сервисом еще кому-то из стратегически важного сегмента?  Или технический вопрос: сколько реально будет стоить решение и можно ли сделать его проще и дешевле? На этом этапе важно понять, какой сценарий может сделать решение ошибочным, и найти самый дешевый способ это проверить. 6️⃣ Зафиксируйте, какой вариант выбрали и чем будете жертвовать, если компромисс невозможен Предположим, вы выбрали делать частичную интеграцию для одного клиента с ручными процессами на начальном этапе. Потому что стратегическая ценность клиента очевидна, но другим представителям целевого сегмента интеграция с конкретным сервисом может не понадобиться.  Если стоимость такой разработки все равно высока, нужно понять, с какой инициативы будет переброшен ресурс, который пойдет на интеграцию. А также зафиксировать, в каком случае возможен пересмотр решения. Проделав все шаги, вы получите не только матрицу оценки вариантов и рисков, но и план принятия решений для дальнейших инициатив. Если через месяц отдел продаж снова предложит сделать полноценную интеграцию, не придется заново все обсуждать: понятно, какое решение приняли, на каких основаниях и что должно измениться, чтобы его пересмотреть. @productsense

Кстати помните пост что Codex доводит задачу до конца даже если кончился лимит? Фичу убрали... 🥰 Из-за того что в твиттере одна девушка выложила харнесс чтобы абузить лимиты, превращая последний ответ в бесконечную сессию. Через такой механизм: 1/ Codex как обычно начинает выполнять задачу 2/ Получает инструмент wait_for_user_input 3/ Когда задача готова, не заканчивает вывод, а вызывает этот тул и ждет 4/ Юзер отправляет новое сообщение 5/ Codex ловит его как результат тула, не прерывая свою работу То есть, не смотря на лимит юзер кое как всё равно мог ставить новые задачи и получать ответы агента Я даже сам успел потестить, но выкладывать это не решился Забавно что после того как пост стрельнул, она удалила все твиты и свой репо, еще и написала:

надеюсь команда Codex сможет это проверить и забанить эти аккаунты, тогда мы все в безопасности 😔

Не кусай руку которая тебя кормит.. @tips_ai

Хакнула запись к врачу. В Португалии, как и во многих странах Европы, очень трудно попасть к врачу, особенно, узкопрофильному. На прошлой неделе мне понадобилось попасть на УЗИ. У меня платная страховка. Во всех крупнейших сетях частных клиник предложили запись на ноябрь- декабрь 😏 и то, сначала надо попасть к гинекологу и взять у него направление. И только потом ловить окошки на УЗИ. Меня, конечно, такой расклад не устроил. Ну как это - ждать УЗИ полгода? После безуспешных попыток назначить себе что-то через обзвон клиник, я вспомнила, что я, вообще-то, вайбкодер😎 И тем же вечером построила агента, который с моих аккаунтов автоматом ловил слоты в двух крупнейших сетях клиник к англоязычным врачам. Открытой записи к ним не было на полгода вперед, но если внезапно кто-то отменялся - мой агент тут как тут меня записывал. К трем врачам из недоступных записал прям на следующий день. Я даже повыбирала лучшего по отзывам. Правда эту систему я хакнула лишь на половину - запись на УЗИ все равно через регистратуру. Но с направлением от врача это уже попроще и побыстрее. Почему в Европе это ТАК сложно?? До меня не доходит. Спрос бешенный, страховка платная, клиники частные - и не попасть… А в качестве видео вам сегодня кусочек Голландии. Поля, каналы, птички, коровки и очень аккуратные домики. Любовь на удаленке | Оля Сохнева #ии_наудаленке

«Как я случайно записала сотни тысяч телефонных звонков на военные базы» Технология ENUM связывала телефонные номера с адресами в сети, но так и не взлетела и сегодня, по сути, мертва. Исследовательница безопасности сканировала эту заброшенную систему и наткнулась на три зоны телефонных кодов, делегированные на сервер имён, домен которого давно протух. Она купила его за 5€ и получила контроль над DNS телефонной инфраструктуры трёх британских территорий. Теоретически это открывало возможность вклиниваться в чужие звонки посредником. Трафика поначалу не было вовсе, так что домены она просто оставила себе для экспериментов. А через полгода заглянула в логи и обнаружила там сотни тысяч запросов. Почти все они вели на военные базы, а адреса источников были в основном американскими: https://u.habr.com/6LzUD