Дайджест за 2 октября 2026

Как превратить LLM в рабочий AI-сервис: роль обвязки и компонентов

ИИ и агенты · Habr · 9/10

Статья объясняет разницу между просто запущенной языковой моделью и готовым к использованию AI-сервисом. Большую языковую модель можно скачать и развернуть, но для реального использования нужна «обвязка» — слой компонентов вокруг модели. По данным исследований, из 33 корпоративных ИИ-пилотов до продакшена доходят только четыре (88% остаются экспериментом), и модель редко является узким местом. LLM сама по себе не имеет тормозов, руля и ограничителей — она не знает, кто отправил запрос, имеет ли пользователь право видеть данные и можно ли вообще выполнять действие. Обвязка включает несколько слоев: интерфейс или API (веб-чат, API для приложений, боты в мессенджерах), контекст и корпоративные данные через RAG, интеграции с внешними системами (CRM, ERP, почта), управление лимитами и стоимостью (кэширование, маршрутизация по моделям, резервные варианты), валидацию результатов перед выполнением действий, безопасность (аутентификация, управление доступом, логирование). Выбор LLM — это только один из этапов создания сервиса. Часть работы можно сократить, используя готовые преднастроенные образы с инструментами вроде Open WebUI, n8n, RAGFlow. Сложность обвязки зависит от задачи: для простого корпоративного чат-бота может быть достаточно модели и веб-интерфейса, для системы с интеграциями потребуется намного больше компонентов.

Выводы автора:

• LLM — это только ядро, а не весь сервис; вокруг модели необходима обвязка из интерфейса, управления доступом, интеграций, валидации и безопасности.
• 88% корпоративных ИИ-пилотов остаются экспериментами, потому что узким местом являются не сами модели, а недостаток инфраструктуры и компонентов вокруг них.
• Для критичных действий важно разделение ответственности: LLM предлагает → программный слой проверяет → система выполняет, особенно при работе с интеграциями и корпоративными системами.

Модель — двигатель, обвязка — вся машина. У двигателя самого по себе нет тормозов, руля и ограничителя скорости.

Оригиналы:Зачем нейросети «обвязка»: как превратить LLM в рабочий AI-сервис

Создатель Rails объявил, что ручное кодирование мертво в эпоху ИИ-агентов

ИИ и агенты · The Pragmatic Engineer · 9/10

Дэвид Хайнемайер Ханссон, создатель Ruby on Rails, выступил с провокационным заявлением на конференции Rails World: компания 37signals полностью отказалась от ручного написания кода в качестве нормального процесса разработки. Ханссон провел аналогию с появлением фотокамеры, которая трансформировала живопись, назвав Claude Opus 4.5 (вышедший 24 ноября 2025) переломной точкой — «Kodak Brownie» эпохи ИИ-агентов. 37signals радикально меняет технологический стек: переходит на нативные мобильные приложения вместо веб-версий, перемещает бэкенд-сервисы на Rust вместо Ruby (так как агенты пишут достаточно хороший Rust), оставляя Rails только для веб-приложений благодаря его философии convention-over-configuration. Сам Ханссон заявил о выходе на пенсию из профессионального программирования примерно 4-5 месяцев назад, переквалифицировавшись в «профессионального создателя вещей», управляющего ИИ-интеллектом. Он утверждает, что ручное кодирование больше не является экономически продуктивным для большинства программистов и компаний, и предсказывает необходимость переосмысления основных принципов архитектуры ПО в эпоху агентов, так как традиционные абстракции теряют смысл, когда стоимость повторения кода упала почти до нуля.

Выводы автора:

• Ручное кодирование перестало быть экономически эффективным для большинства компаний, и профессиональные программисты должны переквалифицироваться в управление ИИ-агентами
• Традиционные принципы архитектуры ПО, основанные на абстракциях, требуют переосмысления в эпоху агентов, так как цена репликации кода приблизилась к нулю
• Claude Opus 4.5 (24 ноября 2025) стал критической точкой перелома, сделав ИИ-кодирование доступным и практичным для большинства разработчиков и команд

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

Оригиналы:Keynote выступление на Rails World

NVIDIA представила платформу безопасности для ИИ-агентов с аппаратным уровнем контроля

ИИ и агенты · Tech Scoop Newsletter · 9/10

NVIDIA запустила Open Agent Safety Platform — комплексную архитектуру для безопасности автономных ИИ-агентов, которые могут получить доступ к шелам, базам данных, API и облачной инфраструктуре. Ключевое отличие от прежних подходов: вместо того чтобы просить модель соблюдать правила, система переносит контроль вовне агента на уровень инфраструктуры.

Архитектура состоит из трёх слоёв: OpenShell (рантайм-контроль), Sentry (мониторинг на уровне железа DPU BlueField-4) и политики доступа. OpenShell работает как контролируемая песочница, которая перехватывает запросы агента к файлам, сетям и сервисам.

Особенность реализации: реальные учётные данные остаются вне агента и подставляются только при одобренных операциях; агент видит только заглушки. Система позволяет назначить узким разрешениям, например разрешить чтение из API GitHub, но запретить запись.

Sentry добавляет второй уровень защиты, работая в отдельном доверенном домене на блокировке доступа к модели. NVIDIA заявляет о способности карантировать нарушившего границы агента за миллисекунды.

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

Выводы автора:

• Безопасность автономных агентов требует переноса контроля вовне их процессов на уровень инфраструктуры и железа, а не полаганием на внутренние инструкции модели.
• Разделение полномочий (intelligence и authority) критично: расширенные способности агента не должны автоматически означать расширение его прав доступа.
• Аппаратный уровень контроля (DPU) позволяет наблюдать и ограничивать агента даже если основная система скомпрометирована.

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

Оригиналы:NVIDIA's Open Agent Safety Platform Moves AI Agent Security Outside the Agent

Запуск Gemma 4 на сервере: сравнение Ollama и llama.cpp

ИИ и агенты · Habr · 8/10

