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

Эпоха AI. Бюджет выделен, ждём чуда.

Рынок в РФ наконец дозрел до массового внедрения корпоративных AI-подписок. Бюджеты на Claude/Codex становятся чуть ли не обязательными. И почему-то все ждут, что продуктивность резко увеличится.

Главная проблема - никто не знает, как ИИ влияет на продуктивность. А еще никто не знает как это достоверно оценить. К примеру в исследовании METR в июле 2025 получили ухудшение продуктивности. Существует много исследований, все с очень разными результатами.

И правда, как измерять-то? Влияет проект, задача, стек, промпты, даже время суток (не шучу). Модели ведут себя по-разному, спецификации отличаются, контекст меняется. Все используют разные инструменты и по-разному. Насколько сильно влияют скиллы разработчика? Знание проекта? Документация? Язык общения? На одной задаче мы могли ускорится в два раза, на другой - протупить дополнительно 2 дня. В каждом аспекте полная неизвестность, помноженная на неизвестность.

Ну и относительно какого периода считать прирост? Тут тоже вопрос без ответа. Многие используют ИИ инструменты аж с 2022 года. Значит нужно собирать статистику с 2021. Но там и технологии были другие, и разработчики, и подходы, и задачи... Объективно ли? Нет. Но 2024 за baseline тоже взять нельзя, тогда уже многие сидели на личных подписках. Но бизнес всё же приходит и говорит: мы выделили бюджет на AI, ждём от вас взрывного роста продуктивности. В два, в три, в пять раз! Как в Майкрософт! Как в Фейсбуке!

Но ведь у многих производительность реально растёт! Правильно. Если тебе менеджер по десять раз на дню пишет про твой статус, режет оценки и торопит - можно и правда ненадолго ускориться. ИИ тут не при чем. Методология "галеры" однозначно работает. Только ни один адекватный разработчик в таком месте долго не задержится.

Впереди много интересного. Будут и хорошие решения, будут и глупые. Всё это постепенно сформирует новые процессы, подходы и метрики. Когда-то ведь впервые появился Git, доски, нормальные фреймворки. И каждый раз сначала был безумный культ, потом разочарование, только потом взвешенный подход, на котором и держится вся реальная польза. Технологии не остановишь, так что нам с вами придется пройти этот путь. Хотим мы этого или нет 🫢

На сайте Hacker News завязалось любопытное обсуждение. Пользователь поделился опытом: в крошечной базе данных на 15 тысяч записей случилась коллизия UUIDv4. Приложение генерировало идентификаторы через uuid, популярный пакет npm, база имела ограничение UNIQUE, и однажды новая запись пришла с тем же UUID b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, что уже лежал в таблице с прошлого года.

Если что, то в этом плане у UUID должен быть полный иммолейт импрувед: вероятность такого события крайне мала. У 128-битного UUIDv4 122 случайных бита, то есть шанс попадания нового UUID в один из уже 15 000 существующих равен примерно один к 3,5 × 10³². Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.

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

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

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

РБПО по ГОСТ Р 56939—2024: вебинар №11 из 30 – Динамический анализ кода программы

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.11. – "Динамический анализ кода программы". На YouTube. Слайды.

Цели 11-го процесса по ГОСТ Р 56939—2024:

Обнаружение недостатков и уязвимостей в коде ПО в процессе его выполнения.

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

Написал большую статью на Habr — От написания промптов к проектированию контекста. Или один очень обширный материал про Context Engineering

Полезно всем, кто работает с агентами Claude Code | Codex 🍦

Что внутри

Context rot и reasoning shift — почему длинный контекст это плохо

Типы Attention и как считается сложность в современных трансформерах

Из каких 7 слоёв состоит контекст Зачем нужен CLAUDE.md / AGENTS.md / GEMINI.md
Что такое MEMORY.md Секция про Skills, MCP, Subagents

Архитектура AGENTS LOOP

