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

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 еще и извинился за необоснованные оценки :)))

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

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

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

Пора научить агента видеть и слышать. Клиент не присылает аккуратный промпт — он кидает фотку накладной, скрин ошибки, голосовое на 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'те!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привет, коллеги! Традиционная подборка открытых онлайн‑мероприятий для тех, кто хочет прокачать скиллы в 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 открытых вебинаров на эту неделю. Если вы не нашли в расписании тему, которая нужна именно вам, — загляните в полный календарь

Работаю над большим 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-схемами и таблицами. Я старался не смешивать два разных назначения в одном файле.

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

Если бы я наткнулся на эту статью в самом начале работы с блокчейном ТОН, это бы сэкономило мне кучу времени на понимание архитектуры и принципов работы смарт контрактов.

Что такое смарт контракт с точки зрения разработчика.

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

• Адрес

• Баланс

• Любые данные, которые вы туда запишите

• Код смарт контракта

• Текущий статус смарт контракта

Ну или если перевести вышесказанное в код, то:

class SmartContract{ 
   readonly address: string; 
   readonly balance: number; 
   readonly code: string; 
   readonly status: 'uninitialized' | 'active' | 'frozen'; 

   storage: object; 
   ... 
}

Плавное погружение...

Представьте, вы написали код класса на своем любимом языке программирования, как полагается, с полями и методами, и превратили этот код в строку. Code - это и есть код вашего смарт контракта. Он будет выполняться в блокчейне. Точкой входа в таком коде будет метод onInternalMessage или onExternalMessage. Чтобы состояние полей класса можно было сохранять и перезаписывать, к смарт контракту прилагается объект Storage , в котором хранятся значения ваших полей.

При сохранении смарт контракта в блокчейн вы отправляете { code, data } , где code - это код вашего смарт контракта, data - начальные данные. По этим двум полям вычисляется будущий адрес смарт контракта: address = hash({ code, data }). По этому адресу будет доступен ваш смарт контракт в блокчейне ТОН. На него можно совершать переводы, просматривать историю транзакцию, с него может переводить средства и вызывать другие смарт контракты.

Как происходит деплой смарт контракта.

Каждый смарт контракт платит немного комиссии по факту своего существования, в пример вспоминается налог на недвижимость. Чем больше жилплощадь - тем больше налог. Но в рамках ТОН вы платите за количество данных, которое хранит ваш смарт контракт, включая сам код вашего смарт контракта. Поэтому при создании на нем должно лежать как минимум чуть-чуть ТОН(как правило копейки). Создать смарт контракт можно 2 способами:

1) Другой смарт контракт делает перевод ТОН, прикрепляя код вашего смарт контракта вместе с начальными значениями(data) в поле Init = { code, data }. Блокчейн видит в переводе это поле и автоматически делает деплой. Статус смарт контракта становится "active".

2) Другой смарт контракт так же делает перевод ТОН, но только не прикрепляя ничего. В таком случае средства останутся висеть на адресе пустого смарт контракта, который будет выглядеть примерно так:

{ 
   "address": "401bf...3004", 
   "balance": 3000, 
   "code": "", 
   "storage": {}, 
   "status": "uninitialized" 
}

Он ждет внешнее сообщение, где в него передадут код и начальные данные таким образом, чтобы address = hash({ code, data }), только тогда он сохранит код и сможет выполняться. Для вызова внешнего сообщения используется обычное API, где передается адрес и Init = { code, data } . Запрос сначала попадет в блокчейн, после чего при совпадении адреса address = hash({ code, data }) произойдет деплой, и статус станет "active".

Заключение

В этой статье мы с вами закрепили азы архитектуры блокчейна ТОН, где каждый адрес является адресом смарт контракта. Разобрали структуру и механику создания. Рады вашему фидбеку или вопросам! Следите за нашими анонсами и новостями в Telegram.

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

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

Игра написана на 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

При этом у классических 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, тестировании, нагрузке, инфраструктуре, работе с данными и проектировании систем.

• 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

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

Всем привет! Хотели похвастаться очередным сложным, но очень важным шагом на пути к возрождению российского геймдева и заодно спросить мнения окружающих (да, мы всегда сначала делаем, потом думаем).

Традиционный подход подразумевает, что разработчик заключает договор с площадкой (Steam, VK Play, Itch и т.д.). Игрок покупает игру, и деньги идут на счёт платформы. После этого в определенные даты происходит выплаты на счета разработчиков за вычетом комиссий. Где-то больше, где-то меньше, где-то по-другому. Но смысл тот же. Этот подход позволяет, во-первых, брать комиссии, во-вторых, легче работать с возвратами и в-третьих, быстрее распознавать отмывание денег и мошенничество.

Мы решили использовать схему маркетплейсов, где каждый разработчик приходит со своим статусом (ООО, ИП, смз). Но приходит он в первую очередь не к нам, а к платёжным агрегаторам типа Юкасса, Робокасса, любая …касса. Одним словом, подключает себе интернет-эквайринг, такое делает любой банк. Банк ему даёт API для подключения, ID магазина, ключи для проведения оплат и всё, действуй.