Статья детально сравнивает два популярных способа запуска открытой модели Gemma 4 от Google на GPU: Ollama и llama.cpp. Gemma 4 26B A4B — это MoE-модель с 26 млрд параметров, где для каждого запроса активируется примерно 4 млрд параметров; в Q4-кванте весит 14–18 ГБ, требует RTX 4090 (24 ГБ). Ollama упрощает запуск, скрывая техническую сложность подобно Docker (установка через скрипт, команды pull/run, встроенный HTTP API). llama.cpp требует компиляции с поддержкой CUDA, но при этом обеспечивает большую гибкость: запуск llama-server с параметрами контекста и распределением слоёв на GPU. Автор провёл бенчмарки на синтетических запросах с 32K входных и 256 выходных токенов, измеряя TTFT (время до первого токена), ITL (задержку между токенами), скорость генерации и полное время запроса. При последовательной обработке Ollama показал: медианное время 7,7 с, TTFT ≈5,9 с, скорость 34,1 выходного токена/с, потребление 16,7 ГБ VRAM. При параллелизме (2 запроса) задержка выросла до 14 с, TTFT до 10,3 с, скорость до 37,5 токена/с и VRAM до 17,4 ГБ. При 4 параллельных запросах задержка достигла 28,3 с, TTFT 11 с, скорость 36,8 токена/с и VRAM 19,3 ГБ — типичный trade-off между задержкой одного запроса и общим throughput. Исследование показывает, что выбор между Ollama и llama.cpp зависит от приоритетов: Ollama проще для быстрого старта, но llama.cpp даёт более тонкую настройку производительности и понимание внутренних механик. Статья полезна как для разработчиков, запускающих LLM в production, так и для тех, кто изучает инструментарий локального инференса.

Выводы автора:

• Ollama и llama.cpp — оба жизнеспособные решения, но Ollama удобнее для начинающих благодаря простоте установки и автоматизации, в то время как llama.cpp требует компиляции, но дает больше контроля над оптимизацией
• При параллельной обработке растёт общая пропускная способность (throughput), но резко увеличивается время ответа на отдельный запрос — критический trade-off для real-time приложений
• Потребление памяти растёт линейно с количеством параллельных запросов, а рост скорости замедляется: 2 параллельных запроса дают +10% производительности, 4 — практически не растут

Ollama должна была упростить пользователю запуск инференса, но разработчики постоянно спорят, правильное ли это решение — единственное верное якобы llama.cpp.

Оригиналы:Как запустить Gemma на сервере: сравниваем Ollama и llama.cpp

Anthropic тестируют кибервозможности GLM-5.3 и обнаруживают высокие риски

ИИ и агенты · Habr · 8/10

Anthropic опубликовали исследование, демонстрирующее опасные возможности открытой модели GLM-5.3 от китайской лаборатории Z.ai в области создания эксплойтов и взлома систем. На бенчмарке ExploitBench GLM-5.3 успешно создала полноценные эксплойты в 12% попыток (50 из 410), что близко к результатам закрытой модели Mythos Preview с 14% успехом, однако в отличие от конкурента веса GLM доступны для скачивания без ограничений. В отдельном эксперименте GLM-5.3-Flash самостоятельно разработала цепочку эксплуатации двух уязвимостей для ARM64 с обходом защиты PAC, потребовав восемь часов вычисления и 20 минут ручной работы исследователя за $20,40. Anthropic также продемонстрировали эффективность техники abliteration для ослабления отказов модели – средняя доля отказов снизилась с 95% до 6% при затратах $4400. Независимый центр CAISI при NIST назвал GLM-5.3 наиболее сильной открытой моделью в кибертестах, оценив её отставание от американских лидеров примерно в четыре месяца. Ранее Hugging Face использовали GLM-5.2 для анализа июльского вторжения агентов OpenAI и восстановили около 17 600 действий атакующих.

Выводы автора:

• Открытые языковые модели, включая GLM-5.3, демонстрируют значительные кибератакующие возможности, сопоставимые с закрытыми коммерческими моделями, что создаёт существенные риски безопасности
• Техники модификации моделей, такие как abliteration, позволяют существенно снизить защиты моделей от выполнения опасных задач, что требует пересмотра подходов к безопасности открытых ИИ-систем

GLM-5.3 создала полноценные эксплойты в 50 из 410 попыток, примерно 12% успеха, при этом её веса можно скачать без каких-либо ограничений в отличие от закрытых конкурентов

Оригиналы:Anthropic обеспокоены возможностями GLM-5.3

Robinhood Agents запущена: ИИ торговли, которая зарабатывает на сделках

ИИ и агенты · Linas from Linas's Newsletter · 8/10

Robinhood запустила Robinhood Agents — встроенного ИИ-торгового агента на HOOD Summit с более чем 150 000 открытых агентских аккаунтов. Компания перепродаёт токены OpenAI и Anthropic по публичной цене (OpenAI даже платит за использование GPT-6 Luna до конца года), зарабатывая не на самом ИИ, а на комиссиях от пользовательских сделок. Материал разбирает модель монетизации агентов, правила маркетплейса, которые переводят пользователей со своих Claude и ChatGPT на собственный агент, и уязвимость для трейдеров — кто несёт убытки при ошибке агента. Параллельно Meta запустила Muse для малого бизнеса (5 млн загрузок в США за 3 недели), которая теперь конкурирует с Claude for Small Business Anthropic: Muse имеет встроенный контекст бренда и объявлений для 200 млн бизнесов на платформах Meta, тогда как Claude требует ручного описания.

Выводы автора:

• Robinhood Agents зарабатывает компании на комиссиях с торгов, а не на перепродаже ИИ-токенов, что переворачивает традиционную модель монетизации LLM.
• Meta Muse для малого бизнеса имеет встроенное конкурентное преимущество благодаря доступу к данным 200 млн бизнесов на её платформах против ручного ввода информации в Claude.

Robinhood перепродаёт токены OpenAI и Anthropic по публичной цене, а компания зарабатывает на ваших сделках, не на ИИ.

Оригиналы:Robinhood Agents запущен на HOOD Summit · Глубокий анализ финансов Robinhood · Как превратить Claude в финансового аналитика без сна

Кризис качества в Big Tech: инженеры «аутсорсят» мышление LLM

ИИ и агенты · The Pragmatic Engineer · 8/10