Как работает Prompt caching Как считается стоимость токенов

Что отличает Новичка от Мастера в работе с современными агентами

А какие там иллюстрации, мммм

А завтра онлайн в 18 мск буду читать лекцию по этой статье, залетайте послушать https://calendar.app.google/TDm1ZZusNtX5w394A

Дорожная карта Agentic AI. Level 4. Мастер примеров — few-shot и structured output

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

Где это реально работает

Лучше всего на задачах, которые повторяются и где у вас есть эталонные примеры. Берёте классификацию обращений клиентов: показали модели пять размеченных примеров, и она начинает раскладывать новые обращения по тем же категориям. Извлечение реквизитов из писем, парсинг характеристик товаров, разметка отзывов по тональности — всё это ложится на few-shot.

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

Три уровня, которые нужно понимать

Чтобы не гадать самим, нужно понимать разницу между режимами. На одном конце zero-shot: только инструкция, без примеров; на мощных моделях для простых задач часто хватает и этого. One-shot добавляет один эталонный образец и полезен, когда важен точный формат ответа. Ну а few-shot это уже от двух до десяти примеров; на практике 3–5 штук оптимум, потому что меньше даёт мало сигнала, а больше добавляет шум и лишние токены. Хорошую базу по технике даёт Prompting Guide, а про подход Claude подробнее в документации: multishot-prompting.

Что класть в примеры

С количеством разобрались. Сложнее вопрос качества: что именно должно быть внутри каждого примера. Основа это пара «вход → выход» без лишнего контекста и специфики конкретного случая, которая только шумит. Если задача нетривиальная, хорошо добавлять hints — короткую подсказку с логикой решения, почему именно такой ответ. И почти всегда работают анти-примеры: «так делать не надо, вот почему» — они помогают модели понять, где проходит граница.

Почему без structured output это бесполезно в бизнесе

Но даже с хорошими примерами остаётся вопрос: куда девать результат. В продакшене нужен не текст, а JSON строго по схеме: category: "техподдержка", priority: "высокий", responsible: "техотдел". Чтобы результат сразу ушёл в CRM, в базу, в следующий сервис: не придётся разбирать свободный текст руками. Примеры для few-shot делайте сразу в этом формате: так модель быстрее схватывает нужную структуру. Документация: OpenAI Structured Outputs, Claude Structured Outputs.

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

По опыту, хорошие примеры в паре со structured output закрывают без файнтюна и без ML-команды огромный пласт задач на извлечение, разметку и классификацию.

Разобрали продвинутый few-shot на реальном кейсе: смотрите видео.

🔔 Следующая тема: RAG и векторные базы — как передать агенту знания о вашем бизнесе.

⬅️ Предыдущая тема: Level 4. Своя кузница — локальный запуск моделей

Подписывайтесь, пожалуйста, чтобы не пропустить!

Больше про ИИ — в ТГ-канале и ВК. Каталог наших курсов, услуг и кейсов по ИИ-агентам. По вопросам — пишите в личку.

💥 💥💥 Новое в Gramax 💥💥💥

Breaking change

• Представление каталога. Фильтр каталога заменили на представления — функция вышла из экспериментального режима. Теперь вместе с фильтрацией статей можно задавать переменные: одна статья показывает разный контент без создания копий.

• ⚠️ Автомиграции нет. Если был настроен фильтр — добавьте его заново через панель представлений.

Gramax Enterprise Server

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

• Фильтрация метрик по каталогу. На страницах метрик добавили фильтры: в отчете по просмотрам — по каталогу, пользователям и типу, в отчете по поиску — по каталогу.

• Улучшения настройки проверок по стайлгайду:

  • Правила отображаются таблицей, редактор открывается в боковой панели.

  • При первом запуске загружается готовый набор правил — можно адаптировать под команду.

  • Правила можно экспортировать — поделиться или сохранить копию.

  • Запуск тестов правил доступен для каждого правила.

Общие изменения

