разработчикам, которые планируют перейти в руководство,
начинающим тимлидам,
менеджерам, которые хотят систематизировать управленческие практики и усилить навыки работы с командой.
На курсе разбирают:
техническое лидерство и архитектурные решения,
управление командой и развитие сотрудников,
Agile-подходы (Scrum, Kanban),
процессы планирования и релизов,
коммуникацию с бизнесом,
обратную связь и 1-on-1.
Отдельный фокус — практика. Студенты отрабатывают управленческие навыки с наставниками — действующими руководителями разработки, а также обмениваются опытом с другими тимлидами и менеджерами.
Что нового в тарифах:
Расширенный тариф: практические отработки управленческих задач и собеседований.
Максимальный тариф: всё из расширенного тарифа, работа с карьерным консультантом, дополнительный модуль по аргументации для руководителей.
Самое быстрое — «хренак-хренак и в продакшн»: о статическом анализе и скорости выхода продукта
Иногда задают вопрос: "Как статический анализ ускорит Time to market?"
Никак. Статический анализатор не ускорит выход продукта/обновления на рынок. С ним будет дороже и медленнее. Причина — неправильный вопрос.
Аналогично можно спрашивать, как этап тестирования ускоряет Time to market? Точно так же — никак. Тестировщикам мало того, что надо деньги платить, так они ещё будут разработчиков багами отвлекать. Намного быстрее просто написать запускающийся код и выложить дистрибутив. Как говорится, "хренак-хренак и в продакшен". Это самый быстрый вариант.
Но про тестирование, в отличии от статического анализа, такой вопрос не задают. Все понимают, что тестирование — важный элемент создания ПО. Видимо, статический анализ — более молодая методология по сравнению с тестированием, и он просто ещё не стал неотъемлемой частью разработки. Хотя видится очевидным, что и то, и другое неразрывно связано с обеспечением необходимого качества создаваемых программных продуктов.
Какой вопрос правильный?
Как статический анализ ускоряет Time to market при выпуске продуктов заданного уровня качества и надёжности?
Другое дело. Если нужно выпустить качественный продукт, то статический анализ может выявить многие ошибки и дефекты безопасности быстрее и дешевле, чем другие методы. Некоторые виды дефектов лучше обнаруживаются статическим анализатором кода, чем юнит-тестами, динамическим анализом, ручным тестирование и так далее.
Впрочем, это свойство и других методик. Есть дефекты, которые наиболее эффективно будут обнаруживать юнит-тесты, поэтому профессиональные разработчики не пытаются выбрать какой-то один подход, а используют сразу несколько. Эти разные меры усиливают друг друга.
Статический анализ применяется на этапе конструирования, то есть написания кода, поэтому позволяет устранить многие ошибки ещё до этапа тестирования. Хотя на анализ предупреждений необходимо тратить время, это окупается сокращением числа дефектов, которые выявляются на других этапах проверки продукта и его эксплуатации. Известно, что чем раньше ошибка найдена, тем дешевле её исправление.
Интересно наблюдать, как инструмент Антрофиков пиарится поиском уязвимостей. Однако за этим технологическим восторгом мало кто задумывается о вполне прикладных последствиях.
Что произойдет, когда крупные корпорации окончательно масштабируют эту практику? Представьте процесс разработки крупных продуктов от Microsoft или Adobe. Каждый новый кусок кода, отправленный программистом, моментально анализируется специализированной нейросетью. Переполнения буфера, ошибки логики, слабые места в модулях проверки лицензий — всё это вычищается еще до релиза. Машинный интеллект устраняет саму возможность человеческой ошибки в архитектуре приложения.
В конечном итоге эта эра “ИИ-аудита” может привести к тому, что новые версии так любимого в России пиратского софта (того же Photoshop, 3ds Max, Windows) и свежие игры станут физически недоступными для взлома.
Традиционный «кряк» всегда строится на эксплуатации бреши в коде или обходе алгоритмов DRM-защиты. Но если код вылизан машиной до структурного идеала, а защита динамически меняется, хакерские релиз-группы просто упрутся в бетонную стену. Безусловно, пираты тоже вооружатся ИИ-инструментами, но это гонка вычислительных мощностей: у транснациональной корпорации всегда будет больше GPU-кластеров для создания идеальной защиты, чем у энтузиастов для ее пробития. Технологический барьер может оказаться непреодолимым, оставив в прошлом привычку просто скачивать нужный рабочий инструмент или игру с торрента.
Пиратство всегда сдерживало жадность корпораций: если подписка стоила слишком дорого, люди уходили на торренты. Если ИИ сделает программы невзламываемыми, разработчики смогут задирать цены до небес. Без бесплатной альтернативы нам придется платить за нужный софт любые деньги, просто потому что деваться будет некуда.
Говорят, что ближе к лету активность найма в ИТ-отрасли ослабевает. Но только не в SSP SOFT.
Про нас как работодателя: компания SSP SOFT работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. По размеру компании — мы «средний бизнес» с числом сотрудников около 500 человек, и с проектами федерального уровня.
Рабочие места у нас в московском офисе, который открылся в 2025 году в ЦАО у самой Красной площади. А еще бывают вакансии в департамент разработки в Томске и почти всегда на «удаленку» из любой точки России.
Работа в SSP SOFT — это сложные и интересные проекты, поддерживающая атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента.
Горячие вакансии мая (больше 10 позиций в Москве): 1️⃣ Бизнес аналитика 2️⃣ Дата Инженера 3️⃣ Системного аналитика 4️⃣ Automation QA Engineer (Java) (инженера по автоматизации тестирования, язык Java) (на остальные вакансии см. ссылку ниже, перейдя на ХХ-ру)
Что предоставляет кадровая политика SSP SOFT: ✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины. ✅ Центр компетенций и личное наставничество ускорят развитие до максимума. ✅ Офис, гибрид или «удаленка» ? Есть все варианты. ✅ Время — ваш ресурс. Мы его уважаем.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀
РБПО по ГОСТ Р 56939—2024: вебинар №13 из 30 – Обеспечение безопасности сборочной среды программного обеспечения
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Обеспечение безопасности при сборке ПО, недопущение привнесения в результаты сборки ПО уязвимостей и ошибок со стороны сборочной среды.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
P.S. В вебинаре рассказывается, в том числе, про GitFlic. Отмечу, что PVS-Studio совместим с платформой GitFlic. Благодаря этому разработчики могут получать результаты сканирования PVS-Studio напрямую в интерфейсе GitFlic, что упрощает процесс разработки и тестирования.
Tе, кто до Go писал на языках с конструкциями try/catch, таких как Java и C#, наверняка испытывают легкое замешательство. Руки так и тянутся к try/catch заменителю — использованию recover в связке с defer — как к самому очевидному аналогу. Но это плохая практика и так делать не стоит. Давайте разберёмся, почему и как можно ошибиться при обработке ошибок в Go.
На протяжении последних 3 месяцев активной работы с Claude Code Терминалом я постоянно дорабатывал свой Status Line
И вот, считаю, что он практически идеален
Это одна строка внизу терминала, которая показывает всё, что обычно приходится держать в голове или проверять руками. И многое из того, что интерфейсный клод код не показывает
Кому полезно Если вы реально работаете в Claude Code, ведёте проекты в Git и хотите меньше думать о техническом состоянии сессии, а больше о самой задаче
Из чего состоит ⤵️⤵️⤵️
✔️ Модель Сразу видно, на чём работаешь: Opus / Sonnet / Haiku, версия и размер контекста.
✔️ Папка и ветка Git Показывает текущий проект и branch. Умеет делать truncate длинных названий проекта
✔️ Состояние репозитория Modified / added / deleted / renamed / untracked / conflicts — всё в одной компактной строке. Конфликты подсвечиваются красным, потому что это единственное, что реально блокирует коммит. Визуализируется через стандартные гитовские сокращения
3M — 3 files modified
1A — 1 added
1D — 1 deleted
1R — 1 renamed
2? — 2 untracked
1! — 1 conflict
✔️ Ahead / behind относительно origin Надо ли пушить или подтянуть изменения
✔️ Drift между CLAUDE.md / AGENTS.md / GEMINI.md Я использую и Claude Code, и CODEX и GEMINI — у них разные главные контекст-файлы. Мой статуслайн показывает, когда они разъехались. Чтобы все имели одинаковый контекст
✔️ Контекстное окно Це база Показывает, сколько контекста уже занято: бар + токены типа 480k/1M. Есть ранние предупреждения, когда сессия начинает подходить к зоне, где Claude скоро захочет compact.
✔️ Prompt cache Видно cache hit ratio, сколько токенов читается из кэша, сколько записывается, и когда TTL протухнет. Помогает лучше понимать, сколько стоит каждый запрос и была ли инвалидация кеша
✔️ Rate limits 5h и 7d Показывает, сколько лимитов осталось и время до reset
Формат сделал плотным, чтобы всё помещалось в одну строку. Если нада, то можно сделать мультистрочный статуслайн
Цвета показывают уровень важности: норм / внимание / опасно
В продолжение о том, что нужно знать с нуля лет. До сих пор ли один программист быстрее, чем два? Программист, который думает только о физических рамках, которые обусловлены возможностями железа, мыслит и принимает эффективные решения быстрее, чем программист, влипший в чистый код с некоторыми дополнениями и оговорками, касающимися конкретного проекта. К примеру, мыслительный процесс инженера-конструктора обычно ограничен строгими рамками законов физики, что оптимизирует ментальную нагрузку и фокусирует внимание. Это совсем другой процесс работы. Инженер-программист-чистокодер с оговорками же может наплодить сущностей в коде даже внутри довольно строгих рамок того или иного подхода, той или иной парадигмы. Раз якорей толком никаких, несмотря на точность самой науки, имеем огромное количество споров о сущностях, что явно неэффективно как в обучении новых спецов программированию, так и восприятии самого контента вокруг айти в целом. Есть две строго неотъемлемые, измеримые характеристики написанного кода независимо от сущностей внутри: корректность исполнения и эффективность использования ресурсов железа. Остальное зависит от конкретного проекта и нынешних трендов, и соответственно по идее должно быть хоть и важным, но несколько менее релевантным.
Кто-нибудь когда-нибудь слышал истории о выгоревших инженерах-конструкторах с 40 часовой рабочей неделей, и чтобы им ещё платили нормально? Или они только от плохих зарплат "выгорать" могут?
20 открытых вебинаров OTUS: архитектура, DevOps, ML, аналитика, Go, безопасность и управление
Собрали ближайшие открытые уроки для тех, кто хочет быстро погрузиться в новую тему, сверить свой подход с практикой и забрать идеи для рабочих задач.
В программе — метрики технического директора, управление ресурсами, BPMN, Kafka Streams, ClickHouse, Deep Learning в проде, Nginx/Angie под нагрузкой, Kubernetes, Go, пентест, ИИ‑агенты и DevSecMLOps.
Все вебинары бесплатные и проходят в рамках онлайн‑курсов OTUS. На встречах можно разобрать актуальные темы, задать вопросы и оценить формат обучения.
12 мая
18:00. «Какие метрики использует технический директор?» — Записаться
19:00. «Управление ресурсами в условиях жестокого дефицита» — Записаться
20:00. «Кастомизация интерфейса Bitrix24: создание уникальных пользовательских решений» — Записаться
13 мая
18:00. «Yahoo Finance и не только — работа с российскими торговыми площадками» — Записаться
20:00. «Основы Kubernetes: архитектура и абстракции» — Записаться
20:00. «DevSecMLOps: как безопасно внедрять ИИ в процессы разработки и эксплуатации» — Записаться
Выбирайте темы под свои задачи: где‑то можно быстро закрыть пробел в теории, где‑то — подсмотреть практический подход, а где‑то — свериться с тем, как похожие задачи решают другие специалисты.
📌 Если в расписании не нашлось темы под вашу задачу, загляните в полный календарь открытых уроков — там больше направлений, дат и практических разборов.
Рынок в РФ наконец дозрел до массового внедрения корпоративных 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 × 1032. Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.
Другую забавную байку в комментах поведал аноним с одноразовым аккаунтом. Примерно десять лет назад товарищ анонима перешёл на работу в некий стартап в качестве технического директора. Дела у компании шли отлично, бизнес быстро рос, в команде было порядка 200 разработчиков.
В первую неделю новый техдир обнаружил, что в стартапе заведён специальный микросервис для генерации UUID. Все остальные команды были проинструктированы передавать запросы на генерацию «безопасных» UUID именно в этот сервис. Новый сотрудник начал разбираться и обнаружил, что сервис — это запросы в отдельную базу данных, которая и хранила все до этого выданные UUID.
Логика работы микросервиса была простой: в ответ на запрос генерировался UUID, выполнялась чрезвычайно важная проверка на уникальность в этой базе данных, а затем идентификатор возвращался клиенту. Работу микросервиса поддерживала отдельная команда из трёх инженеров с собственными спринтами и канбан-доской.
РБПО по ГОСТ Р 56939—2024: вебинар №11 из 30 – Динамический анализ кода программы
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Обнаружение недостатков и уязвимостей в коде ПО в процессе его выполнения.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Дорожная карта Agentic AI. Level 4. Мастер примеров — few-shot и structured output
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 и векторные базы — как передать агенту знания о вашем бизнесе.
Представление каталога. Фильтр каталога заменили на представления — функция вышла из экспериментального режима. Теперь вместе с фильтрацией статей можно задавать переменные: одна статья показывает разный контент без создания копий.
⚠️ Автомиграции нет. Если был настроен фильтр — добавьте его заново через панель представлений.
Gramax Enterprise Server
Настройка LFS на уровне пространства. LFS-паттерны задаются один раз и применяются ко всем репозиториям. В обычных пространствах настройки по-прежнему задаются в каждом каталоге.
Фильтрация метрик по каталогу. На страницах метрик добавили фильтры: в отчете по просмотрам — по каталогу, пользователям и типу, в отчете по поиску — по каталогу.
Улучшения настройки проверок по стайлгайду:
Правила отображаются таблицей, редактор открывается в боковой панели.
При первом запуске загружается готовый набор правил — можно адаптировать под команду.
Правила можно экспортировать — поделиться или сохранить копию.
Запуск тестов правил доступен для каждого правила.
Общие изменения
Свойства вкладок. Можно назначать свойства каталога — управлять видимостью в разных представлениях. Также обновили внешний вид вкладок.
Сортировка и фильтрация таблиц. Сортировка по нескольким столбцам и фильтрация по значениям. Параметры сохраняются со статьей — удобно для больших таблиц.
Фрагменты вместо сниппетов и ссылки с превью. Сниппеты переименованы во фрагменты. Теперь можно ставить ссылки на фрагменты прямо из текста: при наведении — превью, удобно для глоссария.
Скрытие превью при переводе. В редакторе мультиязычных каталогов появился переключатель Предпросмотр статьи — скрывает превью на основном языке, чтобы сосредоточиться на переводе.
Версионирование в редакторе. Теперь можно переключаться между версиями прямо в редакторе, а не только настраивать их.
Управление локальным кэшем. В настройках каталога на вкладке Память отображается размер кэша Git и LFS — можно очистить вручную, если каталог вырос или синхронизация замедлилась.
Навигация по OpenAPI. Для OpenAPI-спецификаций в правой панели доступна навигация по методам API — можно перейти к нужному без прокрутки.
Улучшения поиска:
Поиск внутри папки ограничен ею по умолчанию. При необходимости переключитесь на По всем каталогам.
Поиск учитывает полный путь в навигации: статью Вклады / До востребования найдете по запросу Вклад до востребования.
Результаты из одной диаграммы объединяются в один блок.
Добавлен пункт (пусто) для статей без значения, пункт (выбрать все) сбрасывает фильтр.
Улучшения и стабилизация:
Перетаскивание статей и разделов в левой панели ускорили в 10 раз.
Если Git-сервер недоступен, приложение переходит в офлайн-режим. Вернется автоматически, когда сервер станет доступен.
Обновили тулбар редактора. Элементы сгруппированы по категориям, списки открываются по клику.
Дорожная карта Agentic AI. Level 4. Своя кузница — локальный запуск моделей
Level 4. Своя кузница — локальный запуск моделей
Не всё имеет смысл отдавать в облако. Причин у этого как минимум три:
Приватность. Стоит начать пересылать в чужой API персональные данные клиентов, внутреннюю переписку или код с коммерческой тайной, как логи стороннего провайдера превращаются из абстрактной строчки в SLA во вполне конкретный риск утечки. Локальная модель эту головную боль снимает: данные просто не покидают периметр компании, и обсуждать с безопасниками становится по сути нечего.
Автономность. Когда провайдер прилёг, сети легли или вашему региону внезапно прикрыли доступ, локальный агент этого даже не заметит и продолжит работать, как ни в чём не бывало.
Стоимость. Здесь всё упирается в масштаб. Если вы просто экспериментируете у себя на ноутбуке, локальный запуск получается полностью бесплатным: ни подписок, ни платы за токены, и докупать ничего не придётся, всё поедет на том железе, что уже стоит на столе. Когда же речь идёт про нагруженный прод, картина меняется: нужен сервер с 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 в агенте и погнали…
Всего лишь иллюстрация. Примерно год-полтора назад решил я выбрать - 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. Новые чувства — мультимодальность
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.
"Какой же энтерпрайз проект без пасхалки или просто встроенной игры? — Чем будут заниматься менеджеры, пока агенты делают их работу?" — Вот, держите старый добрый Сапер из Windows в виде адд-она Jmix. И это не просто браузерная игра, вставленная в экран. Причем ни строчки кода не написано руками, только сгенерил проект.
Минное поле — это gridLayout, покрытый кнопками, генерится программно в зависимости от параметров.
Весь look&feel как в оригинальном Minesweeper.
Опубликован на Maven, просто добавляйте зависимость:
