1 из 10 разработчиков ничего не делает на работе. Разбираемся с исследователем из Стэнфорда
В этом выпуске AviCast — разговор с Егором Денисовым-Бланшем, исследователем продуктивности из Стэнфорда. Он проанализировал данные 100 000 сотрудников из 600 IT-компаний по всему миру и выяснил: 10% разработчиков фактически не вовлечены в работу.
Артём Арюткин, CPO технической платформы в Авито, расспросил Егора, как вообще измерить продуктивность в разработке, почему привычные метрики (закрытые тикеты, коммиты, строки кода) не работают и даже вредят, и как AI меняет работу команд и качество кода.
Обсудили: — как считали 1 из 10 и что это на самом деле значит — какие метрики продуктивности работают, а какие ломают команду — риски и подводные камни внедрения AI в разработку
В сентябре покажем, как за пять дней построить Data Lakehouse, защитить данные при работе с LLM, выстроить безопасную ИИ-инфраструктуру и обеспечить отказоустойчивость PostgreSQL для продакшен-нагрузок. Выбирайте интересную тему и регистрируйтесь.
Как построить управляемый Data Lakehouse за неделю на Evolution Data Platform Покажем, как за несколько дней с нуля построить архитектуру Data Lakehouse на Evolution Data Platform — от загрузки сырых данных до курированных витрин. Разберем принципы работы с Apache Iceberg, централизованное управление метаданными, контроль качества данных, единый SQL-слой и оркестрацию пайплайнов. Все увидите на демо. 🧑💻 Для кого: архитекторы данных, дата-инженеры, руководители аналитики и data-направлений, ИТ-директора, специалисты по управлению данными. 📅 Когда: 8 сентября, 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
Как защитить чувствительные данные при работе с LLM с помощью Guardrails Разберем, как работают Guardrails LLM и Guardrails Filter: чем они отличаются, какие данные помогают обнаруживать и как адаптировать правила проверки под задачи компании. Отдельно рассмотрим, как защитный слой Guardrails работает в контуре Evolution Foundation Models, а также какую роль в проверке запросов играют модели-классификаторы HiveTrace. На демо покажем работу open source версии Guardrails Filter. 🧑💻 Для кого: специалисты по защите данных и ИБ, команды разработки ИИ-приложений и тем, кто внедряет LLM в бизнес-процессы. 📅 Когда: 15 сентября, 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
ИИ в облаке: кто отвечает за безопасность Безопасность ИИ в облаке — это общая ответственность провайдера и бизнеса. Разберем, где проходят границы этой ответственности и как выстроить безопасную ИИ-инфраструктуру без лишних рисков. Обсудим подход Zero Trust: расскажем, как контролировать доступ к данным, моделям и сервисам в Cloud.ru Evolution и какую роль в этом играет Evolution Managed Identities (IAM). 🧑💻 Для кого: руководители и специалисты по ИБ (CISO), архитекторы и инженеры, проектирующие ИИ-инфраструктуру, специалисты, работающие с чувствительными данными, руководители, отвечающие за внедрение ИИ в компании. 📅 Когда: 17 сентября, 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
PostgreSQL для продакшен-нагрузок: Multi-AZ, реплики и переключение ролей От доступности PostgreSQL зависит стабильная работа backend-сервисов и пользовательских сценариев. Разберем, как обеспечить высокую доступность PostgreSQL в облаке. Покажем, как в Evolution Managed PostgreSQL устроена архитектура Multi-AZ, какую роль играют реплики базы данных и как работают ручное и автоматическое переключение при плановых работах и сбоях. 🧑💻 Для кого: DevOps-инженеры, SRE-инженеры, инфраструктурные инженеры и все технические специалисты, работающие с PostgreSQL. 📅 Когда: 29 сентября, 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
Представлен открытый проект vphone-cli для загрузки виртуального iPhone с помощью фреймворка Virtualization.framework от Apple, используя инфраструктуру виртуальных машин PCC Research.
Представлен открытый онлайн проект The load‑bearing vocabulary of Claude (репозиторий решения на GitHub). «Мы ежедневно анализируем 100 запросов на слияние (Pull Requests) на GitHub, чтобы изучить тенденции Claude в словарном запасе. Это отражает способ написания, который становится распространённым, и слова в нём — это слова, которые пользователи ассоциируют с определённым способом общения с ИИ», — пояснили в команде проекта.
Первый опыт управления IT-командой: три вывода, которые я сделал
Когда я впервые начал отвечать не только за свою работу, но и за результат небольшой IT-команды, мне казалось, что задача руководителя достаточно простая: распределить задачи, определить сроки и проверить результат.
На практике сложнее всего оказалось не контролировать разработку, а сохранять общий контекст, снимать блокировки и не становиться человеком, через которого должно проходить вообще всё.
Вот три главных вывода, которые я сделал.
Сообщение в чате ещё не является задачей
Большая часть нашей коммуникации проходит в переписке. Это быстро и удобно, но именно в чатах задача легко теряет смысл. Я пишу, что нужно изменить определённое поведение, разработчик задаёт несколько вопросов и начинает работу. Через пару дней выясняется, что итог мы представляли по-разному.
Проблема не в невнимательности. Часть контекста, очевидная для меня, просто не была зафиксирована.
Теперь я стараюсь указывать четыре вещи: зачем нужно изменение, что должен получить пользователь, какие ошибки необходимо учесть и по каким признакам мы примем результат. Даже короткое описание работает лучше, чем цепочка сообщений, разбросанная по нескольким дням.
Задержка не всегда возникает внутри команды
Некоторые задачи зависят от внешних систем и людей, которыми команда не управляет. Например, функция уже реализована, но источник данных периодически возвращает ошибку. Можно бесконечно менять клиентскую часть, хотя постоянное решение требует другого способа интеграции и участия смежной команды.
В такой ситуации бесполезно просто требовать «починить быстрее». Нужно разделить саму разработку и внешнюю зависимость: что уже сделано, где возникла блокировка, кто может принять решение и допустим ли временный вариант.
Для меня это стало важным изменением. Руководитель нужен не только для контроля сроков. Он должен подключать нужных людей и не оставлять разработчика один на один с проблемой, которую нельзя решить внутри команды.
Приёмка является отдельной работой
Технически выполненная задача ещё не всегда означает готовый результат. Экран может открываться, кнопка нажиматься, запрос отправляться, но весь пользовательский путь остаётся непроверенным.
Поэтому я стараюсь принимать работу не по отдельным функциям, а по сценариям. Проверяю основной путь, пустое состояние, ошибку сервиса, повторное действие и возвращение в раздел. Такой список не заменяет тестирование, но помогает не принять за готовый продукт набор экранов, работающих только по отдельности.
Что оказалось самым важным
Первый управленческий опыт показал мне, что руководство мало похоже на раздачу задач. Основная работа происходит между ними: сохранить смысл, выбрать приоритет, снять блокировку и проверить, что технические результаты сложились в работающий продукт.
От руководителя не требуется знать ответы на все вопросы. Но он не должен допускать, чтобы команда неделями ждала решения, доступа или недостающего контекста.
А какой вывод стал главным для вас при первом переходе от самостоятельной работы к управлению командой?
ИИ-агенты уже создают непропорционально большую нагрузку на ИИ-модели и расходуют почти в пять раз больше токенов, чем запросы людей, а с февраля 2026 года их потребление выросло примерно в 14 раз.
LLM пишут код. Почему разработка все еще занимает столько времени?
LLM хорошо справляются с отдельными задачами разработчика: написать код, найти нужный фрагмент в документации, разобраться с ошибкой, предложить вариант исправления. Но скорость разработки определяется не только этим.
После того, как написал код нужно оформить MR, дождаться ревью, смерджить, запустить сборку, вернуть задачу тестировщику. Ошибки со стенда — собрать, отфильтровать известные, понять, кому их передать, посмотреть график дежурств и написать человеку.
Таких действий много, они разбросаны по разным системам и часто зависят от того, кто помнит правильный порядок. Мы решили посмотреть на этот процесс как на инженерную задачу: измерить, где именно теряется время, описать повторяющиеся действия и часть из них передать автоматизированной системе.
Например, раньше цепочка после разработки выглядела примерно так: открыть MR → смерджить → собрать main → перевести задачу → уведомить следующего участника процесса.
Теперь ее можно запустить одной командой. Система сама выполняет действия в трекере, репозитории и сборке — но только в рамках заданных инструкций и с предусмотренными проверками.
То же самое мы сделали с дежурством. Система собирает ошибки со стендов, отсеивает известный шум, определяет подходящую экспертизу и дежурного, а затем формирует отчет в мессенджере.
2 сентября в 15:00 мск приходите на вебинар, чтобы посмотреть, как такой подход устроен изнутри и что из него можно применить в своих процессах.
На вебинаре разберем:
как устроены инструкции: что входит в описание одного действия и как из отдельных инструкций собирать цепочки;
какие метрики помогают найти узкие места: ожидание, передачи задач и переключения между системами;
как одной командой запускать действия сразу в нескольких инструментах;
как автоматизировать дежурство по ошибкам;
какие проверки мы оставили за человеком и почему;
что не сработало при создании системы и какие решения пришлось пересмотреть.
Отдельно поговорим о код-ревью, ответственности за прод и о том, какие действия мы не стали отдавать автоматизации.
Спикер: Владимир Шилун, старший frontend-разработчик Just AI.
Участие бесплатное, достаточно зарегистрироваться. А если вдруг не успеете на эфир — пришлем запись и материалы, чтобы можно было посмотреть все в удобное время.
Соблазн вайб-кодера: хочется решить сложную задачу, надиктовав общий концепт в микрофон. Остается накрутить effort на xhigh/max, чтобы «модель думала изо всех сил». Вайб-кодер считает в этот момент: «чем больше мышления, тем лучше получится продукт». Пока вайб-кодер делает себе кофе, его визионерская/архитектурная/продуктовая роли растворяются в решениях max-effort модели как 3% молоко в кофе. А он хотел кофе по-венски. С шапочкой из взбитых сливок.
Что делает effort:
В документации Anthropic прямо сказано, что параметр effort влияет на все токены ответа:
Таблица поведения оттуда же: низкий против высокого effort:
low: «fewer tool calls», «proceed directly to action without preamble», «terse confirmation messages»
high: «make more tool calls», «explain the plan», «detailed summaries», «more comprehensive code comments»
Высокий effort не делает решение правильнее. Он делает его объёмнее: больше вызовов, больше «а давайте ещё вот это», больше кода, который не отвечает прямому назначению, а багфиксит, импрувит, фичерит без прямого запроса.
Как effort ломает архитектурное / PO / аналитическое восприятие проекта:
Про Opus 4.7/4.8 (это модель под капотом Claude Code) сказано:
Читайте наоборот: на высоком effort модель делает больше, чем вы просили. Она достраивает контекст, которого не было в задаче: то есть ломает неявные, но внутренне ощутимые guardrails вокруг вашей совместной работы. Продукт перестает быть «продуктом от людей для людей», тк вектор продукта, границы фичи, архитектурные компромиссы уходят из головы владельца на откуп бюджету токенов модели.
Перевожу на человеческий: высокий effort - это костыль под отсутствие спецификации (3% молоко). Если у вас есть спека, чек-лист, границы - вам нечего компенсировать мышлением модели. Вы задаёте контекст словами (взбитые сливки), а не «оплачиваете» его тем, что модель додумывает объём работ за вас.
Если решение при этом разрастается - effort тут ни при чём. Нужно явно обозначить границы, лимиты, стиль, формат:
Хочешь простое решение своей понятной задачи? Ставь low/medium effort и напиши в спеке явно: minimal change, no extra features, no refactors.
Суть
Модель лучше воспринимать как младшего специалиста, а не как заместителя (если вы не директор по AI-Slop content, конечно). Джуну вы даёте задачу с границами и ревьюите результат - вы не отдаёте ему видение продукта. Как только вы включаете max и говорите «думай сам» - вы перестаёте быть архитектором/PO/аналитиком и становитесь тем, кто принимает решения модели, не понимая их. Продукт начинает жить свою жизнь под вашу ответственность, ведь от модели можно получить только Sorry! My mistake!, а потом потратить N-кратное количество токенов на формирование нового взгляда на проект, опять же, с вашим личным глубоким участием. Почему бы сразу не расставить границы?
Мой блог в Telegram о создании продукта MiniMap (10K MAU), практике в AI: Fisheye Monk
Перечитал роман "Территория" Олега Куваева. В первый раз читал его 10 лет назад, и тогда же посмотрел замечательный российский фильм, снятый по мотивам книги. Теперь вот я менеджер с опытом, и мне интересно было посмотреть на историю с точки зрения менеджера.
Если размышлять так, то роман, конечно, про стартап. Сама Территория - это неосвоенный рынок. Человек, стоящий во главе организации по её освоению - визионер, абсолютно уверенный в себе тип, везунчик, который резко взлетел на прошлом витке и завоевал себе имя и уважения. Люди в команде - сплошь идейные. Но идея не та, что сейчас некоторые малообразованные товарищи приписывают советскому человеку - мол, "работай много и бесплатно ради будущего детей". Как раз зарабатывают на северах много, сильно больше, чем "на материке".
Тем не менее, очень важно отношение к Работе (именно так, с большой буквы). Это бог, это основа. Если ты не служишь Ей, ты покидаешь коллектив. Просто мотивацией деньгами, славой, романтикой не обойдёшься. Так вот сложилось. Наверное, и это тоже применимо к любому успешному стартапу: конечно, всяк мечтает, чтобы компания выросла до единорога, и программисты потом смогли реализовать свои опционы по 100 млн долларов каждый. Но ещё нужно искренне любить то, что делаешь, гореть этой идеей.
Фигура Чинкова, главы Управления. Это тот самый лидер нашего воображаемого стартапа. Конечно, в обычной, зрелой компании он был бы сразу признан токсиком, хамом, самодуром и к радости окружающих изгнан. Но для стартапов именно такие и нужны. Моё внимание на этот раз особенно привлекли два аспекта его работы как руководителя.
Первый. Насколько важно разбираться в людях, которых берёшь с собой в эту одиссею. Он прекрасно знает своих людей, умело играет на их сильных и слабых сторонах. Это противоречит обыкновенной корпоративной практике, где личная жизнь оберегается, подчёркнуто отделяется от работы. Здесь наоборот, только зная человека всего, можно ему что-то доверять. Лично для меня этот подход скорее привлекателен: я сам в своей работе всячески стараюсь узнать о своих людях больше. С другими тоже делюсь информацией о себе, не закрываюсь и не скрываю, хотя выдерживаю известную меру.
Второй вытекает из первого. Зная людей, Чинков умеет доверять им. Там не то чтобы есть большой выбор, условия таковы, что доверять надо. Это не офис, это бескрайняя тундра Чукотки, и твои люди уходят на маршрут без связи и без твоих ценных советов на недели и месяца. Нет места микроменеджменту. Но всё же доверие в его, Чинкова, исполнении - это конкретное принятое решение каждый раз, это не стихия "деваться некуда". Он подумал, он доверился, он снова выиграл вместе с человеком, кому доверил. Да, ну и конечно надо потом поделиться частью славы и других возможностей со своими людьми: на Территории очень быстро растут вверх и потом вписывают свои имена в название хребтов и горных вершин.
И ещё есть один момент обаяния в этой книге. Дело в том, что Территория разделяет людей на "своих" и нет по критерию какой-то высшей справедливости. В обычном корпоративном мире, особенно в нынешнее время, работник должен максимально угождать представлением компаний о том, каким он должен быть. При попытке устройства на работу требуют вплоть до полного соответствия навыкам, перечисленным в вакансии, всем 100. Карьерные консультанты в один голос кричат: скрывайте всё о себе, что не умещается в требования на данную конкретную должность! Если даже где-то маленький краешек личности чуть выходит за это прокрустово ложе - всё, до свидания, следующий!
Территории важен лишь твой дух, который выражен в твоём отношении к Работе. Готов делать дело - тебе дадут возможность, научат. Потом спросят, конечно. Но и бывшие зеки, и молодые специалисты, и большие учёные - все по-человечески равны перед одним главным принципом. Такой немного жестокий стартап, где можно и даже нужно оставаться Человеком, а не функцией. И в результате приносить гораздо больше пользы, чем любая тщательно подобранная "функция"
Зачем ускорять разработку? Просто через раз вижу этот вопрос, во всех постах про агентов и новую эру автоматического кодинга. Переубедить конечно никого не получится, но написать надо, чтобы получилось структурировано. Погнали.
Нет такого количества задач
Если вы поговорите не с менеджерами, а владельцами бизнесов, то окажется, что количество идей у них такое, что за всю жизнь не сделать. То что из этого не всегда доходит до низов, проблема размера и процессов, которые тоже пытаются решать, поэтому так много разговоров про sdd и аналогичные истории.
Если разработка стала в два раза дешевле/быстрее, становятся экономически оправданными задачи, которые раньше вообще не попадали в backlog.
Это никому не нужно
В конкурентном мире невозможно сделать продукт до конца и сидеть сложа руки. А конкуренция приводит еще к тому, что кто первый встал, того и тапки. Сегодня вы на высоте, завтра ваш бизнес угрохали потому что вы не успели адаптироваться.
Ну если вы работаете у монополиста/госа/стратегического игрока, то можете игнорировать этот пункт :)
Фичи не принесут деньги
Может принесут, а может и нет, это невозможно обобщать не зная конкретных обстоятельства конкретных ситуаций. Например мы годами не могли сделать b2b кабинет таким как хотели наши клиенты, потому что у нас никогда не хватало ресурсов на эту часть. С помощью агентов мы это сделали и смогли получить хорошие контракты, которые от нас раньше уплывали.
Ускорение разработки меняет не только скорость выполнения уже выбранных задач, но и сам набор задач, которые становится рационально делать.
Покажите как это сократило фот?
По правде говоря у многих сократило. Но последовательность другая. Последние годы у многих были сокращения по экономическим причинам, а потом заморозка найма при одновременном росте производительности за счет ИИ. Поэтому ии больше повлиял не на сокращение как таковое, а на отсутствие найма
Покажите как это увеличило прибыль?
В экономике есть только два способа растить маржинальность: рост производительности и повышение цены. Когда то массовое внедрение компьютеров и экселя привело к такому же эффекту.
Итого
Ускорение разработки само по себе не цель. Реальная цель это снизить стоимость изменения продукта, поэтому помимо разработки одновременно ускоряется еще много всего, но об том просто говорят в других местах, куда разработчики не ходят, поэтому у них часто складывается такое одностороннее представление о происходящем
3 неочевидных open source инструмента для разработки в облаке
Собрали инструменты, о которых не так часто говорят, но они закрывают конкретные боли dev-команд в облаке.
🖥️ Cреды разработки
Coder. Спасает, когда нужно, чтобы вся команда работала в идентичных окружениях, новые воркспейсы не требовали длительных настроек, а код при этом не покидал контур компании.
➕ Управляющий слой открыт целиком, воркспейс описывается как код на Terraform, есть аудит-логи и поддержка ИИ-агентов в изолированных рабочих окружениях.
➖ Docker Hub закрыт для российских IP — образы нужно тянуть через собственное зеркало на Harbor/Nexus или GHCR-прокси.
Альтернативы:
DevPod. Если маленькая команда или нужна гибкость по вендору. Инструмент работает как чистый CLI вообще без сервера, единообразие окружений обеспечивается через конфиг devcontainer.json, но централизованного управления нет.
Eclipse Che.Если у команды уже есть Kubernetes-кластер и нужна полноценная K8s-native среда. Также подходит тем, кто работает в экосистеме Red Hat / OpenShift.
🔑 Хранение секретов и разграничение доступов
OpenBao. Есть смысл внедрять, когда секреты уже расползлись по переменным, .env-файлам и табличкам в общем доступе, и теперь это добро трудно найти аудировать, легко потерять и невозможно безопасно ротировать. Инструмент позволяет собрать управление в одном контуре и применять единые политики доступа.
➕ Полностью открытая лицензия (MPL 2.0), можно не только использовать, но и перепродавать в составе других коммерческих продуктов; поддерживает и статические, и динамические секреты, есть PKI для выпуска X.509-сертификатов.
➖ Развертывание и обновления требуют дисциплины, нужны внутренние зеркала container images, helm-чартов и исходников, чтобы поставка не зависела от доступности внешних registry и Git-hosting.
Альтернативы/дополнения:
Infisical. Хороший выбор, если в приоритете удобство для разработчиков и более широкий продуктовый контур вокруг секретов. Еще он удобнее всего для работы с учетными данными ИИ-агентов.
External Secrets Operator. Не замена OpenBao, а Kubernetes-слой для доставки секретов. Он забирает значения из внешнего хранилища: OpenBao, Infisical, AWS Secrets Manager или любого другого бэкенда — и синхронизирует их в нативные Kubernetes Secrets внутри кластера. Стоит выбирать, когда приложения уже живут в Kubernetes и нужен GitOps-подход, когда в Git хранятся только ссылки на секреты и политики доступа, а сами значения остаются в защищенном хранилище (HashiCorp Vault, OpenBao) и никогда не попадают в репозиторий.
🚩 Флаги фич
GO Feature Flag. Выручает, когда нужно безопасно выкатывать фичи без передеплоя. Ну, или мгновенно вернуть как было, не трогая инфраструктуру.
➕ Легкая библиотека флагов на базе стандарта OpenFeature, работает встроенно в приложении или как промежуточный прокси-сервис. Конфиг может хранится в YAML-файле, в Git (даже self-hosted без привязки к GitHub), также можно держать в S3 или Redis. MIT-лицензия, минимум внешней инфраструктуры. ➖ Маленькое коммьюнити, мало готовых интеграций, а поддержка держится на GitHub Issues, доступность которых в РФ нестабильна.
Альтернативы:
Unleash. Если флаги больше нужны инженерам для безопасных раскаток и управления циклом изменений.
Flagsmith. Если кроме включения/выключения функций нужны продуктовые сценарии, например, сегментация пользователей или A/B-тесты.
Не будем скромничать, у нас тоже есть свое open source решение: фильтр для доступа к внешним нейросетям, которое, во-первых, позволяет использовать LLM (в том числе для кодинга), не сливая туда чувствительную инфу, а во-вторых, не ломает при этом вызов функций. Как мы этого добились, рассказывали в статье. Забирайте в свой контур, открывайте pull request’ы, оставляйте issuе — мы открыты к обратной связи.
Быстрое сокращение отставания Китая от США в сфере искусственного интеллекта на одном графике. Если ранее Anthropic оценивала разрыв китайских лабораторий от американских в 6–12 месяцев, то теперь разработка Kimi K3 от Moonshot уступает по мощности лишь лидерам вроде Claude Fable 5 и GPT-5.6, оставаясь при этом дешевле в эксплуатации.
Такие компании, как Moonshot, DeepSeek, Alibaba/Qwen и Z. ai/GLM, резко сократили технологическую дистанцию с американскими разработчиками. Дополнительно позицию Китая усиливает свежая модель GLM-5.3, которая часто даже не учитывается в подобных сравнениях.
Представлен проект MathCode — это терминальный помощник по программированию с ИИ со встроенным механизмом формализации математических формул. «Дайте ему математическую задачу на простом языке, и он автоматически преобразует её в теорему Lean 4 и попытается дать формальное доказательство — с помощью постоянно доступной интерактивной среды Lean REPL, многократно используемых библиотек теорем и аксиом, агентного доказательства и графа знаний Obsidian», — пояснили в команде проекта.
В офисе ИнфоТеКС мы открыли Летний ТехФест и провели воркшоп по Event Storming — это 90 аналитиков, техлидов и ни одной скучной лекции. Всех участников ждали полное погружение в практику и нетворкинг.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Google запустил бесплатный курс по вайбкодингу, который доступен на русском языке — он учит создавать приложения с нуля без опыта. Курс AI for App Building занимает около 2 часов и входит в Google AI Professional Certificate, а после прохождения можно получить сертификат.
ИИ-агента Manus предлагают протестировать бесплатно на две недели без ограничений до 25 августа (без карты, без номера телефона, только регистрация на сайте):
выполняет задачи без подсказок от начала до конца и по расписанию;
одновременно исследует сотни сайтов, книг, статей и других ресурсов;
команда ИИ‑систем внутри: планирование, задачи, проверка;
ИИ‑агент сам заходит на сайты, может заказать еду, забронировать билеты или спланировать отпуск;
работает с таблицами Excel, PDF, документами;
правит картинки прямо на экране;
подключается к Gmail, Slack, GitHub и другим платформам;
показывает свои действия в реальном времени и отчитывается о них.
Anthropic со 2 августа 2026 года начала внедрять маркировку контента, созданного Claude. В сгенерированный текст встраивается невидимый водяной знак, который не влияет на смысл или читаемость и может сохраняться после копирования и некоторых правок. Это может усложнить использование Claude для написания дипломных работ, книг и исследований. Во все актуальные модели встроили криптометки по стандарту C2PA. Метки невозможно увидеть и они сохраняются даже при копировании на другие ресурсы.
Червь Shai-Hulud вернулся в npm и получил настоящую подпись
4 августа в npm вышла новая версия keyv, небольшой библиотеки для работы с хранилищами. Внутри был вредоносный код, и через час он появился в cacheable, flat-cache, cache-manager и остальных пакетах того же автора, а оттуда пошел дальше по чужим учетным записям. Сутки спустя специалисты Aikido насчитали 444 зараженных пакета.
Опознать волну было несложно. Червь складывал краденое в публичные репозитории с описанием «Shai-Hulud: Here We Go Again». Wiz относит образец к тому же семейству, что и прошлогодние.
Атакующий получил доступ к учетной записи мейнтейнера и выпустил зараженные версии от его имени. В них он добавил загрузчик setup.mjs, файл с замаскированным вредоносным кодом и настройку preinstall в package.json. Она заставляла npm запускать загрузчик еще во время обычной установки пакета.
setup.mjs определял, на какой системе работает машина. Если на ней не было Bun (среды для выполнения JavaScript), то он скачивал ее легитимную версию 1.3.13 из официального списка релизов. Затем через Bun запускался Math_Symbol.js. Этот файл собирал токены, ключи и другие секреты, доступные на машине разработчика или сервере сборки. Используя токены публикации червь выпускал зараженные версии пакетов, которыми мог распоряжаться их владелец. Таким образом червь шел не только по дереву зависимостей, но и по полномочиям мейнтейнеров. Очередной зараженный пакет попадал в следующую среду сборки, получал доступ уже к ее секретам и повторял тот же сценарий.
Интересно то, что зараженные версии попали в реестр с настоящей подписью. Год назад экосистема ответила на первую волну Shai-Hulud внедрением доверенных публикаций, при котором пакет собирается в общем сборочном конвейере, а вместе с ним публикуются сведения о происхождении сборки. На августовских версиях эта проверка проходила, и подмены после сборки действительно не было. Вредоносный код лежал в самом репозитории, поэтому конвейер честно собрал и заверил то, что там было.
Второе наблюдение этой волны — это попытка закрепиться там, куда пакетный менеджер уже не смотрит. Получив доступ к репозиториям, червь дописывал в них служебные настройки редактора и ИИ-агента так, что код запускался при обычной работе с проектом, например при его открытии. Запрет скриптов установки, который npm включил по умолчанию этим летом, обрубает главный путь заражения, но эту ветку он не видит. Она живет в конфигурации инструментов, куда дерево зависимостей не заглядывает.
Заражённые версии из реестра уже убрали, а теги последних релизов откатили. Но для машины, куда пакет успел встать 4 августа, это мало что меняет. Секреты уехали в тот же день и работают, пока их не отозвали.
Как в таком случае защитить цепочку поставки?
Новые версии внешних пакетов лучше вовсе не пускать в сборки в день публикации. Период охлаждения хотя бы на 14 дней дает время заметить подозрительный релиз. Доступ к публичным реестрам стоит пропускать через внутренний репозиторий или прокси, чтобы известная вредоносная версия не попала к разработчикам и в сборочные системы. Подробнее о таких рубежах контроля мы писали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».
Когда запись об уязвимости уже появилась в базах данных, композиционный анализ помогает найти проекты, сборки и контейнерные образы, где могла оказаться конкретная версия, если не применялся период охлаждения. Дальше важно очистить внутренний кэш, проверить изменения в CI, редакторах и ИИ-агентах, а также отозвать секреты, к которым имел доступ раннер. Удаление пакета из реестра этого уже не сделает.
GitHub превратили в TikTok — теперь новые библиотеки, инструменты и идеи для своих проектов можно находить обычными свайпами. Сервис Roamers показывает бесконечную ленту открытых репозиториев, почти как рилсы. Если войти через GitHub, рекомендации подстроятся под ваши интересы, но листать можно и анонимно.
Представлен открытый проект torlink, который умеет искать и работать с торрентами из проверенных источников. Запускается командой npx torlnk. Одновременно проверяет FitGirl, YTS, The Pirate Bay, 1337x, Nyaa и другие источники, а результаты показывает вместе с размером и числом сидов. Выбранный файл скачивается в фоне, а после завершения автоматически встаёт на раздачу.
«Найти торрент в наши дни — сплошная головная боль. Один сайт — это минное поле из поддельных кнопок загрузки. Другой скрывает настоящую ссылку под всплывающим окном, которое открывает ещё две вкладки. И после всего этого половина результатов — это неработающие сайты с нулевым количеством раздающих. Torlink — это программа для поиска торрентов, которая работает в вашем терминале, не требует никакой настройки и конфигурации. Один поиск проверяет короткий, тщательно отобранный список надёжных источников, и всё, что вы выберете, загрузится прямо на ваш компьютер. Файлы ваши, сохранены в папке загрузок», — пояснил автор проекта.
Команда Cursor представила исходный код проекта minisqlite. Это реализация СУБД SQLite на языке Rust и успешно проходящая официальный набор тестов sqllogictest от проекта SQLite.
Проект minisqlite подготовлен в ходе эксперимента по проверке эффективности работы ИИ‑моделей GPT-5.5, Grok 4.5, Opus 4.8 и Fable 5, по воссозданию SQLite только на основе официального 835-страничного руководства, без доступа к оригинальному коду, интернету, наборам тестов и исполняемому файлу SQLite. Основная идея эксперимента — использование подробной спецификации в качестве промпта для создания сложного продукта.
Представленная реализация minisqlite основывается на результатах, полученных при использовании ИИ‑модели Opus 4.8.
Проект minisqlite включает около 200 тыс, строк кода на Rust, не содержащего unsafe‑блоков в коде библиотеки. Библиотека может открывать файлы, созданные в оригинальном sqlite3, и записывать файлы, которые можно прочитать в sqlite3. Реализация охватывает диалект SQL от SQLite, поддержку транзакций, 90 встроенных функций, планировщик запросов, движок выполнения запросов и движок хранения, совместимый с дисковым форматом SQLite 3. Из внешних зависимостей в minisqlite задействован только пакет elsa, с использованием которого реализован страничный кэш.
Представлен открытый конвертер book‑to‑skill для ИИ‑агентов. Проект анализирует книги и документы в PDF, EPUB, DOCX, Markdown, считывает текст, собирает конспекты глав, словарь, паттерны и шпаргалку, а затем превращает это в skill. Инстурмент экономит токены — получается в 24–51 раз меньше затрат, чем если просто закинуть нейросети целую книгу.
Для MacBook вышло открытое приложение Himekuri, которое позволяет переворачивать календарь на рабочем столе. Бумага на календаре мнётся, рвётся и улетает вниз экрана. Причём вернуть ее обратно уже нельзя. Закрепить проект можно на рабочем столе, поверх всех окон или использовать как обычное приложение.
Инфраструктура для разработки на гиперскорости: сервисы самообслуживания и MCP в HyperDrive
ИИ уже помогает писать код за минуты. Но путь до рабочего сервиса по-прежнему занимает дни или недели — из-за ручных инфраструктурных процессов, тикетов и согласований.
На вебинаре покажем, как Internal Developer Platform меняет эту модель: разработчик получает готовую инфраструктуру через каталог стандартных сценариев, а DevOps-инженер управляет платформой, шаблонами и политиками.
Ключевые темы:
Почему инфраструктура стала главным ограничением скорости разработки
Почему модель «разработчик → тикет → DevOps» больше не масштабируется
Что такое Internal Developer Platform на практике
Как меняются роли DevOps и ИБ
Как ИИ-агент безопасно и предсказуемо взаимодействует с инфраструктурой через Model Context Protocol
Живое демо новой IDP-функциональности в HyperDrive: создание окружения, self-service, GitOps, встроенные политики безопасности и путь от запроса до готовой инфраструктуры
Кому будет полезно:
CTO
CIO
Head of Platform Engineering
Head of DevOps
Руководителям разработки
Platform Team
DevOps-инженерам
Спикеры:
Павел Лавров Лидер продукта HyperDrive, Orion soft
Даниил Рахновский Архитектор продукта HyperDrive, Orion soft
Сложность пути может заключаться как в создании нового, так и в сохранении и развитии того, что уже есть
Варианты старта: тимлид в новой или существующей команде
Продолжаем серию постов о переходе из роли старшего инженера в трек начинающего технического менеджера — тимлида.
Как это случается
Переход из инженера в тимлида почти никогда не происходит мгновенно. Сначала будущий руководитель набирает управленческий опыт: берёт на себя делегированные активности, работает с чужими целями и учится смотреть на команду шире технических задач.
Освоение роли опирается на три составляющие: теорию, практические кейсы и работу с делегированными активностями. Теории в сети предостаточно, а практических кейсов меньше: их разбирают на абстрактных примерах или внутренних тренингах, да и симуляторы построены на типовых ситуациях. Рост через делегирование возможен только в повседневной работе, с последствиями принятых решений, — поэтому он самый ценный и самый сложный.
Тимлиды вырастают из инженеров разных функций — например, из бэкенда, фронтенда, мобильной разработки или QA. Но старт определяет не столько специализация, сколько то, как человек входит в роль и с какой командой ему предстоит работать.
Стартовые позиции
Нередко новоиспеченный тимлид — это инженер, который давно исполняет обязанности руководителя: формально остаётся инженером, но фактически ведёт команду, распределяет задачи, планирует. Такой плавный переход смягчает шок, но это не единственный сценарий.
Если смотреть шире, есть две принципиально разные стартовые позиции: тимлид в новой команде и в уже существующей. Логика у них общая, но различия существенные, а значит, различается и набор нужных знаний и опыта.
Тимлид в новой команде
Новая команда начинается с чистого листа. Её предстоит собрать, поэтому на первый план выходит быстрый, но точный найм: ошибка на старте дорого обходится. Параллельно — выстраивание отношений, запуск процессов с нуля и культура работы с метриками, которой пока нет. Всё это — в сжатые сроки и при большом объёме контекста.
Команда здесь по определению незрелая, поэтому задача руководителя двойная: выстроить выверенный найм и сформировать среднесрочную стратегию, задающую направление на ближайшие месяцы.
Тимлид в существующей команде
Второй сценарий — приход на замену прежнему руководителю (например, после его повышения или ухода). Чистого листа здесь нет: новому тимлиду достаются незакрытые «хвосты», настрой команды, уровень развития людей, процессы и метрики. Всё это нужно быстро оценить.
Ключевой показатель — зрелость команды или Team Maturity Model (TMM): развитая, базового уровня или незрелая. С развитой можно работать на длинную дистанцию, с незрелой — сначала закрывать базовые пробелы.
Акцент смещается на быстрые победы, укрепляющие доверие, и «north stars» для долгосрочного развития.
Сложности вступления в роль
Состояние команды удобно оценивать через три призмы: метрики, процессы и людей. По каждой из них нужно честно ответить на вопрос: ситуация критичная или некритичная? Такая диагностика быстро показывает, где горит.
Дальше всё упирается в планирование. Правильно разложенные по горизонтам быстрые победы, среднесрочные планы и долгосрочная стратегия — ключ к эффективности на старте. Ошибка в приоритетах может стоить дороже ошибки в конкретном техническом решении.
Онбординг тимлида длится около полугода. За это время необходимо:
показать профессиональный авторитет;
сделать прозрачными границы роли;
быстро погрузиться в боли команды и продукта;
обеспечить быстрые победы и план работы со сложными проблемами;
системно развивать все три направления: метрики, процессы и людей.
Выводы
Оба сценария имеют свои особенности, но логика старта одна: быстро погрузиться в информационное поле команды, понять её проблематику и в первые одну-две недели выработать краткосрочный план, а ко второму месяцу — долгосрочное видение, ту самую «полярную звезду» развития команды.
Что дальше?
В следующей статье поговорим о целеполагании и планировании: как планировать, когда всё горит и ничего не понятно.
Атака на цепочку поставки через Steam, или как вредоносный код спрятали в легитимных обновлениях
В США задержали 21-летнего Зайра Уилкинса, которого обвиняют в причастности к схеме распространения игр с вредоносным кодом через Steam. По версии следствия, встроенное в игры вредоносное ПО собирало учетные данные и другую информацию с компьютеров пользователей.
В июле 2026 года в суд поступили подробные материалы дела. В документе говорится о восьми играх с вредоносным кодом и примерно 8 тысячах зараженных устройств. Следствие связывает атаку с несанкционированным доступом приблизительно к 80 криптовалютным кошелькам и хищением не менее 220 тысяч долларов. Пока это версия обвинения, а не установленные судом факты.
Игры распространялись через учетные записи разработчиков. По данным следствия, для регистрации использовались похищенные персональные данные — это позволяло злоумышленникам успешно проходить проверки площадки, запрашивающей документы и платежные реквизиты. Затем релизы продвигали через соцсети и сообщения пользователям с крупными криптовалютными активами.
Особенно показателен случай Lampy. Вредоносный код содержала обновленная версия игры, выпущенная в январе 2026 года. Пользователю не требовалось переходить на поддельный сайт или устанавливать программу из неизвестного источника – исполняемый файл доставлялся через привычный механизм обновлений.
Судя по опубликованным материалам, злоумышленники не взламывали сам Steam. Они встроились в штатный процесс поставки и использовали доверие к площадке, учетной записи издателя и обновлениям. Этот случай хорошо дополняет привычное представление об атаках на цепочку поставки. Точкой входа может стать не только скомпрометированная зависимость или система сборки, но и канал, через который готовый продукт доходит до пользователя.
Публикация через доверенную площадку не делает программу безопасной, а обновление необходимо проверять как новый исполняемый артефакт. Для владельца площадки это означает повторный анализ каждой загружаемой сборки, сравнение с предыдущим выпуском и запуск в изолированной среде. На устройстве пользователя такая атака уже попадает в зону, ответственности антивируса, EDR и контроля запуска приложений. Они могут обнаружить подозрительное поведение уже установленной программы, хотя ни один из этих уровней сам по себе не дает гарантии.
Представлен открытый проект pdf-inspector на Rust от команды Firecrawl. Это PDF-парсер, который умеет быстро обрабатывать страницы документов. Проект преобразует содержимое в Markdown, но при этом сохраняет структуру документа и таблицы. Решение работает без ограничений, код опубликован под лицензией MIT.
🔥 Основы FastAPI: собираем сервис «прочитать позже»
У каждого есть свалка ссылок «прочитаю потом»: 40 вкладок, сохранёнки в Telegram, закладки с 2022 года. Проблема не в том, что нечего читать, — а в том, что всё это невозможно найти и разгрести.
Решим по-инженерному: напишем свой Read-Later сервис и с нуля освоим FastAPI.
За 1.5 часа: ⚡️ Поймёте, что такое FastAPI и почему он удобен 🧱 Опишете модель данных (SQLAlchemy + Pydantic) 🔁 Напишете полный CRUD 🔍 Научитесь фильтровать через query-параметры 📄 Получите Swagger UI бесплатно 🌐 Подключите простой фронтенд
Для кого: знаете Python, но ещё не писали API.
🛠 Куда дальше — дорожная карта: FastAPI — не просто фреймворк. На нём построен наш MCP Knowledge Server (Qdrant + семантический поиск) — ядро AI-ассистента сообщества, который «помнит» всё изученное.
Цепочка: 🐳 Docker (25.07) → 🐍 FastAPI (06.08) → 🧠 MCP Knowledge Server (сентябрь). В сентябре — отдельный воркшоп: поднимем такой сервер вместе.
📖 Pre-read: за 3 дня до воркшопа — инструкция по установке uv и Python.
Что делать, если ваш руководитель — чайка? «Он появляется внезапно, громко говорит, даёт указания и исчезает. А через неделю возвращается и удивляется, почему ничего не сделано».
Супер‑стиль, особенно ощущения от общения, не правда ли?
Чайка‑менеджментом называют стиль управления, которое олды миллениалы зовут ИБД.
Для самого менеджера это энергонезатратно (включаться в процесс не нужно) + заметно для руководства повыше. Для чайки вообще удобно — выплеснул...эмоции, дал «решение» и улетел.
Для команды — хаос: планы ломаются, приоритеты скачут. Ну и последствия разгребают конечно те, кто остался.
Вы не можете быстро переделать руководителя. Но можете лечь в направлении снижения хаоса вокруг себя.
1) Готовьте факты. Перед встречей соберите короткую сводку: что происходит, какие риски, что вы предлагаете. Это не отчёт, а способ не дать эмоциям заменить разговор по делу.
2) Переводите эмоции в вопросы. У себя, и — что сложнее — у начальствующего. Не «так опять всё сломается», а «как мы поймём, что этот подход работает?» или «что будет признаком, что его стоит остановить?». Возвращаем фокус на результат.
3) Фиксируйте решения. Если на встрече что‑то решили — запишите и отправьте краткое резюме. Сохраняем контекст, в том числе для того чтобы «поймать на слове» (да, токсичненько, но иногда — помогает).
4) Предлагайте пилоты. Вместо «ок, давайте пробовать» — «давайте проверим это на одном проекте». Остаемся в безопасной зоне, используем реальные данные.
Кстати, если вы сами иногда оказываетесь в роли «чайки» — я вас не осуждаю (см. выше — это тоже способ продвижения). Но пожалуйста задумайтесь — регулярные короткие встречи, данные вместо эмоций и сопровождение вместо указов работают лучше, чем шумные появления раз в месяц.
А у вас был такой руководитель? Что помогало — или что точно НЕ помогало?
PyPI готовится закреплять префиксы имен пакетов за организациями
29 июня 2026 года был принят PEP 752. Он описывает механизм, с помощью которого пакетные репозитории смогут закреплять префиксы имен за определенными организациями. Например, новые пакеты с префиксом google-cloud- смогут публиковать только организации, получившие соответствующее право.
Сейчас пространство имен PyPI остается плоским. Если название свободно, пользователь может зарегистрировать пакет, который выглядит частью известного проекта, например, google-cloud-something, opentelemetry-something или apache-airflow-providers-something. Знакомый префикс повышает доверие к названию, хотя реального отношения к организации у пакета может не быть.
PEP 752 предлагает закреплять за владельцем как сам префикс, так и новые названия, которые включают префикс и дефис после него. Попытка опубликовать такой пакет без разрешения будет завершаться ошибкой. При этом уже существующие проекты можно не блокировать. Репозиторий вправе разрешить их владельцам выпускать новые версии и после появления защищенного префикса.
Синтаксис имен не изменится, поэтому дорабатывать pip, uv и другие менеджеры пакетов ради обычной установки не потребуется. Вместе с тем в API репозитория появятся сведения о связи проекта с защищенным префиксом. В дальнейшем менеджеры пакетов и прокси смогут учитывать их в собственных политиках.
Принятый PEP пока описывает стандарт, а не уже работающую функцию PyPI. Правила подачи и рассмотрения заявок вынесены в PEP 755, который остается черновиком. Срок запуска механизма также пока не объявлен.
PEP 752 переносит часть проверки на самый ранний этап, когда в репозитории только появляется новое имя. Для семейств пакетов вроде google-cloud-* или apache-airflow-providers-* это позволяет остановить постороннего издателя до того, как правдоподобно названная подделка станет доступна пользователям.
У такой защиты есть довольно четкие ограничения. Право на префикс подтверждает, что издатель может использовать такое имя в конкретном репозитории, но ничего не говорит о безопасности содержимого. Если учетную запись доверенного издателя скомпрометируют или он сам выпустит вредоносную версию, резервирование не поможет. На другой репозиторий выданное право тоже не распространяется.
Когда механизм заработает, новые метаданные можно будет использовать не только на страницах PyPI. Менеджеры пакетов и корпоративные прокси смогут пропускать пакеты с защищенным префиксом, только если издатель имеет на него право. Это точечная защита от одного семейства атак на имена; остальные сценарии неймсквоттинга мы разбирали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».
Открыли доступ к курсам по ML-системам от основ до продакшна. И да: это бесплатно
Кто-то смотрит на ML как на способ оперативно занять рыночную нишу, не понимая, какой технический фундамент необходим для реализации идеи очередного прорывного продукта. Кто-то запускает идеальный эксперимент в ноутбуке, но выясняется, что он не работает в продакшене. Это две крайности одной и той же проблемы: мало кто понимает, как работают ML-системы от первого винтика данных до последней шестеренки мониторинга. Чтобы глобально исправить это, мы собрали весь свой опыт провайдера облачных и ИИ-решений в линейку курсов Cloud.ru ML System Design и сделали доступ к ней открытым.
Какие курсы есть в линейке?
«Машинное обучение в облаке»⏳15 ч — как использовать облачную инфраструктуру для разработки, обучения и эксплуатации ML-систем.
«ML в продакшене»⏳2 ч — база, которую нужно знать, чтобы довести модель от эксперимента до стабильной работы в боевой среде с учетом инфраструктуры, данных и процессов.
Мультиагентность — эффективный подход или просто красивый фантик?
Каждый, кто гонял задачи через субагентов, знает: это дольше, чем работа в одной сессии. Субагент сперва въезжает в контекст — заново собирает картину, что у основной сессии уже в голове. Плюс оркестрация. Работник ценный, да всякий раз с чистого листа.
Вопрос закономерный: оправдано ли это?
У нас есть приём, обычно зашитый прямо в claude.md: никакого «сам написал — сам и проверил».
Агент, проверяющий собственный код, находит лишь те баги, которые готов за собой признать: он смотрит на задачу из того же замысла, в котором её решал. Оно и понятно — всё равно что просить студента перепроверить контрольную по своему же решению. Спишет у самого себя, да ещё и уверенно.
Поэтому без независимого аудита мёрдж не предлагаем. После любой нетривиальной доработки запускается отдельный агент, не видевший хода решения. Ему на вход — только код диффа и явный чек-лист:
Полнота — покрыты все места вызова, а не одно.
Нерегрессия — не сломаны ли смежные пути.
Тесты — есть ли проверка на изменение и проходит ли.
Скрытые баги — edge-кейсы, null, гонки, ошибки внешних сервисов.
Слои — не уехала ли логика не туда.
Секреты — не утекли ли ключи в код или логи.
Ключевое: аудитору не показывают авторскую версию событий — он судит по коду, а не по рассказу о нём. Нашёл проблему — возвращает автору; чинит автор, аудитор перепроверяет.
И тут «потеря контекста», что обычно мешает, оборачивается главной ценностью: аудитор дорог именно тем, что не видел решения и не заражён замыслом. Он и ловит то, чего у автора глаз уже не берёт: замылен.
Аудитом дело не ограничивается. Та же логика — когда нужно независимое мнение на архитектурной развилке или когда объёмную побочную задачу (длинный лог, незнакомая библиотека) уводишь в отдельную сессию, чтоб не сорить в основном контексте. Словом, субагент хорош там, где отдельный контекст или свежий взгляд дают то, чего одна сессия не может.
Даже там, где субагент оправдан, не обязательно брать самую сильную модель. Механические проверки из чек-листа — не утёк ли ключ, есть ли тест, не уехал ли слой — прекрасно закрывает Sonnet: вопрос узкий, ответ проверяемый. А поймать то, чего не заметил автор, — гонку, хитрый edge-кейс, неочевидное архитектурное последствие — лучше попросить Opus: чтобы увидеть то, что упустил умный, нужен как минимум не менее умный. Дешёвой модели при этом ставим планку приёма: уверена — принимаем, сомневается — поднимает флаг и отдаёт выше.
Отсюда и ответ: мультиагентность — не фантик тогда, когда второго агента поднимают не «чтобы было», а там, где его независимость работает на результат. Иначе — красивая обёртка, а под ней, как водится, пусто.
Проект nosubscription.org содержит библиотеку с 1000+ альтернативами платным программам, включая открытые и бесплатные проекты. Есть удобный поиск и разбивка по категориям.
Представлен открытый редактор презентаций Bento на замену PowerPoint. Презентация в Bento хранит внутри себя слайды, шрифты, картинки, анимации и весь редактор. Базовый файл весит около 560 КБ, открывается в браузере без установки и аккаунта, умеет сам себя сохранять, работает офлайн и даже поддерживает совместное редактирование с шифрованием.
Внутри Bento обычный JSON — поэтому презентацию могут напрямую редактировать ИИ-агенты. Есть графики, комментарии, режим докладчика, PDF-экспорт и анимации между слайдами.