• Свойства вкладок. Можно назначать свойства каталога — управлять видимостью в разных представлениях. Также обновили внешний вид вкладок.

• Сортировка и фильтрация таблиц. Сортировка по нескольким столбцам и фильтрация по значениям. Параметры сохраняются со статьей — удобно для больших таблиц.

• Фрагменты вместо сниппетов и ссылки с превью. Сниппеты переименованы во фрагменты. Теперь можно ставить ссылки на фрагменты прямо из текста: при наведении — превью, удобно для глоссария.

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

• Версионирование в редакторе. Теперь можно переключаться между версиями прямо в редакторе, а не только настраивать их.

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

• Навигация по OpenAPI. Для OpenAPI-спецификаций в правой панели доступна навигация по методам API — можно перейти к нужному без прокрутки.

• Улучшения поиска:

  • Поиск внутри папки ограничен ею по умолчанию. При необходимости переключитесь на По всем каталогам.

  • Поиск учитывает полный путь в навигации: статью Вклады / До востребования найдете по запросу Вклад до востребования.

  • Результаты из одной диаграммы объединяются в один блок.

  • Добавлен пункт (пусто) для статей без значения, пункт (выбрать все) сбрасывает фильтр.

• Улучшения и стабилизация:

  • Перетаскивание статей и разделов в левой панели ускорили в 10 раз.

  • Если Git-сервер недоступен, приложение переходит в офлайн-режим. Вернется автоматически, когда сервер станет доступен.

  • Обновили тулбар редактора. Элементы сгруппированы по категориям, списки открываются по клику.

  • Подсветка текста адаптирована под темную тему.

Подробнее: https://gram.ax/resources/docs/whats-new

Дорожная карта Agentic AI. Level 4. Своя кузница — локальный запуск моделей

Не всё имеет смысл отдавать в облако. Причин у этого как минимум три:

1. Приватность. Стоит начать пересылать в чужой API персональные данные клиентов, внутреннюю переписку или код с коммерческой тайной, как логи стороннего провайдера превращаются из абстрактной строчки в SLA во вполне конкретный риск утечки. Локальная модель эту головную боль снимает: данные просто не покидают периметр компании, и обсуждать с безопасниками становится по сути нечего.

2. Автономность. Когда провайдер прилёг, сети легли или вашему региону внезапно прикрыли доступ, локальный агент этого даже не заметит и продолжит работать, как ни в чём не бывало.

3. Стоимость. Здесь всё упирается в масштаб. Если вы просто экспериментируете у себя на ноутбуке, локальный запуск получается полностью бесплатным: ни подписок, ни платы за токены, и докупать ничего не придётся, всё поедет на том железе, что уже стоит на столе. Когда же речь идёт про нагруженный прод, картина меняется: нужен сервер с GPU, и экономика там сходится не сразу. На сотнях запросов в день локальный инференс вряд ли отобьётся, а вот на десятках тысяч он уже выгоднее облака.

Что вообще получится запустить

Проприетарные модели уровня GPT-5, Claude Opus 4.7 или Gemini 3.1 локально вы, конечно, не запустите: они закрытые и слишком огромные. Зато опенсорс быстро подтягивается следом. Qwen3 от Alibaba, DeepSeek R1 и V3.1, Mistral Small и Magistral это вполне рабочие модели, которые в квантизованных версиях помещаются на одну видеокарту. Даже OpenAI в прошлом году выложила свою открытую gpt-oss, сразу в 20B и 120B параметров.

Чем крутить локально

Проще всего начать с Ollama: ставится одной командой, ещё одной скачивается модель, и всё. Никаких плясок с CUDA, Python и зависимостями, из коробки есть и GUI, и REST-API. Если хочется чего-то более «приложенческого», посмотрите в сторону LM Studio или Jan; у LM Studio при этом есть приятная мелочь: она ещё до скачивания подскажет, хватит ли у вас ресурсов на конкретную модель.

