Планирование, отслеживание и контроль
Представлен проект под названием «Кладбище 100 ИИ‑проектов», которые прекратили свою работу или были приобретены и интегрированы в другие продукты. Список поддерживается в рамках предварительной проверки — каждая запись представляет собой реальный продукт, зарегистрированный на ToolDirectory.AI до прекращения его работы.
РБПО по ГОСТ Р 56939—2024: вебинар №10 из 30 – Статический анализ исходного кода
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.10. – "Статический анализ исходного кода". На YouTube. Слайды.
Цели десятого процесса по ГОСТ Р 56939—2024:
Предотвращение внесения потенциально опасных конструкций и ошибок в ПО, а также использования опасных конструкций и уязвимостей из заимствованного кода.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Рассмотрение 10-го процесса в ГОСТ Р 56939—2024 неразрывно связано с другим ГОСТ Р 71207—2024 "Статический анализ программного обеспечения". В нём говорится о том же, только более подробно и конкретно.
Про ГОСТ Р 71207—2024 я отдельно рассказывал в цикле из пяти вебинаров:
Разрабатываемый нами анализатор кода PVS-Studio совместим с ГОСТ Р 71207—2024 и закрывает 10-й процесс ГОСТ Р 56939—2024 для языков C, C++, C#, Java. Сейчас в процессе реализации поддержка языков Go, JavaScript, TypeScript. Попробовать PVS-Studio.
Прокрустово ложе
В недавнем видосе я рассказывал, что сейчас читаю Талеба (в частности, его идеи вокруг “Антихрупкости”). И вот на днях на работе поймал идеальный личный пример одной из его любимых метафор Прокрустова ложа.
Суть там в чем: в мифе разбойник Прокруст укладывал гостей на свою железную кровать. Если человек был слишком длинным, то он отрубал ему ноги, если коротким - вытягивал суставы. Талеб переносит это на нашу жизнь: когда живая, сложная реальность не влезает в наши жесткие модели и системы, мы предпочитаем обкорнать реальность, лишь бы она поместилась.
А теперь к практике. Как говорят таксисты: блог и инди-хакинг - это для души, а вообще у меня и настоящая работа есть. Я бэкенд-лид в команде, которая пилит платформу для масс-найма (курьеры, сборщики).
Недавно обсуждали с ребятами, почему в какой-то момент автоматизация процессов начинает буксовать: фича обходится дорого, а позитивного эффекта от нее всё меньше. Оцифровать ведь можно только то, что уже жестко формализовано.
А дальше классика: 20% эйчаров закрывают 80% вакансий. И тут возникает моя самая наивная мысль: ну так давайте пилить фичи специально под этих топов!
Но тут кроется засада. Выясняется, что процессы самых эффективных ребят очень сложно загнать в рамки. У них свои паттерны, подходы, интуиция. И когда пытаемся натянуть на них стандартный флоу, мы строим для них то самое Прокрустово ложе. Пытаясь впихнуть нестандартного, сильного спеца в удобные для системы формочки, мы буквально “отрубаем ему ноги”. Мы заставляем его работать “как положено”, лишая тех самых фишек, которые и делали его звездой.
Получается забавный парадокс: классическая автоматизация мешает сильным, но отлично помогает “слабым”. Среднего сотрудника надо меньше учить, он быстрее вкатывается. А если он уйдет, найти замену гораздо проще, а порог входа сильно снижается за счет жесткого и автоматизированного рабочего процесса.
Как наброс на будущее: возможно, дальше мы придем к персональной автоматизации. Когда не человек подстраивается под приложение, а интерфейсы собираются под конкретного спеца и его стиль работы. Грубо говоря: когда мы научимся с помощью ИИ на лету менять размер кровати, а не рубить людям ноги.
У тебя есть ровно 2–3 часа настоящей работы в день. Не больше.
Не потому что ты ленишься. А потому что всё остальное время — встречи, переписка, уведомления, «быстрые вопросы» в чате — это не работа. Это шум, который притворяется работой.
По данным Hubstaff 2026, средний офисный сотрудник проводит в состоянии реальной концентрации лишь 25–37% рабочего дня. Остальные 61% — это переключение между задачами, митинги и реакции на чужие приоритеты. У менеджеров ещё хуже: глубокий фокус занимает всего 27% времени.
И это не частная проблема — это системная. ActivTrak фиксирует: за год средняя сессия глубокой работы сократилась ещё на 8%. Корпоративная культура «занятости» буквально пожирает способность думать.
Что с этим делать?
Первое — перестать считать «занятость» синонимом продуктивности. Ты можешь провести 8 часов в офисе и не создать ничего ценного.
Второе — защитить свои лучшие часы физически. Тайм-блокинг: 90 минут с утра — только одна задача, никаких мессенджеров. Это не роскошь, это гигиена.
Третье — сократить встречи. Исследования показывают: минус 40% встреч = плюс 71% к продуктивности. Большинство созвонов можно заменить голосовым сообщением или коротким текстом.
No-Meeting Day — когда целый день без звонков — это уже не стартаперская экзотика, а норма в сильных командах.
Твои 2–3 часа концентрации — это и есть ты в лучшей форме. Вопрос только в том, кому ты их отдашь: своим целям или чужим срочностям.
В команде Apple вайбкодят приложения — разработчики случайно оставили файлы Claude .md в обновлении Apple Support. После того, как этот инцидент стал публичным в соцсетях, то в Apple выпустили новую версию обновления 5.13.1 без следов вайбкодинга.
Искусственный интеллект Claude Opus от Autropic размышляет не только на английском, но и на русском и китайском языках. Блоки ответов ИИ иногда содержат текст «процесса мышления» на разных языках.
LLM‑модели мыслят на том языке, который был наиболее распространён в обучающих данных по данной теме или для экономии ресурсов — китайские иероглифы более эффективны, чем английские. Модель по умолчанию использует их для экономии вычислительных ресурсов для выражения некоторых мыслей.
Claude мыслит на русском языке при решении задач в области кибербезопасности, потому что обучающие данные по этой области в значительной степени русскоязычные. Claude рассуждает на том языке, который наиболее эффективен для задачи и потом преобразует ответ в английский
Дорожная карта Agentic AI. 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 в агенте и погнали…
🔔 Следующая тема: Few-shot learning, как учить модель прямо в промпте.
⬅️ Предыдущая тема: Level 4. Новые чувства — мультимодальность
Подписывайтесь, пожалуйста, чтобы не пропустить!
Больше про ИИ — в ТГ-канале и ВК. Каталог наших курсов, услуг и кейсов по ИИ-агентам. По вопросам — пишите в личку.
4 статьи для безопасного проектирования и разработки программ
Привет, Хабр! Подготовили для вас подборку полезных материалов по безопасной разработке ПО.
Рассказываем, как повседневные решения разработчика влияют на безопасность сервисов, какие базовые практики помогают избежать большинства уязвимостей, а также как и зачем внедрять безопасную разработку в процессы.
Что внутри:
Процессы и основные риски безопасной разработки.
Требования безопасности
Принципы безопасного проектирования
Безопасное использование сторонних компонентов.
РБПО по ГОСТ Р 56939—2024: вебинар №09 из 30 – Экспертиза исходного кода
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.9. – "Экспертиза исходного кода". На YouTube. Слайды.
Цели девятого процесса по ГОСТ Р 56939—2024:
Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
7 способов убить проект в длииинной Excel-таблице — и один, чтобы спасти
1. Создайте таблицу с 15 вкладками
Сначала все логично: «Общее», «Январь», «Февраль», «Последняя версия»... Через полгода никто не помнит, куда смотреть.
2. Используйте «В работе» как универсальный статус.
Пусть все, что не упало в «Готово», автоматически числится в процессе. Когда на самом деле задача будет выполнена? Неизвестно. Пора вмешаться? Не понятно.
3. Храните переписку, файлы и задачи порознь
Telegram, облачное хранилище, таблицы, почта — проявите фантазию, чтобы каждый поиск занимал не меньше 20 минут.
4. Собирайте статусы раз в неделю вручную
Пинги команды, получение искомого и сведение данных должны растянуться на пару дней. Когда закончите, как раз уже все будет не актуально.
Еще три способа упереться в край возможностей Excel и приблизить конец игры, а также о роскошном минимуме для управления проектами — в новой статье, здесь на Хабре.
Лог в реальном времени: берём госзаказ и закрываем его агентной разработкой
На днях Оскар Хартманн довольно жёстко высказался за вайбкодинг. Тем временем на Пикабу из 45 программистов в профессиональном сообществе вайбкодят только 9. В госсекторе — единицы.
Пока остальные спорят, костыли это или нет — я берусь за реальный тендер и публикую всё как есть.
Подписывайтесь — первый пост как только войду в торги на понижение.
РБПО по ГОСТ Р 56939—2024: вебинар №08 из 30 – Формирование и поддержание в актуальном состоянии правил кодирования
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.8. – "Формирование и поддержание в актуальном состоянии правил кодирования". На YouTube. Слайды.
Цели восьмого процесса по ГОСТ Р 56939—2024:
Обеспечение эффективной и единообразной организации оформления и использования исходного кода в соответствии с предъявляемыми к ПО требованиями.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Автоматизируем процессы в VSCode с помощью расширения n8n-atom, которое заберёт всю рутину. Проект выдаёт цепочки из ИИ-агентов, действий и вызовов инструментов. Atom преобразует n8n-воркфлоу в обычные файлы, чтобы их могли читать нейронки вроде ChatGPT, Claude и Gemini. ИИ читает код пользователя, редактирует его и дает советы по оптимизации сервисов.
Оптимизация контекста для Claude Code на большом проекте (иногда и 50% экономия токенов)
Работаю над большим C++ проектом - реализация сетевого протокола. Использую Claude Code как основной инструмент. Со временем заметил: каждый новый чат начинается с того, что агент долго читает README.md, который разросся до 1000+ строк и 60 КБ.
Проблема
В CLAUDE.md была прописана команда читать README.md в начале каждого диалога, агенту нужно дать контекст проекта. Пока проект был небольшим это работало нормально. Но README рос вместе с проектом и в итоге стал содержать всё: архитектуру, логику DTLS, настройки веб-интерфейса, описание протокола, инструкции по сборке.
И как результат:
Агент тратит тысячи токенов на анализ файла до начала работы
Если задача касается только фронтенда, модель всё равно загружает детали реализации ядра протокола. Лишний контекст снижает точность ответов.
Решение
Вместо одного большого файла использовать иерархию маленьких, в отдельной папке claude-context/:
claude-context/ ├── context-claude.md # общая архитектура и навигация (~90 строк) ├── context-AC-claude.md # Access Controller ├── context-WTP-claude.md # WTP Agent ├── context-WEB-claude.md # Web Interface └── context-TESTS-claude.md # тесты
Главный файл context-claude.md содержит краткое описание проекта и таблицу-навигатор: какой файл читать для какой области. В дочерних файлах описана детализация по модулям, каждый 100-130 строк.
Инструкция в CLAUDE.md теперь выглядит так:
“Start each new conversation by reading claude-context/context-claude.md. For deeper context on specific areas, read the relevant file from that directory.”
Агент читает главный файл (90 строк), понимает область задачи, подгружает только нужный дочерний контекст.
Замер
Чтобы проверить эффект, я поставил Claude одну и ту же задачу в двух разных конфигурациях:
“Добавь тесты для WtpConfigController и WtpRadioController, проверь что если WTP address не строка, то возникает исключение std::runtime_error”
| Параметр | README.md (60 КБ) | Иерархический контекст | Разница | | :------------------- | :---------------- | :--------------------- | :------- | | Токены на сообщения | 36.8k | 17.6k | -53% | | Всего токенов | 56.7k | 37.6k | -34% | | Рост usage за задачу | +11% | +6% | В 2 раза | | Скорость анализа | Заметная пауза | Почти мгновенный старт | |
Важный момент
README.md остался нетронутым - это документация для людей. Файлы в claude-context/ - отдельный артефакт, написанный под AI: плотно, без лирики, с ASCII-схемами и таблицами. Я старался не смешивать два разных назначения в одном файле.
При небольшом проекте в этом подходе смысла нет, накладные расходы на поддержку двух наборов документации не оправдаются.
РБПО по ГОСТ Р 56939—2024: вебинар №07 из 30 – Моделирование угроз и разработка описания поверхности атаки
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.7. – "Моделирование угроз и разработка описания поверхности атаки". На YouTube. Слайды.
Цели седьмого процесса по ГОСТ Р 56939—2024:
5.7.1.1 Создание условий для снижения количества недостатков, связанных с особенностями реализации архитектуры ПО и логики его функционирования, выработка мер по нейтрализации угроз безопасности, связанных с особенностями реализации архитектуры ПО.
5.7.1.2 Уточнение модели угроз и описания поверхности атаки по результатам разработки кода и его изменений.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
РБПО по ГОСТ Р 56939—2024: вебинар №06 из 30 – Разработка, уточнение и анализ архитектуры программного обеспечения
Прошёлся сегодня по использованию вайб-кодинга без соответствующих мер контроля результата – Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом. А теперь продолжим тему, как создавать качественные, надёжные и безопасные приложения. Это всё, кстати, актуально и для веб-кодинга, но, к сожалению, пока мало кто это осознаёт :(
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.6. – "Разработка, уточнение и анализ архитектуры программного обеспечения". Слайды.
Цели шестого процесса по ГОСТ Р 56939—2024:
5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.
5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Из сильного специалиста — в руководителя: 11 открытых уроков про управление, архитектуру и карьерный рост
Управленческие и околоуправленческие роли в IT давно перестали быть только про «руководить людьми». Сегодня это и делегирование, и продуктовые границы, и работа с рисками, и архитектура изменений, и умение принимать решения в условиях дефицита.
Ниже — подборка ближайших бесплатных открытых уроков для тех, кто хочет разобраться в этих задачах предметно.
① Управление командой
➡ 22 апреля, 20:00 — «Делегирование без боли: как перестать быть „главным исполнителем“ и не скатиться в микроменеджмент»
Для тех, кто уже руководит или только переходит в управление и хочет перестроить свою роль без потери контроля.
➡ 28 апреля, 20:00 — «Коучинговые инструменты для мотивации и повышения продуктивности команды»
Если хочется не просто ставить задачи, а реально влиять на вовлеченность и результат команды.
➡ 30 апреля, 20:00 — «Как управлять тимлидами?»
Урок для тех, кто уже управляет не только исполнителями, но и руководителями внутри команды.
② Карьерный рост в управление
➡ 29 апреля, 20:00 — «Разрешите себе карьеру технического директора»
Полезно тем, кто уже вырос из роли сильного технического специалиста и думает о следующем карьерном шаге.
➡ 30 апреля, 19:00 — «МОК‑интервью на позицию Руководитель Проектов»
Практический формат для тех, кто готовится к переходу в управление проектами или хочет проверить себя на интервью.
➡ 12 мая, 18:00 — «Какие метрики использует технический директор?»
Для тех, кто хочет понять, как на уровне CTO смотреть на эффективность команды, процессов и продукта.
③ Продукт, проекты и аналитика
➡ 29 апреля, 20:00 — «Продакт‑менеджер, маркетолог и PMM — в чём разница»
Хороший урок для тех, кто работает на стыке продукта, маркетинга и стратегии и хочет лучше понимать зоны ответственности.
➡ 7 мая, 20:00 — «Как бизнес‑аналитик управляет рисками при разработке IT‑продукта?»
Полезно тем, кто хочет глубже разобраться, как аналитика влияет на устойчивость и качество продуктовой разработки.
➡ 12 мая, 19:00 — «Управление ресурсами в условиях жестокого дефицита»
Актуально для тех, кто работает в условиях перегруженных команд, ограниченного бюджета и постоянных компромиссов.
④ Архитектура и изменения
➡ 30 апреля, 19:00 — «От стратегии к портфелю изменений: как архитектор связывает цели бизнеса, инициативы и архитектурные решения»
Для тех, кому важно понимать архитектуру не только как набор схем, а как инструмент управления изменениями.
➡ 14 мая, 19:00 — «Архитектор как модератор изменений: как проводить архитектурные решения через стейкхоледеров»
Для тех, кто хочет лучше понимать, как продвигать решения в сложной организационной среде, а не только проектировать их.
﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋
Открытые уроки — хороший способ присмотреться к теме. А если хотите пойти дальше, можно посмотреть весь каталог программ по управлению в IT и выбрать подходящее направление под свои задачи.
Мониторинг логов с автоматическим исправлением проблем
И так, раньше надо было использовать различные отдельные инструменты для мониторинга логов (Zabbix и прочее), чтобы в крайнем случае сделать reboot отдельных компонентов или всей системы.
Но оказалось, можно отдать задачу ReAct боту типа OpenClaw (мы используем версию B2B). Он может проверять логи хоть каждые 2 минуты. Тонны токенов здесь не тратятся, он также просто делает поиск по ключевым словам. И важно, что он сам может подобрать ключевые слова и обновлять этот набор исходя из типа логов.
Дальше больше - он может не просто сделать reboot, он может исправить проблему прямо в коде, или сделать откат в git, если поймет, что это проблема новой версии 🔥
Ну то есть, по сути это полноценный support+разраб 24x7, работающий за миску токенов. Да, важно прописать ему некоторые правила (когда то-то делай так, когда это делай сяк), по сути, вашу политику работы с Prod.
Еще полезный кейс: WP умер, перевёл все сайты на OpenClaw.
РБПО по ГОСТ Р 56939—2024: вебинар №05 из 30 – Управление недостатками и запросами на изменение программного обеспечения
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.5. – "Управление недостатками и запросами на изменение программного обеспечения". Слайды.
Цели пятого процесса по ГОСТ Р 56939—2024:
5.5.1.1 Обеспечение управления недостатками ПО.
5.5.1.2 Обеспечение управления запросами на изменение ПО.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Представлен открытый проект AI Marketing Skills, который позволяет использовать Claude Code в качестве маркетингового агентства. Этот ИИ-навык поможет маркетологам, таргетологам, СММ-специалистам или контентщикам в десятки раз повысить свою эффективность.
Сервис открывает доступ к команде ИИ-специалистов: стратегия, комплексный маркетинг, привлечение трафика, контент, поиск продающих связок, сценарии коротких видео, SEO, аналитика и автоматизация, продажи, общение с клиентами. Проект может продвигать любой продукт в одиночку. Решение подойдёт для фрилансеров, которые хотят либо набрать ещё с десяток новых проектов и вырасти в доходе, либо делегировать нейронкам рутинные задачи.
