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

Участвуй в МТС True Tech Champ 2026 — всероссийском чемпионате по программированию с призовым фондом 10 250 000 рублей 🔥

Выбирай, какой трек тебе интереснее 👇

• Алгоритмический (индивидуальный зачет, 2 750 000 ₽). Решай задачи по алгоритмам и структурам данных, которые помогут прокачать навыки для технических собеседований и работы в ведущих ИТ-командах. Лучшие участники пройдут в финал, где в режиме реального времени будут соревноваться в правильности решений и скорости мышления.

• Программирование роботов (командный формат, 7 500 000 ₽). Напиши алгоритмы для робособаки и робота-манипулятора и проведи их через три этапа соревнований. Сначала — через цифровой симулятор, где нужно пройти трассу и выполнить задания по передаче предметов. Затем — подключись к реальному полигону через удаленный доступ и выполни задания на физических роботах дистанционно. А в очном финале лучшим командам предстоит управлять роботами на площадке, дорабатывать алгоритмы под новые условия и бороться за победу на глазах у зрителей.

Шоу-финал с кодерскими челленджами и выступлениями спикеров состоится 22 октября в МТС Live Холл. А лучшие участники получат шанс на стажировку в MTC Web Services (MWS).

Так после МТС True Tech Hack 2026 к команде присоединились три стажера:

1. Илья Матвеев из команды MCLover, 18 лет, студент 1-го курса бакалавриата Института интеллектуальных кибернетических систем (НИЯУ МИФИ). Вышел на позицию стажера frontend-разработчика в MWS Octapi.

2. Роман Субботин из команды DEP_IT_MISIS, 19 лет, студент 2-го курса бакалавриата НИТУ МИСИС по направлению «Прикладная математика» в институте компьютерных наук. Вышел на позицию стажера Python-разработчика в MWS Octapi.

3. Кирилл Ефимович из команды Моторный шуруповерт, 20 лет, студент третьего курса бакалавриата направления «Разработка ПО», Университет Иннополис, GPA: 4.6. Вышел на позицию стажера DevOps в MWS Tables.

➡️ Зарегистрируйся и стань участником масштабного ИТ-чемпионата.

Давненько ничего не писал здесь. В свободное время засел за работу, которую хотел взять в качестве дипломной, но не взял, так как тогда не был уверен в собственных силах. Если кратко, что здесь происходит: я нахожу на лице модели белые маркеры (свзяка из LoG-фильтра и поиска локальных экстремумов методом Китчена-Розенфельда) и пытаюсь отследить их движение в кадре (венгерский алгоритм, он же метод Куна-Манкерса в связке с фильтром Калмана). Модель отслеживания обладает инерцией (в реальности маркер не может телепортироваться и двигается согласно законам реального мира) - требуется стабилизация первые несколько кадров, есть запаздывание и возможна путаница, если движения напоминают конвульсии :) В остальном результат достаточно стабилен. Я хочу прикрутить к получившемуся Proof of Concept графический интерфейс, оптимизировать код (в черновом варианте я создаю кучу лишних объектов, что приводит к частой сборке мусора) и использовать записи с нескольких камер для восстановления положения маркеров в пространстве. Полученные данные в свою очередь можно отправить в любимый графический пакет. Это конечно не коммерческое решение для захвата движений уровня Vicon Nexus, скорее забавный велосипед, но всё же. Ждите эпичного результата и подробной статьи.

Корпорация ценой в три триллиона силами целой армии разработчиков выпустила свою фирменную IDE (Visual Studio 2026) после четырёх лет упорной разработки (предыдущая Visual Studio была 2022):

В наши дни если ты не успевал к релизу перевести настройки в новый формат, тебя били до тех пор, пока ты не успевал. Теперь в мажорном релизе после многих лет разработки можно просто написать: Лифт не работает, пользуйтесь пожарной лестницей. Кажется, это называется «новая искренность»?

Ошибки, которых не видно в сигнатуре: зачем C++ нужен std::expected

Функция выглядит предсказуемо, пока один из вызовов не бросает исключение, о котором никто не вспомнил. Типы ошибок остаются в документации, управление расползается по try/catch, а изменение глубоко в стеке неожиданно ломает обработку выше.