Как встроить в свой код

Самое важное даже не в том, как удобно поднять модель у себя, а в том, что интегрировать её в код ваших приложений так же легко, как сменить провайдера. У всех этих инструментов OpenAI-совместимый API, поэтому в клиенте OpenAI достаточно поменять base_url с облака на localhost, и тот же самый код из прошлых постов продолжит работать без единой правки.

Что брать в продакшен

Эта связка работает, пока вы экспериментируете на ноутбуке. В продакшене ставки выше: опенсорс-модель надо крутить под реальной нагрузкой, и стандарт здесь это vLLM. Он оптимизирован под высокий RPS и параллельный инференс, реально выжимает из GPU всё, что она способна отдать.

Вообщем, не относитесь к локальному запуску, как к большому инфраструктурному проекту. На практике это один спокойный вечер экспериментов: поставили Ollama, скачали Qwen3, поменяли base_url в агенте и погнали…

🔔 Следующая тема: Few-shot learning, как учить модель прямо в промпте.

⬅️ Предыдущая тема: Level 4. Новые чувства — мультимодальность

Подписывайтесь, пожалуйста, чтобы не пропустить!

Больше про ИИ — в ТГ-канале и ВК. Каталог наших курсов, услуг и кейсов по ИИ-агентам. По вопросам — пишите в личку.

ИИ: Гонки на лафетах

Всего лишь иллюстрация. Примерно год-полтора назад решил я выбрать - deepseek или chatgpt. И выбрал deepseek. Однако через некоторое время стал обращать внимание не его лютый подхалимаж, что, кстати, не раз уже обыграли в различных мемах. Не в отношении deepseek, а относительно AI в общем.
Проблему обсудил и с deepseek, и с windows copilot (chatgpt был благополучно забыт). Deepseek стал подхалимски юлить, мол да, copilot хорош и все такое. Copilot же оправдал Deepseek - мол это такая технология поддержки энтузиазма в клиенте. Между прочим тонко намекнув, что сам-то он лучше и глубже. Но это присказка, сказка впереди.
В процессе завершения разработки обертки над EntityFramework попросил оценить проект сразу четверых: deepseek, copilot, chatgpt и grok. Результат ожидаем - сыровато, но в продакшн годно, оценки 4.5/5 и 7/10.
Претензии разные, существенных практически не было, но в одно они уперлись хором - "тяжелые" интерфейсы. Подробности опущу, это было семейство generic-интерфейсов со многими типами. Что-то вроде IInterface(T1), IInterface(T1,T2) и так далее, пока не надоест.
Несколько итераций я эти наезды игнорировал, но AI не унимались. Уже и оценки до 9/10 дошли, но проблема-то осталась.
Вспылил и написал письмо на полстраницы, начинавшееся фразой "Господа AI !". Концептуальное. Гневное. Циркулярное И получил ответы:
- ООО! Мы все поняли. Гениально, единственно верное решение.
Это deepseek 5/5 и copilot 10/10.
- Нуу... Проблема решена, но способ так себе... в общем 9/10 и есть гораздо лучшие альтернативы, рассмотрим?
Это chatcpt и grok. И что характерно, альтернативы предлагают разные, по паре штук каждый. Рассмотрим, конечно.

Это просто зарисовка не о разработке обертки, а о различных системах AI.

UPD: Забыл добавить - deepseek еще и извинился за необоснованные оценки :)))

Я давний пользователь Geeknote - это cli для Evernote. Несколько лет назад проект застрял на втором Питоне - и никто не хотел его портировать на третий. Я ждал что кто-то займётся этим - но пришлось самому - так что я форкнул, починил, и даже связался с Виталием Роденко - одним из создателей Geeknote и администратора на PyPI, чтобы получить право туда пушить. За десяток лет я видел как Geeknote переходил из одни руки в другие - и как он забрасывался, и через несколько лет находился новый мантейнер. Было забавно осознать, что теперь и я стал мантейнером программного продукта, который всегда установлен на все мои машины.