Анонимный инженер из крупной техкомпании описал критическое состояние разработки, когда внедрение AI-инструментов (Claude Code) привело к деградации инженерной культуры и качества кода. По его словам, за полмесяца в новой компании он столкнулся с ситуацией, когда спецификации, код, тесты, документация — всё генерируется LLM-моделями, а люди просто нажимают кнопку для деплоя. Команда работает 12–13 часов в день, но только чтобы отправить что-то в production, несмотря на постоянные призывы менеджмента ускориться. Инженеры перестали разбираться в коде, не исправляют баги, не читают документацию и не думают самостоятельно — всё делают LLM. Автор отмечает, что эта проблема широко распространена от junior (L1) до senior (L7) уровней и вызывает психологическое выгорание из-за отсутствия чувства достижения и смысла в работе. Главное следствие: ориентация только на объём поставок в ущерб пониманию архитектуры и качеству системы.

Выводы автора:

• Чрезмерное внедрение LLM в разработку привело к тому, что инженеры перестали думать и понимать собственный код, что снижает качество продукта и вызывает выгорание.
• Культура максимально быстрого шипа вытеснила культуру качества и осознанной разработки, несмотря на отсутствие объективных причин для замедления.
• Проблема системна и затрагивает все уровни инженеров в крупных компаниях, где AI инструменты используются как замена человеческому мышлению, а не как помощь.

Никакого чувства победы. Никто не решает баги. На самом деле никто больше не думает. Всё делают LLM. Это сильно истощает душу.

Оригиналы:Пост инженера voxium в X о кризисе качества в Big Tech

Парадокс ИИ: почему компании внедряют инновацию впустую

ИИ и агенты · РЭШ · 8/10

Подкаст разбирает парадокс современного бизнеса: компании активно внедряют ИИ, отчитываются о выполнении планов, но реальная производительность не растёт, а часто падает. Гость – Максим Афанасьев, эксперт по ИИ-трансформации, возглавляющий финансовый сектор в Азии в одной из крупных американских компаний ИИ-индустрии и исследователь в Университете Сингапура. Он рассказывает о типичных ошибках внедрения: компании покупают ИИ-продукты без изменения бизнес-модели, что приводит к абсурдным результатам (сотрудники стали пить больше кофе вместо повышения продуктивности, или рост непройденных платежей вместо улучшения сервиса). ИИ кардинально отличается от прошлых инноваций тем, что при неправильном использовании увеличивает переговорную силу сотрудников и потребителей, а не только работодателей. Афанасьев также объясняет различия между азиатским и западным подходами: азиаты имеют более широкий горизонт принятия решений и быстрее адаптируют организационную структуру под требования ИИ. Ключевой вывод: всего около 200 человек в мире способны грамотно внедрить ИИ, и традиционная оргструктура просто не подходит для этого процесса.

Выводы автора:

• ИИ требует переосмысления бизнес-модели и организационной структуры, а не просто установки нового продукта, иначе это приводит к росту затрат и снижению эффективности
• ИИ кардинально отличается от всех предыдущих инноваций (паровой двигатель, электричество, интернет) тем, что усиливает переговорную позицию работников и потребителей, а не только владельцев капитала
• Компании часто внедряют ИИ для отчётности перед акционерами, а не для решения реальных бизнес-задач, что приводит к пустому выполнению плана без практического результата

Мы учимся быстрее корпораций – это главное, что нужно понимать о развитии ИИ и взаимодействии с ним.

Оригиналы:Выпуск подкаста на РЭШ

Агентский ИИ остаётся технологическим пузырём: барьер входа для бизнеса

ИИ и агенты · Substack · 7/10

Автор анализирует реальное состояние внедрения агентского ИИ и опровергает преувеличенные ожидания в LinkedIn. Несмотря на впечатляющие успехи в кодировании и технической работе, большинство бизнес-лидеров по-прежнему воспринимают ИИ только как продвинутый чатбот. По данным McKinsey, только 23% организаций используют агентские системы, и лишь 10% и менее масштабируют агентов в конкретных бизнес-функциях. Масштабирование ограничено только ИТ, данными, операциями обслуживания и разработкой ПО. Главная причина этого — техническое происхождение агентского ИИ: инструмент был создан в терминале командной строки, поэтому маркетологи, директоры по финансам и операционные лидеры не могут его использовать без технических навыков. Пока этот барьер входа не преодолён, агентский ИИ останется нишевой технологией в руках IT-специалистов и data-инженеров.

Выводы автора:

• Масштабирование агентского ИИ ограничено только технологическими функциями и составляет максимум 10% в организациях
• Основной барьер для расширения — техническая сложность: агенты требуют навыков работы с терминалом, недоступных большинству бизнес-лидеров
• Агентский ИИ останется технологическим пузырём до тех пор, пока не будут созданы интерфейсы, доступные для нетехнических пользователей

Агентский ИИ был создан в терминале, и большинство маркетологов, финансовых директоров и операционных лидеров никогда его не открывали.

Оригиналы:The Data & AI Ecosystem: агентский ИИ остаётся технологическим пузырём

Как компании переводят non-tech отделы на AI-инструменты

ИИ и агенты · The Pragmatic Engineer · 7/10

Материал рассказывает о тренде, когда технологические компании переводят non-engineering функции (финансы, HR, поддержка, маркетинг) на специализированные AI-инструменты, а не только инженеров. Автор рассказывает на примере своего брата – стартапа Craft Docs (30 человек, 15 инженеров), который создал Craft Agents для non-engineers и обнаружил, что LLM полезны не только для кода. Craft успешно применяет ИИ для автоматического триажа багов, обогащения данных, поддержки клиентов, создания веб-сайтов маркетингом без разработчиков, автоматизации в HR и финансах.

OpenAI тоже пошла по этому пути: в июне 2026 года non-engineering подразделения (финансы, рекрутмент, юридический) мигрировали на Codex (теперь ChatGPT Work). Автор подчёркивает, что это указывает на системное изменение рабочих процессов во всех функциях технологических компаний, а не только в разработке.

Выводы автора:

• Non-engineering функции в tech-компаниях теперь активно переходят на специализированные AI-инструменты, а не просто используют общие инструменты.
• Даже крупные компании вроде OpenAI массово мигрируют non-tech отделы (финансы, HR, легал, рекрутмент) на собственные AI-платформы.

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

Оригиналы:Глубокий разбор о повороте Craft Docs к AI для non-engineers · Внутри software-фабрики OpenAI

История выбора частоты дискретизации 44.1 кГц: от видеокассет к Audio CD