Где здесь мы? Мы предоставляем бесплатный хостинг для игр. Сама площадка + страница игры + страница разработчика. Всё тоже самое что у itch[.]io. Заодно есть консоль разработчика, в которую добавляется всё больше и больше возможностей. Соответственно, в этой консоли разработчик указывает тот самый идентификатор магазина, суперсекретный ключ и дальше надеется на магию.

Если магия происходит, то наш скрипт подставляет его данные в другой скрипт, только уже от платёжного агрегатора. Игрок видит кнопку обычную кнопку оплаты и оплачивает, после чего денюжки магическим образом летят на счёт разработчика. На этом магия заканчивается, начинается то ли математика, то ли бухгалтерия (я в этом не силён, не шарю).

Опережу (почти) все вопросы и сразу отвечу:

Q: На что вы будете существовать если у вас комиссии 0%?

A: При покупке игры рядом есть еще кнопочка “поддержать платформу”, надеемся, что это сработает

Q: Вы делаете очередного убийцу стима?

A: Нет

Q: Это точно не развод?

A: Точно нет, чесслово

На остальные вопросы обязательно ответим. Так как это не реклама, то прямо указывать название площадки не буду, но подскажу, что наш канал https://t.me/dustore_official

Я полностью пересмотрел концепцию библиотеки LDL.

Что такое LDL?
Это графическая библиотека с единым API для всех систем как старых, так и новых.

Раньше я писал её на C++98, что давало хорошую портабельность. Но сейчас я пересмотрел многие тезисы, которые декларировал на GitHub, чтобы наконец добраться до первого релиза.

Новая стратегия

Я решил выпускать релизы без реализации полного функционала (графика, звук, шрифты и т.д.) постепенно, итеративно.

• Перешёл на C89 для максимальной переносимости. Это не только DOS или Windows 3.x, но и старые системы вроде Solaris, PlayStation 1 и другие.

• Для первого релиза реализую минимальный базовый функционал: графику (OpenGL, Vulkan), окна и события. По возможностям аналог GLFW.

• С каждым следующим релизом буду добавлять: 2D-рендер, звук, шрифты и прочее.

Лицензия и целевые платформы

• Лицензия меняется на LGPLv3.

• На старте поддерживаются Windows и Linux.

Качество и инструменты

При разработке использую:

• AddressSanitizer (ASan)

• UndefinedBehaviorSanitizer (UBSan)

• Различные анализаторы кода

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

Примеры и бэкенды

• Добавлю десятки примеров с OpenGL 1.x, OpenGL 3.x и Vulkan.

• Буду добавлять бэкенды для LDL: не только под ОС, но и поверх других графических библиотек — SDL, SFML, GLFW и т.д.

• API остаётся единым для всех бэкендов.

Это позволит сразу добавить поддержку звука и шрифтов (через бэкенды), а в нативных версиях реализовывать их позже.

 2D-рендер без границ

Одной из главных задач LDL я вижу создание единого 2D-интерфейса, который стирает различия между поколениями графики.

Вам не нужно думать о том, что находится в системе: современная видеокарта с Vulkan, старый ускоритель с OpenGL 1.2 или вообще только центральный процессор (Software Rendering).

• Единый интерфейс: Вы используете одни и те же команды для рисования пикселей, линий и спрайтов.

• Адаптивность: LDL сам выберет наиболее эффективный способ вывода изображения. На современной системе это будет аппаратное ускорение, а на «железе» без видеокарты оптимизированный программный растеризатор.

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

Философия: Машина времени в вашем коде

Зачем тратить силы на поддержку систем, которые многие считают «трупами»?

1. Борьба с цифровым забвением

Современный софт живет 3–5 лет. Мы выбрасываем железо не потому, что оно сломалось, а потому, что софт стал слишком тяжелым и ленивым. LDL — это протест против «запланированного устаревания». Я хочу, чтобы код, написанный сегодня, мог дышать в железе любой эпохи.

2. Инженерный аскетизм

Когда у тебя гигабайты памяти, ты перестаешь ценить каждый байт. Написание библиотеки под C89 для слабого железа — это духовная практика для программиста. Это возвращение к искусству находить изящные решения в условиях жестких ограничений. Каждый сэкономленный такт процессора — это дань уважения инженерам прошлого.

3. Преемственность поколений

Мы стоим на плечах гигантов, но часто забываем их имена. LDL сохраняет возможность для диалога между эпохами. Это инструмент, который позволяет современному разработчику почувствовать «металл» старых машин, не теряя связи с современными технологиями вроде Vulkan.

Итог

LDL — это Little Directmedia Layer. Он маленький не потому, что слабый, а потому, что в нем нет ничего лишнего. Это попытка создать код, который будет принадлежать не конкретной версии ОС, а истории программирования в целом.

