Джун на фронте | IT Dev Log

🌳 Каждый Ethernet-коммутатор в мире до сих пор использует алгоритм, который Рада Перлман придумала в 1985 году. Её разработка — Spanning Tree Protocol (STP) — решила одну из самых опасных проблем сетей: петли. Если соединить коммутаторы в несколько путей, пакеты могут начать бесконечно ходить по кругу, создавая шторм и ломая всю сеть. Перлман придумала способ превратить любую сложную топологию в дерево без циклов: «Сначала выбирается корень. Затем каждый узел оставляет самый дешёвый путь к нему. Остальные связи блокируются». Но самое необычное — её научная статья 1985 года начиналась не с обычной аннотации, а со стихотворения. «I think that I shall never see a graph more lovely than a tree…» Это был не просто красивый текст. Стих буквально описывал работу алгоритма: выбор корневого узла, поиск кратчайших путей и построение бесциклового дерева. Рада Перлман позже получила прозвище «мать интернета» за вклад в сетевые технологии. Иногда самые важные алгоритмы в истории начинаются не с формул, а со стихов.

На неделе возникла мысль в обсуждении о внедрении ИИ в организациях, что есть мощный ограничивающий социальный фактор - это ответственность. Ответственность в смысле blame или первый русский вопрос "кто виноват". Если ты задачу поручил ване и он ее запорол, то виноват ваня. Там есть некоторое пространство для маневра, но в целом так. Если ты запустил задачу через ИИ и что-то пошло не так, то виноват ... ты сам. Сейчас-то еще можно отползти что ИИ плохой и сырой, но когда все дозреет - такие отмазки уже не пройдут. Поэтому это против интересов руководителей начиная от среднего звена, чтобы команду разогнали, а поставили сплошь ИИ. Такая интересная комбинация действующих сил - руководитель заинтересован заменить на ИИ всех (экономический фактор), КРОМЕ ближайшего к себе круга (социальный фактор). Потому что важная роль ближайшего круга - это быть виноватыми, если что пойдет не так. Это понятно для ситуаций, где отвечаешь перед дядей, а не перед собой - у предпринимателя такого ограничения не будет. Я как-то с интересом узнал, что есть ниша зиц-CTO в стартапах - их задача просто оказаться виноватым перед инвестором, если проект не пошел. Фаундер и идея хорошие, а CTO и воплощение плохое. Пока только не могу вычислить, какую картину должны будут выплотить эти действующие силы.

О локальном инференсе LLM Регулярно встречаю блогпосты и призывы инференсить LLM на локальном железе. Но это всегда имеет ограничения. Одни предлагают квантизировать модели в 1b, другие хитро стримить, третьи советуют брать модели поменьне. Но квантизация…

О локальном инференсе LLM Регулярно встречаю блогпосты и призывы инференсить LLM на локальном железе. Но это всегда имеет ограничения. Одни предлагают квантизировать модели в 1b, другие хитро стримить, третьи советуют брать модели поменьне. Но квантизация заметно ухудшает качество. Мелкие модели тоже похуже А "хитрый стриминг"... Вот увидел я пост на медиуме: "Unbelievable! Run Kimi K3–2.8 Trillion Parameters — on a Single 4GB GPU". Думаю - не верю. Открываю... "This is not fast. Roughly five minutes per token." - не юзабельно #llm #ai

Рабочий дневник: День 464 Как я микрофронты собираю 🔥 Вот и случился у меня Enterprise. Это когда скоуп технологий настолько большой, что они особо не нужны соло билдеру. Ну вот зачем микрофронт тудушке? Разве что встроить её рядом с трекером калорий или…