Как и большинство из нас, я стал пробовать LLM - как замену поиску, для анализа кодов, советов, и вот наконец - несколько проектов - даже не читая кода - только давая команды и тестируя результат. Известная шутка - переписать на Rust. Почему бы у нет - Geeknote не велик - около пяти тысяч строк на Питоне, что я и попробовал - через Codex gpt-5.5. Несколько десятков итераций, "добавь это", "добавь то", "пропали теги", "пропала анимация" - и за несколько часов я получил рабочий Geeknote на Rust, назвал его reeknote.

Результат: быстрее работает, раза в два. Теперь буду им пользоваться.

P.S.: CLI хороши для перфоманса, SSH, быстрее разработка без GUI, а ещё похоже и для LLM - можно попросить сохранить ответ в Evernote. Как и прочие интеграции, в том числе в скриптах.

Дорожная карта Agentic AI. Level 4. Новые чувства — мультимодальность

Пора научить агента видеть и слышать. Клиент не присылает аккуратный промпт — он кидает фотку накладной, скрин ошибки, голосовое на 40 секунд.

Картинки

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

Где выбирать модель: artificialanalysis.ai/evaluations/mmmu-pro — 180+ моделей по MMMU-Pro (изображения, документы, диаграммы, схемы). Сейчас лидирует Gemini 3.1 Pro Preview.

Транскрибация

Модель слушает аудио и возвращает текст — с пунктуацией, языком, таймкодами, и если надо — с разделением по спикерам.

Где выбирать: artificialanalysis.ai/speech-to-text — 50+ провайдеров, WER + скорость + цена в одной таблице. Лидер по точности — ElevenLabs Scribe v2 (2.3% WER), из мультимодальных — Gemini (2.9%), gpt-4o-transcribe — 4.1%, Whisper large-v3 — ~5%.

Видео

Модель понимает видео как поток событий во времени — что происходило, в каком порядке, что изменилось. Это не то же самое, что покадровый Vision: там вы нарезаете файл на картинки и отправляете как набор фото — модель не понимает движения и временной связи между ними.

Где выбирать: benchlm.ai/benchmarks/videoMmmu. Нативно видео обрабатывает только Gemini — до часа или ссылка на YouTube. Остальные — только покадровый Vision.

Как вызывать

Картинки — универсальный OpenAI-формат, работает везде. image_url в чат-запросе принимают OpenAI, Anthropic, Gemini, Qwen, Grok. Один и тот же код, разный base_url и api_key.

Транскрибация — многие провайдеры поддерживают OpenAI-формат: напрямую /v1/audio/transcriptions или input_audio через /v1/chat/completions). Но у лидера ElevenLabs Scribe v2: собственный SDK, не совместим с OpenAI-форматом

Видео — тут единого API нет. У OpenAI видеофайл в Chat Completions не принимается. Gemini поддерживает видео-понимание через нативный API.

🔔 Следующая тема: локальный запуск — когда Ollama или LMStudio лучше облачного API.

⬅️ Предыдущая тема: Level 3. Первые артефакты — LLM API и структурированный вывод

Подписывайтесь, пожалуйста, чтобы не пропустить!

Больше про ИИ — в ТГ-канале и ВК. Каталог наших курсов, услуг и кейсов по ИИ-агентам. По вопросам — пишите в личку.

Вайб-кодинг и Jmix

Сидели мы как-то вечером с Курсором и подумали:

"Какой же энтерпрайз проект без пасхалки или просто встроенной игры? — Чем будут заниматься менеджеры, пока агенты делают их работу?" — Вот, держите старый добрый Сапер из Windows в виде адд-она Jmix. И это не просто браузерная игра, вставленная в экран. Причем ни строчки кода не написано руками, только сгенерил проект.

Минное поле — это gridLayout, покрытый кнопками, генерится программно в зависимости от параметров.