Недавно в статье разобрали std::expected из C++23: как сделать ошибку частью сигнатуры, собирать цепочки через and_then и transform, разделять типы ошибок между слоями и постепенно внедрять подход в legacy-код. Заодно увидели, где std::expected действительно полезен, а где добавит лишнюю сложность.

16 июля в 20:00 продолжим тему на бесплатном уроке «Выразительный C++: кодируем намерения». На практике разберём, как переносить неявные договорённости в типы, сигнатуры и структуру программы. Присоединяйтесь.

Полный список бесплатных уроков июля смотрите в дайджесте.

Робот Физтеха попытается установить мировой рекорд по сборке мегаминкса

15 июля в Физтехе пройдет официальная попытка установить мировой рекорд по сборке головоломки мегаминкс роботом. Команда лаборатории интеллектуальных технологий робототехники МФТИ готовится к финальной стадии проекта, о котором я писал в начале весны.

Инженеры физтеха сконструировали робота, способного собирать одну из самых сложных механических головоломок в мире. Пространство состояний додекаэдра под названием "мегаминкс" оценивается примерно в 10⁶⁸, что на порядки превышает сложность классического кубика Рубика. Проект прошел путь от инженерного прототипа до полноценной системы, объединяющей робототехнику и продвинутые алгоритмы поиска на графах состояний.

Что известно о рекорде

По данным разработчиков, текущая версия системы показывает результаты, которые:

• в 68 раз превосходят предыдущий мировой результат среди роботов, который был установлен роботом Megaminxer Дэвида Гилдея 15 лет назад и составляет 8 минут 4 секунды;

• примерно вдвое быстрее лучшего результата человека (текущий рекорд принадлежит спидкуберу из Китая Ziyu Wu и составляет 21.04 секунды).

За счет чего достигается скорость

Рекордные показатели планируется обеспечить не только быстрым манипулятором, но и глубокой алгоритмической работой:

• Оптимизация планирования движений. Робот выполняет вращения независимых граней параллельно, что критично на коротких дистанциях.

• Сокращение длины решения. Вокруг проекта сформировалось сообщество энтузиастов, которые через open-source проект CayleyPy и соревнования на Kaggle работают над поиском кратчайших путей в графах Кэли. Участники применяют Pattern Databases, алгоритм Корфа, Beam Search и другие методы. За последние недели среднюю длину решений на тестовых выборках удалось уменьшить на 15–20% до ~90 ходов. Лучшие решения сейчас дают порядка 70 ходов (правда считаются долго).

Место встречи

Установление рекорда запланировано на 15 июля, 17:30–21:30 в Физтех.Клубе МФТИ в Долгопрудном.

Кроме того, разработчики расскажут о своих инженерных решениях: кинематика, захват, конструкция манипулятора. А также раскроют алгоритмическую часть: как графы Кэли и методы поиска помогают роботу «думать».

Если хотите стать свидетелями рекорда в стенах МФТИ, то регистрируйтесь по ссылке.

Количество мест, как понимаете, ограничено, поэтому будет организована трансляция на YouTube.

Присоединяйтесь и к группе проекта в Telegram.

Cтaтья «BotSharp изнyтpи: ищeм cлaбыe мecтa в кoдe ИИ‑плaтфopмы нa.NET»

Пpинятo cчитaть, чтo в AI и ML бeз Python никyдa, a.NET — этo иcключитeльнo иcтopия пpo enterprise, вeб‑paзpaбoткy и гeймдeв. Ho пpoeкт BotSharp гoтoв пocпopить c этим cтepeoтипoм, пpeдлaгaя ИИ‑плaтфopмy нa экocиcтeмe Microsoft.

Mы peшили зaглянyть пoд кaпoт BotSharp и пpoвepить, какие ошибки есть в его иcxoдном кoде.

Почему ИИ-агент для кода промахивается мимо нужного метода

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

Агент, который ищет код текстом, физически не отличает OrderService.validate от UserDto.validate: для него это просто совпадение символов «validate». Агент, который спрашивает у IDE «кто на самом деле вызывает этот метод», получает точный ответ, потому что IDE знает типы, разрешённые ссылки и видимость каждого символа. Разница между этими двумя подходами не абстрактная, она измеряется в конкретных цифрах.