Разработка и архитектура · Habr · 8/10

Материал раскрывает историю происхождения стандартной частоты дискретизации 44 100 Гц, которая используется в Audio CD и до сих пор господствует в цифровом аудио. Классическое объяснение через теорему Котельникова (Найквиста–Шеннона) обосновывает только нижнюю границу частоты (больше 40 кГц), но не объясняет выбор именно 44 100 Гц. Автор прослеживает путь от PCM-адаптеров, разработанных в конце 1970-х годов японскими инженерами, которые кодировали цифровой звук в видеосигнал для записи на видеомагнитофоны.

Ключ к ответу лежит в телевизионной развёртке: в системе NTSC используется 60 полей по 262,5 строки в секунду, в PAL — 50 полей по 312,5 строки. При трёх отсчётах на канал в одной строке: 60 × 245 = 14 700 строк в секунду и 50 × 294 = 14 700 строк в секунду. Умножение на три отсчёта даёт одинаковую для обоих стандартов частоту 44 100 Гц.

Перебор всех возможных комбинаций показал, что 44 100 Гц — самая высокая частота из вариантов, обеспечивающих целое число строк в обоих стандартах, при которой видеомагнитофону остаётся достаточно строк гасящего интервала для служебных нужд (синхронизация, переключение головок). Так что лишние сто герц — результат компромисса между качеством звука и техническими ограничениями видеоаппаратуры семидесятых годов.

Выводы автора:

• Частота 44 100 Гц выбрана как максимально возможная, обеспечивающая одинаковое число строк данных в секунду как для американского NTSC (60 полей), так и для европейского PAL (50 полей) стандартов видеозаписи.
• При трёх отсчётах на канал в одной видеостроке формула 60 × 245 = 50 × 294 = 14 700 строк в секунду × 3 отсчёта = 44 100 Гц обеспечивает совместимость записей между разными видеостандартами.
• Выбор 44 100 Гц вместо теоретически возможных 45 000 Гц или 46 800 Гц был обусловлен необходимостью оставить видеомагнитофону достаточно служебных строк в гасящем интервале для синхронизации и переключения видеоголовок.

Одна частота на весь мир, одна и та же запись, которую можно сделать в Токио и смонтировать в Лондоне, и именно ради этого число строк подбирали так хитро.

Оригиналы:Частоту Audio CD выбрала видеокассета: откуда взялись ровно 44 100 Гц

Тестирование S3-совместимых хранилищ: поиск замены MinIO

Разработка и архитектура · Habr · 8/10

В конце 2025 года MinIO перестал выпускать Community Edition, удалил веб-консоль и прекратил публикацию Docker-образов, что вынудило крупные команды искать альтернативы. Россельхозбанк провел двухэтапное тестирование трех S3-совместимых решений: коммерческой российской разработки «Закрома», опенсорса RustFS и SeaweedFS. Первый этап проводился в standalone-режиме, второй — в кластерной конфигурации на объемах до 1,5 ТБ.

По функциональности все три кандидата поддерживают boto3, но различаются в реализации STS и шифровании: SeaweedFS покрывает все требования, RustFS имеет ограниченную поддержку STS, Закрома не поддерживает SSE-C и STS-токены. По производительности на чтение SeaweedFS обгоняет MinIO в 5–6 раз, RustFS в 2–4 раза, Закрома держится на уровне эталона. На запись все три отстают: SeaweedFS на 20–30%, RustFS и Закрома в 1,5–2,7 раза. Архитектурные различия Закромы (микросервисная с отдельным слоем управления метаданными) объясняют медленность в одноузловой конфигурации, но потенциально улучшают результаты в кластере. Для администрирования MinIO остается лучшим, RustFS максимально к нему приближен, SeaweedFS требует управления через Keycloak, Закрома имеет понятный интерфейс. Однозначного победителя нет: каждое решение оптимально для своих сценариев применения.

Выводы автора:

• При выборе замены MinIO необходимо учитывать архитектурные особенности: SeaweedFS лучше для чтение-интенсивных сценариев, RustFS дает баланс, Закрома требует кластерной конфигурации для раскрытия потенциала
• Лицензионная чистота и долгосрочная независимость от вендора критичны для крупных банков, что делает open-source решения с Apache 2.0 предпочтительнее проприетарных альтернатив
• Функциональные требования (STS, все методы шифрования) поддерживаются не во всех кандидатах, что может стать блокиратором для интеграции с корпоративной платформой аутентификации

MinIO нарушил негласное правило open source friendly и фактически залочил своих бесплатных пользователей

Оригиналы:Ищем замену MinIO в условиях импортозамещения: опыт тестирования трех S3-совместимых хранилищ

Компенсация задержки в сетевых шутерах: как обмануть игрока справедливо

Разработка и архитектура · Habr · 8/10

Статья разбирает классическую проблему сетевых игр: игрок видит, что попал, но сервер говорит промах. В сетевой игре существует временной разрыв между тем, что видит игрок на экране (интерполированное состояние с задержкой), и тем, что знает сервер (текущее состояние). Из-за пинга (например, 78 мс) и задержки интерполяции (100 мс) пакет с выстрелом приходит на сервер, когда противник уже передвинулся на 0,4 метра. Стандартное решение – сохранять на сервере снапшоты позиций всех объектов за последние ~1000 мс (64 тика при 60 Hz), занимающие примерно 1 MB памяти для 32 игроков. При обработке выстрела сервер откатывает состояние мира назад на время, вычисляемое по формуле: rewindTime = RTT/2 + interpolationDelay. Однако полная компенсация задержки создаёт новую несправедливость: игрок с большим пингом может попадать в противников, которые на сервере уже спрятались за укрытием. Автор показывает, что разработчики сознательно выбирают компромисс между ощущением справедливости для разных игроков, балансируя между честностью сервера и удовлетворённостью игроков.

Выводы автора:

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

Закрываем баг и пишем в тикете «works as designed», только вот игрок почему-то с этим не согласен.

Оригиналы:Попасть нельзя промахнуться

Деградация качества ПО из-за чрезмерной опоры на ИИ и пропуск QA

Разработка и архитектура · The Pragmatic Engineer · 8/10