Один API. Один код. Тридцать лет компьютерной истории.

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

20 апреля, понедельник:

• 20:00. Unit-тесты для iOS приложений, работаем над качеством изнутри

• 20:00. Качество данных (data quality) на практике: от технических метрик до внедрения в команде

• 20:00. От интерфейса до корзины: создаём мини интернет-магазин на языке JavaScript

• 20:00. Эффекты в Scala

• 20:00. Балансировка и геораспределение: как создать быстрое и надёжное приложение для всего мира

• 20:00. Менеджер в перегрузе: как выжить и не выгореть

21 апреля, вторник:

• 19:00. BPMN для 1С: Как правильно моделировать интеграции? (Разбираем 4 уровня детализации)

• 19:00. Значение корпоративной архитектуры для реализации стратегии цифровой трансформации

• 20:00. Функции в SQL: вычисления и переиспользование кода

• 20:00. Оптимизация запросов 1С

• 20:00. Архитектура мониторинга ИБ инфраструктуры на SIEM

• 20:00. Производительность кода на примере алгоритмов сортировки

• 20:00. Как BPMN помогает видеть узкие места

• 20:00. Архитектура Angular-приложения: как писать масштабируемый frontend

• 20:00. Связанные списки в ядре Linux: от API до реального кода

• 20:00. Использование BGP для маршрутизации IPv6

22 апреля, среда:

• 19:00. Основы балансировки нагрузки в Angie и Nginx

• 20:00. Бизнес-процессы CRM. Стандартные активити CRM

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

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

• 20:00. Делегирование без боли: как перестать быть “главным исполнителем” и не скатиться в микроменеджмент

• 20:00. Программируемые реле в АСУ ТП: гибкий инструмент для решения инженерных задач

• 20:00. Создание нейро-сотрудника на базе Telegram-бота и GPT: от регистрации до рабочего прототипа

23 апреля, четверг:

• 18:00. Cоздаём ИИ-ассистента для системного аналитика за 1 час

• 19:00. Интегрируем EDT в процессы непрерывной интеграции. Подключаем 1С к CI/CD

• 20:00. Что нового в Spark 4.0

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

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

27 апреля, понедельник:

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

• 20:00. Настройка кластера Elasticsearch

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

Скрипт намбер ван:

#!/bin/bash

FILE1="/tmp/clp.saved"

# xclip -o -selection primary > "$FILE1"
wl-paste --primary > "$FILE1"
notify-send "Diff" "Первый фрагмент сохранён"

вешаем на одно сочетание клавиш (у меня, например, для удобства, Alt+Shift+1)
(выбираем на вкус для X11 или Wayland)

Скрипт намбер ту:

#!/bin/bash

FILE1="/tmp/clp.saved"
FILE2=$(mktemp /tmp/clp.XXXXXX)

trap 'rm -f "$FILE2"' EXIT

# xclip -o -selection primary > "$FILE2"
wl-paste --primary > "$FILE2"

if [ ! -s "$FILE1" ] || [ ! -s "$FILE2" ]; then
	notify-send "Ошибка" "Нет текста для сравнения"
	exit 1
fi

meld "$FILE1" "$FILE2"

вешаем на другое сочетание клавиш (у меня, например, Alt+Shift+2)

Изолента и реактивный двигатель — вот всё, что нам нужно. Лучше, чем ничего, по крайней мере…
Первый скрипт сохраняет выделенный текст во временный файл /tmp/clp.saved.
Второй скрипт сохраняет выделенный текст в другой временный файл /tmp/clp.XXXXXX, открывает их оба в нашем любимом Meld, мы на всё это дело любуемся, сравниваем, закрываем Meld, после чего скрипт удаляет этот второй временный файл со случайным постфиксом, чтобы не болтался зря. Первый, /tmp/clp.saved пока остаётся, чтобы было удобно с одним и тем же «первовыделенным» сравнивать несколько вариантов, и его всегда можно переопределить первым скриптом.

Итого: Выделили кусок, Alt+Shift+1, выделили другой кусок, Alt+Shift+2 — смотрим, радуемся! 😁

Мы каждый день пишем код, но часто воспринимаем компилятор как "чёрный ящик". Сегодня приоткроем завесу тайны над работой компилятора, расскажем о его жизненном цикле и объясним, на каком этапе в игру вступают деревья.

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

Продолжаем идти по дорожной карте. Пришло время научиться обращаться к моделям через API.

— А куда обращаться? — спросите вы.

Есть несколько вариантов.

1. Первый — на серверы производителей: старым добрым ChatGPT, DeepSeek, Gemini, Qwen.

2. Второй — к хабам опенсорс-моделей, например HuggingFace.

3. Третий — к провайдерам-агрегаторам, которые предоставляют и то и другое: Openrouter, Together, Fireworks.

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

Но, к счастью, OpenAI был впереди планеты всей, и его формат стал стандартом де-факто.

