AI НЕ ДЕЛАЕТ ВАС ПРОДУКТИВНЕЕ Незыблемый факт: AI уже очень хорош в маленьких задачах. Написать плагин, скрипт, небольшую tool'у, UI для UnityEditor окна, вытащить текст из аудио, накидать интеграцию с Google Sheets — вот здесь он реально экономит время. У меня таких историй уже пачка: — история буфера обмена на macOS — парсинг локализаций из Google Sheets в MySQL — извлечение текста из аудиозаписей — терминальный чат для тестирования внутриигрового чата — интеграция BenchmarkDotNet в Unity И тут спорить бессмысленно: да, это ускоряет. Многие мелкие автоматизации можно сделать буквально за 1 промпт. Когда раньше, я даже не брался за это, т.к. на отладку и написание могло уйти полдня-день. 🔸Проблема - большой production Когда я работал в Playtika, уже тогда менеджмент пытался понять, как ускорить процессы разработки через AI. Но модели упирались в контекст. Они могли решить локальную задачу, но плохо держали систему целиком. Сейчас модели стали намного сильнее. Контекст вырос. Opus уже технически способен написать кусок фичи почти полностью. Но я всё равно не готов просто взять и запушить это в большой production-проект. Почему? Потому что в проекте на сотни тысяч строк AI все равно не хватит контекста, чтобы изучить и прочитать все что есть, из-за этого: 🔹Генерируется функционал, который уже есть в проекте 🔹Системы используются не правильно или не полностью 🔹Агент может посчитать, что функция в другой системе написана не правильно и "исправить". И кажется что сделано много, так много кода и анализа никто бы из нас быстро не делал. Но из-за того что это нужно потом вычитать внимательно, проверить и/или переписать, общее время на разработку может только увеличится. 🔸И это не только мое наблюдение METR проверили это на 16 опытных open-source разработчиках, которые в среднем 5 лет работали на своих репозиториях. Результат: с AI они стали медленнее на 19% 🤯 При этом ожидания до начала эксперимента были: ускорение на 24% А после, разрабы думали что AI их ускорил на 20%. Т.е. человек делает больше и из этого создается эффект ускорения. И эти результаты нужно поправлять за Echoes of AI, где:

на чужой кодобазе среднего размера AI действительно ускорял — медианное время падало на 30.7%.

Т.е. получается примерно такой парадокс: 🔹 Если проект маленький или среднего размера, то с AI можно в среднем получать +30% к продуктивности 🔹 Если проект большой или огромный, то важно выделять места, где AI может быть полезен, но не отдавать все ему на откуп. Несоблюдние баланса = +20% к времени выполнения задачи. Этот вывод я и сам ощущаю, когда иной раз проще самому написать, чем промптить, а потом ходить и все переписывать. Это может показаться бредом, если опираться на новостной фон и хайпа вокруг AI. Но это отлично согласовывается даже с тем, что я писал еще до AI хайпа:

Природа разработки ПО - это перенос информации из мира реального в мир абстрактный. Где человек играет ключевую и незаменимую роль.

А скорость переноса ограничена особенностями мозга и ростом синаптических связей. Что ограничено естественным жизненным циклом организма. И это естественное ограничение продуктивности. И даже когда скорость написания кода стремится к бесконечности, проекты НЕ стало разрабатывать быстрее или дешевле. 🔸Функция снижения AI-продуктивности Точных цифр нет, но если накидать порядок величин, кривая выглядит логарифмической. Пусть: x — текущий размер проекта в kLOC, y — прирост продуктивности в %, Smin — kLOC-min, минимальный размер проекта, когда появляется сложность, Smax — максимальный размер проекта, когда эффект от AI = 0 Тогда формула снижения влияния AI на продуктивность будет выглядеть примерно так: y ≈ Smin · ln(Smax / x)

 kLOC | эффект
------+-------
    5 | +23%
   50 | +12%
  500 |   0%

🔻Проще запомнить: продуктивность падает примерно на ~3-5% на каждое удвоение размера проекта. Ставь 👍 если тебе заходит такого рода контент! Ты знаешь кому переслать эту статью 💪 #ai@UniArchitect

