2025 год прошел для меня под знаком работы. В 2022 году я покинул зону комфорта, после чего всё начало быстро меняться и в ушедшем году достигло некой логической запятой. Я теперь "главный эксперт по разработке ПО", хотя предпочитаю называть себя "главным инженером". Я руковожу командой, хотя раньше всячески сопротивлялся переходу в менеджеры. Я уже два года занимаюсь технической областью, с которой в своих "прошлых жизнях" соприкасался очень мало.

Старшая дочка пошла в школу, но я этого почти не заметил, кроме разве что в преддверии 1 сентября. Младшая пошла в садик, и теперь папа по утрам лошадка.

Я продолжал играть в спортивное ЧГК. Хотя должен признать, что уже давно не воспринимаю это как соревнование с другими командами. После локдауна ЧГК для меня окончательно перешло в разряд "интеллектуального альпинизма" и соревнования против некоторой идеальной версии самого себя.

После очень долгого перерыва отводил живьём пару сессий. Эксперимент скорее удался. Хотя должен признать, что логистика игр живьём существенно уменьшает значимость этого хобби для меня.

Стал играть с коллегами в настолочки. Видимо, мне не хватает симулятора проектного менеджмента и хочется на некоторое время почувствовать, что твои решения быстро приносят результат.

В музыкальном плане открыл для себя НТМ, The Cambodian Space Project и Xiii Stoleti. Уже давно хочется больше простых радостей.

Я завёл "персональный канал", в который, возможно, что-то иногда буду писать или просто складывать тут какие-то заинтересовавшие меня артефакты.

Сегодня обнаружил на балконе синицу. Само по себе это было бы непримечательно, но все форточки были закрыты, и мы с женой отчетливо помним, что закрывали их 31 декабря. Видимо, птица залетела раньше и то ли проспала три дня, то ли заныкалась куда-то и в итоге выбралась на поиски еды.

Мой текущий "колхозный" метод чайной церемонии - две кружки и большое ситечко. Время заваривания определяю "на глазок", по наитию и на основе экспериментов над собой. Просто, без изысков, но меня устраивает.

Затестил гунфу. Вроде как работает, заварок можно сделать много. Но одна заварка - это где-то одна пиалка. Если считать итоговый объём напитка, выходит в пользу "колхозного" метода. Да и всяких телодвижений туда-сюда с гунфу из-за количества заварок на тот же объём получается больше.

Бывают, конечно, гунфу крупнее. Но чай я почти всегда пью один. Если очень потребуется, смогу организовать импровизированный чахай.

Так что пока я не выкупил глубокий смысл деления чайника на две колбы. Гунфу встаёт дома на полку для случаев, когда я захочу повыделываться или понаблюдать за раскрытием чайного листа.

Как же меня ЗА Е БА ЛО играть перестрелку

P.S. хорошо, что её в итоге не было

Я привык, что к технологиям предъявляют довольно серьёзные требования. Процессор? Должен грузить Linux, гонять SPECInt и не разваливаться от stress-ng. JVM? Должен запускать Eclipse, IDEA, ну и хотя бы Glassfish. Компилятор Си? Должен собирать ядро Linux и показывать хотя бы на самых базовых бенчмарках типа CoreMark результаты, не слишком далёкие от GCC. И так далее. Кроме шуток, это всё непросто (хотя и не сказать, чтобы слишком сложно). Это некоторый барьер, который необходимо преодолеть, чтобы с тобой разговаривали, как со взрослым.

В вопросах, связанных с ИИ, я наблюдаю, что в качестве такого критерия зрелости нередко принимается демонстрация того, что ИИ в принципе что-то может. Например, написать компилятор Си. Это, конечно, большой шаг по сравнению с “ИИ не смог”, и Claude CC - это большое достижение в мире ИИ. Но дальше начинается самое интересное.

Claude CC довольно неплохо справился с задачей “пройти gcc-torture” (99%). Но написать оптимизатор у роботов не получилось практически совсем. У белковых, конечно, это тоже не всегда выходит. Современный оптимизирующий компилятор С - это плод труда большого числа инженеров, каждый из которых занёс свой +0.1% на геомине. Но ИИ не оказался даже близко. Можно сказать, не явился на соревнования.

