Тем временем рекрутеры
> Дмитрий, добрый день!
> (...)
> Cергей, cкажите, пожалуйста, интересно ли вам обсудить данное предложение?
> Дмитрий, добрый день!
> (...)
> Cергей, cкажите, пожалуйста, интересно ли вам обсудить данное предложение?
Forwarded from Голландский Rust-ист
Продукт, который поможет не терять продуктивность
https://github.com/ovr/vibecoder-connector (поддержите лайками! ваша поддержка бесценна)
Проблема: разработчик запускает Claude Code, переключается на другую вкладку/телефон/кофе, и пропускает момент, когда агент закончил или ждёт ввод. Внимание фрагментировано. Контекст теряется. Продуктивность падает.
Существующие решения — звуковые уведомления — не работают в наушниках с ANC, в шумном офисе, или когда ты уже в пятом созвоне за день. А что если фидбэк будет тактильным? Не на экране, не в наушниках — а физически, через тело.
Я задался этим вопросом, и представляю vibecoder-connector — плагин, который подключается к любому Buttplug-совместимому устройству через Intiface Central и превращает события агента в haptic-паттерны.
Лёгкий тап = сессия началась. Мягкая волна = Claude ждёт ввод. Burst = таска готова. Ты чувствуешь процесс, не отвлекаясь от контекста.
Разработано совместно с исследователями ИИ в Somatic Computing Lab компании Vibetropic, подразделении VibeHoldings Inc.¹ (осн. 2026 — год, когда мы достигли AGI — вы и так это знаете).
Да, Buttplug. Нет, это не шутка — это открытый протокол для управления вибромоторами, 200+ устройств. Мы просто нашли ему продуктивное применение. Node.js, zero config, кастомные паттерны через JSON.
Подход основан на whitepaper «Somatic Feedback Loops in Human-Agent Collaboration» (Vibetropic Research, 2026), в котором показано, что тактильные сигналы сокращают время реакции разработчика на события агента на 42% по сравнению с визуальными уведомлениями и на 67% по сравнению со звуковыми в условиях когнитивной перегрузки.
Полный текст whitepaper пока на рецензии в Nature, но мы верим в open source, поэтому уже на GitHub.
https://github.com/ovr/vibecoder-connector (поддержите лайками! ваша поддержка бесценна)
Проблема: разработчик запускает Claude Code, переключается на другую вкладку/телефон/кофе, и пропускает момент, когда агент закончил или ждёт ввод. Внимание фрагментировано. Контекст теряется. Продуктивность падает.
Существующие решения — звуковые уведомления — не работают в наушниках с ANC, в шумном офисе, или когда ты уже в пятом созвоне за день. А что если фидбэк будет тактильным? Не на экране, не в наушниках — а физически, через тело.
Я задался этим вопросом, и представляю vibecoder-connector — плагин, который подключается к любому Buttplug-совместимому устройству через Intiface Central и превращает события агента в haptic-паттерны.
Лёгкий тап = сессия началась. Мягкая волна = Claude ждёт ввод. Burst = таска готова. Ты чувствуешь процесс, не отвлекаясь от контекста.
Разработано совместно с исследователями ИИ в Somatic Computing Lab компании Vibetropic, подразделении VibeHoldings Inc.¹ (осн. 2026 — год, когда мы достигли AGI — вы и так это знаете).
Да, Buttplug. Нет, это не шутка — это открытый протокол для управления вибромоторами, 200+ устройств. Мы просто нашли ему продуктивное применение. Node.js, zero config, кастомные паттерны через JSON.
Подход основан на whitepaper «Somatic Feedback Loops in Human-Agent Collaboration» (Vibetropic Research, 2026), в котором показано, что тактильные сигналы сокращают время реакции разработчика на события агента на 42% по сравнению с визуальными уведомлениями и на 67% по сравнению со звуковыми в условиях когнитивной перегрузки.
Полный текст whitepaper пока на рецензии в Nature, но мы верим в open source, поэтому уже на GitHub.
GitHub
GitHub - ovr/vibecoder-connector: Bridges the gap between your IDE and your body
Bridges the gap between your IDE and your body. Contribute to ovr/vibecoder-connector development by creating an account on GitHub.
Гораздо более интересный текст про ИИ-агенты, компилятор (JS -> WASM) и на этот раз формальную верификацию.
> "You are avoiding the hard cases. Stop. You have proved 40+ easy cases where closure conversion is identity. The ACTUAL verification is in the cases you keep marking as sorry: captured variable, function call, function definition. YOU MUST ATTEMPT THESE NOW. Not later. Not after 'one more easy case.' NOW."
https://www.basis.ai/blog/verified-compiler/
> "You are avoiding the hard cases. Stop. You have proved 40+ easy cases where closure conversion is identity. The ACTUAL verification is in the cases you keep marking as sorry: captured variable, function call, function definition. YOU MUST ATTEMPT THESE NOW. Not later. Not after 'one more easy case.' NOW."
https://www.basis.ai/blog/verified-compiler/
Basis
Building an Unverified Compiler with Agents
We tasked four agents to build a verified compiler. They produced a compiler, but failed to prove it correct.
Правда, 2025 год.
> Here’s what happens when you actually test state-of-the-art models on verification tasks:
RTL code generation: Claude 3.7 Sonnet gets 34% right. Not amazing, but workable.
Testbench stimulus generation: Drops to 25%. Okay, getting concerning.
Testbench checker generation: 6%. Yes, you read that right. Six percent.
Assertion generation: 19%. Better than checkers, still terrible.
> We finally have data. Instead of just complaining that “AI verification sucks” (which we all knew), we now have specific, quantified ways it sucks. The NVIDIA team identified exact failure patterns:
Timing violations
Coverage gaps
Assertion misplacement
Synchronization issues
This isn’t just academic hand-wraving—it’s a roadmap. We know what’s broken, which means we (or the AI companies) can actually fix it.
https://benharoosh.co.il/why-ai-struggles-with-hardware-testing/
> Here’s what happens when you actually test state-of-the-art models on verification tasks:
RTL code generation: Claude 3.7 Sonnet gets 34% right. Not amazing, but workable.
Testbench stimulus generation: Drops to 25%. Okay, getting concerning.
Testbench checker generation: 6%. Yes, you read that right. Six percent.
Assertion generation: 19%. Better than checkers, still terrible.
> We finally have data. Instead of just complaining that “AI verification sucks” (which we all knew), we now have specific, quantified ways it sucks. The NVIDIA team identified exact failure patterns:
Timing violations
Coverage gaps
Assertion misplacement
Synchronization issues
This isn’t just academic hand-wraving—it’s a roadmap. We know what’s broken, which means we (or the AI companies) can actually fix it.
https://benharoosh.co.il/why-ai-struggles-with-hardware-testing/
rust-coreutils в Ubuntu: blazingly fast, blazingly safe, 40+ CVEs
https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773
https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773
Ubuntu Community Hub
An update on rust-coreutils
This is a follow-up to Jon’s original post on Carefully (but purposefully) oxidising Ubuntu and Julian’s migration spec for 25.10. We promised transparency throughout this process, and this post is written in that spirit. What happened after the announcement…
> An autonomous research loop pointed at a SystemVerilog RV32IM CPU. Each round the agent proposes a microarchitectural hypothesis, implements it in an isolated git worktree, then runs it through riscv-formal + Verilator cosim + 3-seed FPGA place-and-route. Only hypotheses that beat the current champion on CoreMark/MHz get merged.
https://github.com/FeSens/auto-arch-tournament
https://github.com/FeSens/auto-arch-tournament/blob/main/docs/auto-arch-tournament-blog-post.md
+30% к CoreMark/MHz
Правда, исходный CoreMark/MHz - 2.226. То есть, исходная планка не то чтобы очень высокая, ядрышко такое себе. Но всё равно +30% - это довольно весомый результат. Улучшения, "победившие" в турнире - в основном во фронт-энде ядра.
P.S. кстати, сейчас кажется очевидным, почему так: ядро - простой in-order конвейер. Чтобы получить какие-то заметные плюшки от улучшений в бэкенде, надо менять не только ядро, но и модель ядра для компилятора.
https://github.com/FeSens/auto-arch-tournament
https://github.com/FeSens/auto-arch-tournament/blob/main/docs/auto-arch-tournament-blog-post.md
+30% к CoreMark/MHz
Правда, исходный CoreMark/MHz - 2.226. То есть, исходная планка не то чтобы очень высокая, ядрышко такое себе. Но всё равно +30% - это довольно весомый результат. Улучшения, "победившие" в турнире - в основном во фронт-энде ядра.
P.S. кстати, сейчас кажется очевидным, почему так: ядро - простой in-order конвейер. Чтобы получить какие-то заметные плюшки от улучшений в бэкенде, надо менять не только ядро, но и модель ядра для компилятора.
GitHub
GitHub - FeSens/auto-arch-tournament
Contribute to FeSens/auto-arch-tournament development by creating an account on GitHub.
https://nickkossolapov.github.io/fame-boy/building-a-game-boy-emulator-in-fsharp/
> There were more times where I moved to structs (which live on the stack) or went with other not-as-F#-friendly approaches. The PPU was the point where optimization became necessary, and I had to abandon idiomatic F# to an extent.
> I slowly improved performance by spending time regularly looking at the profiler, eventually getting it up to about 120 FPS. But then I found the biggest improvement in FPS. The fix? Turning off the debug build, taking the emulator to a lightning-fast 1000 FPS. It took me embarrassingly long to realise that debug mode is that much worse than release mode. I continued to regularly monitor performance and tweak things even up until the end.
> There were more times where I moved to structs (which live on the stack) or went with other not-as-F#-friendly approaches. The PPU was the point where optimization became necessary, and I had to abandon idiomatic F# to an extent.
> I slowly improved performance by spending time regularly looking at the profiler, eventually getting it up to about 120 FPS. But then I found the biggest improvement in FPS. The fix? Turning off the debug build, taking the emulator to a lightning-fast 1000 FPS. It took me embarrassingly long to realise that debug mode is that much worse than release mode. I continued to regularly monitor performance and tweak things even up until the end.
nickkossolapov.github.io
I built a Game Boy emulator in F#
Hundreds of hours, many late nights, and a working Game Boy emulator in F# with sound, running on desktop and web.
Forwarded from Ряды Фурье
Знаете, что будет, если нейробиологам дать процессор, чтобы они изучали его мышление?
В 2017 году попробовали и знатно облажались. Вот @pavgavr принёс работу.
Смысл в чём: если заморозить мозг, потом послойно его отсканировать и получить карту соединения всех нейронов, а потом запустить это в виртуальную среду и посмотреть, что оно делает — мы получим работающую копию, но всё ещё не будем понимать, КАК она работает. Первую бессмертную муху на этой планете мы так уже запустили, если что.
В 2017 году нейробиологи говорили, что мы нифига не понимаем, потому что данных слишком мало.
Пришли физики (вычислительные нейробиологи), поржали с этого и предложили попробовать на процессоре MOS 6502. Ну, чисто убедиться, что действительно всё поймём.
Он примерно как примитивный червяк — мозг маленький, смешной, хорошо изученный, на порядки проще мозга мушки. Процессор засветился в Apple I, паре стиральных машин, Commodore 64, Денди и Терминаторе (T-800 показывает его ассемблер), плюс на нём работает робот Бендер.
Всего 3510 транзисторов.
Транзисторы собираются в логические вентили, те — в сумматоры, а из них делаются регистры и арифметико-логическое устройство. В цикле считывает команду из памяти и выполняет. Это и есть понимание сути системы.
Приятно, что оригинальных чертежей 1975 года не сохранилось. Поэтому ещё в 2010 году взяли несколько 6502 и стали реверсить. Сварили в серной кислоте при 93 градусах. Полученный каркас сняли панорамой в 72 снимка (итого 342 мегапикселя склейки). Распознали всё OCR для плат, поправили руками ошибки, достроили спрятанные. Получился netlist.
Запустили симулятор этого процессора и заставили его проявлять поведение — играть в старые игры Donkey Kong, Space Invaders и Pitfall. За секунду симуляции писали 1,5 ГБ данных о напряжении на каждом контакте и состоянии каждого транзистора.
Потом стали применять нейробиологические подходы. Сначала — стандартный алгоритм поиска шаблонов показал, что в процессоре есть разные типы транзисторов. Ну, типа, тут вот зрительные транзисторы, а тут вот двигательные. На деле, конечно, все транзисторы в процессоре одинаковые. Примерно как в архитектуре нейросетей осьминога.
Дальше хирургия. Вырезаете кусок и смотрите, что отваливается. Поломка примерно каждого второго приводила к тому, что процессор умирал (не мог запустить игры). Но нашлись транзисторы, поломка которых ломала только Конга, но не Инвандеров. Так биологи открыли транзисторы Донки Конга!
Если вы выломаете деталь из телевизора и перестанет работать канал со спортом, это не значит, что эта деталь — модуль спорта. Метод не сильно помог понять логику работы чипа.
Нейробиологи часто вставляют электрод в один нейрон зрительной коры и показывают животному картинки, ища связь между вспышками света и активностью клетки. Ученые выбрали один транзистор и следили, как часто он выдает активность в зависимости от яркости пикселей на экране во время игры. Построили графики и нашли транзисторы, чья работа идеально совпадала с изменением яркости экрана. Точь-в-точь как реакция нейронов на свет! Но те транзисторы за экран вообще не отвечали, а просто работали синхронно с каким-то внутренним процессом игры.
Изучение одной детали в отрыве от системы дает красивую, но бессмысленную картинку.
Смоделировали ЭЭГ и МРТ — усреднили активность транзисторов по разным зонам чипа. И внезапно они увидели графики, поразительно похожие на волны живого мозга — с определенными ритмами и частотами. Применили алгоритм причинности Грэнджера, чтобы по этим волнам понять, какая зона чипа командует другой зоной. Часть прогнозов попала в инженерную схему, часть мимо.
Дальше взяли всё облако данных и сжали до главных сигналов. Метод выявил 6 главных состояний процессора. Одно из них идеально совпало с тактовым генератором, а другое — с режимом чтения/записи памяти. Но понимания логики в конце не возникло.
Инженеры продолжили ржать, мол, вот так же вы пытаетесь понять живые организмы.
--
Вступайте в ряды Фурье! | Самые полезные посты
Естественный отбор все ещё работает. Просто теперь он отбирает тех, кто читает инструкции.
В 2017 году попробовали и знатно облажались. Вот @pavgavr принёс работу.
Смысл в чём: если заморозить мозг, потом послойно его отсканировать и получить карту соединения всех нейронов, а потом запустить это в виртуальную среду и посмотреть, что оно делает — мы получим работающую копию, но всё ещё не будем понимать, КАК она работает. Первую бессмертную муху на этой планете мы так уже запустили, если что.
В 2017 году нейробиологи говорили, что мы нифига не понимаем, потому что данных слишком мало.
Пришли физики (вычислительные нейробиологи), поржали с этого и предложили попробовать на процессоре MOS 6502. Ну, чисто убедиться, что действительно всё поймём.
Он примерно как примитивный червяк — мозг маленький, смешной, хорошо изученный, на порядки проще мозга мушки. Процессор засветился в Apple I, паре стиральных машин, Commodore 64, Денди и Терминаторе (T-800 показывает его ассемблер), плюс на нём работает робот Бендер.
Всего 3510 транзисторов.
Транзисторы собираются в логические вентили, те — в сумматоры, а из них делаются регистры и арифметико-логическое устройство. В цикле считывает команду из памяти и выполняет. Это и есть понимание сути системы.
Приятно, что оригинальных чертежей 1975 года не сохранилось. Поэтому ещё в 2010 году взяли несколько 6502 и стали реверсить. Сварили в серной кислоте при 93 градусах. Полученный каркас сняли панорамой в 72 снимка (итого 342 мегапикселя склейки). Распознали всё OCR для плат, поправили руками ошибки, достроили спрятанные. Получился netlist.
Запустили симулятор этого процессора и заставили его проявлять поведение — играть в старые игры Donkey Kong, Space Invaders и Pitfall. За секунду симуляции писали 1,5 ГБ данных о напряжении на каждом контакте и состоянии каждого транзистора.
Потом стали применять нейробиологические подходы. Сначала — стандартный алгоритм поиска шаблонов показал, что в процессоре есть разные типы транзисторов. Ну, типа, тут вот зрительные транзисторы, а тут вот двигательные. На деле, конечно, все транзисторы в процессоре одинаковые. Примерно как в архитектуре нейросетей осьминога.
Дальше хирургия. Вырезаете кусок и смотрите, что отваливается. Поломка примерно каждого второго приводила к тому, что процессор умирал (не мог запустить игры). Но нашлись транзисторы, поломка которых ломала только Конга, но не Инвандеров. Так биологи открыли транзисторы Донки Конга!
Если вы выломаете деталь из телевизора и перестанет работать канал со спортом, это не значит, что эта деталь — модуль спорта. Метод не сильно помог понять логику работы чипа.
Нейробиологи часто вставляют электрод в один нейрон зрительной коры и показывают животному картинки, ища связь между вспышками света и активностью клетки. Ученые выбрали один транзистор и следили, как часто он выдает активность в зависимости от яркости пикселей на экране во время игры. Построили графики и нашли транзисторы, чья работа идеально совпадала с изменением яркости экрана. Точь-в-точь как реакция нейронов на свет! Но те транзисторы за экран вообще не отвечали, а просто работали синхронно с каким-то внутренним процессом игры.
Изучение одной детали в отрыве от системы дает красивую, но бессмысленную картинку.
Смоделировали ЭЭГ и МРТ — усреднили активность транзисторов по разным зонам чипа. И внезапно они увидели графики, поразительно похожие на волны живого мозга — с определенными ритмами и частотами. Применили алгоритм причинности Грэнджера, чтобы по этим волнам понять, какая зона чипа командует другой зоной. Часть прогнозов попала в инженерную схему, часть мимо.
Дальше взяли всё облако данных и сжали до главных сигналов. Метод выявил 6 главных состояний процессора. Одно из них идеально совпало с тактовым генератором, а другое — с режимом чтения/записи памяти. Но понимания логики в конце не возникло.
Инженеры продолжили ржать, мол, вот так же вы пытаетесь понять живые организмы.
--
Вступайте в ряды Фурье! | Самые полезные посты
В человеке всё должно быть прекрасно: и лицо, и душа, и мысли, и сакура на заднем плане
Сделал над собой усилие и переселился в касту архитекторов / менеджеров. Долго, конечно, я этому сопротивлялся, практически всю свою предыдущую профессиональную карьеру. В какой-то момент был тимлидом, но на самом деле скорее "играющим тренером". Всякие менеджерские работы давались мне с некоторым внутренним напряжением - ну как же, я трачу время, которое я мог бы пустить на то, чтобы нафигачить ещё что-нибудь полезное.
Но в итоге всё-таки сдался и осознал себя как "больше не кодер". Сегодня "официально" объявил об этом команде. Король умер, да здравствует король.
Но в итоге всё-таки сдался и осознал себя как "больше не кодер". Сегодня "официально" объявил об этом команде. Король умер, да здравствует король.
Почему я перестал писать код? Тут важен "исторический контекст". Работаешь ты такой свою работу, и в какой-то момент окончательно понимаешь: проблемы, которые тебе надо решить, чтобы прийти к успеху - не технические. Ты ищешь человека, который тебе поможет разобраться с организационными больками, и понимаешь: эти больки возникают из-за того, что такого человека просто нет. Ты становишься таким человеком и понимаешь: работы этой очень много (никто ведь до сих пор этим не занимался), и она плохо сочетается с глубоким погружением в технические задачи. Ты страдаешь, потому что не получается достигнуть результата сразу по двум веткам. Команда страдает, потому что всё ещё полагается на тебя как инженера, а у тебя календарь забит и код не поревьюить. Короче, попытка усидеть на двух стульях приводит к взаимному страданию. Проще и полезнее сосредоточиться на чем-то одном.
Рассказывал много раз своим падаванам о том, почему в проде не стоит писать на "академических" языках. Сам при этом решил, чтобы не терять тонус, поиграться с CHICKEN Scheme. Не, ну а что, я же шерстяной волчара.
Ну так вот, дефолтные пакеты под убунту развалены. Попытка установить какой-нибудь egg приводит к ошибкам компиляции где-нибудь в srfi-14. Всё как мы любим: поддержка экосистемы - это не интересно.
Ну так вот, дефолтные пакеты под убунту развалены. Попытка установить какой-нибудь egg приводит к ошибкам компиляции где-нибудь в srfi-14. Всё как мы любим: поддержка экосистемы - это не интересно.
Что-то типа итогов "спортивной карьеры":
- примерно пять команд
- один перерыв примерно на шесть лет
- одно участие в конгрессе МАК
- в одном рукопожатии от (когда-то) основных одиозных персонажей питерской тусовки
- число Снятковского тоже 1
- одна перестрелка на чемпионате мира
- одна разборка с привлечением "комиссии по этике"
- одна медалька с чемпионата России
- два "лучших тура" БалтБерега
- примерно пять команд
- один перерыв примерно на шесть лет
- одно участие в конгрессе МАК
- в одном рукопожатии от (когда-то) основных одиозных персонажей питерской тусовки
- число Снятковского тоже 1
- одна перестрелка на чемпионате мира
- одна разборка с привлечением "комиссии по этике"
- одна медалька с чемпионата России
- два "лучших тура" БалтБерега
Послушал тут подкаст бывших коллег, в котором речь шла про O'Caml. Как один из "архитекторов" К2 (в JB не было такой формальной роли, но де факто это было так), должен сказать следующее: К2 в существенной степени "вдохновлён" тем, как устроен O'Caml. Это совсем не удивительно - примерно все языки, так или иначе выросшие из Caml (а Котлин - это такой язык) сталкиваются с похожими задачами, да и методы декомпозиции этих задач в общем тоже хорошо изаестны. Так что как ни крути, а получается похоже. Но стесняться тут особо нечего, мы все стоим на плечах гигантов.
Наша история с "новым" компилятором для Котлина начиналась на самом деле даже не с мультиплатформенности (она выросла позже, потому что мы поняли, что можем еще и вот так). В "старом" компиляторе Котлина было несколько очагов проблем, связанных с его однопроходностью. В основном эти проблемы кучковались в окрестностях closure conversion (что происходит с локальными переменными, на которые ссылается локальный класс) и с дешугарингом операторов (который в Котлине был с первой попытки задизайнен очень так себе и не учитывал кучи всяких краевых случаев, которые было не так просто протащить через однопроходный бэкенд). На третьем месте в этом списке внутренний мем компилятора Котлина - функция intermediateValueForProperty, на которой идеевский анализ потока данных выдавал предупреждение "слишком сложно, анализировать не буду".
В общем, под луной не так уж много нового.
Наша история с "новым" компилятором для Котлина начиналась на самом деле даже не с мультиплатформенности (она выросла позже, потому что мы поняли, что можем еще и вот так). В "старом" компиляторе Котлина было несколько очагов проблем, связанных с его однопроходностью. В основном эти проблемы кучковались в окрестностях closure conversion (что происходит с локальными переменными, на которые ссылается локальный класс) и с дешугарингом операторов (который в Котлине был с первой попытки задизайнен очень так себе и не учитывал кучи всяких краевых случаев, которые было не так просто протащить через однопроходный бэкенд). На третьем месте в этом списке внутренний мем компилятора Котлина - функция intermediateValueForProperty, на которой идеевский анализ потока данных выдавал предупреждение "слишком сложно, анализировать не буду".
В общем, под луной не так уж много нового.
Трудные времена рождают сильных людей
Сильные люди придумывают мощные костыли
Мощные костыли рождают простые времена
Простые времена рождают слабых людей
Слабые люди не могут справиться с мощными костылями
Сильные люди придумывают мощные костыли
Мощные костыли рождают простые времена
Простые времена рождают слабых людей
Слабые люди не могут справиться с мощными костылями
😁1
Каждый раз, когда кто-либо использует llvm-mca для чего-то кроме тестов на SchedModel, дьявол убивает котёнка.
Пожалейте котят!
Пожалейте котят!