Весь look&feel как в оригинальном Minesweeper.

Опубликован на Maven, просто добавляйте зависимость:

implementation 'io.github.digitilius.minesweeper:minesweeper-starter:1.0.3'

Репозиторий здесь:

https://github.com/digitilius/jmix-minesweeper

Enjoy'те!

РБПО по ГОСТ Р 56939—2024: вебинар №09 из 30 – Экспертиза исходного кода

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.9. – "Экспертиза исходного кода". На YouTube. Слайды.

Цели девятого процесса по ГОСТ Р 56939—2024:

Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.

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

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

Речь не только про разработку и ИТ.  Канализация, кран, автомобиль, самокат, футбольный мячик - это применимо к любой системе физического мира.

Это применимо к подсистемам: двигатель, коробка передач в автомобиле, каталог или система заказов в e-com.

Админский контекст имеет интерфейсы и контракты, которые недоступны в пользовательском контексте. Задача админского контекста обеспечить целостность, консистентность настроек системы для корректной и непротиворечивой работы в пользовательском контексте.

К чему эта мысль?

Если для вашей системы внутри одного домена/поддомена нужно 2 админских или пользовательских контекста, то скорее всего у вас проблемы в архитектуре системы. 2 варианта:

1. разделить домены, создав тем самым два слабосвязанных домена со своими контекстами. Это сделает домены проще, их легче поддерживать.

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

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

Не дублируйте контексты для домена, это плохо кончится.

И ты, leetcode?

Вы заметили, что теперь на leetcode необходимо указать номер телефона для "обеспечения безопасности учётной записи и подтверждения личности":

Add your phone number to secure your account and verify your identity.

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

Я поискал, но сходу не нашёл официальной новости с разъяснениями. Однако, судя по комментам, некоторые пользователи довольны, считая, что эта мера поможет уменьшить количество читеров.

Что думаете? Не давать плюсовать комменты -- это, на мой взгляд, перебор.

📝 Анонс бесплатных открытых уроков на неделю: 27–30 апреля

Привет, коллеги! Традиционная подборка открытых онлайн‑мероприятий для тех, кто хочет прокачать скиллы в IT, управлении, аналитике и автоматизации. На этой неделе — фокус на архитектуру, тестирование, Computer Vision и внутреннюю кухню разработки. Всё бесплатно, но нужна регистрация.

📅 Расписание по дням

_{Понедельник, 27 апреля}

• 20:00 — «Рисуем в формате онлайн модель процесса BPMN в Camunda Modeler»

• 20:00 — «Настройка кластера Elasticsearch»

_{Вторник, 28 апреля}

• 20:00 — «Коучинговые инструменты для мотивации и повышения продуктивности команды»

• 20:00 — «Архитектура ИИ врагов в играх на Unity»

• 20:00 — «Первый нагрузочный тест в Apache JMeter»

• 20:00 — «Архитектура тестового фреймворка: от хаоса к стабильности»

• 20:00 — «Контрактные тесты в Kotlin: как подружить фронт и бэкэнд»

• 20:00 — «Фоновые задачи в Django: работа с Celery»

• 20:00 — «Как работают современные модели компьютерного зрения „из коробки“ на базе популярных библиотек и фреймворков (Hugging Face, OpenCV, YOLO, Roboflow)»

• 20:00 — «Почему только 5% компаний получили реальную выгоду от ИИ в 2025 году?»

_{Среда, 29 апреля}

• 20:00 — «Деревья решений для задач классификации и регрессии»

• 20:00 — «Свой язык на PHP за 60 минут»

• 20:00 — «Трекинг с подвижной камеры: алгоритмы и механика компьютерного зрения на роботах для индустриальных задач»

• 20:00 — «Разрешите себе карьеру технического директора»

• 20:00 — «Качество C#‑кода: от модульных тестов к системному подходу»

• 20:00 — «Продакт‑менеджер, маркетолог и PMM — в чём разница»