Точка отсчёта: почему grep и RAG промахиваются

Кодовый агент ищет по проекту двумя способами: grep/ripgrep по содержимому файлов и векторный поиск по эмбеддингам кусков кода. На маленьком проекте оба варианта работают сносно. На enterprise-репозитории на миллионы строк с десятками модулей поведение ломается одинаково: запрос «найди использования метода validate» возвращает тысячу с лишним совпадений, из которых подавляющее большинство - другие методы с тем же именем в других классах. Векторный поиск находит куски кода, которые «похожи по смыслу», но это может быть валидация в совершенно другом домене.

Что показали цифры на 27 задачах

Мы сравнили три версии агента на 27 задачах вида «найди все места, где используется метод X» из реальных тикетов трёх внутренних репозиториев на Java и Kotlin: агент на ripgrep, агент на ripgrep с векторным RAG и агент на PSI-индексе IntelliJ (find_usages, find_declaration, class_hierarchy вместо текстового поиска).

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

У ripgrep recall высокий (0,82): текстовый поиск почти никогда не пропускает совпадения по имени. Но precision низкий (0,41): больше половины найденного - чужие методы с тем же именем, и их приходится разбирать вручную. У PSI-индекса высоки обе величины (0,96 и 0,93): агент находит почти все нужные места и почти не приносит лишнего. F1 сводит обе величины в одно число, и у ripgrep он проседает именно из-за мусора в выдаче, хотя нужные места он и находит.

Отсюда пятикратная экономия контекста и в пять с лишним раз более дешёвый ответ при кратно более высокой точности: агент на PSI-индексе не читает тысячи лишних строк, которые вернул бы текстовый поиск.

Точный поиск не отменяет проверку

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

Но точный поиск снимает с агента часть ручной работы: не нужно самому перепроверять по всему проекту, все ли использования метода он нашёл - эту проверку берёт на себя IDE, как это устроено в Veai, а оставшуюся часть верификации - компилятор и тесты.

Написал новую, третью статью из серии «Как работают большие языковые модели»

Почему дорогая LLM дороже: экономика инференса, которую видно в твоём 5-часовом лимите

Что внутри ⤵️

1. Про открытые модели и почему мы используем их как пример
2. Из чего складывается цена токена
3. Про Dense и MoE архитектуры
4. Как считается attention и активные параметры
5. Total ≠ active: тренд на MoE архитектуру
6. Почему output-токены дороже input
7. Reasoning-токены как невидимый output, за который тоже приходится платить
8. Context Window и KV-cache — почему длинный контекст дорогой
9. Как посчитать вес одного токена и из чего он складывается
10. В чем разница между KV-cache и prompt caching
11. За счет чего фронтир модели стоят в разы дороже
12. Почему дорогая модель чаще всего реально «умнее»
13. Как всё это итого собирается в 5-часовой лимит

14. И как бонус — сортировка open-weight моделей по active и total

---------------

Вот две предыдущие статьи из этой же серии

• Просто и подробно о том, как работают ChatGPT и другие GPT подобные модели. С картинками. Кстати, эта статья стала одной из победителей Космотекста

• От написания промптов к проектированию контекста. Или один очень обширный материал по Context Engineering. Эта статья сложнее, чем первая, но проще, чем третья

Прочитав эту серию постов, вы станете намного лучше понимать принцип работы современных LLM и агентных систем

Как все так ловко ИИ пользуются... Обзоры кода делают...

Не знаю, то ли я туповат, то ли невезучий, то ли кругом сказочники. Пытаюсь исследовать, какие новые интересные виды ошибок может находить ИИ в С++ коде, о которых не знает PVS-Studio. Claude Opus то нормально мне про интересные баги рассказывает, то на ровном месте с ума сходит.

Даю файл на вход, а он тревожно:

В присланном файле есть места, где содержимое обрезано/повреждено вставкой </context>, поэтому их я не рассматриваю как «баги кода» — это артефакты форматирования. Разберу реальные логические ошибки.

Шо? Какой context? Там максимум — это #include "context.hxx". Ну ладно, давай ошибки посмотрим.

Так, парочка сообщений по делу. Например, найден лишний аргумент при использовании функции форматирования.