Помогает ли claude.md файл? Интересный рисерч. Взяли три реальных Python-репозитория с хорошими AGENTS.md – pdm, firebase-admin-python и opshin. Из смерженных PR сделали 17 задач: описание PR = промпт агенту, тесты из этого же PR = скрытая проверка. Агент тестов не видит. Дальше три режима подачи контекста: – none – файл вообще убран из воркспейса – always_on – весь AGENTS.md вставляется в системный промпт каждый ход – selective – вместо файла лежит вики по темам, агент читает нужное сам Прогнали на Claude Code (Sonnet 4.6) и Codex CLI (GPT-5.5), по 3 повтора. Всего 288 засчитанных прогонов. Результат - все тлен. Claude: 53,3% / 55,6% / 55,6%. Codex: 58,8% / 56,9% / 52,9%. В пределах шума. Автор вручную разобрал «почти прошедшие» падения – те, где до зачёта не хватило пары тестов. И там ни одного случая, где агенту не хватило знания о репозитории. Не хватало интеллекта и инженерии, и такое AGENTS.md не лечит. Отдельно проверял улучшение правил, чтобы падения починить. Не получилось. А вот что реально сработало: у репозитория opshin в AGENTS.md есть строчка: полный прогон тестов занимает больше 20 минут. Без контекста Claude вслепую гонял весь сьют 3,67 раза за прогон. С always_on – 2,44. С selective – 1,67. Время выполнения упало с 2689 до ~2030 секунд, примерно на четверть. Корректность при этом не сдвинулась ни на пункт. То есть контекст-файл работает как операционная инструкция, а не как учебник. «Не запускай полный сьют, он медленный», «сборка вот этой командой», «линтер такой» – экономит время и деньги. А вот всякие там "ты синьор разработчик", "мы придерживаемся чистой архитектуры и SOLID" – не делает ничего измеримого. До этого были две работы с противоположными выводами – одна на Codex-агентах нашла пользу у файла, другая на Claude-агентах не нашла. Оказалось, сложность задач у агентов не совпадает: примерно у 40% задач агенты по-разному упираются в потолок. Задача, на которой можно было бы увидеть эффект у одного агента, у другого либо решается всегда, либо не решается никогда. Короче, писать AGENTS.md стоит, но как список правил, не как описание проекта. Команды, тайминги, грабли, что не трогать. Всё, что агент может вывести из кода сам, туда класть бессмысленно: он и выведет. А качество реализации вытягивается не файлом, а декомпозицией задачи и примерами. https://arxiv.org/abs/2607.27250

Cursor провели замер, сколько стоило бы в API ценах команде из агентов собрать с нуля SQLite на Rust на основе 835-страничного мануала Стоимость прогона, который прошёл бы 100% тестов варьируется в зависимости от модели в 15х раз Самое дорогое: всё на Fable…

Cursor провели замер, сколько стоило бы в API ценах команде из агентов собрать с нуля SQLite на Rust на основе 835-страничного мануала Стоимость прогона, который прошёл бы 100% тестов варьируется в зависимости от модели в 15х раз Самое дорогое: всё на Fable 5 (и планирование и имплементация) Самое дешевое: планирование на Opus 4.8, исполнение на Composer 2.5 Из интересного, делать всё одной и той же моделью односительно дёшево на Grok 4.5 https://cursor.com/blog/agent-swarm-model-economics

Рак виджетов в терминальной стадии

Новый Дипсик это анонс не хуже Кими или Фейбла, если понимать куда смотреть. Это модель уровня GLM-5.2 / Opus 4.8 / GPT-5.5, то есть лучшее что было доступно в мире на апрель 2026 года, но по цене в $0.28 за миллион токенов, то есть примерно в 100 раз дешевле.…

Новый Дипсик это анонс не хуже Кими или Фейбла, если понимать куда смотреть. Это модель уровня GLM-5.2 / Opus 4.8 / GPT-5.5, то есть лучшее что было доступно в мире на апрель 2026 года, но по цене в $0.28 за миллион токенов, то есть примерно в 100 раз дешевле. Прошло 3 месяца, а те продукты и процессы которые требовали сота модельки стали в 100 раз доступнее и дешевле. Тренд ни в падении цены, ни в росте спроса, ни в прогрессе сота моделей не остановится.

Дизайнеры теперь отдают код Вместо макетов дизайнер всё чаще сдаёт в прод прототипы, собранные ИИ-агентами. Рынок ответил на спор «должен ли дизайнер кодить»: UX/UI-роли требуют разработки с ИИ и production-ready доставки. Для фронтендера это меняет интерфейс работы: вы получаете работающий, но не всегда чистый код, и придётся отстаивать ревью перед релизом. Самый цепкий момент для меня, пожалуй, цифры: спрос на UX/UI/Product Design растёт на 16% к 2034, а дизайнерские навыки обогнали кодинг и облака в ИИ-продуктах. Компании хотят перевод технической возможности в человечный интерфейс, поэтому договариваться об архитектуре придётся раньше. Как пишет автор статьи, сгенерированный функционал — это ещё не хороший функционал.

Все, с выходом 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

Спросил у DeepSeek Flash V4, что оно такое. Он себя за Claude 4 считает из 2025 🤗 На скрине CLI на Rust под названием dirge (Dynamic Intent Resolution Grounding Engine). Как подспорье для Opus 5 вполне ок, но китаец есть китаец. Зато дёшево :)

Спросил у DeepSeek Flash V4, что оно такое. Он себя за Claude 4 считает из 2025 🤗 На скрине CLI на Rust под названием dirge (Dynamic Intent Resolution Grounding Engine). Как подспорье для Opus 5 вполне ок, но китаец есть китаец. Зато дёшево :)

