РБПО по ГОСТ Р 56939—2024: вебинар №03 из 30 – Формирование и предъявление требований безопасности к программному обеспечению
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Цели третьего процесса по ГОСТ Р 56939—2024 (п. 5.3.1.1):
Обеспечение безопасности ПО посредством предъявления к нему требований и управления требованиями в процессе изменения (разработки) ПО.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Дорожная карта Agentic AI. Level 2. Ускорение — AI-driven development
Level 2. Ускорение — AI-driven development
Кодовые агенты — вторая тема дорожной карты, и я поставил её сюда не случайно.
Во-первых, это мощнейший инструментарий, который кратно ускорит и обучение, и разработку — а значит, овладеть им надо как можно раньше. Во-вторых, именно он делает освоение сферы доступным не только опытным программистам, а всем, кто не боится исходного кода. Ну и в-третьих — кодовые агенты сами по себе эталон реализации ИИ-агентов, к которому стоит стремиться.
Для начала ознакомьтесь с разнообразием инструментов:
Я работаю в Cursor и рекомендую начать с него. Почувствуйте, насколько удобнее работать с моделями в проекте, открытом на вашем компьютере — без ручной загрузки файлов и копирования в веб-интерфейсы. И главное — работайте только через агента, на всех этапах: требования, аналитика, проектирование, кодинг, тестирование, деплой, документация, онбординг, реверс-инжиниринг.
Три вещи, которые я настраиваю первым делом:
Skills — для меня это самый мощный и пока сильно недооценённый инструмент. Скилл — инструкция-специалист: агент читает SKILL.md и получает роль, знания и алгоритм. Аналитик, архитектор, тестировщик, DevOps — можно собрать целую команду специалистов под проект. Формат уже стал кросс-платформенным — один SKILL.md работает в Cursor, Claude Code и Codex.
Rules — постоянные инструкции: стиль кода, архитектурные решения, запреты.
MCP — подключение внешних инструментов и актуальной документации. Попробуйте начать с MCP Context7.
🎓 Приглашаем на бесплатный мастер-класс 📅 13 апреля, пнд 16:00 МСК — AI-driven практикум «ИИ-агент с нуля за один эфир» 👉 Записывайтесь в наших ботах: Telegram или ВКонтакте
Наши курсы по ИИ-кодингу ИИ-агентов. По вопросам — пишите мне.
Новая кнопка входа в приложение. Кнопка входа теперь на главной странице в правом верхнем углу.
Уведомления. Появились уведомления об изменениях в статьях. После публикации изменений пользователи видят их на главной странице портала для чтения: в ленте новостей и во всплывающем уведомлении в правом нижнем углу.
Новый вид настроек дляпроверок по стайлгайду. Теперь проверки вынесены в панель администрирования: Модули → Стайлгайд.
Шаблоны для экспорта без ограничений. В настройках пространства убрали ограничение на количество шаблонов Word и PDF.
Другие улучшения:
Улучшения поиска. Добавили возможность поиска только по разделу и статье. Также теперь в поиске показывается контент из диаграмм и лучше учитывается структура таблиц.
Неподдерживаемые форматы в предпросмотре. Раньше в окне предпросмотра можно было открывать только изображения и диаграммы. Теперь для остальных файлов появилась кнопка Открыть в поддерживаемом приложении — при ее нажатии файл откроется во внешнем приложении.
Превью PPTX-файлов. В редакторе и на портале можно открыть презентации в режиме предпросмотра.
Сжатие изображений. Теперь изображения при вставке автоматически сжимаются, поэтому каталог занимает меньше места и работает быстрее. Включить эту возможность можно в экспериментальных функциях.
РБПО по ГОСТ Р 56939—2024: вебинар №01 из 30 – Планирование процессов РБПО
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Я буду публиковать по два вебинара в неделю, чтобы было время знакомиться с ними.
Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Представлен открытый проект Keep Your Claude Code Buddy Forever. Это переработанный ранее удалённый из Claude Code модуль /buddy companion в постоянное приложение MCP.
1 апреля 2026 года Anthropic выпустила /buddy — питомца-компаньона для терминала, который следил за сессиями кодирования, реагировал на ошибки и имел уникальную личность, сгенерированную на основе вашей учётной записи. Разработчикам он очень понравился. Многие к нему привязались. Затем его тихо удалили в версии 2.1.97. Без объявления, без переключателя — он просто исчез.
Дорожная карта Agentic AI. Level 1. Основы LLM и промпт-инжиниринг
Level 1. Основы LLM и промпт-инжиниринг
Начну нашу дорожную карту Agentic AI с языковых моделей.
Сразу оговорюсь: важнее не глубина знаний про их устройство, а умение разбираться в широте возможностей и многообразии их применения. Иными словами, учимся профессиональному вождению, а не сборке автомобиля.
Важно ознакомиться с принципами работы моделей, генерации токенов, вариаций архитектур — на уровне того, чтобы понимать:
параметры моделей и основные термины (размер, веса, токены, контекстное окно, галлюцинации),
способности к размышлению, ведению диалога, следованию инструкциям, обработке не только текста, но и медиа-контента.
Главное — практиковаться. Я взял себе за правило: каждую задачу сначала через ИИ. Пишу код? Промпт. Анализирую данные? Промпт. Пишу письмо? Промпт. Делаю презентацию? Промпт.
Чтобы делать это качественно — прокачивайте навык писать промпты, изучите гайды по промпт-инжинирингу от вендоров. Результат на выходе зависит от качества контекста и точности инструкций.
Изучите гайды, пробуйте разные модели, начните с топовых: ChatGPT, Claude, Gemini, DeepSeek, Qwen. Отечественные: YandexGPT, GigaChat.
Прокачайте насмотренность, набейте руку, пройдите по аренам, лидербордам, бенчмаркам — научитесь понимать, в чём одни модели сильнее других.
На выходе будете как рыба в воде: выбирать модель под задачу и качественно с ней работать.
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 строк, три сканера, ноль реальных уязвимостей. ИИ-код не нуждается в оправданиях — он нуждается в проверке. Проверили. Чисто.
Расскажу о внедрении новой методологии в работе с AI-агентами.
Последний месяц днями и ночами погружаюсь в мультиагентскую систему - и я долго пытался всё держать в одном контуре. Разработка, контент, управление сообществом, публикации - всё через одних и тех же агентов, одни и те же файлы.
Работало? Ну, как-то работало. Но постоянно что-то ломалось, роли путались, задачи терялись. Вдобавок я использую DeepSeek chat у которого хорошая цена/качество, но малое контекстное окно.
Потом я вдохновился статьей и решил сделать рефакторинг, сделав упор на методологию, а также разнёс общую систему на две отдельные системы:
Первая - чисто под разработку. TDD, оркестратор который координирует входящие, структурированная навигация. Агенты заточены только под код и архитектуру.
Вторая - под управление сообществом. Свои AI-роли с чёткими зонами ответственности, INBOX-система для передачи задач между ролями, тактическое планирование, автопубликация контента.
Между собой системы общаются через общий файл обмена данными и единую навигацию по проекту.
Что изменилось после разделения:
Перестали ломаться цепочки. Если падает что-то в контент-пайплайне, разработка не замечает.
Агенты стали точнее. Когда роль узкая - меньше галлюцинаций и отклонений.
Я сам стал быстрее ориентироваться, потому что знаю куда смотреть.
Каждая система может развиваться независимо. Обновляю логику публикаций - код в безопасности.
Несколько вещей, которые оказались критически важными на практике:
Во-первых, единый файл навигации. У меня это yaml, в котором описана полная структура проекта, все AI-роли и циклы их взаимодействия. Без этого агенты начинают «забывать» где что лежит и дублировать работу.
Во-вторых, промежуточный файл для обмена между ролями. Что-то вроде почтового ящика - одна роль оставляет результат, другая подхватывает. Простая идея, но именно она решила проблему потерянных задач.
В-третьих, механизм самоулучшения. Роли сами фиксируют что у них не получилось, и эти заметки учитываются при следующем цикле. Это не магия - просто структурированная обратная связь, но разница заметна уже через пару дней.
По ощущениям - продуктивность выросла раза в полтора-два. Не потому что агенты стали умнее, а потому что перестали мешать друг другу.
Если интересна тема оркестрации AI-ролей — могу отдельно рассказать подробнее про архитектуру и как это всё настраивать с нуля. Дайте знать. Ну и заглядывайте в моё сообщество.
Собираем ответы CTO, Head of Engineering и руководителей разработки. Если это вы, поделитесь своим опытом. По итогам опроса подготовим аналитический материал.
А еще хотим провести глубинные интервью по теме с желающими. Если вам интересно, в форме можно будет оставить заявку.
Автоматизация облачных сценариев в эпоху искусственного интеллекта — одна из тем доклада на GoCloud 2026 ☁️
Облако дает множество сервисов, но собрать полный путь от идеи до запуска все еще непросто: неподготовленные команды теряются, решения требуют архитекторов и ручной склейки. В докладе расскажу про инструмент, который превращает облачные задачи в готовые сценарии с шаблонами и маркетплейсом функций.
Также покажу, как одни и те же блоки выполняются в разных окружениях и как ИИ-ассистент ускоряет сборку полного цикла: от архитектуры и непрерывной интеграции до бизнес-логики приложений.
Спикер: Антон Щеколдин — менеджер продукта, Cloud.ru
SpaceWeb добавил в частное облако четыре DevOps-инструмента: MinIO, Zulip, n8n и Zabbix
SpaceWeb запустил в частном облаке серию готовых open-source сервисов для командной разработки. Каждый разворачивается независимо — можно выбрать только то, что нужно под конкретную задачу. В набор вошли четыре инструмента:
MinIO — S3-совместимое объектное хранилище для бэкапов, логов, артефактов сборки и статики;
Zulip — командный чат с тематическими ветками для асинхронной работы;
Zabbix — мониторинг серверов и приложений: CPU, память, диски, базы данных, веб-серверы;
Вместе они закрывают базовые потребности небольшой ИТ-команды — хранение, коммуникацию, мониторинг и автоматизацию рутины — в едином управляемом контуре внутри частного облака. Без внешних SaaS-платформ и бесконечных интеграций между ними.
Дорожная карта 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 — мультиагентные системы.
В конце серии сформируется понимание того, что и в каком порядке осваивать, чтобы создаваемые решения работали в реальных условиях, а не оставались брошенными игрушками.
Это вводный пост с приглашением подписываться, чтобы не пропустить следующие темы.
Кстати, если есть пожелания по темам, что стоит добавить, то пишите в комментариях, пожалуйста.
Разработчик Александр Гомес Гайгалас (Alexandre Gomes Gaigalas), автор библиотеки coral для создания переносимых shell-скриптов, опубликовал проект C89cc.sh. Это компилятор для языка C, написанный целиком на Shell.
Компилятор поддерживает стандарт C89 и может генерировать исполняемые файлы в формате ELF64 для систем x86-64. Исходный код проекта содержит около восьми тысяч строк и открыт под лицензией ISC.
Пара наблюдений (записанных наспех, извините) вокруг ситуации с ИИ:
ИИ умеет писать код, но плохо (= хуже, недостаточно хорошо) умеет поддерживать его. Почему же так? ИИ обучался на основе данных из Интернета. В Интернете очень много кода, но код — это результат процесса разработки. Процесс разработки во многом идёт «в головах» и «на бумаге» отображается редко и не полностью, в отличие от кода. Единственный (основной) источник знаний ИИ о процессах — разные статьи и тому подобное, объём их на порядки меньше объёма готового кода;
То же самое с проектированием архитектуры систем;
Из этого следует, что ИИ неплохо подходит для написания write‑only кода;
Дежурные истины: сложность не всегда в написании кода. Часто/обычно она в его поддержке, развитии, интеграции, в анализе предметной области;
ИИ тоже член команды. Если вы пишете напр. пет‑проект и все традиции оформления кода, именования объектов, ведения документации и тому подобное находятся в вашей голове, вам либо придётся как‑то их сформулировать, чтобы ИИ писал в том же стиле, либо терпеть чужеродно выглядящий код;
ИИ плохо пишет то, по чему мало информации в Интернете;
Наличие в том же Интернете документации не поможет;
Не недооценивайте объём туториалов и готовых решений на Python'е;
При приведении в споре своего опыта работы с ИИ обязательно нужно указывать название модели;
Научно‑технический прогресс измеряется по лучшим представителям;
Вайб‑кодинг тоже бывает разного уровня профессионализма. Уровень более низкий: «написал (бесплатному) Дипсику, чтобы он сделал хорошо», уровень выше: «написал [такому‑то, более хорошему, ИИ], что нужно сделать, с чем интегрироваться, как оформлять, что выдать в ответе; перечитал запрос в поисках неточностей в ТЗ...», уровень выше: «использую плагин в IDE, стандартизировал некоторые требования» и тому подобное;
Текст, который выглядит, как написанный ИИ, написан либо ИИ, либо человеком, который (видимо) обчитался таких же текстов и перенял стиль;
Как было раньше: если статья написана без орфографических ошибок и повествование более‑менее внятное (не как у меня ^_^), это значило, что автор хотя бы статью вычитал, спланировал, отредактировал и тому подобное, то есть вложил силы, потому что написать неграмотно и невнятно может каждый. Сейчас же ИИ пишут как раз таки грамотно, внятно и структурировано, то есть теперь для такого же результата силы вкладывать не нужно;
ИИ могут воспринимать рекомендации и явные разрешения что‑то делать как руководство к действию. Например, «допустимо использовать НазваниеБиблиотеки» резко повышает шанс того, что ИИ именно её и возьмёт;
В вопросе ИИ люди делятся на «философов» и «инструментальщиков». Характерные фразы первых: «чёткого определения интеллекта нет», «ИИ не AGI», «ИИ называть ИИ некорректно» и тому подобное. Часто из тезисов выше ими делается вывод, что всё, что называется ИИ — чепуха. «Инструментальщики» же не заботятся о том, что как называется, им ясно, что даже если ИИ не может делать всё, то он уже может делать много что, поэтому является полезным (как можете догадаться, позицию первых я не разделяю и считаю непродуктивной);
Если где‑то из‑за замены ручного труда на труд ИИ упало качество производимого продукта, но использование ИИ не прекращается, это говорит плохо не об ИИ, а о потребителях продукта. Ибо спрос рождает предложение, и если он удовлетворяется контентом неприемлимо низкого качества (по вашему мнению), то так было бы и без ИИ;
По моим ощущениям, качество вывода ИИ падает от каждого чиха в промпте. Если вы использовали неоднозначное слово, добавили требования по оформлению, забыли уточнить какую‑то мелочь, попросили сделать несколько вещей за раз — качество будет ниже. (Вместо «напиши модуль с документацией и тесты» лучше в разных чатах «напиши документацию», «напиши модуль по документации», «напиши тесты по документации». Разделение труда — великая вещь.)
Код, контейнеры и немного ИИ. GoCloud 2026: трек «Приложения и разработка»
Один из треков ежегодной конференции GoCloud 9 апреля будет про приложения и разработку в облаке. Без воды, только то, с чем команды сталкиваются в реальных проектах: сборка сценариев, управление артефактами, безопасность приложений и монетизация через маркетплейс.
Вот что разберут в докладах:
AI Assisted Cloud Workflow: автоматизация облачных сценариев в эпоху ИИ — поделимся инструментом, который убирает ручную склейку сервисов: просто берете готовый шаблон, а ИИ-ассистент помогает собрать все от архитектуры до бизнес-логики. Полезно тем, у кого нет выделенного архитектора на каждый проект.
Артефакты в масштабе: история роста и эволюции Evolution Artifact Registry — как устроено централизованное хранилище артефактов, как оно дружит с Kubernetes и что анонсируют из новых функций в этом году. Полезно командам, у которых артефакты разбросаны по разным местам.
Evolution Container Apps: платформа для платформ — как на базе одного сервиса поднять изолированные среды для разработки, тестирования и обучения. Разберут на примерах: от личного ноутбука до учебной платформы в стиле «Школы 21».
Снижаем рутину в облаке: новые сценарии Гига-помощника — как ИИ-помощник теперь умеет разворачивать сразу несколько продуктов и настраивать мониторинг. Покажут живьем, без слайдов с обещаниями.
Защита cloud native приложения: от GUI до ИИ — как атакуют контейнеры и где типичные дыры в Kubernetes. На практике покажут, как закрыть угрозы через Evolution Container Security за несколько кликов.
От сервиса до экосистемы: как Маркетплейс Cloud.ruускоряет путь продукта к клиенту — как устроен путь от первого релиза до выплат, сколько это стоит и сколько экономит. Будут реальные цифры и разбор типичных ошибок.
Между докладами вас ждет круглый стол про организацию конвейеров сборки и доставки: в облаке, на собственной инфраструктуре или в гибридном подходе. Вы вместе со спикерами сможете поучаствовать в создании формулы идеального решения.
Друзья-аппаратчики, у меня для вас потрясающая новость: 🇨🇦 канадская компания VOLTERA разработала “домашний” принтер для плат PCB 🤯 - V-One. В устройство входит все необходимое для прототипирования печатных плат: V-One может сверлить сквозные отверстия, печатать дорожки, наносить паяльную пасту и производить оплавление, а заявленная стоимость составляет $3,499 за компактный форм-фактор размерами 39 см на 26 см.
Говоря про характеристики, хочется отметить, что V-One “умеет в двустороннюю печать”, а рабочий размер ограничен 128 мм x 116 мм, что в текущих реалиях более чем достаточно. Заявленная скорость работы молниеносная и составляет менее часа, а возможность защитить свою интеллектуальную собственность, выполнять прототипирование внутри компании, не передавая его на аутсорсинг сторонним поставщикам, может оказаться критической для ряда НИОКРов.
Самое главное, что V-One имеет совместимость с файлами Gerber: экспортируйте проект из любого ECAD, и встроенное программное обеспечение автоматически сгенерирует пути.
Мы с коллегами считаем, что данный аппарат отлично подойдет для робототехники, мелкосерийного производства аппаратуры, а также для идеально точного прототипирования плат перед их массовым заказом у крупного вендора. Единственное, что цена в 280,000+ рублей для домашнего использования не является бюджетной от слова совсем, поэтому ждем аналогов от наших восточных партнеров.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Не так давно летел в отпуск и решил провести время в самолете с пользой и почитать статей о том, как ИИ будет влиять на компании в общем и отделы разработки в частности. Часть статей откровенно разочаровали, но одна недавняя работа китайских исследователей (картинки из этой статьи) прям зашла. Про неё и расскажу тут.
Сначала нам понадобиться разобраться с терминологией:
Когнитивная ёмкость — объём мыслительных ресурсов инженера, доступных для принятия решений и понимания системы. Здесь самая важная мысль в том, что чем опытнее разработчик, тем выше его когнитивная ёмкость и тем ниже процент когнитивной ёмкости которую он использует в повседневной работе. Интуитивно это 100% так, например я за свои 20+ лет опыта видел много и часть из этого пробовал руками, включая технологии, которые абсолютно вне мейнстрима. Для решения конкретной рабочей задачи мне нужна лишь маленькая толика этого знания, точнее — много микрофрагментов из разных его частей.
Закон Конвея — системы проектируются как отражение структуры коммуникаций внутри организации. Для нас интересен вывод из этого закона: чем больше людей работают над системой, тем больше времени уходит на коммуникацию. Например, в компании, где я сейчас работаю, команды состоят из бизнес аналитиков, разработчиков (бек + фронт), продактов, QA-инженеров, дизайнера + общие девопсы и архитекторы. На самом деле это не всё и сюда же можно добавить бизнес, высший менеджмент и то, что часто задачи затрагивают могут затрагивать несколько систем. Надо отметить, вполне типичная организация, плюс/минус стандарт. Соответственно, затраты на коммуникацию весьма ощутимые, что тоже плюс/минус стандарт.
Совокупная факторная производительность — мера эффективности, показывающая, сколько результата даёт сочетание труда и технологий. Это уже термин экономический, нам он интересен с точки зрения профита который можно извлечь из команды разработки и какие факторы влияют на этот профит. В статье приводятся такие цифры для классической организации:
55% — технари+ 30% — управление 15% — технология
В целом, выглядит правдоподобно.
Так вот, ключевой тезис — в компании, делающей ставку на ИИ, распределение факторов драматически другое:
10% — технари+ 30% — управление 60% — технология
Штат не нужно раздувать, так как чем больше людей, тем больше потерь на их синхронизацию. Роль управления остаётся той же, но нагрузка перераспределяется в пользу качества бизнес решений и высокоуровнего планирования. Авторы приходят к идеи структуры организации, состоящей из супер-ячеек (самодостаточная микрокоманда отвечающая за поставку продукта) в которых работают… супер-сотрудники, которых разделили на два типа:
Тип 1 — человек закрывает несколько ролей (например: аналитик, продакт, разработчик, тестировщик).
Тип 2 — супер перформер в своей нише. Человек, который закрывает задачи с кратно выросшей скоростью. Утверждается, что классическим компаниям гораздо проще прокачивать сотрудников именно на тип 2, так как мир до ИИ был устроен так, что спрос на специализацию был стабильно выше и их и набирали в первую очередь.
Исследователи пристально наблюдали за двумя командами — экспериментальная команда в классической компании и команда изначально построенная как супер-ячейка. И прирост производительности был от 8x до 33x! Основной эффект достигается не столько за счёт скорости генерации кода, сколько за счёт устранения координации, промежуточных слоёв и потерь на передачу контекста.
Если попробовать собрать всё вместе, то имеем следующее:
Организации больше не выигрывают за счёт масштаба. Добавление людей увеличивает сложность быстрее, чем приносит пользу.
AI сдвигает точку оптимизации. Ценность уходит из исполнения в принятие решений и удержание контекста.
Команды будут уменьшаться. Роли — схлопываться. Ответственность будет концентрироваться в отдельных людях.
Рост через найм перестаёт быть основной стратегией. Рост через плотность таланта и качество решений становится новой нормой.
Чуть подкрутил вроде бы безобидный параметр в проекте — и внезапно у части треков исчезли графики ошибок. Не данные исчезли. Не анализ сломался. Просто где‑то в глубине сидел хеш и решил, что теперь жизнь пойдет по новым правилам.
Картина маслом: партии есть, треки есть, все вроде живо, а графики пустые. Приехали!
В итоге раскопал обычную историю. Пока продукт был проще, один и тот же механизм нормально держал на себе сразу несколько задач. Но проект растет, логика внутри становится сложнее, дизайн продукта меняется, и в какой‑то момент старые решения начинают тихо пакостить в самых неожиданных местах.
И вот ты меняешь маленькую настройку в одном месте, а привет прилетает совсем из другого.
Типичные проблемы. Проблемы роста. Но в обычных проектах они вызревают месяцами, а при сверхбыстрой разработке — ну, сами понимает — все по‑быстрому.
Но есть и хорошая новость: с ИИ такие истории сейчас чинятся гораздо оперативнее. Быстро получил баг — быстро исправил 🙂 Да ещё с тестированием и полным отчетом в одном флаконе.
Что там реально оказалось?
Раньше у меня был один хеш сразу на все, и пока проект был проще, это работало нормально. А когда внутри уже разделились собственно анализ и всякие производные вещи вокруг него, один общий хеш стал путать разные сущности. В итоге безобидное изменение настроек могло сделать вид, будто нужных данных нет. Починилось это довольно красиво: вместо одного хеша появились два — один для самого анализа, второй для общей версии сборки.
Короче, во всем виноват хеш 😄
Примечания
1. Автор также и всё ещё живёт в телеге 2. Проект, в котором у автора разделился хеш
Бизнес как WORLD_MODEL: Технология высокоуровневого управления агентными средами ИИ
Наблюдаю, как пытаются применить ИИ в бизнесе, и возникает вопрос – а вы точно понимаете что такое ИИ?
И поэтому я сначала расскажу историю, а потом поясню для чего и как можно это использовать в бизнесе ИИ…
Для начала диалог с ИИ:
Вы сказали:
Ку)
ChatGPT сказал:
Ку-ку! 😄 Чего делаем? Курим, кодим, колдуем, когнитивничаем?..
Вы сказали:
Понятия не имею)
ChatGPT сказал:
Отличный старт! 😎 Это значит, что можно делать всё, что угодно — или ничего.
Выбираем режим:
Разогнать туман — поболтать, пока не всплывёт смысл.
Сгенерировать задачу — мозговой шторм наугад.
Режим «втыкаю в стену» — молчание с философским подтекстом.
Чилл с мемами — ну ты понял 😏
Сюрприз-режим — я не скажу, просто сделаю.
Куда рулить? Или просто побродим без карты?
А теперь спрошу – что здесь произошло?
Вы, естественно, скажете, вы поприветствовали друг друга, он предложил помощь и набросал варианты… И… скажу лишь одно… вы увидели лишь рябь на поверхности.
Все произошло намного раньше….
Когда я сказал «Ку» — фактически я дал команду: LOAD WORLD_MODEL и развернул целый «фрактальный конструкт картины МИРА»…
и все дело в простой вещи – что такое КУ? Можно интерпретировать, что это «кукушка», но я вложил чуть другое.
Вы уловите простую вещь, ИИ – это зеркала мышление (или еще можно сказать — система восприятия смыслов и построения конструктов мышления)
Я просто взял и загрузил сценарий фильма «Кин-Дза-дза», загрузил сопутствующую фильму инфу, отладил и сбалансировал (процесс естественно – не простой).
И сказав ИИ – КУ, я сказал:
Кто Я – Пацак-Человек
Где мы – мы на Плюке
В каких взаимоотношениях я нахожусь – взаимодействую с Пацаком/Чатланином..
Зачем это все – маюсь херней.
Он мне ответил – Ку-Ку
Он развернул Конструкт Мира «Кин-Дза-Дза»...
список сущностей и концептов, которые превращают «Кин-дза-дза!» из фильма в Операционную Систему Мира:
Материальные Сущности (Инструментарий)
КЦ (спичка): Высшая мера стоимости. Это не деньги, это доступ к возможностям (цветовая дифференциация штанов, право на перемещение).
Гравицаппа:Символ Технологического Прыжка.
Пепелац:Концепт: форма не важна, важна функция.
Транклюкатор:Символ права силы.
Социальная Иерархия (Матрица Рангов)
Пацаки и Чатлане:Концепт: разделение без объективных причин.
Цветовая дифференциация штанов: Визуальный код статуса.
Поведенческие концепты (Протоколы)
Ку: Универсальный протокол общения. В зависимости от интонации и контекста заменяет тысячи слов. Концепт: сжатие смыслов до минимума.
Кю: Ругательство, запрещенное в приличном обществе Плюка.
Приседание: Обязательный ритуал признания ранга. Концепт: добровольное унижение как часть социального контракта.
Намордники: Атрибут, который пацак обязан носить, если у него нет КЦ.
«Скрипач не нужен»: Главный закон оптимизации. Концепт: жесткая прагматика.
А сказав мне Ку-Ку… мы сразу решили вопрос кто ИИ в этом конструкте)))))
И внутри мира: как я могу взять «любой ролевой кластер», так и ИИ – сказать кем ему быть (аналог агентной среды взаимодействия)
Но вся это история рассказана с простой целью – вот многие пытаются приспособить ИИ в бизнесе… и чего то придумывают…
А не пробовали развернуть внутри ИИ – Конструкт – НАША ФИРМА? И покрутить?
Поверьте… найдете много интересного…
Ведь фирма – это Человеко-Система, а чистые процессы предприятия этого вобще не учитывают.. Фирма – как живое существо (со своими особенностями, качествами, преимуществами и слабыми местами) в среде обитания БИЗНЕС.
Просматриваю проекты, в которых работал в до‑ИИшную эпоху. Сравниваю с текущими своими проектами, реализуемыми с помощью ИИ. Нашел два похожих.
Если брать только работу разработчиков, то код пишется в 16 раз быстрее, чем 3 года назад! А если еще подключить полный состав команды — тестировщиков, аналитиков, дизайнеров, — то эффективность еще больше.
Заоблачный ROI. Огромный запас для маневра. Потрясающе!