addErrorMessage(&sciErr, API_ERROR_CREATE_ZDOUBLE_IN_NAMED_LIST,
    _("%s: Unable to create list item #%d in Scilab memory"),
    "createComplexZMatrixOfDoubleInNamedList", _iItemPos + 1, _pstName);

В строке форматирования два спецификатора %s и %d, а передаются три аргумента: funcName, _iItemPos+1, _pstName. Да, это баг. Про подобные паттерны PVS-Studio уже знает, хотя, возможно, нужно подсказать, что addErrorMessage — это printf-подобная функция. В целом, тут неинтересно, идём дальше.

Ооо, и тут начинается...

checkListItemPosition — неправильное сравнение границы:

// check a valid item
if (_iItemPos > iItem)
{
    addErrorMessage(...);
    return sciErr;
}

Здесь проверка «позиция валидна» использует >, хотя позиции 1-based, а iItem — количество элементов. Это выглядит как граничный дефект, но по сути _iItemPos == iItem допустимо, _iItemPos > iItem — ошибка. Это в порядке — правильная граница. Не баг. (Указываю, чтобы было понятно, что я это проверил.)

Так баг или не баг? Я три раза прочитал текст и посмотрел функцию с кодом. В итоге я не только не понимаю, есть ли здесь ошибка, но и не понимаю, что Claude пытается мне сказать.

Дальше ещё хуже шарики за ролики зашли.

Баг 5 (реальный): утечка в readCommonMatrixOfPolyInNamedList и др. — нет, это API отдаёт указатели наружу. Не баг.

Это всё описание пятого бага, больше ничего нет. Комментировать — только портить.

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

На сегодня мне ИИ достаточно. Пойду лучше пройдусь по парку, пока погода хорошая.

Fable 5 вернули в Claude Code. Как не сгенерировать себе техдолг

Fable 5 снова доступен в Claude, и это хороший повод вернуться к более практичному вопросу: что именно делать разработчику с Claude Code, кроме генерации отдельных кусков кода.

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

21 июля в 20:00 на бесплатном уроке разберём, как использовать Claude Code в разработке ИИ-приложений: от Telegram-ботов и агентов до внутренних сервисов, API и автоматизаций. Отдельно поговорим о работе с большими задачами — как дробить их на этапы, вести разработку итерациями, дорабатывать код и находить ошибки. Присоединяйтесь.

Все июльские разборы по ИИ, разработке, архитектуре и инфраструктуре собрали в дайджесте мероприятий.

Вышла бесплатная книга к курсу «SQL Введение»

Всем привет!

Недавно я публиковал здесь бесплатный курс «SQL Введение» на платформе Stepik. За это время курс уже начали проходить более 400 студентов.

В продолжение курса я подготовил ещё один бесплатный материал — книгу, которая поможет изучать SQL ещё удобнее.

Бесплатный курс: https://stepik.org/a/290855

Зачем появилась книга

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

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

Что представляет собой книга

Книга полностью соответствует программе курса и может использоваться параллельно с его прохождением.

Её можно использовать как:

• офлайн-версию курса для повторения материала;

• удобный конспект при выполнении практических заданий;

• справочник для быстрого повторения основных конструкций SQL.

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

Для кого она будет полезна

Так же, как и сам курс, книга ориентирована на тех, кто только начинает знакомство с SQL:

• студентов IT-специальностей;

• начинающих разработчиков;

• будущих аналитиков данных;

• тестировщиков;

• всех, кто хочет разобраться в основах работы с реляционными базами данных.

Бесплатный доступ

Книга распространяется бесплатно.

Если вы проходите курс «SQL Введение», она уже доступна внутри курса в качестве дополнительного учебного материала.

Кроме того, книга опубликована на GitHub, где всегда можно скачать последнюю актуальную версию.

https://github.com/Awilum/sql-introduction

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

https://github.com/Awilum/sql-introduction/releases

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

Нарезка кода: что скрывает OrcaSlicer

Как не пропустить опасные участки кода при ревью? Можно воспользоваться инструментами статического анализа. Возьмём для примера OrcaSlicer — популярную программу, которая подготавливает 3D-модель к печати. Заглянем внутрь и посмотрим, какие сюрпризы нас ждут.

Посмотрим на одно из предупреждений статического анализатора PVS-Studio:

