Ну а что ещё делать, если лимиты кончились?

20 мая 1935 года родился Владимир Иосифович Левенштейн - человек, чью идею использует почти каждый поиск, мессенджер и телефон на планете.

Имени его почти никто не знает. А идеей пользуются миллиарды людей каждый день, даже не догадываясь об этом. И самое интересное здесь не то, что он сделал, а то, для чего он это делал.

В 1965 году в Докладах АН СССР вышла его статья "Двоичные коды с исправлением выпадений, вставок и замещений символов". Название звучит как что-то про текст и опечатки. На деле работа была про связь.

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

В качестве инструмента он ввёл метрику: минимальное число вставок, удалений и замен, чтобы превратить одну последовательность символов в другую. Её назвали расстоянием Левенштейна.

Пример из учебника:
"кот" → "кит"
Заменили одну букву, расстояние равно 1.

Дальше произошёл странный поворот. Метрика, придуманная для битовых потоков в каналах связи, идеально легла на строки букв. И её стали использовать совсем не для того, для чего она писалась.

Сегодня расстояние Левенштейна всё еще активно используется. К примеру простейший поиск с учетом опечаток часто строится именно на основе Левенштейна. А еще сверка адресов, имён и записей в банках и налоговых.

В задачах, где важен не только набор символов, но и контекст, его потеснили языковые модели:
- автозамена в телефоне: первые поколения считали именно edit distance и превращали "прювет" в "привет", сейчас SwiftKey и Gboard работают на нейросетевых языковых моделях
- подсказки поисковика "возможно, вы имели в виду..."
- дедупликация текстов для обучения LLM: на современных масштабах применяют MinHash и LSH, но логика "найти почти дубликат" та же самая

История с Google показательна. В начале двухтысячных под капотом "Did you mean" стоял именно Левенштейн плюс частотность слов. Питер Норвиг, директор по исследованиям Google, тогда показал, что весь спелл-корректор умещается в 36 строк Python. Языковые модели и анализ кликов пришли позже, когда у компании накопилось достаточно поведенческих данных. Сейчас расстояние Левенштейна там - один сигнал из многих, но фундамент был заложен именно им.

Маленькая, но важная поправка. Левенштейн не придумал способ быстро считать это расстояние. Привычный код на динамическом программировании за O(m*n) - это работа Вагнера и Фишера, 1974 год. Левенштейн дал метрику. Алгоритм её вычисления появился девятью годами позже.

В 2006 году IEEE вручила ему медаль Хэмминга - одну из главных наград в теории информации. На церемонию он не приехал: после инсульта почти не мог работать. Умер в Москве в сентябре 2017-го.

Человек проектировал коды для спутниковой связи. А в итоге дал миру первый язык, на котором компьютеры научились говорить "это почти то же самое". Дальше пришли нейросети и языковые модели, но точка отсчёта осталась за ним.

Снова олимпиада. Собираюсь на трек ML. В этот раз оффлайн, давно пора посмотреть на кластер Ломоносов. В этот раз хочу проверить новые подходы решения задач с быстрыми моделями (haiku, flash 3,5 и т.д).

Предыдущий опыт с Opus 4.6 и Gemini 3 Pro был относительно неудачным. Сложные задачи триггерят режим thinking, который со временем выпадает в таймаут через 20-30 минут. Причем не оставляет ни намёка на решение. Колоссальная потеря времени. А вот постепенная оптимизация/эволюция слабого решения быстрыми моделями показала себя намного лучше. Чтож, проверим.

Кто с Москвы - присоединяйтесь оффлайн. Если нет - приходите онлайн.

Как ИИ помог восстановить доступ к крипто-кошельку, на котором было $400к. Прошу внимания, история достойная.

В студенческие годы один товарищ купил 5 BTC по $250. И однажды под кайфом решил сменить пароль. А потом его забыл. Десять лет эти пять биткоинов пылились на кошельке. И дорожали, дорожали, дорожали. К 2026 году они стали стоить четыреста штук баксов. И это замечательно! Только вот пароля нет. И ничего не помогало его найти.

Последняя надежда была на Claude. Ему поручили копаться в мусоре (изучить все файлы на старом ноутбуке). И, о чудо, на этой свалке нашёлся старый бэкап кошелька - тот, что был сделан ещё до смены пароля. Только вот старый файл с старым паролем не открылся... Btcrecover уверенно выдавала ошибку "Пароль неправильный". Батька Claude почесал голову, выругался и полез разбираться дальше. Залез далеко, аж в исходники btrecover. Там нашелся баг: утилита неправильно склеивала внутренний ключ кошелька с пользовательским паролем. И уже после этого фикса бэкап открылся с первой попытки.