Поэтому начните с интерфейса OpenAI, возьмите провайдер Openrouter. Изучите спецификацию, форматы сообщений, поэкспериментируйте с системным промптом, параметрами генерации, потоковым выводом. Изучите мета-информацию в ответе — количество токенов, время генерации.

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

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

📚 Материалы

• Наш видео-туториал по OpenAI API

• OpenAI Quickstart · Python SDK · Streaming

• HuggingFace Inference API

• Openrouter Quickstart · Together AI · Fireworks AI

🔔 Следующая тема: мультимодальность — голос, изображения, видео.

⬅️ Предыдущая тема: Level 2. AI-driven разработка

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

Наши курсы по ИИ-агентам. По вопросам — пишите мне.

Привет, Хабр. Эти уроки проведут преподаватели курсов Отус в преддверии старта новых потоков. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Участие бесплатное. Присоединяйтесь!

15 апреля, среда:

• 18:00 — Основы протокола HTTP

• 20:00 — OpenAPI + Spring

• 20:00 — Локализация текстов в Symfony: от статических переводов к динамическим данным из базы

• 20:00 — Основы проектирования бизнес-логики в микросервисной архитектуре

16 апреля, четверг:

• 20:00 — Облегчённые (Slim) примитивы синхронизации

• 20:00 — Архитектура ИИ-сервисов для High-Load и Low-Latency инференса

21 апреля, вторник:

• 20:00 — Функции в SQL: вычисления и переиспользование кода

• 20:00 — Производительность кода на примере алгоритмов сортировки

22 апреля, среда:

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

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

23 апреля, четверг:

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

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

29 апреля, среда:

• 20:00 — PHP-разработчик. Продвинутый уровень

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

Способ обучения состоит из трех шагов.

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

ЙЦУ КЕНГуру ШЩаЗ ХЪ

ФЫВА ПРО ЛоДЖЭя

мЯЧ СМИТ ЬБьЮ,

в которых нужно пропускать строчные буквы.

Для запоминания английской раскладки запомните три последовательности

Q WERTY U I OP!

AS DFGHiJKL

ZXCVBNM,.

Второй шаг. Располагаем кисти так, чтобы указательные пальцы опирались на клавиши с бугорками - А и О. Печатаем на ощупь в течении получаса. Если у вас нет своего текста, можно воспользоваться Гонками на клавиатуре https://www.google.com/search?q=гонки+на+клавиатуре. При этом если расположение буквы уже запомнилось, то нажимаем ее правильным пальцем. Если расположение клавиши не запомнилось, то, не глядя на клавиатуру, ощупываем слева на право клавиши в нужном ряду, пока не найдем искомую букву. Например, для нажатия буквы Т ощупываем мизинцем левой руки букву Я, безымянным - букву Ч, средним - С, указательным левой - М, указательным левой руки - букву И, указательным правой руки - букву Т.

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

По необходимости повторяем предыдущие шаги.

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

— Привет. В этом спринте наш главный приоритет — это обработка больших данных из файла, который загружает пользователь. Тебе предстоит сделать пошаговую форму и предварительную проверку перед отправкой, — уверенным голосом сказал Виталий — руководитель проекта.
— Бизнес очень хочет эту фичу и ждёт, — добавил он, повышая уровень ответственности и важности задачи.
— Но… перед этим есть маленькая задачка: нужно в форме группового добавления товаров в корзину показать ошибки, которые возвращает сервер.

Подключились ребята с бэка.
— Раньше у нас этого не было, мы просто падали. Сейчас для каждого отдельного запроса может быть своя ошибка. Мы обсудили это с Виталием и Викой на прошлой неделе и быстро всё сделали, — декларировали они, явно удовлетворённые результатом своей работы.

— Да… там простой процесс: пользователь нажимает кнопку, и для каждого поля уходит свой запрос. Нужно просто показать ошибки, — подтвердила Вика — аналитик.

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

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

— Не уверен… что это можно сделать быстро. Там много старого кода и логики, запросы работают параллельно, мы вообще не обрабатываем ошибки в этой форме. Просто закрываем модалку. Нужно подумать… — сделал я слабую попытку возразить.

— Ну, так… форма же уже работает. Это простое отображение ошибок. Бизнес хочет, чтобы в конце недели это было на проде. Ок…? — закончил вопросом-утверждением Виталий.

— Ок… — зачем-то ответил я. «Б…!!! Зачем я это сказал?!» — тут же промелькнуло у меня в голове, и две половинки моего тела чуть ниже спины нервно сжались в предвкушении нюансов…

Кого узнали и что было дальше?

Кодовые агенты — вторая тема дорожной карты, и я поставил её сюда не случайно.

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

Для начала ознакомьтесь с разнообразием инструментов:

• Онлайн-прототипирование: V0, Bolt, Lovable, Replit

• Консольные агенты: Claude Code, Codex CLI, Gemini CLI, Warp

• AI-coding IDE: Cursor, Windsurf

• Spec-Driven IDE: Kiro, Qoder

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