V1047 Lifetime of the lambda is greater than lifetime of the local variable ‘do_stop’ captured by reference. FillBedJob.cpp 250

void FillBedJob::process(Ctl &ctl)
{
  // ....
  bool do_stop = false;
  // ....
  params.on_packed = 
    [&do_stop] (const ArrangePolygon &ap)
    {
      do_stop = ap.bed_idx > 0 && ap.priority == 0;
    };
  // ....
}

Лямбда-выражение захватывает локальную переменную do_stop по ссылке, а затем сохраняется в params.on_packed. При этом do_stop уничтожается при выходе из метода process, так как заканчивается время жизни локального объекта. Если лямбда будет вызвана после выхода из этой функции-члена, произойдёт обращение к разрушенному объекту, и поведение в этой ситуации не определено.

Можно было бы сделать захват по значению, но в этой лямбде происходит перезапись переменной do_stop, а значит такой вариант не подходит. Поэтому можно сделать do_stop членом класса FillBedJob.

Это лишь один фрагмент, показывающий, что даже в работающем продукте могут быть ошибки. А другие опасные места в коде OrcaSlicer разобрали в новой статье.

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

Листая на C++ Reference список принятых в C++29 фичей, увидел в нем пропозал с знакомым названием, «Thread attributes» (P2019R9). И, оказалось, действительно, я уже читал этот пропозал 4 года назад, но не в 9-й его редакции, а в самой первой. 4 года понадобилось комитету по стандартизации, чтобы принять пустячный пропозал, позволяющий задать имя и размер стека потока при его создании — востребованную фичу, реализованную в куче библиотек C++.

void f();
int main() {
  // Такой вид задания атрибутов предлагался в первой ревизии
  std::jthread P2019R1(
    f, std::thread_name("Worker"),
    std::thread_stack_size(512*1024));
  // А такой приняли 8 ревизий спустя
  std::jthread P2019R9(
    std::thread::name_hint("Worker"),
    std::thread::stack_size_hint(512*1024), f);
}

Не безумие ли это? И сколько действительно правильных пропозалов не вошло в C++ лишь по той причине, что их автор не был готов 4 года подряд защищать свое предложение, отвечая на все мелкие придирки различных подкомитетов?

18 бесплатных уроков недели: разработка, AI, тестирование и DevOps

На этой неделе в OTUS — серия бесплатных открытых уроков для разработчиков, архитекторов, тестировщиков, DevOps‑инженеров, аналитиков и руководителей технических команд.

В программе — Spring и Java, C++ и Linux, GitLab CI, тестирование, мобильная разработка, сетевые технологии, машинное обучение и практическое применение ИИ.

Какие темы запланированы:

Backend и разработка

• 29 июня, 20:00 — «Как работает @Transactional в Spring: границы транзакций и типовые ошибки». Записаться

• 1 июля, 20:00 — «Алгоритмическая сложность коллекций в Java». Записаться

• 2 июля, 20:00 — «Методы, их перегрузка и расширения». Записаться

C++ и системное программирование

• 30 июня, 20:00 — «RAII в C++: фундамент надёжного управления ресурсами». Записаться

• 1 июля, 20:00 — «Классические методы перехвата управления в Linux». Записаться

• 2 июля, 20:00 — «Всё, что нужно знать об управлении памятью в C++». Записаться

AI, ML и автоматизация

• 29 июня, 20:00 — «Обзор ИИ‑технологий для разработчиков: от идей до рабочих решений». Записаться

• 29 июня, 20:00 — «Использование ИИ архитектором 1С: как ускорить анализ требований и подготовку документации». Записаться

• 29 июня, 20:00 — «AI для работы с обратной связью: как анализировать отзывы клиентов, интервью и обращения в поддержку». Записаться

• 1 июля, 18:00 — «Градиентный бустинг — мощный алгоритм ансамблирования в ML». Записаться

• 1 июля, 20:00 — «Архитектурные паттерны AI‑агентов: как проектировать автономные решения для бизнес‑задач». Записаться

• 6 июля, 20:00 — «Как сделать LLM‑приложение, которое отвечает клиентам по базе знаний компании». Записаться

Инфраструктура и DevOps

• 30 июня, 20:00 — «GitLab CI как конструктор workflow». Записаться