Автор The Pragmatic Engineer фиксирует системное снижение качества программного обеспечения в начале года, связанное с чрезмерной опорой на ИИ-агентов и аутсорсингом принятия решений к нейросетям. На примере Uber Eats он показывает три явных багов в недавно выпущенной функции выбора добавок к заказу: валидация лимитов (ограничение в 999 единиц при физическом максимуме 6), проблемы с переполнением текста при локализации на голландский язык и функциональный баг при выборе базового ингредиента миски. Эти ошибки указывают на отсутствие надлежащего QA-тестирования и профессионального подхода команды. Однако автор считает, что инженерная работа не станет менее важной, а наоборот – потребуются новые навыки: глубокое понимание характеристик LLM, проектирование новых систем валидации кода из «агентных фабрик», а также замена дорогостоящих LLM-решений на детерминированный код, который сами LLM могут генерировать (например, автоматические линтеры вместо AI code review).

Выводы автора:

• Опора на ИИ-агентов без надлежащего QA приводит к выпуску продуктов с очевидными багами, как в примере Uber Eats с тремя критическими ошибками в одной функции.
• Инженеры должны научиться работать с нестабильностью LLM, понимать их ограничения (галлюцинации, дорогостоимость, медленность) и строить вокруг них новые системы валидации и детектирования дефектов.
• LLM могут быть использованы для генерации детерминированного кода (например, линтеров), который дешевле и надежнее, чем прямое использование нейросетей для code review на каждом PR.

Я предполагаю, что разработчики и PM, создавшие эту функцию, полностью «выпали из процесса», прекратили надлежащее QA и полагают, что агент позаботится обо всём.

Оригиналы:Качество ПО деградирует повсеместно · Серия необъяснимых сбоев в Spotify · Inspect — инструмент для валидации кода от компании Ramp

Почему управление состоянием — самая сложная задача в проектировании ПО

Разработка и архитектура · ByteByteGo · 7/10

Материал разбирает фундаментальную проблему в разработке ПО — управление состоянием (state), которое представляет собой информацию, сохраняемую системой и влияющую на её функциональность. Примеры состояния встречаются везде: отслеживание авторизованных пользователей на сайте, текущее содержимое в редакторе документов, список выполненных и ожидающих задач в фоновых процессах, записи в базах данных. Любой полезный софт должен управлять состоянием для выполнения своих функций, но сложность заключается в обеспечении корректности состояния при одновременных запросах, добавлении серверов, отказах оборудования и развёртывании обновлений. Распространённый совет "сделать приложение stateless" часто неправильно понимают — он означает не полное отсутствие состояния, а перемещение критического состояния из конкретных серверов приложений в другие хранилища, что позволяет легко заменять отдельные инстансы. Статья обещает разобрать, почему состояние настолько сложно, кто им владеет и что происходит при его недоступности, а также рассмотреть стратегии управления им.

Выводы автора:

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

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

Оригиналы:Why State is the Hardest Thing in Software Design

Когда ИИ пишет код: как меняется профессия разработчика

Разработка и архитектура · The Pragmatic Engineer · 7/10

Материал обсуждает радикальное изменение в разработке ПО, когда ИИ-агенты начинают генерировать большую часть кода, что уже происходит в техиндустрии. Автор предостерегает о наблюдаемом тренде на основе собственного опыта работы с Claude Opus и GPT-5, а также разговоров с опытными инженерами, которые раньше скептически относились к ИИ. Пять месяцев назад автор предсказал серьёзные последствия: более небрежный код, слабее внимание к инженерным практикам, снижение спроса на людей, которые только кодят без глубоких знаний, усиленное давление на junior-инженеров и возросшие требования к CS-образованию. Переходный период оказался сложным, поскольку разработчики теперь ответственны за большие объёмы сгенерированного ИИ кода, который уже работает в production. В тренде также появление non-engineer специалистов, работающих с ИИ-агентами.

Выводы автора:

• ИИ-агенты уже генерируют достаточно качественный код, и темпы изменения в индустрии исключительно высоки
• Разработчики берут на себя ответственность за сгенерированный ИИ код в production, не написав его сами
• Требования к инженерам меняются в сторону более глубоких CS-знаний и архитектурного мышления вместо написания кода вручную

Не более года прошло с момента рождения идеи Claude Code в голове Бориса Черни, а подобные инструменты уже меняют способ, которым пишется софтвер.

Оригиналы:The Pulse: создатель RoR вызвал новые дебаты о 'смерти кодинга вручную' · Inside OpenAI's software factory · Gergely Orosz

Информационная инфраструктура как основа государственного управления

Данные и аналитика · Modern Data 101 | Expert's Desk · 8/10

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

Выводы автора:

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

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

Оригиналы:Data Infrastructure as Civic Infrastructure: The Data Foundation of Governance

Защита номеров телефонов через Oblivious Pseudorandom Function

Кибербезопасность · Habr · 9/10

Статья описывает криптографическое решение задачи, поставленной новым российским законодательством: аудиовизуальные сервисы должны передавать исследовательским организациям стабильный идентификатор пользователя, связанный с его номером телефона, но так, чтобы номер остался защищённым. Простой подход с общим секретом для всех компаний неприемлем — утечка ключа у одного участника скомпрометирует всех. Авторы из Яндекса предложили использовать OPRF (Oblivious Pseudorandom Function) — криптографический протокол, позволяющий вычислять функцию на секретном ключе сервера без раскрытия самого ключа и исходных данных. В финальной схеме используются две независимые третьи стороны (Яндекс и другая крупная интернет-компания), каждая с собственным секретным ключом. Номер телефона преобразуется в точку на эллиптической кривой, затем ослепляется случайным скаляром и последовательно умножается на оба ключа (операции коммутируют). Компания снимает ослепление, и результат становится стабильным идентификатором. Ни один участник схемы не видит номера телефонов других компаний, а для полного перебора атакующему потребуются оба секретных ключа одновременно. Решение сохраняет детерминированность результата (один номер = один идентификатор), но избегает наличия единой точки отказа.

Выводы автора:

• Использование OPRF позволяет избежать необходимости в общем отраслевом секретном ключе, предотвращая критическую компрометацию при утечке в одной компании.
• Распределение функции обработки между двумя независимыми третьими сторонами требует скомпрометировать обе для полного офлайн-перебора номеров.
• Организационные ограничения (лимиты на объёмы запросов, смена ключей) необходимы, так как участник с законным доступом может попытаться использовать протокол как оракул для построения таблицы телефон → идентификатор.

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