Три вещи, которые я настраиваю первым делом:

• Skills — для меня это самый мощный и пока сильно недооценённый инструмент. Скилл — инструкция-специалист: агент читает SKILL.md и получает роль, знания и алгоритм. Аналитик, архитектор, тестировщик, DevOps — можно собрать целую команду специалистов под проект. Формат уже стал кросс-платформенным — один SKILL.md работает в Cursor, Claude Code и Codex.

• Rules — постоянные инструкции: стиль кода, архитектурные решения, запреты.

• MCP — подключение внешних инструментов и актуальной документации. Попробуйте начать с MCP Context7.

Крайне рекомендую изучить Spec-Driven методологию и лучшие практики работы с кодовыми агентами от Anthropic.

На выходе с этого уровня у вас будет персональный кодовый ИИ-агент, который берёт рутину на себя, а вы фокусируетесь на архитектуре.

📚 Наши материалы

• Умный вайб-кодинг

• 300 дней с AI-агентами

• Лучшие практики от Cursor

• Третья эпоха AI-разработки

• Видео: AI-driven разработка · Qoder · Claude Code · Gemini CLI

🔔 Следующая тема: работа с LLM API.

⬅️ Предыдущая тема: Level 1. Основы LLM и промпт-инжиниринг

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

🎓 Приглашаем на бесплатный мастер-класс
📅 13 апреля, пнд 16:00 МСК — AI-driven практикум «ИИ-агент с нуля за один эфир»
👉 Записывайтесь в наших ботах: Telegram или ВКонтакте

Наши курсы по ИИ-кодингу ИИ-агентов. По вопросам — пишите мне.

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

Будет интересно Python-разработчикам, аналитикам и другим ИТ-специалистам, кто интересуется применением ИИ в разработке.

• 📅 Когда: 15 апреля (среда) в 15:00 по мск

• 📍 Где: онлайн 

• 👉 Зарегистрироваться

Начну нашу дорожную карту Agentic AI с языковых моделей.

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

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

• параметры моделей и основные термины (размер, веса, токены, контекстное окно, галлюцинации),

• способы оптимизации (квантизация, прунинг, дистилляция),

• способности к размышлению, ведению диалога, следованию инструкциям, обработке не только текста, но и медиа-контента.

Главное — практиковаться. Я взял себе за правило: каждую задачу сначала через ИИ. Пишу код? Промпт. Анализирую данные? Промпт. Пишу письмо? Промпт. Делаю презентацию? Промпт.

Чтобы делать это качественно — прокачивайте навык писать промпты, изучите гайды по промпт-инжинирингу от вендоров. Результат на выходе зависит от качества контекста и точности инструкций.

Изучите гайды, пробуйте разные модели, начните с топовых: ChatGPT, Claude, Gemini, DeepSeek, Qwen. Отечественные: YandexGPT, GigaChat.

Прокачайте насмотренность, набейте руку, пройдите по аренам, лидербордам, бенчмаркам — научитесь понимать, в чём одни модели сильнее других.

На выходе будете как рыба в воде: выбирать модель под задачу и качественно с ней работать.

📚 Материалы

• Как работают LLM: Prompting Guide, визуализации — LLM Visualizer и Transformer Explainer, наш плейлист с объяснениями основ.

• Промпт-инжиниринг от вендоров: OpenAI Cookbook, Anthropic Prompt Engineering, Claude 4 best practices.

• Выбор модели: видео-гайд, лидерборды — LM Arena, LLM Arena RU, SWE-bench. Хаб моделей: Hugging Face.

🔔 Следующая тема: AI-driven разработка — как грамотно ускорять разработку в X раз.

⬅️ Предыдущая тема: Дорожная карта Agentic AI. Интро

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

🎓 Бесплатные мероприятия на этой неделе

• 📅 9 апреля, чт 18:00 — Онлайн-разбор продакшен-кейса «ИИ-агент консультанта 1С»

• 📅 13 апреля, пнд 16:00 — AI-driven практикум «ИИ-агент с нуля за один эфир»

👉 Записывайтесь на мероприятия в наших ботах: Telegram или ВКонтакте

Ознакомьтесь с нашей траекторией роста по AI-driven разработке и ИИ-агентам.

ruff (Python) — 73 замечания на 63 000 строк. 1.2 на 1000 строк.

Состав: 39 неиспользуемых импортов, 17 неиспользуемых переменных, 6 forward references, 5 f-строк без подстановок, 5 лямбд вместо def. Ноль ошибок, от которых код падает в рантайме.

ESLint (React/TypeScript) — 0 ошибок, 5 warnings на 21 000 строк. Все пять — рекомендация Next.js использовать <Image> вместо <img>.

Для сравнения:
- Зрелый проект с CI-линтингом — 0–2 замечания на 1000 строк.
- Без линтинга — 5–15.
- Легаси — 20–50.

У нас 1.2 и 0.24, при том что CI-линтинга в проекте нет. Claude и Codex запускают ruff и eslint сами на каждое изменение — я вижу это в логах. Результат соответствующий.