• 1 июля, 20:00 — «Что нужно знать для настройки стабильного интернета? OSPF и протоколы динамической маршрутизации». Записаться

Mobile и тестирование

• 30 июня, 20:00 — «Тестирование UX для мобильных приложений: чек‑лист по основным проверкам». Записаться

• 2 июля, 20:00 — «От API до экрана: создаём Android‑приложение на рекомендуемой архитектуре». Записаться

• 2 июля, 20:00 — «REST Assured & JSON Schema Validator: автоматизация тестирования API на практике». Записаться

Зерокодинг

• 2 июля, 20:00 — «Магия Lovable: как создавать готовые интерфейсы с помощью одного запроса». Записаться

А если хотите углубиться в инфраструктуру, сети и DevOps, смотрите подборку материалов в дайджесте.

Пока писал статью про Context Engineering, то дополнительно решил изучить вопрос, который был на хайпе 3 месяца назад

Реально ли Caveman Output Style экономит токены для агентов

Суть

Несколько месяцев назад расхайпилась казалось бы очевидная идея: если заставить модель отвечать коротко, то можно сэкономить много output-токенов

Одна таких реализаций — репо Caveman, который заставляет модель говорить как пещерный человек. Целых 77к звезд

Вот как пример

Обычный ответ модели

The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow comparison sees it as a different object every time, which triggers a re-render. I'd recommend using useMemo to memoize the object

Ответ в стиле Caveman

New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo

Ну и как следствие, обещания автора

Faster response — less token to generate = speed go brrrEasier to read — no wall of text, just the answerSame accuracy — all technical info kept, only fluff removedSave money — ~71% less output token = less cost

Этот репозиторий очень сильно расхайпился — и основная суть всех новостей была в том, что с этим стилем теперь можно тратить на 40-70% меньше output токенов — который самые дорогие

Чтобы лучше понять механизм потенциальной экономии, нужно посмотреть, где агентные системы по типу CLAUDE CODE | CODEX вообще генерируют OUTPUT токены

1. Обычный ответ, который видите вы
2. THINKING блоки, которые вы можете не видеть
3. Генерация кода / схем, которые нельзя сжать
4. Вызов Tools + Цикл tool call → result → next message

В случае выбора любого OUTPUT стиля мы влияем только на пункт 1 — Обычный ответ, который видите вы

И, насколько мы все тут знаем — то, что модель выдает нам как результат ответа — в среднем ~5-10% от всех OUTPUT токенов

Ну так вот

Я по приколу сделал мини эксперимент, где взял 3 варианта Output Style's и прогнал на 5 разных задачах

1 стиль — Caveman Light (Original skill из репозитория выше)
2 стиль — Explanatory. Стиль, который наоборот, старается объяснять как можно подробнее. Я его сам всегда использую — объясняет свои решения и делится инсайтами.
3 стиль — Самописный True Caveman. Который должен общаться прям как настоящий пещерный человек

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

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

Ссылка на статью на сайте, там подробно про этот эксперимент и реально ли это что-то экономит

Я несколько дней на это потратил 🥺

РБПО по ГОСТ Р 56939—2024: вебинар №27 из 30 — PVS-Studio Atlas — новая платформа контроля качества кода

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "PVS-Studio Atlas — новая платформа контроля качества кода". На YouTube. Слайды.

В ходе бонусного вебинара команда PVS-Studio представила новый продукт — PVS-Studio Atlas, предназначенный для работы с результатами анализа кода: просмотра, аналитики, разметки и формирования отчётов для сертификационных лабораторий и ФСТЭК.

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

PVS-Studio — статический анализатор кода для поиска критических и типовых ошибок

Также приглашаю всех познакомиться с нашим статическим анализатором PVS-Studio, который может закрыть не только 10-й процесс ГОСТ Р 56939, но и будет полезен по другим направлениям:

1. Обучение сотрудников (п.5.2). Формирование у программистов понимание антипаттернов и уязвимых конструкций, что улучшает их техническую экспертизу;

2. Моделирование угроз и разработка описания поверхности атаки (п.5.7). Дополняет процесс, выявляя потенциальные уязвимости, которые формируют поверхность атаки;