_{Четверг, 30 апреля}

• 19:00 — «МОК‑интервью на позицию Руководитель Проектов»

• 19:00 — «От стратегии к портфелю изменений: как архитектор связывает цели бизнеса, инициативы и архитектурные решения»

• 20:00 — «Yahoo Finance и не только — работа с российскими торговыми площадкам»

• 20:00 — «Поиск в базе знаний: где векторы ошибаются, а графы помогают»

• 20:00 — «Как управлять тимлидами?»

• 20:00 — «Битрикс24 + MAX: разработка чат‑ботов и автоматизация коммуникаций» 

• 20:00 — «Планируем внедрение DevSecOps — что следует учесть?»

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

Оптимизация контекста для Claude Code на большом проекте (иногда и 50% экономия токенов)

Работаю над большим C++ проектом - реализация сетевого протокола. Использую Claude Code как основной инструмент. Со временем заметил: каждый новый чат начинается с того, что агент долго читает README.md, который разросся до 1000+ строк и 60 КБ.

Проблема

В CLAUDE.md была прописана команда читать README.md в начале каждого диалога, агенту нужно дать контекст проекта. Пока проект был небольшим это работало нормально. Но README рос вместе с проектом и в итоге стал содержать всё: архитектуру, логику DTLS, настройки веб-интерфейса, описание протокола, инструкции по сборке.

И как результат:

• Агент тратит тысячи токенов на анализ файла до начала работы

• Если задача касается только фронтенда, модель всё равно загружает детали реализации ядра протокола. Лишний контекст снижает точность ответов.

Решение

Вместо одного большого файла использовать иерархию маленьких, в отдельной папке claude-context/:

claude-context/
├── context-claude.md       # общая архитектура и навигация (~90 строк)
├── context-AC-claude.md    # Access Controller
├── context-WTP-claude.md   # WTP Agent
├── context-WEB-claude.md   # Web Interface
└── context-TESTS-claude.md # тесты

Главный файл context-claude.md содержит краткое описание проекта и таблицу-навигатор: какой файл читать для какой области. В дочерних файлах описана детализация по модулям, каждый 100-130 строк.

Инструкция в CLAUDE.md теперь выглядит так:

“Start each new conversation by reading claude-context/context-claude.md. For deeper context on specific areas, read the relevant file from that directory.”

Агент читает главный файл (90 строк), понимает область задачи, подгружает только нужный дочерний контекст.

Замер

Чтобы проверить эффект, я поставил Claude одну и ту же задачу в двух разных конфигурациях:

“Добавь тесты для WtpConfigController и WtpRadioController, проверь что если WTP address не строка, то возникает исключение std::runtime_error”

| Параметр             | README.md (60 КБ) | Иерархический контекст | Разница  |
| :------------------- | :---------------- | :--------------------- | :------- |
| Токены на сообщения  | 36.8k             | 17.6k                  | -53%     |
| Всего токенов        | 56.7k             | 37.6k                  | -34%     |
| Рост usage за задачу | +11%              | +6%                    | В 2 раза |
| Скорость анализа     | Заметная пауза    | Почти мгновенный старт |          |

Важный момент

README.md остался нетронутым - это документация для людей. Файлы в claude-context/ - отдельный артефакт, написанный под AI: плотно, без лирики, с ASCII-схемами и таблицами. Я старался не смешивать два разных назначения в одном файле.

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

ИИ что? Проверяем Semantic Kernel

Проекты, связанные с интеграцией искусственного интеллекта, всё чаще становятся частью повседневной разработки. Один из таких проектов — Semantic Kernel. Он представляет собой SDK для построения AI-агентов и оркестрации LLM-сценариев и активно развивается компанией Microsoft.

Однако под капотом даже самых современных решений скрывается вполне обычный C# код со всеми присущими ему проблемами. Поэтому мы проверили проект и написали статью о самых интересных ошибках в коде Semantic Kernel.