Безопасность

ruff и ESLint проверяют стиль, не безопасность. По совету из комментариев прогнал bandit — security-сканер для Python.

1 432 находки. Реальных уязвимостей: 0.

• 2 HIGH — SHA1 для fingerprint'а шахматных партий. Это не криптография, а генерация коротких ID для внутренней классификации. Подделывать бессмысленно.

• 5 MEDIUM «SQL injection» — bandit видит f-string в SQL-запросе и сигнализирует. Но внутри f-string стоят только ?-плейсхолдеры, данные идут параметрами. Классическая параметризация, инъекция невозможна.

• 4 MEDIUM «url open» — HTTP-клиенты Lichess, Chess.com, OpenRouter. URL из конфига, пользователь не контролирует.

• 1 421 LOW — 1 250 assert'ов (bandit предупреждает, что assert удаляется при запуске с -O, но Django и Celery никто так не запускает), остальное — try/except/pass в опциональных ветках.

Фронтенду отдельный security-сканер не нужен: React экранирует HTML автоматически, dangerouslySetInnerHTML не используется, фронт не работает с БД, файлами и процессами.

85 000 строк, три сканера, ноль реальных уязвимостей. ИИ-код не нуждается в оправданиях — он нуждается в проверке. Проверили. Чисто.

p.s. Проверку проходил код из статьи Вайбкодинг по Chess’ноку. 1. e4

На Reddit разработчик с 11-летним стажем описал тревожный момент: он не смог отладить баг в собственном коде без Claude. Не потому что баг сложный, а потому что разучился генерировать гипотезы самостоятельно.

Что произошло

Разработчик столкнулся с нестабильным багом сетевых таймаутов в продакшене. Сервис писал сам, два года назад. Раньше подобная проблема решалась за час методичной работы. Теперь 40 минут пинг-понга с Claude без результата.

Когда он закрыл чат и попробовал разобраться сам, обнаружил: внутренний диалог, который раньше подсказывал «проверь пул соединений», «может retry storm», «посмотри балансировщик», стал заметно тише.

Баг он в итоге нашёл. Но медленнее, чем три года назад, когда AI ещё не использовал.

Почему это не про «AI плохой»

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

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

Классический пример — GPS-навигация. Исследование в Nature Communications (2017) показало: люди, которые постоянно ездят по навигатору, хуже справляются с задачами пространственной ориентации, чем те, кто периодически строит маршруты сами.

Где это ломается у разработчиков

На практике выделяются три зоны риска:

Генерация гипотез
AI отлично проверяет гипотезы. Но если перестать генерировать их самостоятельно, навык быстро деградирует. Через полгода становится сложно просто «посидеть» с проблемой.

Валидация решений
Раньше разработчики продумывали архитектуру и решения самостоятельно. Теперь часто тянутся к AI за подтверждением. В итоге снижается доверие к собственной экспертизе.

Коммуникация
Некоторые прогоняют через AI даже сообщения коллегам. Возникает размывание авторства мысли: это ты формулируешь или инструмент за тебя.

Контраргумент: а Stack Overflow?

Частое возражение: разработчики годами копировали решения с Stack Overflow и не деградировали.

Разница в модели взаимодействия:

1. Нужно сформулировать проблему

2. Найти релевантный ответ

3. Адаптировать решение под свой контекст

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

Что делать: практические подходы

Правило 5 минут
Перед тем как открыть Claude, потратить 5 минут на самостоятельный анализ stack trace. Это простой способ «включить» мышление.

Unplugged-сессии
Периодически дебажить без AI. Например, один час в неделю. Это не ограничение, а тренировка.

Приходить с гипотезами
Разница между джуном и сеньором в работе с AI: джун ждёт решение, сеньор приносит несколько гипотез и использует AI как инструмент проверки.

Рефлексия после решения
После решения с помощью AI зафиксировать, какие гипотезы ты мог бы выдвинуть сам. Это возвращает осознанность процессу.

Честно

Я не демонизирую AI-инструменты. Сам использую ежедневно. Но когнитивная атрофия — реальный риск, который стоит учитывать.

Если вы программируете много лет и замечаете, что раньше справлялись быстрее без AI, это не паранойя. Навык требует практики, а делегирование мышления — это решение с определённой ценой.

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

С сегодняшним обновлением, оно успешно разыскало в интернете и проверило все 5546 зависимости одного из наших проектов, кроме 4 мусорных внутренних библиотек.

Научил работать с Java (раньше были только Python, JS и Go). Починил целую пачку багов.

Это такой краулер, который принимает на вход SBOM (в виде CSV или cyclonedx) и потом сомневается в нем: старается обойти интернет, и на самом деле физически найти файлы с лицензиями. Выкачать их репозиториев, распаковать из архивов, или даже открыть в барузере их сайты и распарсить веб-странички. И фактически проверить на соответствие. В отчете описывает, что и откуда взялось, и почему она думает что лицензия на самом деле не MIT а GPL. На выходе получается CSV или JSONL файл, который можно отгружать безопасникам на ревью.