Упорство и труд Claude - ключ от кошелька найдут. А еще пару лет назад мы могли о таком только мечтать. А сейчас вон, драйвера чинят, игры старые портируют, теперь вон и кошельки восстанавливают. Круто!

Прогнал тестирование проекта через Claude прямо в браузере

Дал Клоду доступ к Chrome (через плагин Claude in Chrome) и одну задачу: «прощёлкай весь функционал и составь отчёт о работоспособности». После одной из самых жирных фич у меня на проекте много чего отвалилось — хотел понять масштаб.

Что в итоге получилось:
— прощёлкал всю админку, публичную часть
— проверил лендинг: демо, тарифы, форму заявки
— залез в консоль и Network, померил тайминги через Performance API
— сложил всё в test_report.md с приоритизацией багов

И нашёл вполне реальные вещи, не «вода»:
🔴 403 на прямом заходе/F5 на вложенных страницах админки (nginx без fallback на index.html)
🔴 404 на фоновом паттерне темы — фон просто не грузился
🔴 сломанный эндпоинт конфига чата, который ещё и 440мс впустую жрёт
🟡 пустое демо на лендинге первые 6 секунд + hydration mismatch в Nuxt
🟡 опечатки, сброс контекста после F5

Отдельно порадовало, что он сам додумался перепроверять свои же выводы: сначала решил, что сломан фильтр (пустая выдача), а потом понял, что это была комбинация «поиск + фильтр» без совпадений, и переиграл вердикт. Не просто «вижу пусто → баг».

И конечно же понравилось, что в чате остались скриншоты всех найденных артефактов. Удобно!)

Честно про минусы:
⚠️ вкладка под автоматизацией иногда подвисала, скриншоты отваливались по таймауту
⚠️ paint-метрики (FCP/LCP) врут, потому что фоновая вкладка троттлится — для честных цифр всё равно нужен Lighthouse руками

Вывод: как первый проход QA по живому продукту — неожиданно полезно. Не заменяет ручное тестирование и автотесты, но за один заход выдаёт приоритизированный список «что пойти чинить». Я за полчаса получил карту поломок, на которую сам бы потратил вечер.

#claude

Вдохновляемся ИИ-поэзией после тяжёлого рабочего дня.

Оригинал то знаем?

Послушайте!
Ведь, если токены сжигают —
значит — это кому-нибудь нужно?
Значит — кто-то хочет,
чтобы ответы были?
Значит — кто-то
называет эти миллионы запросов
не «тратой денег»,
а автоматизацией?

И, надрываясь
в метелях ночного вайбкодинга,
врывается в API,
боится, что лимит кончился,
платит,
обновляет подписку дрожащей рукой,
просит —
чтоб обязательно
достроило MVP!

клянётся —
не перенесёт
эту безнейросетную муку.

А после
ходит тревожный,
но спокойный наружно.
Говорит кому-то:
— Ведь теперь деплой не страшен?
Да?..

Послушайте!
Ведь, если токены сжигают —
значит — это кому-нибудь нужно?

Я не мог это не выложить

Для ресёрча к постам иногда прогоняю тему сразу через несколько разных моделей. Одна лучше ищет детали, другая помогает проверить факты, третья подкидывает неожиданные углы для рассказа. Удобно, когда это можно делать в одном месте, не прыгая между сервисами. В последнее время для такого часто открываю Umnik AI. Claude к примеру намного хуже справляется с поиском по ru ресурсам, а вот chatgpt - намного лучше. Но они часто очень "сдержанные", поэтому острые вопросы удобнее разобрать с Гроком. И вот уже в сумме получается +- объективно. Так и живём.

И так, важный вопрос.

Принёс новый GitHub-тренд для тех, кто работает с большими проектами - CodeGraph.

Идея простая: CodeGraph (ссылка на репо) заранее строит для агента «карту проекта». Он индексирует репозиторий, вытаскивает функции, классы, импорты, вызовы и зависимости, складывает всё в локальную SQLite-базу, а потом отдаёт агентам через MCP.

То есть вместо привычного ритуала grep → read → grep → read → grep → read агент может запросить готовый граф кода.

