Программирование *

У меня был ранний доступ к первой публично доступной модели класса Mythos — Claude 5 Fable. Большинство обсуждений вокруг Mythos сосредоточено на кибербезопасности, но я тестировал модель на всём остальном (ограничения Fable фактически блокируют её использование в этой области).

Мой вывод: это реальный скачок относительно всех моделей, с которыми я работал раньше. И, что важнее, он говорит о фундаментальных изменениях в том, как мы взаимодействуем с AI.

5 марта 2026 года в своём доме, в окружении семьи, тихо умер человек, чей код вы трогали на этой неделе. Возможно, прямо сегодня. Возможно, он уронил вам прод.

Звали его сэр Чарльз Энтони Ричард Хоар. Для друзей — Тони. Для пары поколений студентов — C. A. R. Hoare, тот самый, что в 26 лет придумал quicksort, выиграв у начальника спор на шесть пенсов. Тьюринговская премия 1980 года, логика Хоара, CSP, на которой потом выросла половина теории конкурентности. Большая, красивая, почти безупречная карьера.

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

Это null.

Есть расхожий сюжет: коварная индустрия наплодила багов, а гениальные инженеры героически с ними борются. Красиво. И, как обычно, неправда. Потому что самый дорогой баг в истории софта добавил не злодей и не нерадивый джун. Его добавил один из умнейших людей в истории computer science. 

Вот про эту историю и поговорим.

Каждый раз, когда техно-энтузиасты на Хабре начинают петь оды ИИ, который вот-вот заменит всех разработчиков, меня охватывает легкий скепсис. Дело в том, что многие простые задачи совсем не так просты, как кажутся нейросетям или продакту. Знаменитое: “да что там делать, вон ИИ отдай, к вечеру уже на прод зальете”, обычно открывает такую кроличью нору, что проваливаться и падать там можно неделями, а приземление оказывается очень болезненным. 

Вот казалось бы, что сложного, сделать дверь в игре? В 2014 году у Liz England вышло отличное эссе “Проблема Двери”, где Лиза описывает 22 логических вопроса, на которые должен ответить гейм-дизайнер при установке двери в игре. Эссе стало настолько классическим, что в сабредите r/GameDesign автомод прикрепляет ссылку на него в каждый тред. При этом эссе явно выходит за границы геймдева и становится универсальным, показывая, что кажущаяся простота в нашем деле часто не является таковой. Это касается и дверей в игре, и “просто логина на сайте”, и задачи вызова лифта, и визуализации прогресса ожидания и ещё тысячи вещей, необходимость детального продумывания которых менеджментом обычно в расчет не берется.

Я сделал это! Это огромный повод для гордости. Теперь программа работает по тем же математическим принципам, что и самые передовым фрактальным в мире!

Ключевые особенности:

Расчёт опорной траектории на 5000 бит всего один раз.
Реактивный расчёт миллионов пикселей на аппаратном double.
Революционный алгоритм Reference Reset to Zero.
Настоящий SSAA 8x8 для идеально сглаженного изображения без алиасинга.
Параллелизм OpenMP для высокоскоростного многопоточного рендеринга.

Есть полный код в С++ - main.cpp
Есть Гитхаб https://github.com/Divetoxx/Mandelbrot#russian с версии в виндовс Mandelbrot_windows_msse3.exe и Mandelbrot_windows_mavx2 и для Линукс Mandelbrot_linux_msse3 -msse3 и Mandelbrot_linux_mavx2

Всем привет! Продолжаю тему локальных LLM. В предыдущей статье мы сравнивали железо для инференса — Nvidia DGX Spark, Mac Studio M3 Ultra и Strix Halo. И как можно было догадаться, я остановился именно на последнем.

Теперь, когда железка есть, встает вопрос: а как из него извлечь практическую пользу для кодинга?

Claude code с оригинальными LLM - это, конечно, замечательно. Но это стоят денег, да и свой код в чужие дата-центры не всегда правильно лить. Плюс за всякое неосторожное движение можно попасть в бан, рискуя потерять все свои наработки.

Одно из решений: Claude Code во free mode с локальными моделями. Anthropic позволяет заменить свои модели на любые с совместимым API. То есть, на что угодно — даже на модель, крутящуюся прямо у вас на компьютере.

В этой статье я расскажу, как всё это настроить на Strix Halo — от загрузки моделей до первого запроса к Claude Code.

В третьей статье пойдет речь уже о готовом аллокаторе который вполне пригоден для распределения памяти

В стандарте C++20 было представлено множество нововведений, и одним из наиболее крупных и долгожданных в их числе являлись модули. Теперь, когда с тех пор минуло около шести лет, то воодушевление сменилось здоровым цинизмом. Так, авторы сайта Are We Modules Yet прогнозируют, что поддержка модулей во всех библиотеках будет обеспечена к 1 мая 2167 года, а на Reddit не проходит и двух недель, как возникает очередной тред на тему: «Ну что, ими уже можно пользоваться»? (спойлер: нет).

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