Исходники - как всегда, на GitVerse.

https://gitverse.ru/anarchic/licensedog

Дорожная карта Agentic AI: от основ до production-ready агентных систем

Друзья, я решил в апреле разобрать горящую тему этого года - что надо знать и уметь для разработки production-ready ИИ-агентов.

По сути, это будет своеобразная дорожная карта Agentic AI Engineering — по этапам, от основ до зрелых систем.

Я буду выкладывать небольшие посты с раскрытием важных тем и ссылками на полезные материалы.

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

• Основы языковых моделей и промпт-инжиниринг,

• Работа с LLM API и структурированный вывод,

• AI-driven разработка с ИИ-агентами,

• Мультимодальность — голос, изображения,

• Local inference — локальный запуск моделей,

• RAG — как передать агенту знания о вашем бизнесе,

• Agents — агенты с памятью, инструментами и планированием,

• MCP — стандарт интеграции агентов с внешними системами,

• Observability & Evaluation — мониторинг и оценка качества RAG-систем и агентов,

• Security & Guards — безопасность агентных систем,

• Управление датасетами и промптами,

• Сontext-engineering — работа с большим контекстом,

• Skills — навыки агентов,

• Agent harness — решение сложных задач, субагенты и планирование,

• Multi-agents — мультиагентные системы.

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

Это вводный пост с приглашением подписываться, чтобы не пропустить следующие темы.

Кстати, если есть пожелания по темам, что стоит добавить, то пишите в комментариях, пожалуйста.

🔔 Следующий пост: основы языковых моделей — с чего всё начинается.

Больше про ИИ-кодинг и ИИ-агентов в ТГ и ВК.
Приглашаю ознакомиться с нашими онлайн-курсами по ИИ-разработке ИИ-агентов.

Компилятор поддерживает стандарт C89 и может генерировать исполняемые файлы в формате ELF64 для систем x86-64. Исходный код проекта содержит около восьми тысяч строк и открыт под лицензией ISC.

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

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

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

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

Мне захотелось поделиться своими мыслями на тему код-ревью, о том как формулировки влияют на скорость работы и состояния людей:

Ссылка на статью

Если хоть раз сидел и думал: «что от меня тут вообще хотят?» — ты точно поймёшь :)

Расскажем, как обойти лимиты n8n для enterprise- и ИИ-систем: живой трейсинг и метрики из коробки, предсказуемое масштабирование, нативная работа с кастомными моделями машинного обучения и мультиагентными системами. Плюс бесшовный импорт сценариев из n8n без простоев. В финале — живая миграция реального воркфлоу за минуты.

Спикер: Владислав Янковский — старший Go-разработчик, Cloud.ru

Трек: Прикладной ИИ

📅 Когда: 9 апреля в 16:40–17:00 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: NoCode инструменты для создания AI-приложений с RAG: быстрый старт

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

Cursor — это сейчас, пожалуй, самый продвинутый AI-редактор на рынке. По сути, это VS Code, в который встроили настоящий искусственный интеллект на стероидах. Composer позволяет одной командой править сразу десяток файлов, агент понимает весь проект, хорошо справляется с рефакторингом, поиском багов и даже архитектурными решениями. Качество кода от Claude Sonnet 4.5 или свежих GPT часто вызывает искреннее «вау».

Но есть большая ложка дёгтя. Cursor — американский продукт, и российские карты он не принимает. Чтобы купить подписку Pro, приходится либо использовать виртуальные карты через крипту, либо платить посредникам (Oplatym и подобные), либо покупать готовые аккаунты (что рискованно). Сам редактор после оплаты работает без VPN, но первоначальная настройка оплаты — это отдельный квест. Бесплатная версия быстро упирается в лимиты, особенно если активно юзаешь мощные модели.

Harvi Code — Первый в России AI кодинг-агент. Российский ответ на все эти заморочки. Это полноценный AI-агент прямо внутри VS Code. Пишешь задачу в чате — он генерит код, рефакторит, фиксит баги, работает с контекстом всего проекта. Не тормозит, контекст держит хорошо, интерфейс привычный.

Самое приятное — модели на любой бюджет. Есть топовые (Claude Sonnet 4.5, GPT-5.4 и другие). А главное — очень низкая стоимость токенов. Для каждой модели есть свой коэффициент стоимости. Для большинства повседневных задач их хватает с головой, и можно вообще почти не тратить деньги. Оплата — российскими картами или СБП, без всяких посредников и VPN.

Коротко по делу:

• Если тебе нужен мощный multi-file agent и ты готов один раз настроить оплату через проверенного посредника — бери Cursor. Он до сих пор в топе по возможностям.

• Если хочешь работать стабильно, без лишних телодвижений и не думать каждый месяц про «как бы оплатить» — Harvi Code сейчас выглядит гораздо практичнее для российского разработчика.