Оригиналы:Как мы защищаем номера телефонов с помощью Oblivious Pseudorandom Function

PlayStation 5 взломана через браузер: доступ к ядру на прошивках 7.00–13.60

Кибербезопасность · Habr · 7/10

Разработчик Натан Фарго опубликовал открытую цепочку эксплойтов Relapse для PlayStation 5, работающую на прошивках версий 7.00–13.60 и обеспечивающую доступ к памяти ядра консоли. Эксплойт запускается через системный браузер PS5 и использует последовательно две группы уязвимостей: сначала ошибки в JavaScriptCore и системе копирования объектов дают доступ к памяти браузерного процесса. Затем через утечку адресов и ошибку use-after-free в функции ядра aio_multi_wait удаётся обойти рандомизацию памяти и получить чтение-запись к ядру системы благодаря тому, что ядро продолжает обращаться к уже освобождённому участку памяти, содержимое которого Relapse успевает подменить. После успешной атаки на сетевом порту 9021 открывается ELF-загрузчик, позволяющий передавать на консоль программы, модули, инструменты отладки и homebrew-приложения. Эксплойт не устанавливает альтернативную прошивку, поэтому после перезагрузки PS5 атаку нужно повторять. Исходный код доступен на GitHub; важно, что текущая версия ПО PS5 — 14.00, а эксплойт работает только до версии 13.60.

Выводы автора:

• Открытый эксплойт Relapse обходит защиту PS5 через браузер и даёт полный доступ к ядру консоли на прошивках версий 7.00–13.60
• Уязвимость использует две группы ошибок: в JavaScript-движке и функции ядра aio_multi_wait, что позволяет обойти рандомизацию памяти
• После успешной эксплуатации можно загружать пользовательское ПО и homebrew-приложения, но эффект теряется при перезагрузке консоли

Ядро продолжает обращаться к уже освобождённому участку памяти, содержимое которого успевает подменить Relapse

Оригиналы:PlayStation 5 взломали: эксплойт работает с версиями прошивок 7.00–13.60 и даёт доступ к памяти ядра консоли

МСФО 9: практическое руководство по расчёту ожидаемых кредитных убытков

Финтех и финансы · Вестник НАУФОР · 9/10

Статья подробно разбирает требования стандарта МСФО 9 к учёту кредитных убытков на примере практических алгоритмов расчёта ключевых риск-метрик. Стандарт, действующий с 2018 года, требует проактивного формирования резервов при существенном увеличении кредитного риска до наступления дефолта, вводя три «корзины обесценения»: необесцененные активы, активы с возросшим риском (стадия 2) и обесцененные активы. Основная формула для расчёта ожидаемых кредитных убытков (ECL) включает четыре компоненты: вероятность дефолта (PD), потери при дефолте (LGD), подверженную риску сумму (EAD) и коэффициент дисконтирования. Для индивидуальной оценки (корпоративные кредиты, проектное финансирование) применяется сценарный анализ с взвешиванием по вероятностям, для однородных портфелей (розничные кредиты) — упрощённые методики на основе исторических частот дефолтов. PD рассчитывается из ретроспективных данных с корректировкой на макроэкономические прогнозы (через коэффициент эластичности), LGD — из коэффициентов возврата при урегулировании проблемных активов с учётом временной стоимости денег, EAD — как все договорные денежные потоки плюс ожидаемые выборки по неиспользованным обязательствам.

Выводы автора:

• МСФО 9 требует проактивного учёта кредитного риска на стадии его существенного увеличения, до наступления дефолта, что усложняет оценку, но позволяет своевременно формировать резервы.
• Стандарт не предписывает готовых методик расчёта PD, LGD и EAD, оставляя финансовым организациям свободу выбора моделей при условии обоснования допущений статистикой или экспертным суждением.
• Для расчёта ожидаемых кредитных убытков необходимо корректировать исторические вероятности дефолта на ожидаемые макроэкономические условия и обязательно учитывать временную стоимость денег.

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

Оригиналы:Как не получить убытки: Динар Набиуллин о требованиях МСФО 9

Почему высокие ставки разрушают портфель кредитов малому бизнесу

Финтех и финансы · Б.О: Банки · 9/10

Статья разбирает критическую проблему кредитования МСП: компании заимствуют готовые розничные модели (PDL) микрофинансирования, которые неработают для бизнеса и приводят к краху портфелей. По данным Банка России, объём выдач МФО бизнесу в I квартале 2026 года составил 40 млрд рублей, но NPL 90+ в бизнес-сегменте вырос до 8,3%, а у коммерческих МФО — до 13%. Банковское кредитование МСП показывает схожие проблемы: при выдачах 6,6 трлн рублей портфель практически не растёт, погашения сопоставимы с новыми займами, просроченная задолженность достигла 655,8 млрд рублей и выросла на 11,6% с начала года. Авторы выявляют типичные ошибки: займы по ставке 100%+, короткие сроки, низкие суммы (50 тыс. вместо 10 млн), отсутствие понимания денежного цикла заёмщика, NPL 90+ свыше 40% в худших портфелях, конверсия одобрения в выдачу ниже 5%. Высокая цена вытесняет устойчивые компании, остаются лишь те, кому деньги нужны срочно без учёта стоимости. Структура ставок усугубляет проблему: 81,3% кредитов с плавающей ставкой привязаны к ключевой ставке, что создаёт непредсказуемость долговой нагрузки. Повторные займы часто маскируют реструктуризацию, а не развитие бизнеса. Вывод: кредитование МСП — отдельный бизнес, требующий понимания экономики клиента, денежных циклов и корректного продукт-маркета, а не слепого переноса розничных подходов.

Выводы автора:

• Высокие ставки выталкивают из портфеля устойчивых предпринимателей и оставляют рискованных заёмщиков, ухудшая качество портфеля независимо от скоринга
• Модели PDL-микрофинансирования несовместимы с кредитованием бизнеса: нужно учитывать денежные циклы, экономику заёмщика и реальные сроки возврата
• Заём должен соответствовать денежному циклу клиента и способству развитию, а не становиться способом обслуживания прежней задолженности

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

Оригиналы:Кредитовать малый бизнес нельзя дорого