Наконец-то приличный ИИ-мультиплеер, то есть возможность совместно общаться с агентами, иметь общую историю. А заодно, замена слеку и гитхабу. Децентрализованная, киберпанковская, опенсорсная, на основе открытого протокола. И сделал, конечно, Джек Дорси, создатель твиттера. Называется Buzz, типа Вжжж, а агенты там — вроде как пчелки. Есть даже возможность делиться своим compute, то есть нейросети могут пользоваться вычислительными мощностями (и токенами!) всех согласных участников чата. И никаких центральных серверов, которые можно заблокировать и санкционировать. Прям глоток свежего воздуха. Developer preview скачивать тут, все исходники открыты на гитхабе. 🐝

Мы живём в проклятом мире, который сами себе и создали Общаюсь переодически с нанимающими менеджерами (речь тут про технарей в основном) и они уже тоже, как и HR'ы удивляются количеству похожих резюме. Говорят, что никакой уникальности, у всех одинаковый вылизанный формат, какой ужас! Вот вам 2 причины, по которым не надо их слушать: 1. Те, кто следит за айти рынком хотя-бы года с 20, помнят, как в те времена, HR'ы ругались, что кандидаты совсем не умеют составлять резюме. Напишут 3 скромные строчки и всё! Все как один топили за то, чтобы был единый и удобный формат, по которому легко будет понять, чем человек занимался на прошлой работе и какую пользу принёс. И вот, когда рынок заставил - теперь у всех этот самый единый формат. HR'ы довольны? Нет конечно, вы что! Никакой уникальности, глупые одинаковые резюме, а мне надо вот, чтоб с изюминкой! Кароче, противоречие самим себе очевидно. 2. Но про огромное количество резюме под копирку, говорят не только HR'ы, а ещё и технари, участвующие в найме. Объясняю, почему вам не стоит прислушиваться к их советам. Для начала нам надо понять, для чего мы делаем резюме? Ответьте себе на этот вопрос и продолжите читать пост. Те из вас, кто ответил что то в стиле "для того, чтобы описать свой опыт, компетенции, сильные стороны и карьерный трек" - поздравляю, вы ошиблись. На текущем рынке резюме, по своим задачам, намного ближе к рекламному баннеру или лендингу, чем к описанию того, какой вы классный специалист. Задача резюме - пробиться через десятки фильтров и попасть на глаза к нанимающему менеджеру. Помню даже тейк Егора Бугаенко о том, что можно даже иметь 2 резюме, одно - для прохождения фильтров, второе - для описания опыта. Те нанимающие менеджеры, которые жалуются на ворох одинаковых резюме, не понимают, что если это резюме они УВИДЕЛИ, то оно УЖЕ выполнило свою задачу. Так что они, видя лишь одну сторону рынка, ругают расчёску за то, что ей не очень удобно переворачивать котлеты на сковороде.

Как я platform-explorer.com редизайнил 👨‍💻 Вот уже 8 месяцев я коммичу в Open Source для dash.org. Не в основной блокчейн, где всем заведует Core Team (ещё их называют Dash Core Group, Inc. или DCG), а в Dash Platform Оно как L2: блокчейн поверх блокчейна на инфре mainnet. Тут повезло потыкать код не только десктопных кошельков на Electron и Rust с React Native, но и SDK, расширения, бэкенда, индексера, парсера, npm-пакетов и лендинга. 😎 Не так давно я начал отвечать за фронтенд обозревателя блоков для Dash Platform. Он первый такой в своём роде, что пздц как круто и ответственно. Если делать всё то же самое ещё лет пять, можно оттяпать большой кусок рынка в этой децентрализованной экосистеме. 🤓 Из последнего было интересно редизайнить главную страницу вместе с GPT. Первым делом захотел добавить реалтаймов. Побрейнштормив с тимтехлидом, решили показывать последние транзакции и блоки. Ниже идут эпохи и данные по ней. Это период в ~9.1 дня, за который начисляют вознаграждения владельцам мастернод. По каждой собираем data с блокчейна, на бэке считаем, агрегируем и отдаём на фронт. 🥄 Ну и шлифанули общей статистикой: рост пользователей на Platform (их называют identities), последние голоса за юзернеймы (этакий ENS), лучших валидаторов и сколько $DASH в ZK пуле. Как по мне, получилось НОРМ. На всё ушло 48 часов за месяц. Не без огрехов, конечно, но это первая итерация. Она как раз располагает к правкам и расширению. 📊 #статистика в IT 1706д | 5555ч