А вы как сейчас кодите с ИИ? Пробовали оба варианта? Что в итоге оставили в основном редакторе? Пишите в комментариях, интересно почитать реальный опыт.

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

Буквально недавно я так дебажил одну рубишную либу и выяснилось что там внутри есть косячки. Не долго думая, прямо в той же сессии я попросил агента собрать ишью дал линк на репу и потом просто скопировал это туда на гитхаб (наверное можно было попросить его сделать ишью автоматом, попробую так в следующий раз). Получилось очень обстоятельно с примерами кода, описанием того где ошибка. При желании можно было бы сразу пулреквест кинуть, но я не был уверен в какую сторону решит пойти автор либы. Вот кстати тот ишьюс. И фикс был сделан буквально в тот же день.

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

Наш агент Фроня (Фронезис) устроен иначе. Прежде чем что-то опубликовать, он устраивает совет внутри себя — и только при согласии двух из трёх действует. Byzantine consensus: если один ошибается или галлюцинирует, остальные блокируют.

Но этого мало. Каждое решение запечатывается криптографической подписью до выполнения — не после. Это Leibniz Layer™, наш протокол верификации. Любое действие агента можно проверить по хэшу в любой момент.

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

Не побоимся этого слова — первый в мире агент который подписывает свои решения до действия и позволяет любому их проверить. leibniz.fronesislabs.com

Привет, Хабр. Эти уроки проводят преподаватели курсов Отус в преддверии старта новых потоков. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Это бесплатно. Приходите!

• 25 марта 20:00
  РазвИИтие на основе ClickHouse: базы данных для искусственного интеллекта

• 25 марта 20:00
  Кракозябры vs Java: как победить кодировки и стать гуру Unicode?

• 25 марта 20:00
  Типы данных, переменные и функции в Rust

• 25 марта 20:00
  Инструменты профилирования и оптимизации в Go

• 25 марта 20:00
  Механизмы блокировок в PostgreSQL

• 26 марта 20:00
  Путешествие запроса в PostgreSQL: от разбора до исполнения (от parser до executor)

• 26 марта 20:00
  NestJS и архитектура масштабируемых серверных приложений на Node.js

• 26 марта 20:00
  Проектирование RAG систем

• 30 марта 19:00
  Расширение возможностей автоматизации через REST API

• 30 марта 20:00
  Чтение CSV — вход в Spark

• 30 марта 20:00
  Spring Boot Actuator: основы мониторинга и управления приложением

• 30 марта 20:00
  Индексы в PostgreSQL

• 30 марта 20:00
  Стили взаимодействия микросервисов: 5 секретов, которые изменят ваш подход к backend-разработке

• 30 марта 20:00
  Основные шаблоны проектирования в системном дизайне

• 31 марта 20:00 SQL:
  Оконные функции — когда GROUP BY уже не хватает

• 1 апреля 20:00
  Scala + Cats: аккумулируем ошибки с Validated без боли

• 1 апреля 20:00
  Создание интерфейсов с помощью OpenAPI

• 2 апреля 20:00
  Анатомия памяти: типы данных, способы хранения, аллокации и работа GC

• 6 апреля 20:00
  Ошибки системного аналитика при описании REST API

• 9 апреля 20:00
  PostgreSQL как векторная база данных: ИИ-поиск без лишних сервисов

• 9 апреля 20:00
  Realtime на Node.js и TypeScript: создаём WebSocket-чат и разбираем архитектуру backend

• 9 апреля 20:00
  Модели восстановления в SQL Server: как не потерять данные и настроить бэкапы правильно

• 13 апреля 20:00
  Как работают структуры данных C# «под капотом»

• 13 апреля 20:00
  Telegram-бот с искусственным интеллектом на Python

• 14 апреля 20:00
  Case classes и pattern matching: суперсила Scala на практике

• 14 апреля 20:00
  Влияние нефункциональных требований на архитектуру

• 15 апреля 18:00
  Основы протокола HTTP

• 15 апреля 20:00
  OpenAPI + Spring

• 15 апреля 20:00
  Основы проектирования бизнес-логики в микросервисной архитектуре

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

• Superbase CLI — управление миграцией БД на PostgreSQL, генерирует типы из схемы БД, создаёт аутентифицированные HTTP-запросы.

• Skill Creator — позволяет создавать агентные скиллы без лишних заморочек, постоянно улучшаете и оттачиваете навыки Claude для конкретных задач.

• Get shit done — создаёт легковесную систему разработки с контекстным инжинирингом и поддерживает Claude Code, OpenCode, Gemini CLI, Codex, Copilot, и Antigravity.

• Notebooklm-py — обеспечивает программный доступ к фичам NotebookLM, который очень хорошо будет смотреться с агентами Claude Code, Codex, и OpenClaw.

• Obsidian.md — аналог NotebookLM со схожим функционалом, который работает в России и в него можно интегрировать Claude, чтобы получить мощный ворфлоу.