Reuters раскрыл убытки Anthropic: 42 млрд за 2025 год при оценке в 2 трлн

Финтех и финансы · Habr · 8/10

Reuters получила доступ к фрагментам заявки Anthropic на IPO, которая раскрыла финансовое состояние компании. Anthropic оценивает себя в 2 триллиона долларов – сумму, которая может быть завышена, если сравнить её с капитализацией Ford (47 млрд), создавшей автомобильную промышленность и продавшей 2,2 млн машин в 2025. В 2025 году убытки Anthropic составили 42 млрда долларов, а операционные убытки выросли втрое: с 2,98 млрд в 2024 до 8,06 млрд в 2025. При этом компания планирует потратить 518 млрд долларов на облачную инфраструктуру в ближайшие годы. Серьёзный риск для инвесторов – четверть выручки компании поступает всего от двух крупных клиентов, которые не привязаны долгосрочными контрактами и могут в любой момент сократить или прекратить затраты. Anthropic не подала в суд на Reuters и отказалась комментировать публикацию, что косвенно подтверждает подлинность информации.

Выводы автора:

• Убытки Anthropic в 2025 году составили 42 млрда долларов при операционных убытках 8,06 млрд, растущих втрое год к году
• Концентрация выручки высокая: четверть доходов от двух клиентов без долгосрочных контрактов, создаёт риск резкого обнуления доходов
• Оценка компании в 2 триллиона долларов выглядит несоизмеримо высокой по сравнению с капитализацией компаний, создающих материальную стоимость

Четверть выручки обеспечивается двумя крупными клиентами, и эти клиенты не привязаны к компании долгосрочными контрактами, так что могут запросто снизить или вообще обнулить затраты.

Оригиналы:Reuters получила доступ к заявке Anthropic на IPO. Что внутри? Убытки

Государственные гарантии и микрокредиты: как поддержать рост МСП

Финтех и финансы · Б.О: Не банки · 7/10

Материал рассказывает о том, как в России работают финансовые инструменты господдержки для малого и среднего бизнеса через Национальную гарантийную систему. По состоянию на август 2026 года в стране зарегистрировано 6,7 млн субъектов МСП, лидируют Москва (877 тыс.), Московская область (470 тыс.) и Санкт-Петербург (384 тыс.). НГС объединяет 89 региональных гарантийных организаций с капиталом 108,4 млрд рублей и портфелем поручительств 331,5 млрд рублей, а также 139 государственных микрофинансовых организаций со средствами 95,9 млрд рублей. За первое полугодие 2026 года МСП получило 6,9 тыс. поручительств РГО на 44,9 млрд рублей, обеспечив доступ к 111,8 млрд рублей кредитов. В Санкт-Петербурге с начала программ выдано свыше 7 тыс. поручительств на 63,7 млрд рублей, привлекших 178,5 млрд рублей финансирования. В декабре 2025 года запущены «зонтичные» поручительства с максимумом 20 млн рублей на предпринимателя и упрощённой процедурой рассмотрения (решение за один день). ГМФО предоставляют займы до 5 млн рублей на срок до трёх лет под 3–12% годовых. В 2026 году планируется выдать займов на 48,8 млрд рублей. Основные заёмщики — производственные компании (38,7%), услуги (33%) и торговля (15,8%).

Выводы автора:

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

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

Оригиналы:Как финансовые инструменты господдержки обеспечивают структурную трансформацию сектора МСП

Как экономисты точнее промышленников предсказали влияние кризиса газа на Германию

Экономика · РЭШ · 9/10

Профессор Константин Егоров разбирает, почему в марте 2022 года экономисты дали более верный прогноз последствий нехватки российского газа для Германии, чем чиновники и бизнес. В начале кризиса правительство и BASF ожидали коллапса экономики, сравнимого с кризисом 1970-х годов из-за 55%-ной зависимости от российского газа. Экономисты же предсказали потери не более 3% ВВП при дефиците в 30%, что казалось опасным оптимизмом. Реальность подтвердила экономистов: при дефиците 20% немецкая экономика в 2022 году выросла на 1,8%, а в 2023 году упала всего на 0,3%, потери оказались близки к предсказанным 2-3%. Секрет успеха лежит в экономической теории — потери пропорциональны доле расходов на газ в ВВП. Экономисты правильно оценили, что доля газа не превысит 4% расходов (вместо ожидаемых 16-100%), полагаясь на сигналы рыночных цен, в которых уже заложена экспертиза всех участников. В итоге люди снизили потребление газа на 17%, бизнес — на 26%, а промышленный выпуск практически не упал, компании адаптировались через импорт и перераспределение производства.

Выводы автора:

• Рыночные цены содержат агрегированную информацию об альтернативах и гибкости экономики лучше, чем мнение отдельных экспертов или правительства.
• Экономические потери от дефицита ресурса пропорциональны доле его расходов в ВВП, а не абсолютному объёму нехватки, если существуют хоть какие-то альтернативы.
• Немецкая экономика продемонстрировала большую адаптивность, чем ожидалось: через снижение потребления, импорт и перераспределение производства удалось избежать коллапса.

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

Оригиналы:Один в поле не воин: откуда берутся прогнозы экономистов

Как B2B-продукту не стать заказной разработкой

Продукт и карьера · Habr · 8/10

Статья описывает систему работы с клиентскими запросами в крупном B2B-продукте Яга Задачи, которая предотвращает превращение продукта в набор кастомизаций. Авторский подход начинается с переквалификации клиентского запроса не как задачи в дорожную карту, а как сигнала рынка, требующего анализа. Перед внесением функции в основной продукт команда проверяет, повторяется ли запрос у других клиентов, упоминается ли в тендерах, есть ли у конкурентов. Если функция подтверждена рынком и соответствует стратегии (как SLA или дорожки на канбан-досках), она идёт в дорожную карту; если это уникальный процесс одной компании, ищут другие решения. Вместо накопления отдельных функций по запросам команда разрабатывает универсальные механизмы — например, скрипты на Groovy, которые позволяют заказчикам сами автоматизировать свои сценарии. Дорожная карта разделена на квоты: развитие продукта, клиентские доработки, технический долг, поддержка и крупные проекты. При масштабировании создаётся отдельная команда клиентских решений (Customer Engineering), которая берёт специфичные задачи, но строит их на стандартных точках расширения, не создавая отдельных версий продукта. Дополнительно внедряется экосистема плагинов: специфичная функция, нужная нескольким клиентам, не входит в ядро, а разрабатывается партнёром и продаётся через маркетплейс. Стоимость кастомизации не ограничивается разработкой: нужны тестирование, поддержка, совместимость с будущими версиями, что часто превышает первоначальную оценку.