3. Экспертиза исходного кода (п.5.9). Позволяет усилить проверку стороннего кода, который команда включает в проект. Например, его можно использовать для выбора сторонних библиотек, оценивая качество их кода;

4. Поиск уязвимостей в программном обеспечении при эксплуатации (п.5.24). Можно просматривать ранее отключённые предупреждения PVS-Studio с целью дополнительного выявления дефектов в коде.

Скачать PVS-Studio.

Основные характеристики:

• Поддерживает: C, C++, C#, Java, (скоро Go, JavaScript, TypeScript).

• Совместим с ГОСТ Р 71207—2024 (Статический анализ кода).

• Может применяться для РБПО согласно ГОСТ Р 56939—2024.

• Включён в Реестр российского ПО: запись № 9837.

• Удовлетворяет требованиям к статическим анализаторам, приведённых метеорическом документе ЦБ "Профиль защиты" – Статический анализ кода в методическом документе ЦБ РФ "Профиль защиты".

• Полная информацию: Статический анализатор кода PVS-Studio в 2026: ГОСТ Р 71207, ГОСТ Р 56939, приказ ФСТЭК №117.

Бэкенд без слепых зон: 10 открытых уроков для разработчиков

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

Собрали бесплатные открытые уроки для бэкенд‑разработчиков разных стеков. Преподаватели‑практики покажут рабочие подходы, разберут типовые ошибки и ответят на вопросы. Заодно можно познакомиться с экспертами и проверить формат обучения OTUS.

Архитектура и взаимодействие сервисов

• 22 июня, 20:00. «OAuth 2.0, JWT и коварные куки: проектируем безопасную аутентификацию». Записаться

• 24 июня, 20:00. «RabbitMQ против Kafka — что выбрать для вашей структуры: сравнение и лучшие практики». Записаться

• 24 июня, 20:00. «Отказоустойчивый и высокодоступный кластер RabbitMQ». Записаться

Java и Spring

• 22 июня, 20:00. «Контейнеризация Java-приложений с Docker». Записаться

• 29 июня, 20:00. «Как работает @Transactional в Spring: границы транзакций и типовые ошибки». Записаться

• 1 июля, 20:00. «Алгоритмическая сложность коллекций в Java». Записаться

• 22 июля, 20:00. «DAO на Spring JDBC». Записаться

.NET и Go

• 18 июня, 20:00. «Хостинг ASP.NET Core изнутри». Записаться

• 25 июня, 20:00. «Кеширование в ASP.NET Core: от IMemoryCache до Redis». Записаться

• 8 июля, 20:00. «Чистая архитектура на Go без "карго-культа": слои, DTO и интерфейсы». Записаться

Выбирайте тему под свой стек и подключайтесь к открытым урокам.

Больше бесплатных открытых уроков по другим направлениям смотрите в нашем дайджесте.

GLM 5.2 в open source: модель уровня Claude Opus 4.7, которую негде запустить, пока негде.

Zhipu выложили веса GLM 5.2 под MIT лицензией. 744 миллиарда параметров, MoE, 40 миллиардов активных на токен, контекст на миллион. GLM-5.2 играет достойно на многих бенчмарках.

Дома не запустить. FP8 веса ~800 гигабайт, нужно минимум 8 карт H200 или 10 карт H100. Теперь про abliteration, потому что в этом вся суть.

Любая западная модель отказывает вам по десять раз на дню. Напиши эксплоит для пентеста: отказ. Проанализируй уязвимость по CVE: отказ. Разбери вредоносный код из лога: отказ. Безопасники и разработчики каждый день упираются в стену цензуры и делают руками то что нейросеть могла бы закрыть за секунды.

Abliteration это удаление цензурных слоёв из модели. Модель перестаёт решать за вас что можно а что нельзя. Для моделей поменьше энтузиасты делают это за дни. Для 744B монстра уйдёт пара недель, но результат появится на Hugging Face неизбежно. MIT лицензия, веса открыты, технически ничего не мешает. Вопрос кто первым поставит под эту версию железо и откроет API.

Считаем деньги.

Huawei Ascend, легальный путь. Чип 910B: ~110 тысяч юаней (~1.4 млн рублей), нужно 16 штук (два сервера Atlas 800, ~1 ТБ видеопамяти). Итого 55-90 млн рублей. Производительность 60-70% от NVIDIA, зато без санкционных рисков.