Многие ML‑инженеры знают, что нужно использовать CrossEntropyLoss, log_softmax и logsumexp. Гораздо меньше людей могут объяснить, что именно они спасают и почему без них обучение модели периодически превращается в генератор nan. Именно об этом и поговорим.

В августе 2025 года TypeScript впервые возглавил рейтинг GitHub по числу активных контрибьюторов, обойдя Python и JavaScript. Изменился подход к написанию кода: типы стали машиночитаемыми контрактами, фреймворки сделали TS вариантом по умолчанию, а ИИ-инструменты используют типы как ограничения. Разбираемся, какие цифры подтверждают тренд, где он создаёт издержки и как выбирать стек в 2026 году с учётом изменений рынка.

Тема конечных автоматов (КА) актуальна. Почти как тема реализации светофоров. Но вот, если серьезно, только отношение к ней разное. Время от времени появляются статьи типа «Конечные автоматы (FSM) – это ловушка для программиста» [1]. И здесь очень не хочется, чтобы складывалось превратное представление о некой «псевдо-математической» автоматной абстракции. Нужно оберегать народ от подобных суждений, которые ни на чем не основываются.

Не будем, в пику упомянутой статье, петь дифирамбы автоматам в очередной раз. Потому, как «сколько не говори халва, во рту сладко не станет». Но можно реализовать пример из статьи только с позиции другого взгляда на автоматы. Это больше убедит, чем пространные рассуждение в духе «свист-технологии» или той же многопоточности и конкурентности.

Пусть перед нами стоит задача реализовать светофор и при этом уже есть довольно интересное, если не сказать – оригинальное, решение, которое дает право автору статьи весьма критично высказываться в отношении автоматов. Само решение сводится к следующим шагам: 1) создается таблица, строки которой определяют цвет светофора и его время; 2) создается простая программка перебора строки, которая зажигает в прямом и переносном смыслах, реализуя управление светофором.

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

Наткнулся на репозиторий claude-code-best-practice — под 56 тысяч звёзд, #1 в GitHub Trending, внутри собраны в том числе советы самого создателя Claude Code. И поймал странное чувство: весь последний год я по кусочкам писал статьи ровно про то, что тут лежит в одном месте. Оркестрация, индексация кода, память агентов, выбор модели — это всё узлы одной карты. Но в одном месте карта спорит с моим опытом. Репо жёстко заявляет: «agentic search (glob+grep) бьёт RAG, векторные БД мы попробовали и выкинули». А я прямо сейчас внедряю Graphify во все проекты — и он работает: быстро, точно, сокращает токены. Кто из нас прав? Полез разбираться — и нашёл, что сам создатель Claude Code признал: ранний Claude Code использовал RAG, но agentic search «обогнал всё, и это было неожиданно». Правда, добавил: «оценивали в основном по ощущениям». В статье распутываю этот спор и выкладываю навигатор по репозиторию на русском.

Всем привет! Я молодой java-лид в одной из "гостех" контор и меня мучает вопрос, или навязчивая мысль "А что мы получим, делегировав разработку ИИ"...

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

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

Во-вторых, разве нам, кто пишет код, так интересно становиться "операторами IDE"? Это же насколько унылой стала работа: пишешь промт, ждешь n секунд/минут, получаешь какое-то решение, ревьюишь его, а кто-то и ревьюит агентами, коммитишь, а кто-то и это делает агентами. Все..? Это же не инженерия, а очень вялый cuк-OLD-инг :)

Первичное наполнение контекста — крайне важная задача, результаты которой влияют на качество решения/сгенерированного кода, возможно, даже больше, чем выбранная модель. В Claude Code за это отвечает Explore sub-agent, который, к слову, справляется неплохо, ровно до тех пор, пока вы не начинаете "по настоящему" использовать Spring: добавляя собственные starters, используя OpenAPI (Spec-first), определяя Bean/Components в стиле Josh Long (описывая их в конфигурациях), а также внедряя множество других инструментов фреймворка. В этом случае качественный анализ можно провести, только зная особенности работы Spring Framework и экосистемы.

В этом выпуске еженедельного дайджеста Skill of the week разберёмся, как, используя Spring Explore Skill, научить агента понимать специфику Spring-приложения и выполнять качественный первичный анализ.

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

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

Качество работы с кодящим агентом почти не зависит от того, какая под капотом модель. Я довольно долго в это не верил — менял модели, крутил промпты, ждал следующий релиз. А разница, оказалось, не в модели. Она в том, что вокруг модели: есть ли у агента память между сессиями, карта проекта, правила, руки и место под результат. Голая модель — это эрудит без рабочего места. Каждый разговор она начинает с чистого листа.