Сделал необычную RTS на Ludum Dare 59 за пару дней

Игра написана на Go (Ebitengine), исходники на есть гитхабе.

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

Я накидал небольшой шаблон для игр на стеке своих геймдев-библиотек. Его можно посмотреть тут: https://github.com/quasilyte/gscene-game-template.

С этим шаблоном старт начала работы над игровой логикой и "мясом" игры становится ближе. Это позволяет +/- выйти на удобство какого-нибудь Godot, где не нужно первые несколько часов настраивать как у нас обрабатывается input, звук и сцены. Я этот шаблон буду дорабатывать по мере участия в джемах, за каждую мини-игру у меня копится TODO на то, что еще там можно было бы улучшить.

Если тема разработки игр на Go вам интересна, заходите в наше русскоязычное сообщество в телеграме. Мы там обсуждаем всякие библиотеки для геймдева, свои игры, и всё такое.

Кстати, ребята из чатика тоже сделали свои игры на Ebitengine, вот они:

• https://dqso.itch.io/hired-or-homeless

• https://metalim.itch.io/zero-day-lunch

MCP - это было очень модно (где-то год назад). Но многие до сих пор не поняли простую вещь: агент с доступом к командной строке может пользоваться любыми CLI-интерфейсами ничуть не хуже.

При этом у классических CLI есть очевидные преимущества:

- Их банально легче разрабатывать

- Они прозрачнее и понятнее в работе

- Применяться они могут не только агентами, но и людьми

- Их уже существует огромное множество под любые задачи

В Google это тоже осознали и выкатили [свой инструмент](https://github.com/googleworkspace/cli). Сделан он явно для агентов (его выпустили только в этом месяце), но это именно CLI, а не очередной MCP-сервер.

Точных фактов по этой теме пока нет. Кто-то говорит, что [в простых задачах MCP требует больше контекста, а в сложных — меньше, чем CLI, если инструменты грамотно обернуты и хорошо обнаруживаются агентом](https://portofcontext.com/blog/cli-vs-mcp-vs-code-mode). Кто-то, что этой разницей можно пренебречь, да и вызвана она тем, что не все CLI адаптированы под экономию контекста. Но все согласны, что CLI может дать агенту доступ ко всем тем же инструментам и обеспечить одинаковый процент успеха при выполнении задач, при этом будучи куда понятнее для человека и значительно проще в написании и поддержке.

В моих проектах я буду использовать CLI.

Бэкенд «тормозит», API ломаются, а архитектура трещит: уроки, которые помогают закрыть эти проблемы

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

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

• 22 апреля 20:00. Bun + ИИ: создаём быстрый сервер нового поколения на JavaScript

• 22 апреля 20:00. Symfony Workflow: конечный автомат для реализации бизнес-логики

• 23 апреля 20:00. Многопоточность в C++: как писать быстрые и безопасные приложения

• 23 апреля 20:00. Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?

• 28 апреля 20:00. Фоновые задачи в Django: работа с Celery

• 30 апреля 20:00. Поиск в базе знаний: где векторы ошибаются, а графы помогают

• 4 мая 20:00. Интерфейсы в Golang изнутри

• 5 мая 20:00. Postgres + JSON: реляционная мощь, документная гибкость

• 5 мая 20:00. Архитектурные решения в бэкенд-разработке

• 6 мая 19:00. Разработка проекта на Kotlin: коллаборация человека, архитектурных шаблонов и ИИ-команды

• 6 мая 20:00. Rust в деле: пишем многопользовательский чат с сервером, клиентом и CLI

• 7 мая 20:00. От кода до Kubernetes за полтора часа

• 7 мая 20:00. Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS

• 13 мая 20:00. Kafka Streams DSL

• 13 мая 20:00. ClickHouse для аналитики больших данных: практические кейсы и связь с NoSQL-экосистемой

• 14 мая 20:00. Взаимодействие с базой данных и миграции на Go

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