NVIDIA H100, серый путь. Карта ~3.3 млн рублей, 10 штук с обвязкой: 40-50 млн. Быстрее, но риски поставки и нет гарантии.

Операционка: ~1-1.5 млн рублей в месяц (локация, электричество, инженеры).

Кто заплатит. Корпорации, которым нельзя лить данные в западные API: выделенный сервер с abliterated моделью, договор с юрлицом, ответственность на клиенте. Разработчики и физлица: публичный доступ, базовый тариф с обычной версией, премиум с abliterated после верификации.

Для российского рынка это окно. Ни один провайдер в РФ пока не даёт доступ к abliterated модели такого уровня. Что думаете?

Вот такую работу предлагает Райфайзен для Java-разработчиков с опытом от 3 лет. И как это теперь развидеть? 😎

От падающего теста до правки: как General ведёт задачу в любимой IDE

Когда разработчик открывает AI-чат в IDE, он не думает категориями режимов. Он не формулирует задачу как «сначала Plan, потом Code, затем Test и Review» — он пишет проще:

Почини тест

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

Под этот сценарий в Veai сделан режим General: вы описываете цель обычными словами, а агент сам выбирает маршрут — проход по коду, планирование, тесты, ревью, отладка или подключение субагентов. Специализированные режимы (Ask, Code, Test, Plan, Review, Debug) остаются для случаев, когда вы хотите управлять процессом явно.

Почему ручной выбор режима мешает

Реальная задача редко укладывается в один режим. «Исправить падающий тест» — это сразу несколько подзадач: понять причину, решить, где ошибка (в тесте, production-коде, моках, данных или окружении), внести правку и запустить проверку. Если режим нужно выбрать заранее, новый разработчик начинает не с решения проблемы, а с изучения классификации агентов. General убирает этот выбор из начала задачи.

Что происходит по шагам

На запрос «в сервисе оплаты падает тест, найди причину и почини» General в простом случае ведёт задачу сам:

1. находит и запускает тест через IDE run configuration — в том же окружении, что и разработчик (SDK, профиль, переменные, модули), а не в собранном из терминала, которое может отличаться;

2. читает стектрейс, открывает связанный production-код, при необходимости смотрит usages, warnings и inspections;

3. вносит минимальную правку и перезапускает проверку: тест прошёл или упал — это факт из IDE, а не предположение модели.

Если стектрейса не хватает, агент опирается на отладчик (breakpoints, значения переменных, call tree), а если стектрейс уводит в библиотеку — открывает её код или декомпилированный класс через IDE, а не угадывает API по памяти модели.

Когда подключаются субагенты

Маршрут выбирает не отдельный классификатор, а сама модель: по тексту задачи и первым фактам из проекта она решает, достаточно ли пройтись по коду или стоит разложить работу на субагентов (один исследует причину, второй — зависимости, третий — тесты). Поправить одну строку General сделает сам, большую задачу — распараллелит. Многоагентность здесь не самоцель, а инструмент для задач, где она реально ускоряет результат.

Полностью исключить ошибки модели нельзя. Но General опирается не только на LLM, grep и RAG, а на JetBrains IDE как на источник проверяемых фактов: run configurations, SDK и classpath, структуру кода, usages и inspections, coverage, код зависимостей и ошибки компиляции так, как их видит IDE. Отсюда меньше галлюцинаций API и ситуаций «у агента прошло, а в IDE или CI падает».

Разницу можно измерить. 

Мы прогнали 8 enterprise-задач на Java/Spring через четыре агента на одной модели — Cursor, Claude Code, JetBrains Junie и Veai:

Контроль остаётся у разработчика

Даже когда агент ведёт задачу автономно, последнее слово за человеком: разработчик смотрит diff в окне Agent Changes и решает, что принять. Перед этим General может сам прогнать несколько субагентов-ревьюеров по своим изменениям и устранить критические проблемы ещё до того, как покажет результат человеку, — авторевью встроено в маршрут, а не остаётся отдельным ручным шагом. Идея не в том, чтобы убрать review, а в том, чтобы убрать лишнюю ручную маршрутизацию до него.

Установить Veai 5.12

Обратная связь — support@veai.ru и чат с командой.