Какие из этого выводы? Никаких, ждём, когда роботы смогут что-то ещё.

>> Скормил твою реплику ChatGPT 5.4 extended thinking. Он согласен с тобой. Интересен полный ответ?

Да. Здесь различие очень существенное.

Есть, грубо говоря, два порога. Первый — порог ненулевой способности: система вообще может породить нечто, что компилирует C, проходит большую часть тестов и собирает крупный проект. Второй — инженерный порог: артефакт становится участником взрослого соревнования, где уже смотрят не на сам факт существования, а на полноту, устойчивость, предсказуемость и качество результата. В случае Claude’s C Compiler был уверенно преодолён первый порог: Anthropic пишет о сборке Linux 6.9 на x86/ARM/RISC-V, о почти 99% прохождении «most compiler test suites including the GCC torture test suite», о сборке QEMU, FFmpeg, SQLite, Postgres и Redis. Но сам же автор проекта отдельно фиксирует, что это capability benchmark и что на уровне зрелости у системы остаются серьёзные ограничения. См.: https://www.anthropic.com/engineering/building-c-compiler

Самое показательное тут именно не «смог / не смог», а характер недостачи. Carlini прямо пишет, что сгенерированный код «not very efficient», причём даже при включённых оптимизациях он хуже, чем код GCC с отключёнными оптимизациями; кроме того, новые фичи и багфиксы часто ломали уже работавшую функциональность. А текущий README репозитория добавляет ещё более жёсткую деталь: все уровни -O0…-O3, а также -Os и -Oz, сейчас гоняют один и тот же optimization pipeline. То есть это не просто «оптимизатор слабый»; это означает, что сама дисциплина разграничения уровней оптимизации, trade-off’ов между скоростью компиляции, скоростью исполнения и размером кода фактически ещё не состоялась.

Поэтому ваша формулировка «не явился на соревнования» почти точна. Современный оптимизирующий компилятор — это не одна великая идея, а длинная история накопленных локальных побед: выбор представлений, регистровое распределение, instruction scheduling, учёт register pressure, shrink-wrapping, cost models, векторизация и множество таргет-специфических эвристик. В документации GCC это видно буквально по перечню самостоятельных семейств оптимизаций и их тонким включениям на разных уровнях -O; даже одна только область scheduling/register allocation уже разветвлена на несколько отдельных проходов и эвристик. На этом фоне «у нас есть SSA IR и 15 passes» — это начало разговора, а не его зрелая стадия. См.: https://github.com/anthropics/claudes-c-compiler

Отсюда, по-моему, следует более общий тезис об ИИ. В этой области слишком часто аплодируют переходу от нуля к единице, тогда как в инженерии уважение обычно начинается где-то на переходе от 0.7 к 0.95. ИИ сегодня часто силён именно в зоне «собрать осмысленный черновой артефакт при мощном оракуле из тестов и известного toolchain’а». Но он заметно слабее там, где нужно годами выжимать проценты по геометрическому среднему, удерживать регрессии, строить корректные cost models и поддерживать длинную дисциплину улучшений без распада системы. История с CCC это очень хорошо показывает: система способна породить впечатляющий компиляторный организм, но пока не демонстрирует того типа накопительной инженерной зрелости, по которому в обычной технологии и решают, разговаривать с тобой «как со взрослым» или нет.

Если выразить это совсем коротко: сегодня ИИ уже умеет производить доказательства возможности; гораздо реже он производит артефакты, выдерживающие нормальные критерии технической взрослости.

Весной
Не ной

Тем временем рекрутеры

> Дмитрий, добрый день!
> (...)
> Cергей, cкажите, пожалуйста, интересно ли вам обсудить данное предложение?

Продукт, который поможет не терять продуктивность

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.

Гораздо более интересный текст про ИИ-агенты, компилятор (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/

Правда, 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/

rust-coreutils в Ubuntu: blazingly fast, blazingly safe, 40+ CVEs

https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773

> 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://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.