Выводы автора:

• Клиентский запрос должен рассматриваться как сигнал рынка, а не автоматически попадать в дорожную карту — нужно проверить, повторяется ли эта потребность у других компаний.
• Вместо разработки отдельных функций по каждому запросу эффективнее создавать универсальные механизмы расширения (скрипты, API, интеграции), которые позволяют заказчикам сами решать свои специфичные задачи.
• Разделение дорожной карты на чётко определённые квоты (продукт, клиентские доработки, технический долг, поддержка) предотвращает незаметное заполнение всего плана маленькими кастомизациями.

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

Оригиналы:«Тут только одну фичу добавить…»: как не превратить B2B-продукт в заказную разработку

Что ищут топовые компании в главе продукта: мнение трёх рекрутеров

Продукт и карьера · Nikhyl Singhal (The Skip) · 8/10

Подкаст с ведущими рекрутерами в области управления продуктом (Andrew Abramson, Lindsay Keith, Caroline Horn) разбирает, как изменились требования к кандидатам на позицию chief product officer в 2026 году. Год назад компании ищили молодого основателя, готового работать 996 часов; сейчас спрос сместился в сторону опытных руководителей, которые остаются близки к разработке и инструментам — т.н. «executive builders». Ключевые требования: быть hands-on разработчиком, владеть техническими деталями, иметь позицию в офисе (Bay Area или New York), и демонстрировать не столько опыт основателя, сколько качества, которые он отражает — высокая инициативность, сильное суждение, комфорт с неопределённостью. Рекрутеры отмечают, что интервью теперь включают live working sessions с реальными задачами вместо контрольных прототипов, а спрос на позиции резко вырос: Caroline уже видела больше поисков в первой половине 2026, чем во всём 2025. Конкуренция за талант привела к взлёту компенсации — стартапы предлагают liquidity через tender offers и secondaries, конкурируя с крупными tech-компаниями и лабораториями. Режим 996 не исчез, но стал более честным — обе стороны обсуждают его на ранних этапах.

Выводы автора:

• Спрос сместился с молодых основателей на опытных руководителей-практиков, которые сочетают стратегическое мышление с hands-on разработкой и техническими знаниями.
• Интервью для топ-позиций теперь включают live working sessions с реальными задачами команды вместо контрольных заданий, что лучше имитирует день-за-днём работу.
• Компенсация и условия (включая режим работы и локацию) стали критическим фактором найма, и обе стороны ищут честного обсуждения ожиданий на ранних этапах.

Победная позиция — это то, что я называю executive builder: кто-то достаточно опытный, чтобы руководить функцией, но всё ещё близкий к работе, чтобы строить.

Оригиналы:Three Top Executive Recruiters on Where Product Management Is Going · Spotify · Apple Podcasts

Рабочая идентичность против идентичности на рабочем месте

Продукт и карьера · Substack · 8/10

Джон Катлер разбирает критическое различие между рабочей идентичностью (что ты делаешь) и идентичностью на конкретном рабочем месте (где ты это делаешь). В США медианный работник остаётся в компании всего 4 года, в технологиях — 2-3 года, а многие компании исчезают или превращаются в тени самих себя за 10-50 лет. Однако карьера в профессии может длиться десятилетия. Корпоративная политика «вовлечения сотрудников» часто пытается слить эти две идентичности в одну, используя лозунги типа «ты сделаешь лучшую работу здесь» или «мы строим что-то важное». Проблема: когда весь смысл твоей личности привязан к конкретной компании, ты становишься уязвим перед кризисом идентичности при её изменении. Вместо этого нужно развивать долгосрочный взгляд на свой профессиональный путь и ремесло в целом, не привязываясь к текущему работодателю, понимая, что компания — это временное соглашение для достижения экономической цели, а не часть личности.

Выводы автора:

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

Компания — это не человек. Это «временное соглашение между людьми, капиталом и институтами для достижения общей экономической цели».

Оригиналы:John Cutler: Рабочая идентичность vs. идентичность на рабочем месте

Подпольное архивирование кинофильмов: как фанаты спасают культурное наследие

Прочее · Habr · 7/10

Статья рассказывает о том, как энтузиасты восстанавливают и сохраняют классические фильмы, создавая неофициальные версии, когда студии намеренно изменяют оригиналы ради коммерческой выгоды. Автор приводит личный опыт восстановления «Хорошего, плохого, злого» Серджо Леоне, столкнувшись с халтурной реставрацией MGM, которая добавила недостающие сцены и переделала звук. Крупные киностудии часто переделывают фильмы из-за маркетинговых соображений или ревизионизма самих режиссёров — яркий пример Джордж Лукас со «Звёздными войнами». Независимые лейблы вроде Arrow и Kino пытаются сохранить исторически верные версии, но даже они сталкиваются с финансовыми и юридическими ограничениями. В то же время сообщества фанатов (Project 4K77, Despecialized) тратят годы на создание точных копий из различных источников, не ограниченные корпоративными дедлайнами и бюджетами. Благодаря любительским проектам спасены такие фильмы, как «Носферату» и «Наполеон», которые в ином случае были бы потеряны. Фанаты могут позволить себе создавать множество вариантов с разными аудиодорожками (до 100 ГБ данных), что невозможно для коммерческих релизов.

Выводы автора:

• Студии часто намеренно переделывают классические фильмы из-за маркетинговых целей или воли ревизионистских режиссёров, что делает оригиналы недоступными для историков и зрителей.
• Любительские сообщества обладают преимуществом перед профессионалами благодаря отсутствию временных, бюджетных и юридических ограничений, позволяя им сохранять исторически точные версии фильмов в лучшем качестве.
• Неофициальное архивирование фильмов стало жизненно важным инструментом культурного наследия, спасившим такие шедевры, как «Носферату» и «Наполеон», которые иначе были бы потеряны.

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

Оригиналы:Записки из подполья незаконного архивирования фильмов