Собственно, никакой магии тут нет, и польза весьма приземлённая. У больших проектов есть ощутимый налог на разведку: каждый новый агент сначала пытается понять, где что лежит, какие файлы важные, кто кого вызывает и где начинается нужный flow. Память и карта проекта в markdown тут не сильно спасает. Когда в репозитории сотни или тысячи файлов, агент может сжечь кучу токенов просто на то, чтобы осмотреться.

А раздутый контекст - это не только дороже и медленнее. Это ещё и лишний шум: модель тащит за собой мусор, который насобирала по пути. В итоге её «интеллект» внезапно начинает напоминать меня после третьего созвона подряд.

По собственным бенчмаркам автора на 7 open-source проектах CodeGraph дал примерно 35% экономии стоимости, 57% меньше токенов, 46% быстрее ответы и 71% меньше tool calls. Цифры красивые, но пока это именно авторский benchmark, а не независимое исследование.

Полноценных независимых исследований именно CodeGraph пока нет - инструмент свежий. Судя по релизам, он появился буквально в мае 2026 года и сейчас активно допиливается. Но сама идея не новая. Уже много лет существуют статические анализаторы, графы вызовов и графы зависимостей. Теперь этим всем пытаются научить пользоваться AI-агентов, потому что каждый лишний обход проекта - это токены, деньги и время.

Сразу задаюсь вопросом: почему это не стало мейнстримом раньше?

Думаю, основная причина в том, что раньше боль была слабее. AI и до этого умел писать код, объяснять файлы и помогать с рефакторингом, но чаще человек сам приносил ему контекст: вот файл, вот функция, вот ошибка. С агентами сценарий поменялся: теперь им всё чаще отдают задачу целиком - «разберись в проекте, найди нужную логику, измени её и проверь последствия».

И тут внезапно значимая часть работы уходит не на кодинг, а на разведку проекта. Поэтому старая идея code intelligence снова стала актуальной. Это привычные IDE-фичи вроде Go to definition, Find usages и Rename symbol, только теперь не для человека, а для агента. CodeGraph пытается дать ему не простыню файлов, а карту связей внутри проекта.

Но открытых вопросов всё ещё много. Как сделать такой граф универсальным, если в реальных проектах есть динамические импорты, DI-контейнеры, ORM, generated code и магия фреймворков? Как заставить агента действительно пользоваться графом, а не продолжать бегать через grep/read по привычке?

Похожие подходы уже проверяли в исследованиях. Например, в препринте про Codebase-Memory использовали похожую связку: Tree-sitter, knowledge graph и MCP. Результат ожидаемый: токенов уходит сильно меньше, tool calls тоже меньше, но качество ответов может просесть, если вопрос требует не карты проекта, а внимательного чтения конкретной реализации.

То есть это снова не «серебряная пуля» для разработки. Но инструмент может быть полезным для больших репозиториев.

Claude Opus 4.8 вышел. И самое интересное — не бенчмарки.

Anthropic обновила Opus: модель стала сильнее в кодинге, reasoning и агентских задачах, цена осталась прежней — $5 / $25 за миллион токенов.

Но главный апдейт - в поведении.

One of the most prominent improvements in Opus 4.8 is its honesty

Opus 4.8, по словам Anthropic, чаще признаёт неопределённость, лучше ловит собственные ошибки и примерно в 4 раза реже пропускает баги в написанном коде без замечаний.

Плюс в Claude Code появился dynamic workflows: Claude может разбивать большую задачу на десятки/сотни параллельных subagents и тащить большие миграции, аудиты и рефакторинги.

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

И вот это уже гораздо интереснее очередного плюсика в бенче.

Конечно же не забыли напомнить и про Mythos:

we expect to be able to bring Mythos-class models to all our customers in the coming weeks.

Хочется верить, что в ближайший месяц-полтора уже выпустят модель для всех.

Кажется у меня новое хобби... Генерировать новости под стихи Маяковского. Как же круто.

ОДА НА OPUS 4.8

Слушайте!
Граждане
        двадцать шестого года —
из кода,
из ночи,
из кофе остывшего —
встаёт
       не машина,
              не просто метОда,
а Опус!
Четыре!
       И восемь!
              вышедший!

Я звал его —
            он отвечал мне строчками,
не мямлил,
        не путал,
            не лез в чепуху.
Где раньше я бился
                над багом
                       до точки я,
теперь —
       раз-два! —
              и поправка вверху.

Товарищ процессор,
                давай,
                    разгоняйся!
Мы вместе
        запустим
              стартап до небес!
Проект мой
          ракетою
                в космос врезается —