Вот это всё вокруг модели — память, карта, правила, руки — и называется харнесс. Ниже — разбор моего харнесса целиком, слой за слоем, на одном реальном проекте: пять сервисов, Kubernetes, прод. Не идеальная схема из README, а то, что видно в логах: что реально вызывается каждый день, а что я нагородил и забыл. Спойлер: половина подключённых MCP-серверов за 98 сессий не вызвалась ни разу. Сразу оговорюсь: сессии сохранились не все — у Claude Code, похоже, есть ротация логов, часть истории потерялась. Так что мои числа — это нижняя граница, реальные ещё выше.

Открываешь чужой код на Python, а там — Java. Абстрактные базовые классы в местах, где хватило бы простой функции, фабрики фабрик и нагромождение паттернов, усложняющих чтение бизнес-логики. Знакомая картина?

Многие разработчики механически переносят архитектурные привычки из строго типизированных языков в Python, создавая переусложненный неидиоматичный код. В этой статье мы возьмем классические правила SOLID и переведем их на язык динамической типизации (Pythonic way). Разберем на реальных примерах, где принципы спасают проект, а где слепое следование им скатывается в карго-культ.

Я наткнулся на подход к функциональным тестам, который меня по-настоящему удивил. Тесты в нём вообще не знают, что внутри Spring: стучатся в реально поднятый сервис по HTTP, как обычный клиент, гоняются параллельно и проходят за секунды. Я разбирал это на код-ревью и сначала прифигел, а потом не стал переходить на него сам, но кое-что забрал себе. В статье сравниваю оба подхода, разбираюсь где какой уместен, и показываю три вещи, которые подсмотрел и притащил в свой Spring

Codex хорош, пока не приходится в пятый раз объяснять ему одни и те же правила проекта: где проверки прав, как запускать тесты, почему не надо тащить старые alias-модули и что мы уже решали в прошлом чате.

Поэтому я сделал Hermes Codex Plugin — плагин, который хранит правила, summaries и прошлые решения в SQLite, ищет их через FTS5 и подкладывает Codex только маленький релевантный кусок контекста.

На связи Сергей Смирнов, AI-инженер и основатель LLMStart.ru. Сегодня разбираем, как написать биллинг для продакшн ИИ-агента.

Когда ваш ИИ-бот начинает отвечать клиентам в B2B-сегменте, каждый его ответ стоит токенов. Чтобы экономика продукта сходилась, расходы на LLM нужно жестко контролировать и тарифицировать. Кажется, что достаточно просто прикрутить калькулятор, но на деле всё сложнее: один HTTP-запрос может дергать до пяти разных нейросетей, и не все они идут через стандартный граф фреймворка.

В новой статье на Хабре рассказываю: — Почему считать деньги по чатам — это путь к хаосу. — Зачем мы изобрели «микрокредиты» вместо наивных токенов. — Как протащить контекст биллинга через пять LLM-вызовов в одном запросе с помощью магии ContextVar + Mixin.

Разбор для тех, кто делает multi-tenant LLM-сервисы и уперся в ограничения готовых прокси-решений.

Про C++ часто шутят, что любую вещь можно сделать пятью разными путями, четыре из которых компилируются, три работают, а два правильные, но один зависит от фазы луны. Часто такие шутки и идиомы откладываются в коллективной памяти сообщества какой именно из этих путей правильный в каждой конкретной ситуации.

Большинство этих примеров родилось в эпоху до C++11, когда у языка ещё не было ни умных указателей в стандарте, ни move-семантики, ни constexpr, ни концептов, и приходилось руками собирать из шаблонов и перегрузок некоторые конструкции, которые в более поздних стандартах язык даёт почти бесплатно. Многие идиомы, примеры и идеи стоит читать в двух смыслах сразу, как исторический артефакт, объясняющий «почему старый код выглядит вот так», и как живой приём, который всё ещё применяется в движках и играх.

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

Когда я собирал оглавление Game++, раздел про идиомы, идеи, паттерны и механизмы C++ планировался шестым и завершающим, и должен был занять страниц сто, по одной на каждый пункт, но чем дальше я собирал материал, тем яснее становилось, что каждая секция тянет за собой историю, а каждая история требует контекста, а каждый контекст в игрострое никогда не бывает простым. В итоге текст разросся до размеров, при которых он просто сломал бы структуру книги, и мне пришлось выбирать между «урезать до неузнаваемости» и «отпустить жить отдельно». Пришлось выбрать второе.

Перед вами то, что могло бы стать половиной Game++, но стало самостоятельным материалом. Здесь собраны идиомы, идеи, паттерны и механизмы C++, которые сложились в сообществе за несколько десятилетий и продолжают жить в кодовых базах игровых движков, иногда под своими именами, иногда под другими, иногда вообще без имён, потому что их давно перестали объяснять. У большинства имена все же есть, есть и история с ответом почему именно так, а не иначе.

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