Походу, Питон — всё 👩‍💻 Всем привет! В момент субботнего вайбкодинга я неожиданно понял, что Питон — всё. Ну, не совсем прям всё, но уже всё. Почему? Потому что я сидел и портировал свои последние питон-поделки на Rust + Tauri. А почему? Потому что это проще, быстрее и надёжнее. Когда я собирал портативку Higgs Ultimate, я не испытал ни одной из проблем, которые обычно ловлю при сборке питона: не ебался с venv и окружениями, не было ни намёка на Градио, который заебал уже сам по себе, не было нелепых тупняков с версиями. Всё просто разобралось, поменялось и собралось обратно. А ведь мне, как вайбкодеру, вообще пофиг, на чём вайбкодить — лишь бы быстро увидеть результат и потыкать пальцами. Так вот: Rust + Tauri закрывает всё то же самое, что раньше закрывал мой стек Питон + Градио. Только быстрее, приятнее и надёжнее. Но это я уже говорил 😄 Может, конечно, я просто окрылён опытом разработки на новом стеке. А может, Питон уже и правда всё. Какие у него по факту остались преимущества перед тем же Растом — при условии, что я не знаю ни того языка, ни другого? То-то же 😏 Сейчас вот портирую Dub Studio на Rust + Tauri — и, как будто бы, она станет работать в разы быстрее, сборка станет меньше размером, надёжность вырастет, и всё будет в одном файле. Посмотрим, как оно выйдет в реальности. А какие мысли у вас? Меняли ли вы язык своих вайбкодинг-поделок в последнее время? Делитесь в комментах 👇 Всех обнял, увидимся на стриме всегда ваш - Nerual Dreming ❤️

@jitbit принёс файловую систему πfs, где всё можно хранить внутри π. Пи — такое хитрое число, что грубо говоря, там каждый следующий знак можно воспринимать как условно-случайный. То есть запись числа содержит любую конечную последовательность цифр. А это значит, что рано или поздно внутри π встретится полная копия вашей ДНК, ваш пароль от роутера, каждый из ваших файлов и даже тот файл, что вы запишете завтра. И чтобы обратиться туда, надо сделать вещи: 1. Найти данные внутри π (это может занять от пары секунд до пары веков и больше) 2. Записать смещение и длину (это почти мгновенно) Чтобы прочитать — просто перейти по координатам и вычитать нужную длину. В реализации файловой системы чтения нет, это вы уж сами. Собственно, от файловой системы остаётся только аналог FAT, где хранятся смещение и длина + заголовки файлов. Система очень надёжная, даже если вы потеряете метаданные, сами данные будут храниться вечно. Запись делается через формулу Дэвида Бейли — можно вычислить два шестнадцатеричных знака дробной части π начиная с позиции id, без вычисления всех предыдущих. Корректна до id ≈ 1,18×10^7, дальше надо разрабатывать отдельные типы или переходить на C++ с его __float128. Для длинных смещений формула работает очень быстро по сравнению с любыми другими методами, потому что даёт считать без вычисления предыдущих цифр (то есть без сильных затрат оперативки), но всё равно время выполнения растет линейно-логарифмически. Ещё она очень хорошо параллелизуется, но при этом у неё нет квантового ускорения. В текущей реализации пишутся чанки, для прототипа — по 1 байту. На каждый байт данных хранится 2 байта метаданных. Если вы хотите писать чанки больше или сразу целые файлы — придётся менять параметры и больше считать. У файловой системы есть проблемы: — Нормальность π — это недоказанная гипотеза. Доказаны иррациональность и трансцендентность, но не равномерная встречаемость. Все эмпирические проверки её подтверждают, но строгого доказательства нет. Это значит, что не факт, что искомая последовательность встретится. — Для смещений порядка 2^64 одно чтение блока заняло бы тысячи процессорных лет, а смещение мегабайтного файла пока не получается записать никуда. — На практике на игровом компьютере 4 байта пишутся мгновенно, 8 байт — 18 секунд, 10 байт — 2 недели, 16 байт — 780 возрастов Вселенной. Именно поэтому выбран чанк 1 байт — чтобы вы могли хоть что-то быстро записывать. — И того, что мы уже вычислили, в массиве найдётся любой блок до 6 байт, и уже с вероятностью около 2% — блок из 7 байт. — Маркетинговый материал включает заявления "infinite storage" и "100% dedup", это правда. — Версии для Win уже 14 лет всё ещё нет. Можно над ней смеяться, но вообще-то она работает. Наглядным пособием почему хранение данных в π или в Вавилонской библиотеке или в бесконечной константе ничего не даёт. Потому что вся информация перетекает в индексы. Судя по запросам сообщества, нужна поддержка ещё 𝐞, √2, τ, предлагают пихать метаданные тоже внутрь π, чтобы уменьшить объём хранения, в планах поддержка Hadoop. Вот вам некоторые полезные смещения: hex 0xF00D — 13680, 0xDEAD — 40771, 0xC0DE — 53378, ASCII 'Hi' — 4506, ASCII 'OK' — 12301. Ещё там есть точка Фейнмана: шесть девяток подряд «999999» на позиции 762. Название файловой системы (314159, первые шесть цифр π) лежат на позиции 176451. 16470 стоит на позиции 16470, 44899 на позиции 44899, 1 на позиции 1 (если считать передними когтями с нуля). И да, если вы дочитали до этого места, вы упоротые. -- Вступайте в ряды Фурье! | Лучшие посты — Тебя как зовут? — Как Лёху. — Как какого Лёху? — Как любого Лёху.