а Опус
       внизу
           подаёт ему вес.

Не спать!
        Не сдаваться!
              Гори, предприятие!
Пускай говорят,
             что работа —
                     тюрьма.
Я выйду!
       Я брошу!
            И — солнце! — объятия! —
останусь
       один
          на один
              с новым Опусом.
                    Да!

.git/info/exclude — личный .gitignore, который не уезжает в репу

Знакомая боль: пробуешь у себя в проекте новый инструмент - и каждый раз git status шумит этими файлами, рискуешь случайно закоммитить лишнего. У меня там и .cursor, и agent.md от Codex, и claude.md от клода, и много чего еще... С codegraph еще и его папка появилась.

В проектный .gitignore это добавлять нежелательно. Если каждый раз туда добавлять всё больше и больше - он превратится в огромную свалку. Плюс в больших проектах пока твой .ginignore разойдется по develop/main - пройдет вечность, которую ты будешь страдать.

А оказывается, у git ровно для этого есть встроенная штука — .git/info/exclude.

Это файл внутри .git/, синтаксис как у .gitignore, но он:
- не коммитится (живёт в .git/, а .git/ сам по себе не версионируется);
- виден только тебе;
- работает в этом конкретном клоне репозитория.

Пример. Открываешь .git/info/exclude и пишешь туда что угодно:

- CLAUDE.md
- AGENTS.md
- .cursor/
- experiments/

Всё - git status чист, ничего случайно не уедет в PR.

Бонус: есть глобальный игнор на все репы

Если те же файлы засоряют тебе вообще все проекты - можно настроить глобально:

git config --global core.excludesFile ~/.gitignore_global

В этот файл кладём универсальные паттерны (CLAUDE.md, .idea/, .DS_Store).

Не знаю почему я не нагуглил это раньше. Такая маленькая фича, а такая полезная.

Новый день - новый скилл. Разберем /simplify для Claude Code.

Он проходит по недавно изменённым файлам и ищет, что можно упростить. Спавнит трёх параллельных агентов под разными углами - неиспользуемые импорты, лишние переменные, шанс вытащить общую логику, переусложнённые условия. Найденное чинит сам.

Можно сузить фокус: /simplify focus on memory efficiency или /simplify focus on error handling. Полезно, когда знаешь, где у изменений шероховатости, но хочешь, чтобы Claude довёл до ума детали

Запускается локально. В отличие от /ultrareview бесплатный и быстрый, по ощущениям ближе к мини-ревью.

Лучше всего работает сразу после крупного рефакторинга или после того, как принял большой батч AI-сгенерированного кода. Именно там накапливаются мелкие огрехи, которые поодиночке незаметны

Хорошая привычка - дёргать /simplify перед коммитом после серьёзных изменений. Дешевле, чем ловить те же вещи на code review.

#claude

🏆 Как я взял первое место на олимпиаде по оптимизации — и почему дело было не в алгоритмах

Победа решилась 0.005 балла. Серьёзно - после нескольких часов борьбы общий зачёт разделили пять тысячных. И вот что я вынес из этой гонки: на таком уровне выигрывает не тот, кто придумал самый умный алгоритм, а тот, у кого правильно выстроен процесс работы.

Несколько принципов, которые реально решили исход 👇

1. Итерации важнее озарений. Учёл эту ошибку из прошлого опыта. Я не пытался родить идеальное решение сразу. Начинал с малого. Рабочее, пусть и не самое оптимальное решение - отличная база. Каждую задачу я прогонял через лесенку версий: простой рабочий вариант → отправил → улучшил → отправил снова. Побеждает число честных итераций, а не глубина раздумий.

2. Учимся на ошибках. Архитектура строится так, чтобы учиться на своих ошибках и делать выводы: после того, как сформирован валидный базовый ответ, он служит основой и обоснованием для будущих улучшений. Каждая итерация - это ценная информация. Всё это позволяет пробовать больше. Без страха и с чувством азарта.

3. Разные модели - разное решение. В какой-то момент Claude начал упираться в потолок своих знаний. На помощь приходят другие модели, которые учились на других данных. Это отличный источник инсайтов и альтернативных подходов.

Любопытный момент: задачу B по очкам я проиграл - другой участник сделал её лучше. Но ровный, дисциплинированный процесс по всем задачам сразу всё таки вытащил общую победу.

Вывод: запускай больше, измеряй, фиксируй выводы. Правильный флоу бьёт зубрёжку. ⚡️