std::expected в C++23: гайд по миграции с исключений на функциональный error handling Берём функцию, которая грузит пользователя, проверяет права и собирает DTO. На исключениях она пишется в три строки и выглядит компактнее, чем цепочка на std::expected. Вот только какие типы исключений способна бросить эта цепочка вызовов, видно не в сигнатуре, а в документации, и компилятор промолчит, когда в глубине добавится ещё один. С std::expected из C++23 набор возможных ошибок стоит прямо в возвращаемом типе, и его проверяют статически на компиляции. Гайд ведёт от базового API к monadic-цепочкам через and_then и transform_error, показывает конвертацию ошибок между слоями и честно перечисляет места, где переходить как раз не стоит.

📖Фундаментальный гайд по сборке ИИ-агентов Голая языковая модель - это просто генератор текста. Чтобы она начала выполнять задачи автономно, нужна инфраструктура. На GitHub выложили подробное руководство по созданию таких обвязок с нуля. 🔍Внутри разобрана вся техническая механика. Авторы пошагово показывают, как прикрутить к LLM долгосрочную память, настроить динамическую сборку контекста, подключить выполнение внешних инструментов и жестко задать границы безопасности. Отдельно препарируется логика работы в изолированных песочницах и оркестрация мультиагентных систем. Материал построен на практике и подкреплен готовым кодом. Для понимания рынка авторы напрямую сравнивают подходы к архитектуре в популярных инструментах: Cursor, Aider и Claude Code. Руководство полностью открытое. Если планируете собирать рабочие системы, а не просто перекидываться текстовыми промптами в чате - забирайте репозиторий по этой ссылке. 🦔 CyberYozh

Язык, который вызывает те же драки, что и «Чёрный квадрат» Малевича Стоит упомянуть Оберон в сообществе программистов, и от него не остаётся камня на камне. Автор видел, как из-за этого языка умирали целые сообщества, а когда обмолвился, что собирается писать статью, ему в личку пришёл человек с просьбой не писать. Пазл сложился, когда он однажды услышал, как люди обсуждают «Чёрный квадрат». Реакция та же, что у зрителя перед Малевичем: «ну я так тоже могу, почему это в галерее, а не на помойке». Оберон устроен так же радикально. Нет привычного ООП, управление памятью отдано сборщику мусора, а цикла FOR просто нет. При этом на таком минимуме написана целая операционная система, запускающаяся прямо на голом железе, а Java и Go оказались его прямыми наследниками. Посмотрим, докуда дотягивается параллель с картиной, которую все ругают и все знают.

И еще одна интересная статья: главный навык агентного кодинга – знать, чего ты не знаешь Пишут, что Fable – первая модель, где качество результата упирается не в модель, а в вас! (та-даам) Точнее, в вашу способность прояснять свои unknowns. Типа карта – это ваши промпты, skills и контекст, то есть то, что вы даёте агенту. Территория – кодбаза и реальные ограничения, где работа на самом деле происходит. Разница между ними = unknowns. Чем больше объём работы, тем больше таких дыр агент встретит и тем чаще будет угадывать, чего вы хотели. Дальше они разбирают как раз классический квадратик 2х2: – Known knowns – то, что вы написали в промпте – Known unknowns – то, что вы ещё не решили, но знаете об этом – Unknown knowns – то, что для вас настолько очевидно, что вы никогда это не запишете, но узнаете, если увидите – Unknown unknowns – то, о чём вы вообще не думали Автор говорит: посмотрите, как промптят крутые программисты – у них почти нет unknowns, они в синхроне и с кодбазой, и с поведением модели. И это тренируемый и очень важный скилл. Чего делать-то надо: – Blind spot pass – перед работой в незнакомой части кодбазы прямо просить Claude найти ваши unknown unknowns, буквально этими словами. «Я ничего не знаю про auth-модули здесь, сделай blind spot pass и помоги мне промптить тебя лучше» (!) – Прототипы до имплементации – ловить unknown knowns дёшево. «Сделай HTML со страницей в 4 радикально разных дизайн-направлениях, я отреагирую» – Interviews – просить Claude интервьюировать вас по одному вопросу, приоритезируя те, где ответ меняет архитектуру – References – лучший референс не скриншот и не доки, а source code. «Вот Rust crate с нужным backoff, прочитай и реимплементируй семантику в нашем TypeScript-клиенте» – Implementation plan – но с фокусом на то, что вы скорее всего захотите поменять: data models, интерфейсы, UX. Ну и записывать артефакты, чтобы можно было понять, что и как создавалось и как теперь работает: – implementation-notes.md во время работы – логи отклонения от плана в раздел Deviations – Квиз после – просить Claude сделать отчёт по изменениям и квиз в конце. Мерджить только после того, как ты сдал квиз на 100%. Это прикольный конечно паттерн, типа: честный ответ на вопрос «а вы понимаете, что агент вам намерджил?» Короче, хватит уже модели ругать, пора смотреть в зеркало https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns

GigaChat 3.5 - что по кодингу? Пока мы все ждем релиз GPT-5.6, в каналах все чаще наблюдаю анонсы новой модели от Сбера. Очевидно, что работа была проделана немаленькая, поэтому поздравляю ребят с релизом! Там действительно получился довольно большой скачок в сравнении с их предыдущей моделью, а в пабликах часто наблюдаю как пишут, что уровень модели сопоставим, либо даже выше, чем DeepSeek V3.2. Но для нас главный вопрос - что с агентным кодингом? Поскольку мне Сбер денег не занес, придется писать правду. И тут главная проблема в том, что из официального релиза это практически не понятно. Т. к. единственный прямой agentic coding бенчмарк, который опубликовала команда - это Terminal Bench 2 (в этом месте хочется позанудствовать, что не существует бенчмарка Terminal Bench 2, а существует Terminal Bench 2.0 и более честная его версия Terminal Bench 2.1 - догадаемся, что речь про 2.0). Причем даже в нем мы видим сравнение только с DeepSeek V3.2 и GigaChat 3.1 Ultra. Ну что ж, мы не из робкого десятка, поэтому соберем результаты других моделям по крупицам из других источников. Например, результаты Terminal Bench 2.0/2.1 удобно смотреть здесь и здесь. GigaChat-3.5-Ultra: 13.48 (харнесс Terminus 2, данные от команды сбера) GPT-OSS-120B: 18.7 (Terminus 2, данные из лидерборда tbench) Qwen3.6-35B-A3B: 24.6 (харнесс little-coder) DeepSeek-3.2: 39.6 (Terminus 2) Nemotron 3 Ultra (550B-A55): 50.94 (Terminus 2, результаты из vals.ai) Тем не менее, наверное, на рынке РФ из отечественных моделей, похоже, что GigaChat 3.5 пока самая сильная модель. Но объективно сказать трудно, т. к. ни Яндекс, ни Сбер более широкого сравнения не публикуют и друг друга в бенчмарки не добавляют - а зря, ведь современные бенчмарки достаточно легко прогоняются через Harbor, нужны только токены. А к колегам по цеху предложение на будущее публиковать System Card модели с техническими подробностями, как это делают OpenAI и Anthropic, а также показывать больше современных бенчмарков: хотя бы DeepSWE 1.1 и SWE-rebench 2.0. @ai_driven

​​Cayley graph search с Claude Code: решение головоломок в 2026 с помощью агентов Я написал большой пост про два Kaggle-соревнования из серии CayleyPy — IHES Picture Cube и Megaminx. Это комбинаторные головоломки (кубик и додекаэдр), но по сути - поиск коротких путей в огромных неявных графах Cayley: вершины графа — это состояния головоломки, рёбра — это ходы, а решить пазл значит найти короткий путь до собранного состояния. Мы занимаемся этим уже пару лет и опубликовали несколько статей, а в 2026 году я решил попробовать новый подход: вместо того, чтобы писать код самому, я использовал Claude Code + Opus как агента, который пишет код. Сам я задавал направление исследований, ревьюил код и решал какие эксперименты стоит гонять. Поэтому пост получился про две вещи сразу: про то как мы решаем графы Cayley (learned heuristic + wide beam search + пост-обработка) и про то, как выглядит research-цикл, когда имплементацию делает агент. Из интересного - не раз упирался в ограничения агентов. Claude так и не смог правильно реализовать shared-beam SPMD после 10 попыток, а Codex завёл его с первой попытки. И почти все значимые идеи приходили от меня, а не от агента — клод плохо справляется с неопределённостью и часто выбирает безопасные пути (даже когда просишь его быть активнее). По ощущениям, агенты позволяют проверять идеи намного быстрее, чем раньше. Но это работает только если внимательно следить за агентом и не давать ему лениться. Блог Medium #ai #kaggle